Exam Tip
to generate reports without affecting the database performance = Use Read Replicas.
Explanation
Amazon RDS Read Replicas provide enhanced performance and durability for RDS database (DB) instances. They make it easy to elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads. You can create one or more replicas of a given source DB Instance and serve high-volume application read traffic from multiple copies of your data, thereby increasing aggregate read throughput. Read replicas can also be promoted when needed to become standalone DB instances. Read replicas are available in Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server as well as Amazon Aurora.
Reference
https://aws.amazon.com/rds/features/read-replicas/

Exam Tip
Static content on S3 = Use Cloudfront
Explanation
When you use Amazon S3 as an origin for your distribution, you place any objects that you want CloudFront to deliver in an Amazon S3 bucket. You can use any method that is supported by Amazon S3 to get your objects into Amazon S3, for example, the Amazon S3 console or API, or a third-party tool. You can create a hierarchy in your bucket to store the objects, just as you would with any other Amazon S3 bucket.
Using an existing Amazon S3 bucket as your CloudFront origin server doesn’t change the bucket in any way; you can still use it as you normally would to store and access Amazon S3 objects at the standard Amazon S3 price. You incur regular Amazon S3 charges for storing the objects in the bucket. For more information about the charges to use CloudFront
Reference
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html#concept_S3Origin

Exam Tip
shared storage between multiple EC2 instances = Use Amazon EFS
Explanation
Amazon EFS is designed to provide massively parallel shared access to thousands of Amazon EC2 instances, enabling your applications to achieve high levels of aggregate throughput and IOPS with consistent low latencies.
Amazon EFS is well suited to support a broad spectrum of use cases from home directories to business-critical applications. Customers can use EFS to lift-and-shift existing enterprise applications to the AWS Cloud. Other use cases include: big data analytics, web serving and content management, application development and testing, media and entertainment workflows, database backups, and container storage.
Reference
https://aws.amazon.com/efs/

Exam Tip
transactional + scalable database + high write consistency + linked tables = Amazon Aurora
Explanation
Amazon Aurora is a MySQL and PostgreSQL-compatible relational database built for the cloud, that combines the performance and availability of traditional enterprise databases with the simplicity and cost-effectiveness of open source databases.
Amazon Aurora is up to five times faster than standard MySQL databases and three times faster than standard PostgreSQL databases. It provides the security, availability, and reliability of commercial databases at 1/10th the cost. Amazon Aurora is fully managed by Amazon Relational Database Service (RDS), which automates time-consuming administration tasks like hardware provisioning, database setup, patching, and backups.
Reference
https://aws.amazon.com/rds/aurora/

Exam Tip
The presigned URLs are valid only for the specified duration.
Explanation
All objects by default are private. Only the object owner has permission to access these objects. However, the object owner can optionally share objects with others by creating a presigned URL, using their own security credentials, to grant time-limited permission to download the objects.
When you create a presigned URL for your object, you must provide your security credentials, specify a bucket name, an object key, specify the HTTP method (GET to download the object) and expiration date and time. The presigned URLs are valid only for the specified duration.
Anyone who receives the presigned URL can then access the object. For example, if you have a video in your bucket and both the bucket and the object are private, you can share the video with others by generating a presigned URL.
Reference
https://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html

Exam Tip
High Availability = Multi AZ
Explanation
When you add a subnet to your load balancer, Elastic Load Balancing creates a load balancer node in the Availability Zone. Load balancer nodes accept traffic from clients and forward requests to the healthy registered instances in one or more Availability Zones. For load balancers in a VPC, we recommend that you add one subnet per Availability Zone for at least two Availability Zones. This improves the availability of your load balancer. Note that you can modify the subnets for your load balancer at any time.
Select subnets from the same Availability Zones as your instances. If your load balancer is an Internet-facing load balancer, you must select public subnets in order for your back-end instances to receive traffic from the load balancer (even if the back-end instances are in private subnets). If your load balancer is an internal load balancer, we recommend that you select private subnets.

