VPC, subredes y route tables

A las 03:00 un Auto Scaling group deja de lanzar instancias. El registro de eventos dice There are not enough free addresses in subnet subnet-0a1b2c3d to satisfy the requested number of instances. La subred es 10.0.4.0/27, el equipo la dimensionó para 32 instancias y solo llegaron a arrancar 27. No hay nada roto. La subred hizo exactamente lo que AWS documenta que hace, y nadie leyó esa parte antes de elegir la máscara.

La planificación de direcciones es la parte del diseño de una VPC que no se puede desandar. Una regla de security group se agrega en 10 segundos y se borra en otros 10. Un bloque CIDR no se puede redimensionar nunca. Por eso esta lección arranca con la aritmética de direcciones y sigue con la route table, que es la otra mitad de toda VPC y el primer lugar donde mirar cuando el tráfico se va a donde no debía.

Una VPC es un rango de direcciones más un router

Saca la consola del medio y una VPC son 2 cosas: un bloque de direcciones IP que reclamaste y un router implícito que AWS opera por ti dentro de ese bloque. Todo lo demás en este dominio, subredes, gateways, endpoints, peering, es una forma de decirle a ese router a dónde mandar los paquetes que todavía no sabe ubicar.

Cuando creas una VPC tienes que darle un bloque CIDR IPv4, y el tamaño permitido va desde un /16 (65.536 direcciones) hasta un /28 (16 direcciones). AWS recomienda un bloque de los rangos privados de la RFC 1918:

Hay 4 bloques que se rechazan de plano: 0.0.0.0/8, 127.0.0.0/8 (loopback), 169.254.0.0/16 (link-local) y 224.0.0.0/4 (multicast). Hay uno más que se permite pero conviene evitar: varios servicios de AWS, entre ellos AWS Cloud9 y SageMaker AI, usan 172.17.0.0/16 internamente, y elegirlo invita a conflictos dentro de esos entornos que después cuesta mucho diagnosticar.

También puedes correr una VPC sobre direcciones públicas enrutables que sean tuyas. AWS igual se niega a enrutar desde el CIDR de tu VPC directo a internet, y nunca anuncia el rango de una subred hacia internet, así que siempre sales por un gateway sin importar el tipo de direcciones.

Las decisiones de CIDR que no se pueden deshacer

Tres reglas hacen que equivocarse en el primer CIDR salga caro.

No puedes redimensionar un bloque CIDR. Ni agrandarlo ni achicarlo. Si 10.0.0.0/16 se llena, no lo conviertes en un /15.

No puedes quitar el CIDR primario. Sí puedes asociar bloques IPv4 secundarios (5 por VPC por defecto, ajustable hasta 50) y desasociarlos después. El bloque con el que creaste la VPC se queda mientras la VPC exista.

Los bloques secundarios quedan restringidos por el rango donde vive el primario. Si algún CIDR de la VPC viene de 10.0.0.0/8, AWS se niega a agregar un bloque de 172.16.0.0/12 o de 192.168.0.0/16. La exclusión aplica en las dos direcciones. AWS impone esto porque las funciones entre VPCs y entre cuentas del lado de AWS necesitan bloques que no choquen. Dentro de la misma regla hay 2 trampas más: si algún bloque asociado cae en 10.0.0.0/15, no puedes agregar uno de 10.0.0.0/16, y un bloque secundario nuevo no puede ser igual ni más grande que un CIDR de destino que ya viva en alguna de tus route tables.

Agregar un CIDR secundario hace una cosa automáticamente: aparece una nueva ruta local en todas las route tables de esa VPC, con el bloque nuevo como destino.

Con IPv6 la forma es distinta. Pides un bloque del pool de Amazon y no eliges el rango; una asignación típica se ve como 2001:db8:1234:1a00::/56. Puedes asociar hasta 5 bloques IPv6 por VPC, de /44 a /60 en incrementos de /4. Toda dirección IPv6 provista por Amazon es globalmente única y por lo tanto pública por defecto, y eso se vuelve la historia completa en la próxima lección.

Una subred vive en exactamente una zona de disponibilidad

Una subred es una porción del rango de la VPC, y vive entera dentro de una sola zona de disponibilidad. No puede abarcar varias. Esa única frase define la forma de todas las VPC que vas a construir: para correr una carga de 2 capas en 3 zonas necesitas 6 subredes, no 2.

Los bloques IPv4 de subred van de /28 a /16, tienen que estar dentro del bloque de la VPC y no se pueden superponer entre sí. La cuota por defecto es de 200 subredes por VPC. Para IPv6, las máscaras de subred van de /44 a /64 en incrementos de /4, y un /64 es la elección convencional.

Los tipos de subred que ves nombrados en las preguntas de examen se definen puramente por ruteo, no por un ajuste:

