Which design should a solutions architect implement?
Store the uploaded images in Amazon Elastic File System (Amazon EFS). Send application log information about each image to Amazon CloudWatch Logs. Create a fleet of Amazon EC2 instances that use CloudWatch Logs to determine which images need to be processed. Place processed images in another directory in Amazon EFS. Enable Amazon CloudFront and configure the origin to be the one of the EC2 instances in the fleet.
Store the uploaded images in an Amazon S3 bucket and configure an S3 bucket event notification to send a message to Amazon Simple Notification Service (Amazon SNS). Create a fleet of Amazon EC2 instances behind an Application Load Balancer (ALB) to pull messages from Amazon SNS to process the images and place them in Amazon Elastic File System (Amazon EFS). Use Amazon CloudWatch metrics for the SNS message volume to scale out EC2 instances. Enable Amazon CloudFront and configure the origin to be the ALB in front of the EC2 instances.
Store the uploaded images in an Amazon S3 bucket and configure an S3 bucket event notification to send a message to the Amazon Simple Queue Service (Amazon SQS) queue. Create a fleet of Amazon EC2 instances to pull messages from the SQS queue to process the images and place them in another S3 bucket. Use Amazon CloudWatch metrics for queue depth to scale out EC2 instances. Enable Amazon CloudFront and configure the origin to be the S3 bucket that contains the processed images.
Store the uploaded images on a shared Amazon Elastic Block Store (Amazon EBS) volume mounted to a fleet of Amazon EC2 Spot instances. Create an Amazon DynamoDB table that contains information about each uploaded image and whether it has been processed. Use an Amazon EventBridge rule to scale out EC2 instances. Enable Amazon CloudFront and configure the origin to reference an Elastic Load Balancer in front of the fleet of EC2 instances.
Explanations:
Amazon EFS is not suitable for serving a large number of images for a web service. It lacks the scalability, durability, and performance characteristics needed for such an application. Using EC2 instances to process images from CloudWatch Logs is also inefficient and would introduce unnecessary complexity and overhead.
While using S3 for storage and SNS for notifications is a good approach, storing processed images in EFS introduces scalability and availability issues. EFS is designed for file storage, not for large-scale content delivery. The use of CloudFront with EC2 instances behind an ALB is also suboptimal for static image delivery.
Storing images in S3 provides a highly scalable and durable storage solution. Using SQS for decoupling the image processing workflow and scaling EC2 instances based on queue depth is efficient. CloudFront configured with an S3 origin is ideal for serving processed images globally with low latency.
EBS volumes are not shared across EC2 instances, making this solution unsuitable for scaling. Additionally, using Spot instances can lead to instability, and DynamoDB for image metadata isn’t ideal for the use case. EventBridge is not the most appropriate tool to scale EC2 instances based on workload.
In my experience, the answer is:
Store the uploaded images in an Amazon S3 bucket and configure an S3 bucket event notification to send a message to the Amazon Simple Queue Service (Amazon SQS) queue. Create a fleet of Amazon EC2 instances to pull messages from the SQS queue to process the images and place them in another S3 bucket. Use Amazon CloudWatch metrics for queue depth to scale out EC2 instances. Enable Amazon CloudFront and configure the origin to be the S3 bucket that contains the processed images.