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 (Amazon CloudWatch Events) 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 storing globally accessible images, as it’s primarily designed for low-latency access within a VPC rather than internet-accessible storage. Additionally, using EC2 instances for log processing adds unnecessary complexity, and this setup does not effectively leverage S3’s scalability and integration with CloudFront for static content delivery.
Amazon SNS is a pub/sub service and does not guarantee that messages will be processed in order. SNS alone lacks persistence, meaning messages could be lost if consumers are not available to receive them. Additionally, using Amazon EFS for processed image storage is inefficient compared to S3’s scalability, durability, and compatibility with CloudFront for web distribution.
Storing images in Amazon S3 and using an S3 event notification to trigger processing in an EC2 fleet via SQS ensures reliable messaging and processing order. SQS’s message persistence allows for scaling based on queue depth, while processed images can be stored back in S3. This setup is scalable and integrates efficiently with CloudFront for global content delivery.
Using a shared EBS volume mounted to multiple EC2 instances is complex and not ideal for high-availability setups. DynamoDB and EventBridge add unnecessary components for simply tracking processing status, while S3 offers better scalability and durability for storing image files. CloudFront cannot directly reference an EBS volume, making this setup inefficient for web content distribution.