amazon-web-services - site - us east virginia aws
¿Por qué necesitamos una subred privada en VPC? (4)
La respuesta de Michael: sqlbot supone implícitamente que se requieren direcciones IP privadas. Creo que vale la pena cuestionar esa suposición: ¿necesitamos 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 2014 a las 23:45
Imagine un escenario en el que esté utilizando una VPC y asigne direcciones IP públicas a todas sus instancias EC2. No se preocupe, eso no significa que sea necesariamente accesible a través de Internet, ya que utiliza grupos de seguridad para restringir el acceso exactamente de la misma manera que las cosas funcionaron con EC2 classic. Al usar direcciones IP públicas, tiene el beneficio de poder exponer fácilmente ciertos servicios a una audiencia limitada sin la necesidad de utilizar algo como un ELB. Esto lo libera de la necesidad de configurar una instancia NAT o puerta de enlace NAT. Y como necesita la mitad de subredes, puede optar por utilizar una asignación de CIDR más pequeña para su VPC o puede crear subredes más grandes con el mismo tamaño de VPC. Y menos subredes significa que también pagará menos por tráfico inter-AZ.
Entonces, ¿por qué no hacemos esto? ¿Por qué dice AWS 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 usar direcciones IP privadas que son efectivamente ilimitadas, en lugar de consumir excesivamente las direcciones públicas IPv4. Puede ver alguna evidencia de esto en la forma en que AWS determina el precio de las IP elásticas; un EIP adjunto a una instancia es gratuito, pero un EIP no utilizado cuesta dinero.
Pero por el bien del argumento, 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. Asociar la dirección IP pública
Puede solicitar una dirección IP pública al iniciar una nueva instancia de EC2. Esta opción aparece como una casilla de verificación en la consola, como el --associate-public-ip-address cuando se utiliza aws-cli, y como el indicador AssociatePublicIpAddress en un objeto de interfaz de red incrustado al usar CloudFormation. En cualquier caso, la dirección IP pública se asigna a eth0 (DeviceIndex = 0). Solo puede usar este enfoque al lanzar una nueva instancia. Sin embargo, esto tiene algunos inconvenientes.
Una desventaja es que al cambiar el grupo de seguridad de una instancia que usa un objeto de interfaz de red incrustado se forzará el reemplazo inmediato de la instancia, al menos si está utilizando CloudFormation.
Otra desventaja es que una dirección IP pública asignada de esta manera se perderá cuando la instancia se detenga.
2. IP elástica
En general, las IP elásticas son el enfoque preferido porque son más seguras. Se le garantiza que continuará utilizando la misma dirección IP, no se arriesga a eliminar accidentalmente ninguna instancia 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 EC2.
... Pero AWS te limita a 5 EIP por región. Puede solicitar más, y su solicitud puede ser otorgada. Pero AWS podría igualmente negar esa solicitud en función del razonamiento que mencioné anteriormente. Por lo tanto, probablemente no desee confiar en EIP si planea escalar su infraestructura más allá de 5 instancias de EC2 por región.
En conclusión, el uso de las direcciones IP públicas ofrece algunos beneficios agradables, 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 las que son.
Hay 4 escenarios en la configuración de AWS VPC. Pero echemos un vistazo a estos dos:
- Escenario público de escenario 1: 1.
- Escenario 2: 1 subred pública y 1 subred privada.
Como cualquier instancia iniciada en una subred pública no tiene EIP (a menos que esté asignada), ya no es direccionable desde Internet. Entonces:
- ¿Por qué hay una necesidad de subred privada?
- ¿Cuáles son exactamente las diferencias entre subredes privadas y públicas?
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 de AWS es ~ 3 veces más cara 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 instaladas varias instancias de NAT para conmutación por error, etc.), que generalmente es cierto para la mayoría de los 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,
El costo mensual de la instancia administrada NAT = $ 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 estándar de transferencia de datos AWS para todos los datos transferidos a través del Puerta de enlace NAT) = $ 47.98
Instancia t2.nano configurada como una instancia NAT = $ 4.84 / mes ($ 0.0065 * 744 horas en un mes) + $ 10 ($ .10 / GB cargos estándar de transferencia de datos AWS para todos los datos transferidos a través de la instancia NAT) = $ 14.84
Por supuesto, esto cambia cuando se utilizan instancias de NAT redundantes, ya que la puerta de enlace NAT administrada de AWS tiene redundancia incorporada para alta disponibilidad. Si no le importan los $ 33 adicionales mensuales, entonces la instancia administrada de NAT 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 fruncir el ceño ante la idea de combinar VPN y NAT).
Yo sugeriría una subredes "privadas" de vértigo diferentes y instancias / gateways de 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 abandonar 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 de 250mbit o 10gbit).
Si tiene una máquina que tampoco necesita acceder a Internet directamente (y le preguntaría cómo está parcheando *), entonces 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 a la suya.
Actualización: a fines de diciembre de 2015, AWS announced una nueva característica, una Puerta de enlace NAT administrada para VPC . Este servicio opcional proporciona un mecanismo alternativo para instancias de VPC en una subred privada para acceder a Internet, donde anteriormente la solución común era una instancia EC2 en una subred pública dentro de la VPC, funcionando como una "instancia NAT" proporcionando traducción de direcciones de red ( técnicamente, traducción de dirección de puerto ) para instancias en otras subredes privadas, permitiendo que esas máquinas utilicen la dirección IP pública de la instancia NAT para su acceso saliente a Internet.
El nuevo servicio gestionado NAT 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 el servicio de Puerta de enlace NAT administrado se puede aprovisionar, en su lugar. Se ofrecerá una versión ampliada de esta respuesta que integra más información acerca de NAT Gateway y cómo se compara con una instancia 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 funciones diferentes. Todas las configuraciones de VPC con acceso a Internet tendrán un objeto virtual de puerta de enlace de Internet.
Para comprender la distinción entre subredes "privadas" y "públicas" en Amazon VPC, es necesario comprender cómo funcionan en general el enrutamiento IP y la traducción de direcciones de red (NAT) 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, dictamina 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 "Puerta de enlace de Internet" 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 realiza la función "instancia NAT", en el caso de una subred "privada".
Internet Gateway no realiza ninguna traducción de direcciones de red para instancias sin direcciones IP públicas, por lo que una instancia sin una dirección IP pública no se puede conectar a Internet: para hacer cosas como descargar actualizaciones de software o acceder a otros recursos de AWS como S3 1 y SQS - si la ruta predeterminada en su subred de VPC es el objeto de la Pasarela de Internet. 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 de salida a Internet. Aquí es donde entra Network Address Translation² y una instancia de 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 "Puerta de enlace de Internet"; es una instancia de EC2 configurada como instancia de NAT.
Una instancia de NAT es una instancia en una subred pública con una IP pública y una configuración específica. Hay AMI preconstruidas para hacer esto, o puedes construir el tuyo propio.
Cuando las máquinas con direcciones privadas 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 que sepa 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, cuando se accede a un recurso externo de Internet desde una subred privada, el tráfico atraviesa la instancia NAT y parece que el destino se originó a partir de la dirección IP pública de la instancia NAT ... para que el tráfico de respuesta regrese a la instancia NAT. Ni el grupo de seguridad asignado a la instancia de 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 son con estado. Se dan cuenta de que el tráfico de respuesta está correlacionado con las sesiones originadas internamente, por lo que se permite automáticamente. El tráfico inesperado es, por supuesto, denegado 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 de NAT para cualquier subred privada dada siempre está en una subred diferente, y esa otra subred es siempre una subred pública, porque la instancia NAT necesita tener una IP pública externa, y su puerta de enlace predeterminada debe ser el objeto VPC "Puerta de enlace de Internet".
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 NAT (que realiza NAT en el tráfico) y no el objeto 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 enrutar hacia afuera a través de la instancia NAT, lo que eliminaría el tráfico (ya que estaría compuesto de respuestas a conexiones de las que no es consciente, por lo que se consideraría no válido) o reescribiría 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 provenientes de una dirección IP distinta a la que estaban tratando de iniciar las comunicaciones con .
En esencia, entonces, las designaciones "privadas" y "públicas" no se refieren realmente a la accesibilidad o inaccesibilidad de Internet. Son sobre los tipos de direcciones que se asignarán a las instancias en esa subred, que es relevante debido a la necesidad de traducir (o evitar traducir) esas direcciones IP para las interacciones de Internet.
Como 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 de VPC interno. 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, deben originar tráfico de Internet saliente, entonces técnicamente podrían implementarse en una subred "pública" y aún así serían inaccesibles desde Internet ... pero bajo tal configuración, es imposible para ellos originar tráfico de salida hacia Internet, lo que incluye conexiones con otros servicios de infraestructura de AWS, de nuevo, como S3 1 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. Existe un concepto relativamente nuevo llamado VPC Endpoint que permite que sus instancias, incluidas las que solo tienen direcciones IP privadas, accedan directamente a S3 desde subredes seleccionadas dentro de la VPC, sin tocar "Internet", y sin utilizar una instancia NAT o una puerta de enlace NAT , pero esto requiere una configuración adicional, y solo se puede usar para acceder a los depósitos dentro de la misma región de AWS que su VPC. De forma predeterminada, S3, que es, hasta el momento, el único servicio que ha expuesto la capacidad de crear puntos finales de VPC, solo es accesible desde VPC a través de Internet. Cuando crea un punto final de VPC, crea una lista de prefijos ( pl-xxxxxxxx ) que puede usar en sus tablas de rutas de VPC para enviar tráfico vinculado a ese servicio de AWS en particular directamente al servicio a través del objeto virtual "VPC Endpoint". También resuelve un problema de restringir el acceso saliente a S3 para una instancia particular, porque la lista de prefijos puede usarse en grupos de seguridad salientes, en lugar de una dirección IP o bloque de destino, y un punto final VPC S3 puede estar sujeto a declaraciones políticas adicionales , restringiendo el acceso al cubo desde el interior, según lo deseado.
2. Como se indica en la documentación, lo que se está discutiendo aquí es el puerto y la traducción de direcciones de red. Es común, aunque técnicamente es un poco impreciso, referirse a la operación combinada como "NAT". Esto es algo similar a la forma en que muchos de nosotros solemos decir "SSL" cuando en realidad queremos decir "TLS". Sabemos de lo que 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 el rol real de un dispositivo NAT es la traducción de direcciones y la traducción de direcciones de puertos (PAT)".