¿Por qué necesitamos una subred privada en VPC?

Hay 4 escenarios en la configuración de AWS VPC. Pero echemos un vistazo a estos dos:

• Escenario 1: 1 subred pública.
• Escenario 2: 1 subred pública y 1 subred privada.

Dado que cualquier instancia lanzada en una subred pública no tiene EIP (a menos que esté asignada), ya no es direccionable desde Internet. Luego:

• ¿Por qué hay una necesidad de subred privada?
• ¿Cuáles son exactamente las diferencias entre subredes privadas y públicas?

Actualización: a fines de diciembre de 2015, AWS anunció una nueva característica, una puerta de enlace NAT administrada para VPC . Este servicio opcional proporciona un mecanismo alternativo para que las instancias VPC en una subred privada accedan a Internet, donde anteriormente, la solución común era una instancia EC2 en una subred pública dentro de la VPC, que funcionaba como una "instancia NAT", proporcionando traducción de direcciones de red ( técnicamente, traducción de direcciones de puerto ) para instancias en otras subredes privadas, lo que permite que esas máquinas utilicen la dirección IP pública de la instancia NAT para su acceso saliente a Internet.

El nuevo servicio NAT administrado no cambia fundamentalmente la aplicabilidad de la siguiente información, pero esta opción no se aborda en el contenido que sigue. Una instancia de NAT todavía se puede usar como se describe, o en su lugar se puede aprovisionar el servicio de puerta de enlace NAT administrada. Próximamente se publicará una versión ampliada de esta respuesta que integra más información sobre NAT Gateway y cómo se compara con una instancia de NAT, ya que ambas son relevantes para el paradigma de subred privado / público en VPC.

Tenga en cuenta que Internet Gateway y NAT Gateway son dos características diferentes. Todas las configuraciones de VPC con acceso a Internet tendrán un objeto virtual de Internet Gateway.

Para comprender la distinción entre subredes "privadas" y "públicas" en Amazon VPC se requiere comprender cómo funciona el enrutamiento IP y la traducción de direcciones de red (NAT) en general, y cómo se implementan específicamente en VPC.

La diferenciación central entre una subred pública y privada en VPC se define por cuál es la ruta predeterminada de esa subred, en las tablas de enrutamiento de VPC.

Esta configuración, a su vez, dicta la validez de usar, o no usar, direcciones IP públicas en instancias en esa subred en particular.

Cada subred tiene exactamente una ruta predeterminada, que puede ser solo una de dos cosas:

• el objeto "Internet Gateway" de la VPC, en el caso de una subred "pública", o
• un dispositivo NAT, es decir, una puerta de enlace NAT o una instancia EC2, que desempeña el rol de "instancia NAT", en el caso de una subred "privada".

La puerta de enlace a Internet no hace ninguna traducción de direcciones de red para casos sin direcciones IP públicas para una instancia sin una dirección IP pública no se puede conectar al exterior a Internet - a hacer cosas como descargar actualizaciones de software, o el acceso a otros recursos de AWS como S3 ¹ y SQS - si la ruta predeterminada en su subred VPC es el objeto de Internet Gateway. Entonces, si usted es una instancia en una subred "pública", entonces necesita una dirección IP pública para hacer una cantidad significativa de cosas que los servidores comúnmente necesitan hacer.

Para las instancias con solo una dirección IP privada, hay una forma alternativa de acceso saliente a Internet. Aquí es donde entra la traducción de direcciones de red² y una instancia NAT.

Las máquinas en una subred privada pueden acceder a Internet porque la ruta predeterminada en una subred privada no es el objeto VPC "Internet Gateway", es una instancia EC2 configurada como una instancia NAT.

Una instancia NAT es una instancia en una subred pública con una IP pública y una configuración específica. Hay AMI preconstruidos para hacer esto, o puedes construir el tuyo propio.

