Escenario 2 de la guía VPC en AWS (aquí) muestra cómo configurar una subred pública y privada. Citar:
Recomendamos este escenario si desea ejecutar una aplicación web pública y al mismo tiempo mantener servidores back-end a los que no se puede acceder públicamente. Un ejemplo común es un sitio web de varios niveles, con los servidores web en una subred pública y los servidores de bases de datos en una subred privada. Puede configurar la seguridad y el enrutamiento para que los servidores web puedan comunicarse con los servidores de bases de datos.
Tengo entendido que, según la forma en que esté configurada la tabla de enrutamiento, todas las subredes dentro de una VPC pueden comunicarse entre sí. Entonces, si el propósito es la seguridad, para no permitir que el tráfico externo ingrese a un servidor back-end, como una base de datos, ¿por qué no simplemente tener el servidor en la subred pública y NO asignarle una IP pública? De esta forma se garantiza la misma funcionalidad: no se puede acceder desde el exterior, pero se puede comunicar con todos los demás servidores. ¿Cuál es la diferencia?
Respuesta1
Colocar un servidor en una subred pública pero sin una IP pública evitará que ese nodo se comunique con el mundo exterior: no tendrá una IP pública y no tendrá una ruta a una puerta de enlace NAT. Esto incluye servicios o API de AWS sin punto final de VPC. Por lo general, todos los nodos necesitan algún tipo de acceso externo, por lo que colocar el nodo en una subred privada ayuda con eso.
También evita que alguien agregue accidentalmente (o intencionalmente) un EIP o un grupo de seguridad a un nodo que toma lo que era un nodo privado y lo convierte en un nodo público.