An on-premises order-processing platform uses a web front end (VMs), RabbitMQ for messaging, and a Kubernetes cluster for the containerized backend. The company wants to migrate to AWS without making major application changes and with the least operational overhead. Which architecture meets these constraints?

This option correctly addresses all requirements. Using an AMI for the web front end in an EC2 Auto Scaling group behind an ALB allows for direct migration ("lift and shift") with minimal changes and high availability. Replacing on-premises RabbitMQ with Amazon MQ (for RabbitMQ) offers a fully managed service that is protocol-compatible, minimizing application changes and operational overhead. Hosting the Kubernetes backend on Amazon EKS provides a managed Kubernetes control plane, reducing operational burden while maintaining the existing container orchestration platform. The Lambda/API Gateway option requires significant re-architecture of the web front end, violating the "no major application changes" constraint. Installing Kubernetes on EC2 instances for the backend increases operational overhead compared to managed EKS. Replacing RabbitMQ with Amazon SQS would require application code changes due to SQS's different messaging model (queue-based vs. broker-based), violating the "no major application changes" constraint.