Cuando las máquinas con dirección privada envían tráfico hacia afuera, el tráfico es enviado, por VPC, a la instancia NAT, que reemplaza la dirección IP de origen en el paquete (la dirección IP privada de la máquina privada) con su propia dirección IP pública, envía el tráfico a Internet, acepta los paquetes de respuesta y los reenvía a la dirección privada de la máquina de origen. (También puede reescribir el puerto de origen y, en cualquier caso, recuerda las asignaciones para saber qué máquina interna debe recibir los paquetes de respuesta). Una instancia de NAT no permite que ningún tráfico entrante "inesperado" llegue a las instancias privadas, a menos que se haya configurado específicamente para hacerlo.

Por lo tanto, al acceder a recursos externos de Internet desde una subred privada, el tráfico atraviesa la instancia de NAT y parece que el destino se originó en la dirección IP pública de la instancia de NAT ... por lo que el tráfico de respuesta vuelve a la instancia de NAT. Ni el grupo de seguridad asignado a la instancia NAT ni el grupo de seguridad asignado a la instancia privada deben configurarse para "permitir" este tráfico de respuesta, porque los grupos de seguridad tienen estado. Se dan cuenta de que el tráfico de respuesta está correlacionado con sesiones originadas internamente, por lo que se permite automáticamente. El tráfico inesperado, por supuesto, se niega a menos que el grupo de seguridad esté configurado para permitirlo.

A diferencia del enrutamiento IP convencional, donde su puerta de enlace predeterminada está en su misma subred, la forma en que funciona en VPC es diferente: la instancia NAT para cualquier subred privada dada siempre está en una subred diferente, y esa otra subred siempre es una subred pública, porque la instancia de NAT debe tener una IP externa pública, y su puerta de enlace predeterminada debe ser el objeto VPC "Internet Gateway".

Del mismo modo ... no puede implementar una instancia con una IP pública en una subred privada. No funciona, porque la ruta predeterminada en una subred privada es (por definición) una instancia de NAT (que realiza NAT en el tráfico), y no el objeto de Internet Gateway (que no lo hace). El tráfico entrante de Internet golpearía la IP pública de la instancia, pero las respuestas intentarían enrutarse hacia afuera a través de la instancia NAT, lo que dejaría caer el tráfico (ya que estaría compuesto de respuestas a conexiones que no conoce, por lo que se consideraría inválido) o volvería a escribir el tráfico de respuesta para usar su propia dirección IP pública, lo que no funcionaría ya que el origen externo no aceptaría respuestas que vinieran de una dirección IP distinta de la que intentaban iniciar las comunicaciones .

En esencia, entonces, las designaciones "privadas" y "públicas" no se refieren realmente a la accesibilidad o inaccesibilidad de Internet. Se trata de los tipos de direcciones que se asignarán a las instancias en esa subred, lo cual es relevante debido a la necesidad de traducir, o evitar traducir, esas direcciones IP para las interacciones de Internet.

Dado que VPC tiene rutas implícitas desde todas las subredes de VPC a todas las demás subredes de VPC, la ruta predeterminada no juega un papel en el tráfico interno de VPC. Las instancias con direcciones IP privadas se conectarán a otras direcciones IP privadas en la VPC "desde" su dirección IP privada, no "desde" su dirección IP pública (si tienen una) ... siempre que la dirección de destino sea otra dirección privada dentro de la VPC.

Si sus instancias con direcciones IP privadas nunca, bajo ninguna circunstancia, necesitan originar tráfico de Internet saliente, entonces técnicamente podrían implementarse en una subred "pública" y seguirían siendo inaccesibles desde Internet ... pero bajo tal configuración, les es imposible generar tráfico saliente hacia Internet, que incluye conexiones con otros servicios de infraestructura de AWS, nuevamente, como S3 ¹ o SQS.

