Uma empresa executa um aplicativo de e-commerce onde cada novo pedido é publicado em uma fila RabbitMQ em uma instância Amazon EC2 em uma única Availability Zone. Uma instância EC2 separada processa as mensagens e armazena os detalhes em um banco de dados PostgreSQL em outra instância EC2. Todas as instâncias EC2 estão na mesma Availability Zone. A empresa deseja a mais alta disponibilidade com o menor overhead operacional. O que um arquiteto de soluções deve fazer?

A opção correta oferece a mais alta disponibilidade com o menor overhead operacional. Migrar o RabbitMQ para o Amazon MQ (com par ativo/em espera) é uma solução gerenciada que garante alta disponibilidade para a fila de mensagens. Usar um grupo de Auto Scaling Multi-AZ para as instâncias EC2 do aplicativo distribui a carga e garante resiliência. Migrar o banco de dados para o Amazon RDS Multi-AZ para PostgreSQL proporciona alta disponibilidade e failover automático para o banco de dados, sendo uma solução gerenciada que reduz o overhead operacional em comparação com a manutenção de um banco de dados em instâncias EC2. As opções incorretas falham em um ou mais aspectos: A primeira opção está incorreta porque manter o PostgreSQL em instâncias EC2 com Auto Scaling Multi-AZ ainda exige gerenciamento significativo do banco de dados, o que aumenta o overhead operacional em comparação com o RDS Multi-AZ. A terceira e quarta opções estão incorretas porque sugerem criar um grupo de Auto Scaling Multi-AZ para as instâncias EC2 que hospedam o RabbitMQ. Embora o Auto Scaling possa aumentar a disponibilidade, o Amazon MQ é uma solução gerenciada que oferece maior disponibilidade e menor overhead para o RabbitMQ. Além disso, a quarta opção também mantém o PostgreSQL em instâncias EC2, o que não é a solução de menor overhead.