AWS Certified Solutions Architect - Associate (SAA-C03)

Using AWS Lambda for processing provides automatic scaling, which allows the application to handle varying concurrency without having to manually provision or manage servers. Storing the photos in Amazon S3 is cost-effective and ensures virtually unlimited scalability. Retaining Amazon DynamoDB for the metadata is also ideal because DynamoDB offers consistent performance at any scale, especially when properly using features like auto scaling.

A solution that stores both data and images in DynamoDB alone can become costly and is not typically the recommended practice for storing large objects like photos. Simply increasing the number of Amazon EC2 instances and using Provisioned IOPS volumes can help with performance but does not natively handle highly variable traffic without additional services or elasticity configurations. Using services specifically for streaming and data ingestion is more aligned with continuous data ingestion scenarios, which does not match the real-time image processing requirements as effectively as a serverless approach with Lambda and S3.

In a real-world scenario, this strategy provides a scalable architecture for image processing. For instance, the Lambda function can be triggered each time an object is put into an S3 bucket. The function can then apply the desired transformations or frames to the uploaded photo. DynamoDB remains well-suited for storing metadata such as user preferences, timestamps, and relevant attributes about the photo frames.

In this scenario, a web-based application must read and store a large repository of text documents—totaling 900 TB. Amazon Simple Storage Service (Amazon S3) provides virtually unlimited scalability at a more cost-effective rate compared to alternatives, such as Amazon EBS or Amazon EFS. Employing an object-based storage solution is ideal for this workload because it can handle high throughput and deliver the necessary durability and availability. By contrast, a service like Amazon OpenSearch Service (Amazon Elasticsearch Service) is well-suited for search and analytics but would be prohibitively expensive to store all 900 TB of data long-term.

Using Amazon S3 also offers flexible storage classes (e.g., S3 Standard, S3 Intelligent-Tiering, or S3 Glacier) that can further optimize storage costs, especially for data that is accessed infrequently. This combination of scalability and tiered pricing makes Amazon S3 the most cost-effective choice for hosting and delivering large volumes of static data.

Example

A common approach is to serve static files—such as large text documents—from an S3 bucket using presigned URLs or by fronting S3 with Amazon CloudFront as a content delivery network to reduce latency and offload traffic from origin servers. The combination of S3, CloudFront, and EC2 ensures that the solution can auto scale when needed while minimizing overall costs.

Serving both static and dynamic content through a single Amazon CloudFront distribution—where static content is sourced from Amazon S3 and dynamic content from the Application Load Balancer (ALB)—is a best practice for optimizing performance and reducing latency. CloudFront’s global network of edge locations helps cache and accelerate the delivery of both types of content to end users. By configuring multiple origins (S3 for static assets and ALB for dynamic requests) within the same CloudFront distribution, you can use path-based routing to cache static assets while allowing pass-through of dynamic requests to the ALB. Amazon Route 53 can then provide DNS resolution, typically via an alias record, that points to the CloudFront distribution. This approach simplifies your architecture and reduces cost by eliminating the need to introduce AWS Global Accelerator for this scenario.

Using AWS Global Accelerator is valuable in specific use cases—such as non-HTTP/HTTPS traffic or multi-region active-active ALB deployments—but for a standard web application serving static and dynamic data over HTTP/HTTPS, a single CloudFront distribution is typically sufficient to provide edge caching, global reach, and lower latency. Creating multiple domain names or separate endpoints would overcomplicate the setup and does not offer significant benefits over CloudFront alone in this common web-serving pattern.

Example

Assume you have an S3 bucket named “my-app-static-content” and an ALB with a DNS name of “my-app-alb-123456789.us-east-1.elb.amazonaws.com.” You can configure CloudFront with an origin for the S3 bucket to handle requests for paths like “/static/” and another origin for the ALB to handle “/api/” or “/dynamic/.” Then, you create a behavior in CloudFront that routes “/static/” to the S3 origin and another behavior that routes all other paths to the ALB origin. Finally, use Route 53 to create an alias record pointing to the CloudFront distribution, for example, “app.example.com → d1234abcdef.cloudfront.net.”