Reference
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-manage-subnets.html

Exam Tip
Keyword deliver content around the world so CloudFront is the content delivery feature.
Explanation
To deliver video on demand (VOD) streaming with CloudFront, use the following services:
a) Amazon S3 to store the content in its original format and to store the transcoded video.
b) An encoder (such as AWS Elemental MediaConvert) to transcode the video into streaming formats.
c) CloudFront to deliver the transcoded video to viewers.
To create a VOD solution with CloudFront:
a) Upload your content to an Amazon S3 bucket.
b) Transcode your content by using a MediaConvert job. The job converts your video into the formats required by the players that your viewers use. You can also use the job to create assets that vary in resolution and bitrate. These assets are used for adaptive bitrate (ABR) streaming, which adjusts the viewing quality depending on the viewer’s available bandwidth. MediaConvert stores the transcoded video in an S3 bucket.
c) Deliver your converted content by using a CloudFront distribution. Viewers can watch the content on any device, at any time.

Reference
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/on-demand-video.html

The simplest solution to open the firewall to access S3 buckets from the company network is:

Use Amazon CloudFront with S3 buckets as the origin and configure the CloudFront IP in the company network.

Here’s why:

• CloudFront acts as a proxy: CloudFront is a Content Delivery Network (CDN) service that sits in front of your S3 buckets.
• Reduced security risk: Instead of opening your S3 buckets directly to your company’s network, you only need to allow traffic from the known IP addresses of CloudFront. This significantly reduces the attack surface.
• Improved performance: CloudFront caches content at edge locations closer to your users, resulting in faster delivery times.

Other options and their considerations:

• Create Lambda function with an IAM role: While this approach can work, it introduces additional complexity. You’d need to manage Lambda functions and their associated IAM roles, which might not be necessary if the primary goal is simply to access S3.
• Create an IAM role with S3 bucket access permissions: This approach is less secure as it directly exposes your S3 buckets to your entire company network.
• Configure IP whitelisting in Amazon API Gateway: API Gateway is designed for APIs, not for general file storage access. This solution would be overly complex and less efficient for this use case.

By using CloudFront, you can securely and efficiently allow your legacy application to access S3 buckets while minimizing security risks and improving performance.

The correct solution is to use the ChangeMessageVisibility API call to increase the visibility timeout.

Here’s why:

• Visibility timeout: The visibility timeout determines how long a message will be invisible to other consumers after it’s received. If a message is not processed successfully within the visibility timeout, it will become visible again to other consumers.
• Duplicate processing: By increasing the visibility timeout, you can give the application more time to process the message before it becomes visible again. This can help prevent duplicate processing if the application encounters temporary failures or delays.
• Other options: Creating a new queue or using the ReceiveMessage API call with a wait time would not address the root cause of the duplicate records.

Reference
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html

Exam Tip
to recover deleted object from Amazon S3 bucket , you have to enable versioning.
Explanation
When you delete an object from a version-enabled bucket, Amazon S3 creates a delete marker for the object. The delete marker becomes the current version of the object, and the actual object becomes the previous version. With a delete marker, Amazon S3 responds to requests for the object as though the object was deleted. For example, if you send a GET request for the object, Amazon S3 returns an error.
Reference
https://aws.amazon.com/premiumsupport/knowledge-center/s3-undelete-configuration/

Exam Tip
AWS KMS is best option encrypt the data at rest in Amazon Redshift cluster
Explanation
In Amazon Redshift, you can enable database encryption for your clusters to help protect data at rest. When you enable encryption for a cluster, the data blocks and system metadata are encrypted for the cluster and its snapshots.
You can enable encryption when you launch your cluster, or you can modify an unencrypted cluster to use AWS Key Management Service (AWS KMS) encryption. To do so, you can use either an AWS-managed key or a customer-managed key (CMK). When you modify your cluster to enable KMS encryption, Amazon Redshift automatically migrates your data to a new encrypted cluster. Snapshots created from the encrypted cluster are also encrypted. You can also migrate an encrypted cluster to an unencrypted cluster by modifying the cluster and changing the Encrypt database option
Reference
https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-db-encryption.html

