What should a solutions architect recommend to meet these requirements?
Move the application to AWS Elastic Beanstalk. Configure load-based auto scaling and time-based scaling to handle scaling during lunch hours.
Move the application to Amazon Elastic Container Service (Amazon ECS). Create an AWS Lambda function to handle scaling during lunch hours.
Move the application to Amazon Elastic Container Service (Amazon ECS). Configure scheduled scaling for AWS Application Auto Scaling during lunch hours.
Move the application to AWS Elastic Beanstalk. Configure load-based auto scaling, and create an AWS Lambda function to handle scaling during lunch hours.
Explanations:
Moving the application to AWS Elastic Beanstalk allows for simplified deployment and management. Configuring load-based auto scaling automatically adjusts resources based on traffic patterns, which effectively addresses slow response times during peak lunch hours.
While moving to Amazon ECS can handle containerized applications well, using AWS Lambda for scaling does not directly apply to ECS scaling needs. ECS requires more configuration and management compared to Elastic Beanstalk, making this option less optimal for the given scenario.
Although Amazon ECS can be configured with scheduled scaling for application auto-scaling, this option is not as straightforward as using Elastic Beanstalk. It also lacks the dynamic scaling features based on real-time traffic, which is crucial for handling peak usage effectively.
While Elastic Beanstalk with load-based auto scaling is beneficial, combining it with a Lambda function for scaling adds unnecessary complexity for the scenario. The built-in auto-scaling features of Elastic Beanstalk are sufficient to manage traffic spikes without the need for additional Lambda functions.
I judge that the answer is:
Move the application to AWS Elastic Beanstalk. Configure load-based auto scaling and time-based scaling to handle scaling during lunch hours.