Redes

Por qué el CIDR predeterminado de VPC es /16 - Curiosidades y trampas del diseño de direcciones IP

Explicamos por qué el CIDR predeterminado de VPC es /16, la historia del espacio de direcciones privadas RFC 1918, las 5 direcciones IP no utilizables en subredes y los patrones de fallo en el diseño CIDR.

約 6 分で読めます

RFC 1918 y la historia de las direcciones IP privadas

Para comprender el diseño CIDR de VPC, primero es necesario conocer la historia de RFC 1918. Publicado en 1996, RFC 1918 reservó tres rangos de direcciones para redes privadas que no se conectan directamente a Internet: 10.0.0.0/8 (aproximadamente 16,77 millones de direcciones), 172.16.0.0/12 (aproximadamente 1,04 millones de direcciones) y 192.168.0.0/16 (aproximadamente 65.000 direcciones). El trasfondo de la reserva de estos tres rangos fue el rápido crecimiento de Internet en la década de 1990. El espacio de direcciones IPv4 tiene solo unos 4.300 millones de direcciones, y era evidente que se agotarían si se asignara una IP global a cada dispositivo. Al combinar direcciones privadas con NAT (Network Address Translation), se pudieron colocar múltiples dispositivos detrás de una sola IP global, mitigando el agotamiento de direcciones. El CIDR predeterminado de VPC 10.0.0.0/16 es un bloque /16 extraído del rango 10.0.0.0/8 de RFC 1918.

Por qué /16 - Un tamaño equilibrado, ni demasiado grande ni demasiado pequeño

Un bloque CIDR /16 contiene 65.536 direcciones IP. La razón por la que AWS eligió /16 como predeterminado es el equilibrio entre proporcionar suficiente espacio de direcciones IP para la mayoría de las cargas de trabajo y poder extraer 256 bloques /16 dentro del rango 10.0.0.0/8. El CIDR de VPC puede especificarse desde /16 hasta /28. /28 tiene 16 direcciones (de las cuales solo 11 son utilizables) y es la VPC más pequeña. /16 tiene 65.536 direcciones y es el tamaño máximo predeterminado. En la práctica, /16 es excesivo en muchos casos. Si solo se ejecutan 100 instancias EC2, un /24 (256 direcciones) es suficiente. Sin embargo, dado que el CIDR de VPC no se puede reducir posteriormente (aunque sí ampliar), es seguro configurarlo con un tamaño mayor desde el principio. /16 es un valor predeterminado razonable que proporciona margen para futuras expansiones. No obstante, en entornos multi-VPC, asignar /16 indiscriminadamente agota rápidamente el espacio 10.0.0.0/8. Se agota con 256 VPCs, por lo que se necesita una asignación CIDR planificada.

Las 5 direcciones IP no utilizables en subredes

En las subredes de VPC, las primeras 4 y la última dirección IP de cada subred, un total de 5 direcciones, están reservadas por AWS y no pueden asignarse a instancias EC2 u otros recursos. En el caso de una subred /24 (10.0.1.0/24): 10.0.1.0 es la dirección de red, 10.0.1.1 es para el router de VPC, 10.0.1.2 es para el servidor DNS, 10.0.1.3 está reservada por AWS para uso futuro, y 10.0.1.255 es la dirección de broadcast. Es decir, de las 256 direcciones de una subred /24, solo 251 son realmente utilizables. Esta reserva de 5 direcciones tiene mayor impacto cuanto más pequeña es la subred. En una subred /28 (16 direcciones), con 5 reservadas, solo quedan 11 utilizables, lo que significa que aproximadamente el 31% no está disponible. Incluso para recursos que necesitan pocas ENI (Elastic Network Interface) como la conexión VPC de Lambda o NAT Gateway, se requiere un mínimo de /28. Si se diseñan subredes sin conocer estas direcciones reservadas, se enfrentará al problema de falta de direcciones IP.

Patrones de fallo en el diseño CIDR

El fallo más común en el diseño CIDR de VPC es la superposición de CIDR. Al conectar VPCs mediante VPC Peering o Transit Gateway, si los CIDR de las VPCs conectadas se superponen, el enrutamiento se vuelve imposible. Si se reutiliza el predeterminado 10.0.0.0/16 en todas las VPCs, la conexión entre VPCs se vuelve completamente imposible. El mismo problema ocurre con la conexión a redes on-premises (Direct Connect, Site-to-Site VPN). Si la red on-premises utiliza 10.0.0.0/8, y el CIDR de la VPC está en el rango 10.x.x.x, el enrutamiento entrará en conflicto. En este caso, es necesario usar los rangos 172.16.0.0/12 o 100.64.0.0/10 (direcciones CGN, RFC 6598) para la VPC. Otro patrón de fallo es dividir las subredes demasiado finamente. Si se crean muchas subredes /24, las direcciones IP de cada subred se limitan a 251, y cuando las instancias aumentan con Auto Scaling, las direcciones IP se agotan. Por el contrario, si las subredes son demasiado grandes, existe el riesgo de una distribución desigual entre AZs.

IPv6 y el futuro de VPC