The simplest approach to achieve this requirement is:

Add NAT Gateway in the public subnet and add route to it from the private subnet.

Here’s why:

• NAT Gateway in Public Subnet: This allows the database server in the private subnet to access the internet for tasks like OS updates, security patches, and software downloads. The NAT Gateway acts as an intermediary, translating the private IP addresses of the database servers to public IP addresses when they initiate outbound connections.
• Route from Private to Public: This ensures that all internet-bound traffic originating from the database servers in the private subnet is routed through the NAT Gateway in the public subnet. This prevents direct inbound internet access to the database servers, enhancing security.

Key Considerations:

• Security Groups: Implement robust security groups on the database servers to further restrict inbound and outbound traffic based on specific ports, protocols, and IP addresses.
• Network ACLs: Use Network Access Control Lists (NACLs) to filter traffic at the subnet level. You can configure NACLs to allow outbound traffic for necessary services (like OS updates) while strictly denying all inbound traffic.
• Regular Security Audits: Conduct regular security audits and vulnerability assessments to identify and address any potential 1 security risks.
• By combining these measures, you can effectively allow the database server to access the internet for necessary updates while maintaining strong security and preventing direct internet access to the database.

Reference
https://aws.amazon.com/premiumsupport/knowledge-center/nat-gateway-vpc-private-subnet/

Explanations
The best steps to enhance this architecture and address scaling and performance issues are:

• Replace ELB classic load balancer and reverse proxy with ELB Application Load Balancer.
• Use auto scaling group with EC2 instances.

Explanation:

• ELB Application Load Balancer:
  • Offers advanced features like path-based routing, host-header based routing, and cookie-based routing, eliminating the need for a separate reverse proxy.
  • Provides better performance and scalability compared to Classic Load Balancers, especially for HTTP/HTTPS traffic.
• Auto Scaling Groups:
  • Automatically adjust the number of EC2 instances based on demand, ensuring optimal resource utilization and handling traffic spikes effectively.
  • Helps maintain application availability and performance during fluctuating workloads.

Why other options might not be the best fit:

• Replace ELB classic load balancer and reverse proxy with ELB Network Load Balancer: Network Load Balancers are primarily designed for Layer 4 (TCP, UDP) traffic. While they offer high performance, they might not be suitable for application-level routing and features provided by Application Load Balancers.
• Replace only ELB classic load balancer with ELB Application Load Balancer: While this would improve the load balancing capabilities, it wouldn’t address the need for dynamic scaling.
• Replace EC2 instances with c4.large instances: Upgrading instance types can improve performance, but it doesn’t provide a scalable solution for handling fluctuating traffic.

By implementing these changes, the architecture will be more scalable, resilient, and efficient in handling increasing traffic demands.

Reference
https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html
https://aws.amazon.com/blogs/aws/new-advanced-request-routing-for-aws-application-load-balancers/

Exam Tip
use CloudFront to serve a static website hosted on Amazon S3
Explanation
Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds, all within a developer-friendly environment. CloudFront is integrated with AWS – both physical locations that are directly connected to the AWS global infrastructure, as well as other AWS services. CloudFront works seamlessly with services including AWS Shield for DDoS mitigation, Amazon S3, Elastic Load Balancing or Amazon EC2 as origins for your applications, and Lambda@Edge to run custom code closer to customers’ users and to customize the user experience. Lastly, if you use AWS origins such as Amazon S3, Amazon EC2 or Elastic Load Balancing, you don’t pay for any data transferred between these services and CloudFront.
Reference
https://aws.amazon.com/cloudfront/

