Which solution will improve the reliability of the application?
Migrate the application to a set of AWS Lambda functions. Set the Lambda functions as targets for the ALB. Create a new single EBS volume for the static content. Configure the Lambda functions to read from the new EBS volume. Migrate the database to an Amazon RDS for MySQL Multi-AZ DB cluster.
Migrate the application to a set of AWS Step Functions state machines. Set the state machines as targets for the ALCreate an Amazon Elastic File System (Amazon EFS) file system for the static content. Configure the state machines to read from the EFS file system. Migrate the database to Amazon Aurora MySQL Serverless v2 with a reader DB instance.
Containerize the application. Migrate the application to an Amazon Elastic Container Service (Amazon ECS) cluster. Use the AWS Fargate launch type for the tasks that host the application. Create a new single EBS volume for the static content. Mount the new EBS volume on the ECS cluster. Configure AWS Application Auto Scaling on the ECS cluster. Set the ECS service as a target for the ALB. Migrate the database to an Amazon RDS for MySQL Multi-AZ DB cluster.
Containerize the application. Migrate the application to an Amazon Elastic Container Service (Amazon ECS) cluster. Use the AWS Fargate launch type for the tasks that host the application. Create an Amazon Elastic File System (Amazon EFS) file system for the static content. Mount the EFS file system to each container. Configure AWS Application Auto Scaling on the ECS cluster. Set the ECS service as a target for the ALB. Migrate the database to Amazon Aurora MySQL Serverless v2 with a reader DB instance.
Explanations:
While migrating to AWS Lambda can improve scalability and cost-effectiveness, Lambda functions are not well-suited for applications that require stateful connections like databases. Also, relying on a single EBS volume for static content would create a bottleneck, and Amazon RDS for MySQL Multi-AZ would help with reliability but may not fully resolve read load issues without read replicas.
AWS Step Functions are not designed to directly serve web requests or handle high-frequency traffic. Although migrating to Amazon Aurora MySQL Serverless v2 with a reader DB instance would improve read performance, using state machines may introduce unnecessary complexity for the application. EFS is a suitable option for static content but does not address the application’s scalability needs effectively.
Containerizing the application and using ECS with Fargate can enhance scalability, but relying on a single EBS volume for static content can lead to performance issues. Additionally, Amazon RDS for MySQL Multi-AZ may improve reliability, but without read replicas, it does not resolve the read-heavy load during peak times.
This option effectively addresses the application’s scalability and reliability issues. Containerizing the application with ECS and Fargate allows for better resource management and scaling. Using Amazon EFS for static content ensures that all containers have consistent access to frequently updated files. Migrating to Amazon Aurora MySQL Serverless v2 with a reader DB instance significantly improves read performance during peak loads.
I measure that the answer is:
Containerize the application. Migrate the application to an Amazon Elastic Container Service (Amazon ECS) cluster. Use the AWS Fargate launch type for the tasks that host the application. Create an Amazon Elastic File System (Amazon EFS) file system for the static content. Mount the EFS file system to each container. Configure AWS Application Auto Scaling on the ECS cluster. Set the ECS service as a target for the ALB. Migrate the database to Amazon Aurora MySQL Serverless v2 with a reader DB instance.