AWS soporta IPv6 en VPC desde 2016. El CIDR IPv6 de VPC es /56 y AWS lo asigna automáticamente. Dado que el espacio de direcciones IPv6 es 2^128 (aproximadamente 340 undecillones), prácticamente infinito, no existen las preocupaciones de diseño CIDR propias de IPv4. Sin embargo, la migración completa a IPv6 aún está lejos. Muchas redes on-premises empresariales son solo IPv4, y algunos servicios de AWS tampoco soportan completamente IPv6. El enfoque realista es configurar la VPC con dual-stack (IPv4 + IPv6) e introducir IPv6 gradualmente desde las nuevas cargas de trabajo. El diseño CIDR de VPC es extremadamente importante desde el inicio, ya que una vez decidido es difícil de cambiar (se pueden agregar CIDRs a la VPC pero no eliminar ni modificar los existentes). En entornos multi-cuenta y multi-región, se recomienda usar IPAM (IP Address Manager) para gestionar centralizadamente el espacio de direcciones IP de toda la organización. Para aprender sistemáticamente los fundamentos del diseño de redes, puede consultar libros especializados (Amazon).

Servicios relacionados

Amazon VPCRed virtual aislada lógicamente en la nube de AWS donde puede lanzar recursosAWS Transit GatewayHub de red que conecta múltiples VPC y redes on-premises a través de un gateway central

Artículos relacionados

Diseño de red en Amazon VPC - Configuración de subredes y optimización de NAT GatewayPresentamos el diseño de separación de subredes públicas/privadas, la gestión por capas de Security Groups y la reducción de costos de NAT Gateway mediante Gateway VPC Endpoints.Red hub-and-spoke con AWS Transit Gateway - Diseño de conectividad multi-VPCAgregación de múltiples VPCs y redes on-premises en topología hub-and-spoke, estableciendo límites de seguridad con separación de tablas de rutas. También presentamos la conectividad multi-región mediante peering.Conectividad privada con AWS PrivateLink - VPC Endpoints y Endpoint ServicesAccede a servicios AWS y servicios de terceros de forma privada sin pasar por internet. Presentamos el diseño de Interface Endpoints y Gateway Endpoints.

Más sobre este tema

Construcción de service mesh con AWS App Mesh - Control de comunicación entre microservicios y observabilidadPresentamos cómo configurar de forma declarativa despliegues canary con sidecar Envoy, políticas de reintento y cifrado mTLS, y cómo visualizar las dependencias entre servicios con la integración de X-Ray.Descubrimiento de servicios con AWS Cloud Map - Resolución dinámica de nombres para microserviciosDescubra dinámicamente endpoints de microservicios usando enfoques basados en DNS y API. Aprenda cómo automatizar el registro y desregistro de servicios mediante integración con ECS y EKS.Cómo funcionan los más de 600 PoPs de CloudFront - Enrutamiento Anycast y la jerarquía de cachéAprenda cómo CloudFront enruta las solicitudes de los usuarios al PoP más cercano usando Anycast, la estructura de dos niveles de edge locations y cachés de borde regionales, y los factores de diseño que determinan las tasas de acierto de caché.Diseño de conexión dedicada - Conexión de red privada estable con Direct ConnectExplicamos las técnicas de diseño de conexión dedicada con AWS Direct Connect, presentando la selección entre conexión dedicada y conexión hospedada, la configuración redundante y la integración con VPC para lograr una conexión de red privada estable.Conexión dedicada con AWS Direct Connect - Configuración redundante y control de tráficoDiseñe configuraciones redundantes de conexión dedicada y conéctese a VPCs de múltiples regiones con Direct Connect Gateway. También presentamos la agregación de ancho de banda con LAG y el cifrado MACsec.Gestión y diseño de Elastic IP - Uso de IP estáticas y optimización de costosExplicamos la asignación de Elastic IP, la asociación con EC2, el impacto en costos de EIP no utilizadas y la consideración de alternativas.Por qué ELB tiene 3 tipos - La lógica de diseño detrás de la separación de ALB, NLB y CLBExplicamos por qué los 3 tipos de balanceadores de carga ALB, NLB y CLB (Classic) coexisten sin unificarse, desde la perspectiva de las capas del modelo OSI, las características de rendimiento y la evolución histórica.Optimización de red global con AWS Global Accelerator - Entrega de baja latencia y failoverAprende a enrutar tráfico hacia la red global de AWS usando IPs Anycast, diseñar grupos de endpoints y lograr failover mediante health checks.

Artículos y servicios similares

Amazon VPCServicio de red virtual aislada lógicamente dentro de AWS que permite definir subredes, tablas de rutas, gateways y controles de seguridad para desplegar recursos en una red personalizadaLa verdadera razón por la que NAT Gateway es caro - Estructura de tarifas de procesamiento de datos y estrategias de reducciónExplicación de la estructura de doble cobro de NAT Gateway, los patrones que inflan los costos de procesamiento de datos, la reducción de costos con VPC Endpoints, la alternativa de NAT Instance y la migración a IPv6.Diseño de red en Amazon VPC - Configuración de subredes y optimización de NAT GatewayPresentamos el diseño de separación de subredes públicas/privadas, la gestión por capas de Security Groups y la reducción de costos de NAT Gateway mediante Gateway VPC Endpoints.Gestión y diseño de Elastic IP - Uso de IP estáticas y optimización de costosExplicamos la asignación de Elastic IP, la asociación con EC2, el impacto en costos de EIP no utilizadas y la consideración de alternativas.