Uma plataforma local de processamento de pedidos usa um front-end web (VMs), RabbitMQ para mensagens e um cluster Kubernetes para o back-end conteinerizado. A empresa deseja migrar para a AWS sem fazer grandes alterações no aplicativo e com a menor sobrecarga operacional. Qual arquitetura atende a essas restrições?

A opção correta minimiza alterações no aplicativo e a sobrecarga operacional. Criar uma AMI da VM do servidor web e executá-la em um grupo do EC2 Auto Scaling atrás de um Application Load Balancer é uma migração direta para o front-end. Substituir o RabbitMQ local pelo Amazon MQ é ideal, pois o Amazon MQ é um serviço de broker de mensagens gerenciado que suporta RabbitMQ, exigindo poucas ou nenhuma alteração de código. Hospedar o back-end no Amazon EKS (Elastic Kubernetes Service) permite que o cluster Kubernetes existente seja migrado com sobrecarga operacional mínima, pois o EKS gerencia o plano de controle. As opções incorretas apresentam desvantagens: Usar AWS Lambda e API Gateway para o front-end exigiria uma reescrita significativa do aplicativo web, o que viola a restrição de "sem grandes alterações". Instalar o Kubernetes em instâncias EC2 para o back-end aumentaria a sobrecarga operacional, pois o cliente seria responsável pelo gerenciamento do plano de controle do Kubernetes, diferentemente do EKS. Substituir o RabbitMQ pelo Amazon SQS (Simple Queue Service) exigiria alterações no código do aplicativo, pois o SQS é uma fila de mensagens, não um broker de mensagens compatível com RabbitMQ.