Which solution will meet these requirements with the LEAST operational overhead?
Create an AMI of the web server VM. Create an Amazon EC2 Auto Scaling group that uses the AMI and an Application Load Balancer. Set up Amazon MQ to replace the on-premises messaging queue. Configure Amazon Elastic Kubernetes Service (Amazon EKS) to host the order-processing backend.
Create a custom AWS Lambda runtime to mimic the web server environment. Create an Amazon API Gateway API to replace the front-end web servers. Set up Amazon MQ to replace the on-premises messaging queue. Configure Amazon Elastic Kubernetes Service (Amazon EKS) to host the order-processing backend.
Create an AMI of the web server VM. Create an Amazon EC2 Auto Scaling group that uses the AMI and an Application Load Balancer. Set up Amazon MQ to replace the on-premises messaging queue. Install Kuhernetes on a fleet of different EC2 instances to host the order-processing backend.
Create an AMI of the web server VM Create an Amazon EC2 Auto Scaling group that uses the AMI and an Application Load Balancer. Set up an Amazon Simple Queue Service (Amazon SQS) queue to replace the on-premises messaging queue, Configure Amazon Elastic Kubernetes Service (Amazon EKS) to host the order-processing backend.
Explanations:
This option maintains the existing web server VM by creating an AMI and using an EC2 Auto Scaling group for scalability and reliability. It replaces RabbitMQ with Amazon MQ, a fully managed service, reducing operational overhead. The use of Amazon EKS for the backend allows for efficient container orchestration with minimal changes to the existing architecture.
While this option introduces a serverless approach using AWS Lambda and API Gateway, it requires significant changes to the web front end, which contradicts the requirement of making no major changes to the application. It also complicates the setup by requiring a custom runtime.
This option involves installing Kubernetes on EC2 instances, which adds complexity and operational overhead compared to using Amazon EKS. While it does use an AMI for the web server, the need to manage the Kubernetes installation on EC2 instances increases the management burden.
Although this option correctly creates an AMI and uses an EC2 Auto Scaling group, it suggests using Amazon SQS instead of Amazon MQ. SQS is a different type of messaging service that may require significant changes in the backend communication architecture, which does not align with the goal of minimizing changes. Additionally, operational management of SQS might not integrate as smoothly as Amazon MQ with the existing RabbitMQ setup.
As far as I can tell, the answer is:
Create an AMI of the web server VM. Create an Amazon EC2 Auto Scaling group that uses the AMI and an Application Load Balancer. Set up Amazon MQ to replace the on-premises messaging queue. Configure Amazon Elastic Kubernetes Service (Amazon EKS) to host the order-processing backend.