Which solution will meet these requirements with the LEAST development me?
Move the application tier to AWS Lambda functions in the existing VPC. Create an Application Load Balancer to distribute traffic across the Lambda functions. Use Amazon GuardDuty to scan the Lambda functions. Migrate the database to Amazon DocumentDB (with MongoDB compatibility.
Change the EC2 instance type to a smaller Graviton powered instance type. Use the existing AMI to create a launch template for an Auto Scaling group. Create an Application Load Balancer to distribute traffic across the instances in the Auto Scaling group. Set the Auto Scaling group to scale based on CPU utilization. Migrate the database to Amazon DynamoDB.
Move the application tier to containers by using Docker. Run the containers on Amazon Elastic Container Service (Amazon ECS) with EC2 instances. Create an Application Load Balancer to distribute traffic across the ECS cluster. Configure the ECS cluster to scale based on CPU utilization. Migrate the database to Amazon Neptune.
Create a now AMI that is configured with AWS Systems Manager Agent (SSM Agent). Use the new AMI to create a launch template for an Auto Scaling group. Use smaller instances in the Auto Scaling group. Create an Application Load Balancer to distribute traffic across the instances in the Auto Scaling group. Set the Auto Scaling group to scale based on CPU utilization. Migrate the database to Amazon Aurora MySQL.
Explanations:
AWS Lambda is designed for stateless, short-duration workloads and may not be ideal for handling an entire application tier that requires persistent connections. Additionally, DocumentDB and MongoDB are not suitable for MySQL workloads, making this solution inappropriate for the application requirements.
Changing to a smaller instance and using an Auto Scaling group won’t address the need for high availability or improve fault tolerance. Using DynamoDB, a NoSQL database, would not be a suitable replacement for MySQL, which is relational.
Moving to containers introduces complexity and requires significant development effort to refactor the application. ECS with EC2 instances also doesn’t offer the same level of automated scaling and management that Aurora or RDS does for MySQL. Neptune is a graph database, which is incompatible with the MySQL workload.
This solution enhances availability by using Auto Scaling and load balancing. The new AMI with the SSM Agent allows for easy patch management, reducing downtime. Migrating the database to Amazon Aurora MySQL provides a fully managed, highly available relational database solution that is compatible with MySQL.
I estimate that the answer is:
Create a now AMI that is configured with AWS Systems Manager Agent (SSM Agent). Use the new AMI to create a launch template for an Auto Scaling group. Use smaller instances in the Auto Scaling group. Create an Application Load Balancer to distribute traffic across the instances in the Auto Scaling group. Set the Auto Scaling group to scale based on CPU utilization. Migrate the database to Amazon Aurora MySQL.