Uma empresa executa um aplicativo web de três camadas on-premises: frontend Apache, camada intermediária Java monolítica e armazenamento PostgreSQL. Uma promoção recente sobrecarregou todas as camadas, o aplicativo travou e o banco de dados atingiu os limites de capacidade de leitura. Várias promoções estão planejadas. Você deve projetar uma migração para a AWS que maximize a escalabilidade e minimize o esforço operacional. Quais três etapas realizam isso? (Escolha três.)

A refatoração do frontend para servir ativos estáticos do Amazon S3 com o Amazon CloudFront melhora a escalabilidade e o desempenho, descarregando o servidor Apache e distribuindo o conteúdo globalmente. O re-hospedagem do aplicativo Java no AWS Elastic Beanstalk com auto scaling garante que a camada intermediária possa lidar com picos de tráfego automaticamente, minimizando o esforço operacional. A migração do PostgreSQL para o Amazon Aurora PostgreSQL usando o AWS DMS, com Aurora Auto Scaling para réplicas de leitura, resolve os gargalos de leitura e oferece alta escalabilidade e disponibilidade. As opções incorretas são: Re-hospedar o frontend Apache em instâncias EC2 com EFS para ativos estáticos não é ideal, pois o S3/CloudFront é mais escalável e de menor custo para ativos estáticos. Refatorar o aplicativo Java para Fargate é uma boa opção para escalabilidade, mas Elastic Beanstalk atende ao requisito de minimizar o esforço operacional com menos refatoração. Re-hospedar o banco de dados PostgreSQL em uma instância EC2 maior não resolve a escalabilidade de leitura e adiciona sobrecarga de gerenciamento em comparação com o Aurora.