^{1. Con respecto a S3, específicamente, decir que siempre se requiere acceso a Internet es una simplificación excesiva que probablemente crecerá en alcance con el tiempo y se extenderá a otros servicios de AWS, a medida que las capacidades de VPC continúen creciendo y evolucionando. Hay un concepto relativamente nuevo llamado VPC Endpointeso permite que sus instancias, incluidas aquellas con solo direcciones IP privadas, accedan directamente a S3 desde subredes seleccionadas dentro de la VPC, sin tocar "Internet" y sin usar una instancia NAT o puerta de enlace NAT, pero esto requiere una configuración adicional, y es solo se puede usar para acceder a los depósitos dentro de la misma región de AWS que su VPC. De manera predeterminada, S3, que es, a partir de este escrito, el único servicio que ha expuesto la capacidad de crear puntos finales VPC, solo es accesible desde dentro de VPC a través de Internet. Cuando crea un punto final VPC, esto crea una lista de prefijos (pl-xxxxxxxx) que puede usar en sus tablas de ruta VPC para enviar tráfico vinculado a ese servicio AWS particular directamente al servicio a través del objeto virtual "VPC Endpoint". También resuelve el problema de restringir el acceso saliente a S3, por ejemplo, porque la lista de prefijos se puede usar en grupos de seguridad salientes, en lugar de una dirección IP o bloque de destino, y un punto final S3 VPC puede estar sujeto a declaraciones de políticas adicionales. , restringiendo el acceso al cucharón desde el interior, según se desee.}

^{2. Como se señala en la documentación, lo que realmente se está discutiendo aquí es la traducción de direcciones de puerto y de red. Es común, aunque técnicamente un poco impreciso, referirse a la operación combinada como "NAT". Esto es algo similar a la forma en que muchos de nosotros tendemos a decir "SSL" cuando en realidad queremos decir "TLS". Sabemos de qué estamos hablando, pero no usamos la palabra más correcta para describirlo. "Nota Utilizamos el término NAT en esta documentación para seguir la práctica común de TI, aunque la función real de un dispositivo NAT es la traducción de direcciones y la traducción de direcciones de puerto (PAT)".}

Sugeriría una tachuela diferente: abandone las subredes "privadas" y las instancias / puertas de enlace NAT. No son necesarios Si no desea que la máquina sea accesible desde Internet, no la coloque en un grupo de seguridad que permita dicho acceso.

Al deshacerse de la instancia / puerta de enlace NAT, está eliminando el costo de ejecución de la instancia / puerta de enlace y elimina el límite de velocidad (ya sea 250mbit o 10gbit).

Si tiene una máquina que tampoco necesita acceder a Internet directamente (y le preguntaría cómo la está parchando *), entonces, por supuesto, no asigne una dirección IP pública.

* Si la respuesta aquí es algún tipo de proxy, bueno, estás incurriendo en una sobrecarga, pero cada uno por su cuenta.

No tengo la reputación de agregar un comentario a la respuesta de Michael anterior, por lo tanto, agrego mi comentario como respuesta.

Vale la pena señalar que la puerta de enlace administrada por AWS es ~ 3 veces más costosa que en la fecha en comparación con la ejecución de su propia instancia. Por supuesto, esto supone que solo necesita una instancia de NAT (es decir, no tiene varias instancias de NAT configuradas para conmutación por error, etc.), lo cual generalmente es cierto para la mayoría de los escenarios de casos de uso pequeños a medianos. Suponiendo una transferencia de datos mensual de 100 GB a través de la puerta de enlace NAT,

Costo mensual de la instancia NAT administrada = $ 33.48 / mes ($ 0.045 / hora * 744 horas en un mes) + $ 4.50 ($ 0.045 por GB de datos procesados ​​* 100GB) + $ 10 ($ .10 / GB cargos de transferencia de datos estándar de AWS para todos los datos transferidos a través del Puerta de enlace NAT) = $ 47.98

t2.nano instancia configurada como una instancia NAT = $ 4.84 / mes ($ 0.0065 * 744 horas en un mes) + $ 10 ($ .10 / GB cargos de transferencia de datos estándar de AWS para todos los datos transferidos a través de la instancia NAT) = $ 14.84

Esto, por supuesto, cambia cuando busca instancias NAT redundantes, ya que la puerta de enlace NAT administrada por AWS tiene redundancia incorporada para alta disponibilidad. Si no le importan los $ 33 adicionales al mes, entonces la instancia NAT administrada definitivamente vale la pena el dolor de cabeza reducido de no tener que mantener otra instancia. Si está ejecutando una instancia de VPN (por ejemplo, OpenVPN) para acceder a sus instancias dentro de la VPC, simplemente puede configurar esa instancia para que también actúe como su puerta de enlace NAT, y luego no tiene que mantener una instancia adicional solo para NAT ( aunque algunas personas pueden desaprobar la idea de combinar VPN y NAT).

