Arquitectura de VPC y bloques CIDR

Una Amazon Virtual Private Cloud (VPC) es una red privada aislada lógicamente dentro de una Region de AWS que usted define y controla. Cada cuenta de AWS incluye una VPC predeterminada (CIDR 172.31.0.0/16) en cada Region, pero las arquitecturas de producción siempre usan VPC personalizadas. Una VPC abarca todas las zonas de disponibilidad de su Region y le proporciona control total sobre el direccionamiento IP, las subredes, las tablas de rutas, las puertas de enlace de internet y la seguridad. Los recursos dentro de una VPC están aislados de otras VPC y de internet, salvo que configure explícitamente la conectividad.

Un bloque CIDR (Classless Inter-Domain Routing) define el rango de direcciones IP de una VPC o subred mediante el formato x.x.x.x/prefix. La longitud del prefijo determina cuántas direcciones IP hay en el rango: /16 = 65.536 direcciones, /24 = 256 direcciones, /28 = 16 direcciones (el tamaño mínimo de subred en AWS). Para las VPC, AWS permite bloques CIDR desde /16 (el más grande) hasta /28 (el más pequeño). Elija un CIDR de VPC que: (1) no se superponga con las redes locales (para futuras conexiones VPN/Direct Connect), (2) sea lo bastante grande para las subredes planificadas y (3) use espacio de direcciones privadas RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Una subred es un segmento del rango de direcciones IP de una VPC que se encuentra en una sola zona de disponibilidad. Las subredes se clasifican como públicas (tienen una ruta a una puerta de enlace de internet) o privadas (sin ruta directa a internet). Como práctica recomendada para una arquitectura típica de tres niveles, cree al menos tres niveles de subredes: público (balanceadores de carga, hosts bastión), private-app (instancias de EC2, tareas de ECS) y private-data (RDS, ElastiCache), y replique cada nivel en al menos dos AZ para lograr alta disponibilidad.

Un diseño CIDR común para una VPC con el CIDR 10.0.0.0/16 en dos AZ y tres niveles: Public AZ-a: 10.0.1.0/24; Public AZ-b: 10.0.2.0/24; Private-App AZ-a: 10.0.10.0/24; Private-App AZ-b: 10.0.11.0/24; Private-Data AZ-a: 10.0.20.0/24; Private-Data AZ-b: 10.0.21.0/24. Esta distribución deja espacio para agregar subredes de AZ-c (10.0.3.0/24, 10.0.12.0/24, 10.0.22.0/24) sin tener que rediseñar todo el esquema CIDR. Diseñe siempre pensando en el crecimiento.

AWS reserva las primeras cuatro y la última dirección IP de cada subred. Para una subred 10.0.1.0/24: 10.0.1.0 (red), 10.0.1.1 (router de la VPC), 10.0.1.2 (DNS/DHCP), 10.0.1.3 (uso futuro) y 10.0.1.255 (broadcast). Una subred /24 tiene 256 IP totales menos 5 reservadas = 251 utilizables. Una subred /28 (la mínima) tiene 16 IP menos 5 = 11 utilizables. Esto es importante al dimensionar las subredes según la cantidad de recursos (instancias de EC2, funciones de Lambda con VPC, etc.) que planea implementar.

Puede añadir hasta cuatro bloques CIDR secundarios a una VPC existente sin volver a crearla. Esto resulta útil cuando el CIDR principal se ha agotado (todas las subredes están llenas) o cuando necesita añadir espacio de direcciones de un rango RFC 1918 diferente para un caso de uso específico, como la red de pods de Kubernetes. Los CIDR secundarios están sujetos a ciertas restricciones; por ejemplo, no puede añadir un CIDR superpuesto y no se pueden utilizar determinados rangos públicos que no pertenecen a RFC 1918. Planifique cuidadosamente desde el principio el tamaño del CIDR de la VPC para minimizar la necesidad de utilizar CIDR secundarios.

VPC Peering establece una conexión de red privada entre dos VPC para que sus recursos puedan comunicarse mediante direcciones IP privadas. Las VPC emparejadas pueden pertenecer a la misma cuenta, a cuentas diferentes o incluso a distintas regiones (emparejamiento entre regiones). Requisito: los CIDR de las dos VPC no deben superponerse. Limitación: el emparejamiento es no transitivo; si VPC-A tiene un emparejamiento con VPC-B y VPC-B con VPC-C, VPC-A no puede comunicarse con VPC-C a través de VPC-B. Para obtener conectividad en malla completa entre muchas VPC, utilice AWS Transit Gateway.

AWS Transit Gateway (TGW) actúa como un concentrador de red central —un router en la nube— que conecta varias VPC, VPN y conexiones de Direct Connect. En lugar de crear N*(N-1)/2 conexiones de VPC Peering para formar una malla completa de N VPC, debe asociar cada VPC y cada conexión a Transit Gateway, que se encarga de enrutar el tráfico entre ellas. TGW admite tablas de enrutamiento que permiten controlar qué asociaciones pueden comunicarse entre sí, lo que posibilita la segmentación de la red; por ejemplo, puede aislar las VPC de producción de las VPC de desarrollo en el mismo TGW.

Dos configuraciones de DNS controlan la resolución de nombres en una VPC. enableDnsSupport: cuando es true (valor predeterminado), la VPC utiliza el resolver de DNS proporcionado por AWS en 169.254.169.253 o la segunda IP del CIDR de la VPC (por ejemplo, 10.0.0.2 para 10.0.0.0/16). enableDnsHostnames: cuando es true (debe habilitarse para las VPC personalizadas; está activado de forma predeterminada en la VPC predeterminada), las instancias de EC2 de la VPC reciben nombres de host DNS como ip-10-0-1-15.ec2.internal. Ambas opciones deben estar habilitadas para que Route 53 Private Hosted Zones funcionen dentro de la VPC.

Los registros de flujo de VPC capturan metadatos sobre el tráfico de red que circula por su VPC: IP de origen y destino, puerto, protocolo, bytes transferidos y si el tráfico se aceptó o se rechazó. Los registros de flujo pueden publicarse en CloudWatch Logs (para consultarlos con Logs Insights) o en S3 (para analizarlos con Athena). Son muy valiosos para el análisis forense de seguridad (quién se conectó a qué), el análisis del tráfico (identificar flujos con un gran consumo de ancho de banda) y la resolución de problemas (¿por qué se rechazó una conexión?). Los registros de flujo funcionan en el nivel de la VPC, la subred o una ENI individual.

Antes de crear una VPC, planifique todas las necesidades futuras de conectividad: conectividad con la red local (VPN o Direct Connect): asegúrese de que el CIDR de la VPC no se superponga con las subredes locales; conectividad entre VPC (emparejamiento o Transit Gateway): planifique CIDR que no se superpongan en todas las VPC de su organización; acceso a servicios de AWS (VPC endpoints para S3, DynamoDB y SSM, con el fin de evitar que el tráfico pase por Internet); y dimensionamiento de subredes: deje margen en cada subred para el consumo de direcciones IP de los pods de EKS, las funciones de Lambda y las interfaces de red elásticas.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que: una VPC es una red lógicamente aislada en una región, definida por un bloque CIDR que se divide en subredes públicas y privadas distribuidas entre varias AZ; AWS reserva 5 IP en cada subred, por lo que siempre debe dimensionarlas teniendo en cuenta esta reducción; y VPC Peering y Transit Gateway conectan VPC de forma privada, pero los rangos CIDR no deben superponerse. A continuación, exploraremos los Internet Gateways y las tablas de enrutamiento.