Sí existe un ajuste real en la subred, y vale conocerlo porque se confunde seguido con la distinción pública/privada: el auto-assign IP setting, que decide si una interfaz de red creada en esa subred recibe automáticamente una dirección IPv4 pública, y una IPv6 si corresponde. Puedes sobreescribirlo por instancia al momento del lanzamiento. Controla si la instancia tiene dirección pública, no si el tráfico puede llegar a internet. Hacen falta las 2 cosas, y se configuran en 2 lugares distintos.

A dónde se van 5 direcciones en cada subred

Volvamos al aviso de las 03:00. En una subred con CIDR 10.0.1.0/28, AWS reserva las primeras 4 direcciones y la última:

Entran 16 direcciones, salen 11. La pérdida es de 5 fijas en cualquier tamaño, así que golpea fuerte a las subredes chicas y apenas se nota en las grandes:

Acá vive el error predecible. On-premises aprendes que una subred pierde 2 direcciones, la de red y la de broadcast, y esa regla es correcta en casi todos lados menos en AWS. AWS se queda con 3 más. Si dimensionas una subred restando 2, te van a faltar 3 justo cuando importa, durante un evento de escalado.

Una nota sobre 10.0.1.2. El Route 53 Resolver que tus instancias consultan de verdad vive en la base del rango de la VPC más 2, y en una VPC con varios bloques CIDR queda en el bloque primario. AWS igual reserva base más 2 en cada subred de cada bloque, y por eso la dirección no está disponible en ninguna subred aunque solo una aloje al resolver.

Hay 2 consumidores más de direcciones de subred que sorprenden durante la planificación de capacidad: un NAT gateway toma una dirección privada de la subred donde vive, y cada interface VPC endpoint toma una por subred donde esté habilitado. Ninguno aparece como instancia.

Dimensionar una VPC real

Toma una carga con capa web y capa de base de datos en 2 zonas de disponibilidad, con expectativa de crecer.

VPC             10.0.0.0/16      65.536 direcciones

Pública  AZ-a   10.0.0.0/24         251 utilizables  (nodos del ALB, NAT gateway)
Pública  AZ-b   10.0.1.0/24         251 utilizables

Privada  AZ-a   10.0.16.0/20      4.091 utilizables  (instancias de aplicación)
Privada  AZ-b   10.0.32.0/20      4.091 utilizables

Datos    AZ-a   10.0.48.0/24        251 utilizables  (subnet group de RDS)
Datos    AZ-b   10.0.49.0/24        251 utilizables

Dos cosas de este diseño son deliberadas. Las subredes públicas son chicas porque los nodos del load balancer y un NAT gateway necesitan muy pocas direcciones, y las privadas son generosas porque ahí es donde ocurre el escalado. Además los bloques quedan espaciados en vez de pegados uno tras otro, lo que deja lugar para tallar 10.0.64.0/20 y siguientes para una tercera zona o una capa nueva sin renumerar nada.

Verifica la capacidad desde la CLI y no desde una planilla:

aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=vpc-0abc123def4567890" \
  --query "Subnets[].{Subnet:SubnetId,AZ:AvailabilityZone,CIDR:CidrBlock,Free:AvailableIpAddressCount}" \
  --output table

AvailableIpAddressCount es el número que importa durante un incidente. Ya descuenta las 5 direcciones reservadas y todo lo que está desplegado en este momento.

Las route tables deciden a dónde van los paquetes

Toda subred tiene que estar asociada a una route table. O la asocias explícitamente, o la subred queda asociada de forma implícita a la main route table de la VPC, que AWS crea junto con la VPC.

Cada ruta tiene un destino (un bloque CIDR o una prefix list) y un target (un internet gateway, un NAT gateway, una interfaz de red, una conexión de peering, un transit gateway, y así). El router compara la dirección de destino del paquete contra los destinos de la tabla y le entrega el paquete al target que coincide.

Cada route table también contiene una ruta local, una por bloque CIDR asociado, contando IPv4 e IPv6 por separado. Cubre el tráfico interno de la VPC, se agrega automáticamente y no se puede borrar. Sí puedes reemplazar o restaurar su target, y puedes agregar una ruta más específica que la local siempre que el destino coincida con el CIDR completo de una subred y el target sea un NAT gateway, una interfaz de red o un endpoint de Gateway Load Balancer. Esa excepción existe para poder forzar el tráfico entre 2 subredes a través de un appliance de inspección.

La main route table tiene sus propias reglas. Puedes editar sus rutas pero no borrarla, no puedes convertir una gateway route table en la principal, y sí puedes reemplazarla haciendo principal a una tabla personalizada. AWS recomienda dejarla solo con la ruta local y asociar cada subred de forma explícita, y hay una razón filosa detrás de esa recomendación. Pon una ruta 0.0.0.0/0 hacia un internet gateway en la main route table y toda subred que crees desde ese momento, hasta que alguien la asocie a otra tabla, es una subred pública. Nadie planea hacer eso. Pasa cuando se agrega una ruta a la tabla que estaba abierta en la consola.

