Uma empresa executa um aplicativo de front-end web em três VMs Linux atrás de um balanceador de carga baseado em requisições HTTP em seu data center on-premises. O aplicativo precisa de armazenamento de arquivos para dados críticos. A empresa deve migrar o aplicativo para a AWS o mais rápido possível e manter a arquitetura da AWS altamente disponível, fazendo o MÍNIMO de alterações na arquitetura existente. Qual opção de migração satisfaz esses requisitos com o mínimo de alterações arquitetônicas?

A opção correta mantém a arquitetura de VMs Linux com o mínimo de alterações, migrando para instâncias EC2 em três Zonas de Disponibilidade para alta disponibilidade. O Amazon EFS oferece armazenamento de arquivos compartilhado e gerenciado, compatível com Linux e acessível por múltiplas instâncias EC2, substituindo a necessidade de um servidor de arquivos on-premises com pouca alteração na aplicação. O Application Load Balancer (ALB) é ideal para balanceamento de carga baseado em HTTP, como o balanceador de carga existente. As outras opções são menos adequadas: Migrar para ECS Fargate com S3 para armazenamento de arquivos exigiria reengenharia significativa do aplicativo para usar armazenamento de objetos em vez de sistema de arquivos, e um NLB não é ideal para tráfego HTTP. Migrar para EKS Fargate com FSx for Lustre introduziria uma nova tecnologia (Kubernetes) e um sistema de arquivos de alto desempenho (Lustre) que pode ser excessivo e mais complexo do que o necessário para um aplicativo web padrão. Migrar para EC2 em três Regiões diferentes da AWS é um exagero para alta disponibilidade e aumentaria a latência e complexidade. EBS não é um armazenamento de arquivos compartilhado entre instâncias, e a replicação entre regiões para EBS não é para acesso simultâneo.