Uma empresa está mudando a forma como aplica patches em instâncias EC2. Atualmente, as instâncias aplicam patches pela internet via um NAT gateway na VPC da conta do aplicativo. Uma VPC privada dedicada em uma conta central hospeda instâncias EC2 que atuam como um repositório de origem de patches. A empresa deseja usar o Systems Manager Patch Manager e o repositório de patches da conta central para aplicar patches em instâncias EC2 na conta do aplicativo, enquanto impede que todas as instâncias na conta do aplicativo acessem a internet. As instâncias ainda precisam de acesso ao Amazon S3 (onde os dados do aplicativo são armazenados), ao Systems Manager e ao repositório de patches na conta central. Qual solução atende a esses requisitos?

A solução correta utiliza VPC endpoints para o Systems Manager e Amazon S3, permitindo que as instâncias do aplicativo acessem esses serviços sem precisar da internet. A exclusão do NAT gateway garante que não haja acesso à internet. Uma conexão de emparelhamento de VPC (VPC peering) entre a conta do aplicativo e a conta central permite o acesso seguro ao repositório de patches, mantendo o tráfego dentro da rede AWS. A atualização das tabelas de rotas em ambas as contas é essencial para direcionar o tráfego corretamente através do emparelhamento. As opções incorretas falham por diversos motivos: A opção de ACL de rede e servidor VPN personalizado é excessivamente complexa e não é a maneira ideal de gerenciar o acesso a serviços AWS ou recursos entre VPCs. Além disso, bloquear apenas a porta 80 não impede todo o acesso à internet. A opção de VIFs (Virtual Interfaces) é para Direct Connect, não para acesso a serviços AWS dentro da mesma região ou entre VPCs. Um Transit Gateway seria uma alternativa ao VPC peering, mas a combinação de VIFs e Transit Gateway não se encaixa nos requisitos. A opção de ACL de rede que bloqueia o tráfego de entrada na porta 80 não impede o tráfego de saída para a internet, o que é um requisito.