Una plataforma local de procesamiento de pedidos utiliza un front-end web (VMs), RabbitMQ para mensajería y un clúster de Kubernetes para el backend en contenedores. La empresa desea migrar a AWS sin realizar cambios importantes en la aplicación y con la menor sobrecarga operativa. ¿Qué arquitectura cumple con estas restricciones?

La opción correcta minimiza los cambios en la aplicación y la sobrecarga operativa. Crear una AMI de la VM web y usar Auto Scaling Group con ALB es una migración directa del front-end. Reemplazar RabbitMQ con Amazon MQ es ideal porque Amazon MQ es un servicio de intermediario de mensajes gestionado que soporta RabbitMQ, lo que permite una migración sin cambios significativos en el código. Alojar el backend en Amazon EKS es la forma nativa de AWS de ejecutar Kubernetes, manteniendo la arquitectura existente del backend. Las otras opciones son incorrectas porque: Usar AWS Lambda y API Gateway requeriría reescribir el front-end, lo cual es un cambio importante en la aplicación. Instalar Kubernetes en instancias EC2 para el backend aumentaría la sobrecarga operativa, ya que EKS es un servicio gestionado. Reemplazar RabbitMQ con Amazon SQS requeriría cambios en el código de la aplicación, ya que SQS tiene una API diferente a RabbitMQ.