Exam Tip
You can use Route 53 health checking to configure active-active and active-passive failover configurations. You configure active-active failover using any routing policy (or combination of routing policies) other than failover, and you configure active-passive failover using the failover routing policy.
Explanation
Active-active failover
Use this failover configuration when you want all of your resources to be available the majority of the time. When a resource becomes unavailable, Route 53 can detect that it’s unhealthy and stop including it when responding to queries.
In active-active failover, all the records that have the same name, the same type (such as A or AAAA), and the same routing policy (such as weighted or latency) are active unless Route 53 considers them unhealthy. Route 53 can respond to a DNS query using any healthy record.
Active-passive failover
Use an active-passive failover configuration when you want a primary resource or group of resources to be available the majority of the time and you want a secondary resource or group of resources to be on standby in case all the primary resources become unavailable. When responding to queries, Route 53 includes only the healthy primary resources. If all the primary resources are unhealthy, Route 53 begins to include only the healthy secondary resources in response to DNS queries.
Reference
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-types.html

Exam Tip
SQS is used for decoupling + scaling microservices. Not the best use case for Kinesis.
Explanation
Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. SQS eliminates the complexity and overhead associated with managing and operating message oriented middleware, and empowers developers to focus on differentiating work. Using SQS, you can send, store, and receive messages between software components at any volume, without losing messages or requiring other services to be available. Get started with SQS in minutes using the AWS console, Command Line Interface or SDK of your choice, and three simple commands.
SQS offers two types of message queues. Standard queues offer maximum throughput, best-effort ordering, and at-least-once delivery. SQS FIFO queues are designed to guarantee that messages are processed exactly once, in the exact order that they are sent.
Reference
https://aws.amazon.com/sqs/

Amazon SQS (Simple Queue Service) would be the most suitable low-cost AWS service for this requirement. Here’s why:

• FIFO Queues: SQS offers FIFO (First-In, First-Out) queues specifically designed to process messages in the order they are sent. This ensures that orders are processed sequentially, preventing any out-of-order processing.
• High Throughput: SQS can handle a high volume of messages, with the ability to process thousands of messages per second depending on the queue type. 250 transactions per second should be well within its capacity.
• Reliability and Durability: SQS is highly reliable and durable, ensuring that messages are not lost even in case of system failures.
• Cost-Effective: SQS is a cost-effective option, especially for moderate message volumes. You only pay for the number of messages you send and receive.

Why other options might not be the best fit:

• Amazon SNS (Simple Notification Service): Primarily designed for fan-out delivery of messages to multiple subscribers. It’s not ideal for maintaining strict order of processing.
• Amazon MQ: A managed message broker, which is more complex and expensive than SQS for this use case. It’s often overkill for simpler messaging needs.
• Kinesis Streams: Designed for real-time data streaming and processing. While it can handle high throughput, it might be an overkill for this specific scenario and potentially more expensive than SQS.

In Summary:

SQS with FIFO queues provides a reliable, cost-effective, and straightforward solution for handling the order processing requirements between the order service and stock service.

Reference
https://aws.amazon.com/sqs/

Exam Tip
if you need to bypass web servers and store the files directly into S3 bucket , then use pre-signed URL.
Explanation
A presigned URL gives you access to the object identified in the URL, provided that the creator of the presigned URL has permissions to access that object. That is, if you receive a presigned URL to upload an object, you can upload the object only if the creator of the presigned URL has the necessary permissions to upload that object
All objects and buckets by default are private. The presigned URLs are useful if you want your user/customer to be able to upload a specific object to your bucket, but you don’t require them to have AWS security credentials or permissions. When you create a presigned URL, you must provide your security credentials and then specify a bucket name, an object key, an HTTP method (PUT for uploading objects), and an expiration date and time. The presigned URLs are valid only for the specified duration.
Reference
https://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html

