Uma aplicação é executada em uma única instância Amazon EC2 lançada por um grupo do Auto Scaling (min=1, max=1) em uma sub-rede privada. A aplicação usa uma instância de banco de dados Amazon RDS for MySQL. A VPC tem sub-redes em três Availability Zones, mas apenas um NAT gateway é implantado. O arquiteto deve garantir que a aplicação possa operar em várias Availability Zones. Qual solução atende a esse requisito?

A solução correta garante alta disponibilidade e resiliência em várias Availability Zones (AZs). Implantar NAT gateways adicionais em outras AZs e atualizar as tabelas de rotas é crucial para que as instâncias EC2 em sub-redes privadas em diferentes AZs possam acessar a internet ou outros serviços fora da VPC, mesmo que uma AZ falhe. Converter o RDS para Multi-AZ assegura que o banco de dados tenha um standby em outra AZ para failover automático. Configurar o Auto Scaling Group (ASG) para lançar instâncias em várias AZs e definir min/max=3 distribui a aplicação, permitindo que ela continue operando se uma AZ ficar indisponível. As opções incorretas falham em aspectos críticos: Substituir o NAT gateway por um virtual private gateway é inadequado, pois este último é para conectividade VPN/Direct Connect, não para acesso à internet de sub-redes privadas. Substituir o NAT gateway por uma instância NAT é menos gerenciado e escalável que um NAT gateway. Migrar para PostgreSQL ou lançar instâncias EC2 adicionais sem um ASG configurado para resiliência Multi-AZ não resolve o problema de forma abrangente. Habilitar backups automáticos no RDS é uma boa prática, mas não garante alta disponibilidade em caso de falha de AZ. Manter as capacidades mínima e máxima do ASG em 1 anula o objetivo de operar em várias AZs, pois a aplicação ainda estaria em uma única instância.