What should a solutions architect do to meet these requirements?
Create a static website hosted in Amazon S3 that invokes AWS Lambda functions to resize the images and store the images in an Amazon S3 bucket.
Create a static website hosted in Amazon CloudFront that invokes AWS Step Functions to resize the images and store the images in an Amazon RDS database.
Create a dynamic website hosted on a web server that runs on an Amazon EC2 instance. Configure a process that runs on the EC2 instance to resize the images and store the images in an Amazon S3 bucket.
Create a dynamic website hosted on an automatically scaling Amazon Elastic Container Service (Amazon ECS) cluster that creates a resize job in Amazon Simple Queue Service (Amazon SQS). Set up an image-resizing program that runs on an Amazon EC2 instance to process the resize jobs.
Explanations:
This option leverages Amazon S3 for storing images and AWS Lambda for on-demand image resizing, which allows for automatic scaling based on traffic. This serverless architecture is highly available and cost-effective, making it suitable for unpredictable traffic patterns.
While Amazon CloudFront can distribute content, invoking AWS Step Functions for resizing images adds unnecessary complexity. Additionally, storing resized images in Amazon RDS is not optimal as RDS is a relational database and not intended for image storage.
This option relies on an EC2 instance for dynamic hosting and image processing, which does not scale automatically and can lead to availability issues. Managing the EC2 instance also requires more overhead compared to serverless solutions.
Although using Amazon ECS can provide scalability, this option introduces unnecessary complexity with the use of SQS for managing resize jobs. It also requires managing EC2 instances, which does not fully maximize the benefits of serverless architecture.