A monolithic REST API for a mobile app runs on five EC2 instances in public subnets and is fronted by a Route 53 multivalue answer record that points directly to the instances' IPs. Sudden large traffic spikes are overwhelming the app. Which solution will allow the application to scale to the new, variable load with the LEAST operational overhead?

The correct solution is to deploy an Application Load Balancer (ALB) in front of the API, move EC2 instances to private subnets, register them as ALB targets, and update Route 53 to point to the ALB. ALBs automatically distribute incoming traffic across multiple targets, providing high availability and scalability without manual intervention. Moving instances to private subnets enhances security by removing them from direct public access. This approach offers the least operational overhead for scaling EC2-based applications. Breaking the API into Lambda functions (serverless) is a significant architectural change, not just a scaling solution, and involves considerable refactoring and operational overhead. Containerizing the API on EKS also introduces significant operational complexity with Kubernetes management. While using an Auto Scaling group is good for scaling, manually updating Route 53 with a Lambda function for every scaling event is complex and less efficient than using an ALB, which inherently handles target registration and de-registration.