Exam Tip
1. Use Amazon Lambda for pay-per-use compute instead of EC2.
2. Use CloudFront infront of S3 to cache images at the nodes. Hence reducing data transfer cost.
Explanation
Lambda@Edge lets you run Node.js and Python Lambda functions to customize content that CloudFront delivers, executing the functions in AWS locations closer to the viewer. The functions run in response to CloudFront events, without provisioning or managing servers. You can use Lambda functions to change CloudFront requests and responses at the following points:
After CloudFront receives a request from a viewer (viewer request)
Before CloudFront forwards the request to the origin (origin request)
After CloudFront receives the response from the origin (origin response)
Before CloudFront forwards the response to the viewer (viewer response)

Reference
https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html

Exam Tip
you can use AWS CloudTrail to monitor, and retain account activity related to actions across AWS multi Regions
Explanation
AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your AWS infrastructure. CloudTrail provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command line tools, and other AWS services. This event history simplifies security analysis, resource change tracking, and troubleshooting. In addition, you can use CloudTrail to detect unusual activity in your AWS accounts. These capabilities help simplify operational analysis and troubleshooting.
Reference
https://aws.amazon.com/cloudtrail/

Exam Tip
low latency and high throughput= Use Cluster placement groups
Explanation
Cluster placement groups
A cluster placement group is a logical grouping of instances within a single Availability Zone. A cluster placement group can span peered VPCs in the same Region. Instances in the same cluster placement group enjoy a higher per-flow throughput limit of up to 10 Gbps for TCP/IP traffic and are placed in the same high-bisection bandwidth segment of the network.
The following image shows instances that are placed into a cluster placement group.

Cluster placement groups are recommended for applications that benefit from low network latency, high network throughput, or both. They are also recommended when the majority of the network traffic is between the instances in the group. To provide the lowest latency and the highest packet-per-second network performance for your placement group, choose an instance type that supports enhanced networking. For more information, see Enhanced Networking.
We recommend that you launch your instances in the following way:
Use a single launch request to launch the number of instances that you need in the placement group.
Use the same instance type for all instances in the placement group.
If you try to add more instances to the placement group later, or if you try to launch more than one instance type in the placement group, you increase your chances of getting an insufficient capacity error.
If you stop an instance in a placement group and then start it again, it still runs in the placement group. However, the start fails if there isn’t enough capacity for the instance.
If you receive a capacity error when launching an instance in a placement group that already has running instances, stop and start all of the instances in the placement group, and try the launch again. Starting the instances may migrate them to hardware that has capacity for all of the requested instances.
Partition placement groups
Partition placement groups help reduce the likelihood of correlated hardware failures for your application. When using partition placement groups, Amazon EC2 divides each group into logical segments called partitions. Amazon EC2 ensures that each partition within a placement group has its own set of racks. Each rack has its own network and power source. No two partitions within a placement group share the same racks, allowing you to isolate the impact of hardware failure within your application.
The following image is a simple visual representation of a partition placement group in a single Availability Zone. It shows instances that are placed into a partition placement group with three partitions—Partition 1, Partition 2, and Partition 3. Each partition comprises multiple instances. The instances in a partition do not share racks with the instances in the other partitions, allowing you to contain the impact of a single hardware failure to only the associated partition.

Partition placement groups can be used to deploy large distributed and replicated workloads, such as HDFS, HBase, and Cassandra, across distinct racks. When you launch instances into a partition placement group, Amazon EC2 tries to distribute the instances evenly across the number of partitions that you specify. You can also launch instances into a specific partition to have more control over where the instances are placed.
A partition placement group can have partitions in multiple Availability Zones in the same Region. A partition placement group can have a maximum of seven partitions per Availability Zone. The number of instances that can be launched into a partition placement group is limited only by the limits of your account.
In addition, partition placement groups offer visibility into the partitions — you can see which instances are in which partitions. You can share this information with topology-aware applications, such as HDFS, HBase, and Cassandra. These applications use this information to make intelligent data replication decisions for increasing data availability and durability.
If you start or launch an instance in a partition placement group and there is insufficient unique hardware to fulfill the request, the request fails. Amazon EC2 makes more distinct hardware available over time, so you can try your request again later.
Spread placement groups
A spread placement group is a group of instances that are each placed on distinct racks, with each rack having its own network and power source.
The following image shows seven instances in a single Availability Zone that are placed into a spread placement group. The seven instances are placed on seven different racks.