Cuotas que conviene recordar: 200 route tables por VPC, 500 rutas no propagadas por route table (ajustable a 1.000) y 100 rutas propagadas, que no es ajustable.

Dos rutas coinciden. ¿Y ahora?

Las route tables no son listas de reglas de firewall. No se evalúan de arriba hacia abajo y no hay ningún orden que razonar. AWS elige la ruta que coincide y es más específica, o sea el prefijo más largo.

Recorre una tabla:

Un paquete para 172.31.5.10 coincide con 172.31.0.0/16 y con 0.0.0.0/0. El /16 es más específico, así que el paquete se va a la conexión de peering. Un paquete para 93.184.216.34 coincide solo con 0.0.0.0/0 y sale por el internet gateway. Un paquete para 10.0.4.19 coincide con la ruta local y nunca deja la VPC.

Cuando 2 rutas tienen el mismo destino, el empate se rompe con una escalera de prioridad:

1. Prefijo más largo (esto resuelve la mayoría de los casos antes de que importe el resto)
2. Rutas estáticas
3. Rutas de prefix list
4. Rutas propagadas, en el orden rutas BGP de Direct Connect, luego rutas estáticas de VPN, luego rutas BGP de VPN

Las rutas estáticas son las que creas tú, más las que crean un internet gateway, un NAT gateway, una interfaz de red, un ID de instancia, un gateway VPC endpoint, un transit gateway, una conexión de VPC peering o un endpoint de Gateway Load Balancer. Las propagadas son las que aparecen solas cuando adjuntas un virtual private gateway y habilitas la propagación de rutas.

Esta escalera produce una de las fallas más silenciosas de las redes en AWS. Una VPC híbrida propaga 172.31.0.0/24 desde la red on-premises por un virtual private gateway. Después alguien agrega una ruta estática para el mismo 172.31.0.0/24 hacia un internet gateway. No falla nada. Gana la ruta estática, y el tráfico que debía cruzar la VPN se va derecho a internet. Si un escenario dice que el tráfico hacia un centro de datos está "saliendo por el internet gateway", busca una ruta estática que esté tapando a la propagada.

Hay 2 rangos que no se pueden enrutar en absoluto: 169.254.168.0/22 para IPv4 y fd00:ec2::/32 para IPv6. AWS los reserva para servicios alcanzables únicamente desde las instancias, como el Instance Metadata Service y el servidor DNS de Amazon. Un bloque más grande que los contenga sí se acepta, pero los paquetes apuntados dentro del rango reservado no se reenvían.

Tips de examen

• Aritmética de direcciones de subred: resta 5, nunca 2. Un /24 da 251 utilizables, un /28 da 11. Los errores de direcciones insuficientes durante el escalado son esta cuenta.
• Pública contra privada es una propiedad de la route table, nunca de la subred. Una pregunta que diga "la subred estaba configurada como privada" está describiendo una route table, y el arreglo siempre es de ruteo.
• Llegar a internet exige las 2 cosas: una ruta al internet gateway y una dirección IPv4 pública o IPv6 en el recurso. Si falta cualquiera de las 2, el síntoma es el mismo.
• Una subred sin asociación explícita usa la main route table. Así es como las subredes se vuelven públicas por accidente.
• El prefijo más largo resuelve las rutas superpuestas. Las route tables no tienen orden de evaluación, así que "la primera ruta que coincide" siempre es una respuesta equivocada.
• Destinos idénticos: la estática le gana a la propagada. Ojo con esto en escenarios híbridos donde el tráfico sale por el gateway equivocado.
• No puedes redimensionar un bloque CIDR ni quitar el CIDR primario. Si una opción te ofrece ampliar el CIDR de una VPC en el lugar, está mal.
• Restricción de CIDR secundario: una VPC que usa un rango RFC 1918 no puede agregar un bloque de otro rango RFC 1918.
• Una subred vive en una sola zona de disponibilidad. Multi-AZ significa más subredes, no subredes más grandes.
• La ruta local no se puede borrar. Sí se le puede reemplazar el target, y se puede sobreescribir con una ruta más específica cuyo destino sea el CIDR completo de una subred y cuyo target sea un NAT gateway, una interfaz de red o un endpoint de Gateway Load Balancer.

El hábito que conviene llevarse es que una VPC responde exactamente 2 preguntas sobre cualquier paquete: ¿esta dirección me pertenece?, y si no, ¿a qué target se lo entrego? La planificación de direcciones responde la primera, las route tables responden la segunda, y casi todo ticket de conectividad de este dominio es una de esas 2 respuestas estando mal. La próxima lección toma el target más común que vas a poner en una route table, los gateways que conectan una VPC con internet, y muestra por qué existen 3 en vez de uno.