A company migrated an application to AWS. The app runs on two EC2 instances behind an Application Load Balancer (ALB). The MySQL database runs on a separate EC2 instance and is read-heavy. Each EC2 instance stores frequently updated static content on its attached Amazon EBS volume; the static content must be copied to each EBS volume when updated. Load varies throughout the day, and during peak times the application cannot serve all requests. Tracing shows the database cannot handle peak read traffic. Which solution will increase the application's reliability?

The correct solution addresses all identified bottlenecks and improves reliability. Containerizing the application with Amazon ECS Fargate provides scalability and simplifies management, while Application Auto Scaling ensures the application can handle varying loads. Using Amazon EFS for static content centralizes storage, eliminating the need to copy content to individual EBS volumes and ensuring consistency across instances. Migrating to Amazon Aurora MySQL Serverless v2 with a reader instance provides a highly scalable, fault-tolerant, and read-optimized database solution, directly addressing the peak read traffic issue. The other options are less effective: Migrating to Lambda functions and reading from a single EBS volume is not a standard or efficient pattern for Lambda, as Lambda functions are stateless and EBS volumes are not directly mountable by Lambda. Migrating to Step Functions is not suitable for a general web application as Step Functions are designed for orchestrating workflows, not serving web requests. Using a single new EBS volume mounted on an ECS cluster for static content is problematic for multiple Fargate tasks, as EBS volumes can typically only be attached to a single EC2 instance at a time, making it unsuitable for shared access across multiple containers/tasks.