The company seeks to run containerized applications in a manner that reduces both cost and operational overhead while still allowing the infrastructure to be occasionally disrupted. Because the applications are stateless, the workloads can be gracefully restarted when Spot Instances are reclaimed. A managed service for container orchestration, such as Amazon EKS, offloads many operational tasks like cluster control plane management and upgrades. Combining Amazon EKS with Spot Instances provides significant cost savings compared to On-Demand Instances, and the stateless nature of the application addresses the interruption risk associated with Spot Instances. This approach aligns well with cost optimization goals and allows the team to handle disruptions gracefully.

In practice, one might mix both Spot and On-Demand Instances in a managed node group to further optimize reliability and cost. The stateless design ensures service availability even when nodes scale in or out due to Spot interruptions. By offloading cluster management to AWS via a managed node group, the company avoids dealing with self-managed clusters, which can significantly reduce operational overhead.

Example

Consider a large-scale stateless web application that uses containers for microservices. By deploying these containers in Amazon EKS and configuring a managed node group to use Spot Instances, the team can benefit from Amazon EKS automatically managing node provisioning and updates. The deployment could reference a service like the Kubernetes Deployment controller to handle rolling updates, ensuring minimal downtime if a Spot Instance is reclaimed.

A minimal-overhead approach is to rely on Amazon S3’s built-in capabilities for automatically replicating objects to the analysis bucket, and then use Amazon EventBridge to fan out notifications to both an AWS Lambda function and Amazon SageMaker Pipelines. Configuring replication is simpler to manage and maintain than writing and running a custom AWS Lambda function for copying objects. Once objects are in the analysis S3 bucket, EventBridge can consume the “Object Created” events and forward them in parallel to Lambda and SageMaker Pipelines, removing the need for additional orchestration logic or separate triggers. This streamlines the entire data flow and avoids the complexity of custom code that polls or copies objects.

When the new files land in the analysis bucket via S3 replication, an EventBridge rule will detect the object creation event. The rule can invoke a Lambda function to perform the pattern-matching code, and can also trigger the workflow in SageMaker Pipelines using the appropriate API calls or a direct integration. This design uses managed services that handle scaling and high availability, ensuring consistent performance while requiring minimal operational overhead.

For example, consider a case where multiple teams are sending a growing volume of daily reports into the initial bucket. By configuring replication to the analysis bucket in the same or in a different Region, you ensure that new files arrive almost immediately in the bucket where your analytics processing occurs. Then EventBridge processes each object creation notification, triggering a Lambda function for real-time data validation or cleansing. In parallel, the same event can launch a SageMaker pipeline execution so that machine learning models can be retrained or produce new inferences.

Using Amazon CloudFront to serve both static and dynamic content is typically the most efficient solution for reducing global latency, because CloudFront has a wide network of edge locations that can quickly deliver content to end users. When CloudFront is configured to use an Application Load Balancer as its origin, clients benefit from optimized SSL/TLS termination at edge locations and persistent connections back to the origin. This ensures that not only the static assets but also the dynamic API responses are delivered as quickly as possible, no matter where the user is located.

By contrast, only caching static content in CloudFront and routing dynamic content directly from an origin can lead to slower responses for those dynamic requests. Deploying multiple Regions and relying solely on Route 53 latency or geolocation routing can be more complex and may require additional data synchronization or replication strategies. While multi-region designs can reduce latency, using CloudFront in front of a single-region ALB is often sufficient and simpler for many workloads.

Examples:

• If you have a news portal that needs to serve global users, CloudFront will cache static media at edge locations and accelerate API requests by reducing the round trip to a single origin.
• A personalized weather application that must retrieve real-time data benefits from CloudFront’s optimized path back to its ALB origin, ensuring fast and secure delivery of custom weather alerts.

Reconfiguring the target group in the development environment to have only one EC2 instance as a target is the most cost-effective solution among the choices. Development environments typically do not require the same level of high availability or performance as production environments. Reducing the number of running EC2 instances from a minimum of two to just one will directly cut the compute costs for the development environment significantly (potentially by 50% or more if more than two instances were running). This would involve adjusting the Auto Scaling group settings for the development environment to have a minimum, desired, and maximum capacity of one instance. While the general application design mentions 'at least two EC2 instances,' this is often a standard for production-like availability, which can be relaxed for a development environment to save costs.