Spread placement groups are recommended for applications that have a small number of critical instances that should be kept separate from each other. Launching instances in a spread placement group reduces the risk of simultaneous failures that might occur when instances share the same racks. Spread placement groups provide access to distinct racks, and are therefore suitable for mixing instance types or launching instances over time.
A spread placement group can span multiple Availability Zones in the same Region. You can have a maximum of seven running instances per Availability Zone per group.
If you start or launch an instance in a spread placement group and there is insufficient unique hardware to fulfill the request, the request fails. Amazon EC2 makes more distinct hardware available over time, so you can try your request again later.
Reference
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html

Exam Tip
SQS = decouple the web application from the database

Explanation
Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. SQS eliminates the complexity and overhead associated with managing and operating message oriented middleware, and empowers developers to focus on differentiating work. Using SQS, you can send, store, and receive messages between software components at any volume, without losing messages or requiring other services to be available. Get started with SQS in minutes using the AWS console, Command Line Interface or SDK of your choice, and three simple commands.

Reference
https://aws.amazon.com/sqs/

Exam Tip
VPC flow logs records the IP traffics in subnet level
Explanation
VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data can be published to Amazon CloudWatch Logs or Amazon S3. After you’ve created a flow log, you can retrieve and view its data in the chosen destination.
Flow logs can help you with a number of tasks, such as:
a) Diagnosing overly restrictive security group rules
b) Monitoring the traffic that is reaching your instance
c) Determining the direction of the traffic to and from the network interfaces

Reference
https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html

Exam Tip
key-value store + changeable schema = Amazon DynamoDB
Explanation
Amazon DynamoDB is a key-value and document database that delivers single-digit millisecond performance at any scale. It’s a fully managed, multiregion, multimaster, durable database with built-in security, backup and restore, and in-memory caching for internet-scale applications. DynamoDB can handle more than 10 trillion requests per day and can support peaks of more than 20 million requests per second.
Reference
https://aws.amazon.com/blogs/aws/amazon-dynamodb-internet-scale-data-storage-the-nosql-way/

Aurora Replicas are independent endpoints in an Aurora DB cluster, best used for scaling read operations and increasing availability. Up to 15 Aurora Replicas can be distributed across the Availability Zones that a DB cluster spans within an AWS Region. The DB cluster volume is made up of multiple copies of the data for the DB cluster. However, the data in the cluster volume is represented as a single, logical volume to the primary instance and to Aurora Replicas in the DB cluster.
As a result, all Aurora Replicas return the same data for query results with minimal replica lag—usually much less than 100 milliseconds after the primary instance has written an update. Replica lag varies depending on the rate of database change. That is, during periods where a large amount of write operations occur for the database, you might see an increase in replica lag.
Aurora Replicas work well for read scaling because they are fully dedicated to read operations on your cluster volume. Write operations are managed by the primary instance. Because the cluster volume is shared among all DB instances in your DB cluster, minimal additional work is required to replicate a copy of the data for each Aurora Replica.
To increase availability, you can use Aurora Replicas as failover targets. That is, if the primary instance fails, an Aurora Replica is promoted to the primary instance. There is a brief interruption during which read and write requests made to the primary instance fail with an exception, and the Aurora Replicas are rebooted. If your Aurora DB cluster doesn’t include any Aurora Replicas, then your DB cluster will be unavailable for the duration it takes your DB instance to recover from the failure event. However, promoting an Aurora Replica is much faster than recreating the primary instance. For high-availability scenarios, we recommend that you create one or more Aurora Replicas. These should be of the same DB instance class as the primary instance and in different Availability Zones for your Aurora DB cluster. For more information on Aurora Replicas as failover targets,
Reference
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html