Cenário 2 do guia VPC na AWS (aqui) mostra como configurar uma sub-rede pública e privada. Citar:
Recomendamos este cenário se você quiser executar um aplicativo Web voltado para o público, enquanto mantém servidores back-end que não são acessíveis publicamente. Um exemplo comum é um site multicamadas, com os servidores Web em uma sub-rede pública e os servidores de banco de dados em uma sub-rede privada. Você pode configurar segurança e roteamento para que os servidores web possam se comunicar com os servidores de banco de dados.
Entendo que, com a forma como a tabela de roteamento é configurada, todas as sub-redes em uma VPC podem se comunicar entre si. Então, se o objetivo é segurança, para não permitir tráfego externo em um servidor back-end, como um banco de dados, por que não apenas colocar o servidor na sub-rede pública e NÃO atribuir a ele um IP público? Dessa forma, a mesma funcionalidade é garantida: não pode ser acessado de fora, mas pode se comunicar com todos os demais servidores. Qual é a diferença?
Responder1
Colocar um servidor em uma sub-rede pública, mas sem um IP público, impedirá que esse nó se comunique com o mundo externo - ele não terá um IP público e não terá uma rota para um gateway NAT. Isso inclui APIs ou serviços da AWS com endpoint não VPC. Geralmente acontece que todos os nós precisam de algum tipo de acesso externo, portanto, colocar o nó em uma sub-rede privada ajuda nisso.
Também evita que alguém adicione acidentalmente (ou intencionalmente) um EIP ou grupo de segurança a um nó que pega o que era um nó privado e o torna um nó público.