La respuesta de Michael - sqlbot supone implícitamente que se requieren direcciones IP privadas. Creo que vale la pena cuestionar esa suposición: ¿necesitamos siquiera usar direcciones IP privadas en primer lugar? Al menos un comentarista hizo la misma pregunta.

¿Cuál es la ventaja de un servidor en una subred privada con una instancia NAT [vs.] un servidor [en una] subred pública con una estricta política de seguridad? - abhillman 24 de junio de 14 a las 23:45

Imagine un escenario en el que utiliza una VPC y asigna direcciones IP públicas a todas sus instancias EC2. No se preocupe, eso no significa que sea necesariamente accesible a través de Internet, porque usa grupos de seguridad para restringir el acceso exactamente de la misma manera que las cosas funcionaban con EC2 classic. Al usar direcciones IP públicas, tiene la ventaja de poder exponer fácilmente ciertos servicios a una audiencia limitada sin necesidad de usar algo como un ELB. Esto lo libera de la necesidad de configurar una instancia NAT o una puerta de enlace NAT. Y dado que necesita la mitad de subredes, puede optar por utilizar una asignación de CIDR más pequeña para su VPC o puede hacer subredes más grandes con el mismo tamaño de VPC. Y menos subredes significa que también pagará menos por el tráfico entre AZ.

Entonces, ¿por qué no hacemos esto? ¿Por qué AWS dice que la mejor práctica es usar IP privadas?

Amazon Web Services tiene un suministro limitado de direcciones IPv4 públicas porque Internet en su conjunto tiene un suministro limitado de direcciones IPv4 públicas. Le conviene utilizar direcciones IP privadas que sean efectivamente ilimitadas, en lugar de consumir en exceso las escasas direcciones IPv4 públicas. Puede ver alguna evidencia de esto en cómo AWS valora las IP elásticas; un EIP adjunto a una instancia es gratuito, pero un EIP no utilizado cuesta dinero.

Pero en aras de la discusión, supongamos que no nos importa la escasez de direcciones IPv4 públicas en Internet. Después de todo, mi aplicación es especial. ¿Qué pasa después?

Solo hay dos formas de adjuntar una dirección IP pública a una instancia EC2 en una VPC.

1. Dirección IP pública asociada

Puede solicitar una dirección IP pública al iniciar una nueva instancia EC2. Esta opción aparece como una casilla de verificación en la consola, como el indicador --associate-public-ip-address cuando se usa aws-cli, y como el indicador AssociatePublicIpAddress en un objeto de interfaz de red incorporado cuando se usa CloudFormation. En cualquier caso, la dirección IP pública se asigna a eth0(DeviceIndex = 0). Solo puede usar este enfoque al iniciar una nueva instancia. Sin embargo, esto viene con algunos inconvenientes.

Una desventaja es que cambiar el grupo de seguridad de una instancia que está usando un objeto de interfaz de red incrustado forzará el reemplazo inmediato de la instancia, al menos si está usando CloudFormation.

Otra desventaja es que una dirección IP pública asignada de esta manera se perderá cuando se detenga la instancia.

2. IP elástica

En general, las IP elásticas son el enfoque preferido porque son más seguras. Se garantiza que continuará utilizando la misma dirección IP, no corre el riesgo de eliminar accidentalmente ninguna instancia de EC2, puede conectar / desconectar libremente una IP elástica en cualquier momento y tiene la libertad de cambiar los grupos de seguridad aplicados a sus instancias de EC2.

... Pero AWS lo limita a 5 EIP por región. Puede solicitar más, y su solicitud podría ser concedida. Pero AWS podría igualmente negar esa solicitud basándose en el razonamiento que mencioné anteriormente. Por lo tanto, es probable que no desee confiar en EIP si planea escalar su infraestructura más allá de 5 instancias EC2 por región.

En conclusión, el uso de direcciones IP públicas tiene algunos buenos beneficios, pero se encontrará con problemas administrativos o de escala si intenta usar direcciones IP públicas exclusivamente. Esperemos que esto ayude a ilustrar y explicar por qué las mejores prácticas son como son.