Uma empresa migrou um aplicativo para a AWS. O aplicativo é executado em duas instâncias EC2 atrás de um Application Load Balancer (ALB). O banco de dados MySQL é executado em uma instância EC2 separada e tem muitas operações de leitura. Cada instância EC2 armazena conteúdo estático frequentemente atualizado em seu volume Amazon EBS anexado; o conteúdo estático deve ser copiado para cada volume EBS quando atualizado. A carga varia ao longo do dia e, durante os horários de pico, o aplicativo não consegue atender a todas as solicitações. O rastreamento mostra que o banco de dados não consegue lidar com o tráfego de leitura de pico. Qual solução aumentará a confiabilidade do aplicativo?

A opção correta aborda todos os pontos fracos do aplicativo. O Amazon ECS com Fargate e Application Auto Scaling permite que o aplicativo escale dinamicamente para lidar com picos de tráfego sem a necessidade de gerenciar servidores. O Amazon EFS resolve o problema do conteúdo estático, fornecendo um sistema de arquivos compartilhado e escalável, eliminando a necessidade de copiar dados para cada volume EBS. O Amazon Aurora MySQL Serverless v2 com uma réplica de leitura resolve o gargalo do banco de dados, oferecendo escalabilidade automática para leituras e alta disponibilidade. As outras opções têm falhas: Migrar para Lambda e EBS único para conteúdo estático não é ideal, pois o EBS não é um sistema de arquivos compartilhado para Lambda e não escalaria bem para conteúdo estático acessado por muitas funções. Migrar para Step Functions não é apropriado para um aplicativo web interativo, pois Step Functions são para orquestração de fluxos de trabalho. Além disso, usar EFS com Step Functions para conteúdo estático não é um padrão comum ou eficiente. A opção que sugere um volume EBS único para o conteúdo estático no ECS não é escalável nem resiliente para múltiplos contêineres, pois o EBS é um armazenamento de bloco de instância única.