Una empresa ejecuta una aplicación de comercio electrónico donde cada nuevo pedido se publica en una cola de RabbitMQ en una instancia de Amazon EC2 en una única zona de disponibilidad. Una instancia de EC2 separada procesa los mensajes y almacena los detalles en una base de datos PostgreSQL en otra instancia de EC2. Todas las instancias de EC2 están en la misma zona de disponibilidad. La empresa desea la mayor disponibilidad con la menor sobrecarga operativa. ¿Qué debe hacer un arquitecto de soluciones?

La opción correcta mejora la disponibilidad y reduce la sobrecarga operativa. Migrar a Amazon MQ para RabbitMQ ofrece alta disponibilidad con un par activo/en espera gestionado por AWS, eliminando la gestión de EC2 para RabbitMQ. Un grupo de Auto Scaling Multi-AZ para la aplicación garantiza que la aplicación esté disponible en varias zonas de disponibilidad y pueda escalar automáticamente. Migrar a Amazon RDS for PostgreSQL Multi-AZ proporciona alta disponibilidad y conmutación por error automática para la base de datos, con AWS gestionando la replicación y los parches. Las opciones incorrectas no optimizan la disponibilidad o la sobrecarga operativa. La primera opción mantiene la base de datos en EC2, lo que aumenta la sobrecarga operativa para la alta disponibilidad. Las otras dos opciones proponen grupos de Auto Scaling para RabbitMQ en EC2, lo cual es menos eficiente y más complejo de gestionar que Amazon MQ.