Changing the ALB balancing algorithm to least outstanding requests is a performance optimization technique and does not directly reduce the number or size of EC2 instances, thus not impacting cost in the way intended.

Reducing the maximum number of EC2 instances in the development environment’s Auto Scaling group can prevent scaling up and save costs if the environment previously scaled beyond its typical needs. However, if the minimum and desired instance counts remain at two (to satisfy an 'at least two instances' policy), this option doesn't reduce the baseline running cost. Configuring for a single instance provides a more substantial baseline cost reduction for a typical development workload.

Reducing the size of the EC2 instances in both environments would reduce costs, but the question specifically asks about configuring the development environment. Furthermore, reducing instance sizes in the production environment might negatively impact its performance, especially since it's stated to have periods of high traffic. This option is less targeted and potentially detrimental to production.

A high-volume ingestion system can quickly overwhelm a Lambda function when it must handle data reception and database insertion simultaneously. By separating these responsibilities into two functions and introducing an Amazon SQS queue between them, the design becomes more scalable and resilient. One Lambda function can receive the incoming data through Amazon API Gateway and place it in the queue. The other Lambda function can then pull from the queue to load data into Amazon Aurora PostgreSQL asynchronously. This decoupled pattern prevents overloading the data-loading function and the database, because SQS will buffer incoming requests when volumes spike, protecting backend resources while still accepting incoming data.

Using a queue also eliminates the need to increase concurrency limits on a single function drastically. Instead, you can process messages at your own pace while effectively handling sudden bursts of traffic. This design minimizes configuration effort, because you are offloading the scaling complexity to a managed queue that handles incoming throughput automatically. Amazon SNS, while useful in some event-driven scenarios, would not offer the same level of control over concurrency and buffering, and rewriting the application to run on Amazon EC2 instances would add overhead. Similarly, changing the database engine to DynamoDB might require a fundamental rewrite or redesign of the data model, which is often impractical when an Aurora-compatible, relational database is needed.

Example:

Imagine a scenario where a web application receives user information in real time. The first function simply validates the incoming data and publishes each record to an SQS queue. A second function is configured with an SQS trigger to run automatically for each message (or batch of messages). This second function inserts records into the Aurora database. Even if hundreds of thousands of user records arrive within a short period, the queue naturally absorbs the spike. The Lambda function that processes the database inserts scales up to match the number of messages, but if it hits a limit or the database becomes a bottleneck, the messages remain in the queue, ensuring no data is lost.

A suitable configuration is to deliver VPC Flow Logs to Amazon S3 and then use an S3 Lifecycle policy to transition the logs from the S3 Standard storage class to S3 Standard-Infrequent Access (S3 Standard-IA) after 90 days. During the initial 90-day window, the logs remain in S3 Standard for frequent access. After that, because the logs are only accessed intermittently, S3 Standard-IA provides a more cost-effective storage class.

Delivering VPC Flow Logs to Amazon S3 is a common approach for compliance requirements and cost efficiency. Amazon Kinesis does not offer an economical long-term storage solution for logs. Amazon CloudWatch Logs does include retention settings but lacks a cheaper storage tier for intermittent access. AWS CloudTrail is intended to record API calls in AWS, not to capture network traffic patterns.

In a real-world scenario, administrators often configure a short retention time in S3 Standard (for logs heavily accessed by security teams) and then configure a lifecycle rule that transitions objects to a cheaper storage class (like S3 Standard-IA) once access patterns diminish. This pattern reduces storage costs while still allowing occasional queries.

For example, imagine a DevOps team writing Athena queries to analyze log data for the first 90 days. Subsequently, the volume of queries diminishes, so the logs can move to S3 Standard-IA without sacrificing availability for occasional lookups.

When creating a VPC for peering, the IP address ranges must not overlap. Since the development VPC has 192.168.0.0/24, it is not possible to use the same IP range for another peered VPC. Furthermore, AWS requires a CIDR block between /16 and /28 for a VPC. Both 192.168.1.0/32 and 10.0.1.0/32 are invalid because /32 is smaller than the minimum /28 subnet size. Therefore, the correct solution is 10.0.1.0/24, which provides a non-overlapping address range within the supported VPC CIDR limits.

In real-world scenarios, many companies choose a private IP space (for instance, 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) large enough to scale subnets without overlap.