Máscaras de Red: La Decisión Estratégica que Define tus Límites de Escalabilidad
Por qué el /16 por defecto es deuda técnica latente, cómo dimensionar con el autoescalado en mente y una tabla de decisiones de subnetting para arquitectos cloud-native.
Máscaras de Red: La Decisión Estratégica que Define tus Límites de Escalabilidad
Hay decisiones de arquitectura que se toman en cinco minutos y se pagan durante cinco años. Elegir la máscara de red de un VPC es una de ellas. En quince años diseñando infraestructuras híbridas y nativas de cloud, he visto migraciones enteras descarrilar no por un fallo de código, ni por una base de datos mal dimensionada, sino por un /16 que alguien puso "por si acaso" el primer día del proyecto.
Este artículo no va sobre cómo convertir binario a decimal. Va sobre por qué la máscara que eliges es, en realidad, un contrato de escalabilidad con tu yo del futuro. Y sobre cómo firmar ese contrato sin arruinarte.
El error del /16 por defecto
Cuando arranca un proyecto, el 10.0.0.0/16 parece la opción sensata: 65.536 direcciones, espacio de sobra, nadie se va a quejar. Es cómodo. También es, casi siempre, un error de diseño disfrazado de prudencia.
El problema no es matemático, es operativo. Un /16 plano concentra tres patologías que solo aparecen cuando el entorno ya está en producción y es tarde para moverse:
Seguridad diluida. Una red enorme y plana invita a reglas de firewall perezosas. Cuando todo vive en el mismo rango, los Security Groups y las Network ACLs terminan escritos como allow 10.0.0.0/16 porque segmentar "a mano" dentro de ese océano es tedioso. El resultado es un radio de explosión gigantesco: un pod comprometido puede hablar con la base de datos de producción, con el bastion y con el clúster de otro equipo, todo dentro del mismo dominio de confianza implícito.
Ruido de broadcast y descubrimiento. Aunque en la nube el broadcast tradicional está limitado, los mecanismos de service discovery, ARP en capas de overlay y el propio churn de IPs efímeras en Kubernetes generan tráfico de control que crece con el tamaño del segmento. Rangos innecesariamente grandes significan tablas de rutas más pesadas y más entradas que propagar entre nodos.
Desorden documental. Este es el asesino silencioso. En una empresa con veinte equipos, un /16 sin subnetting deliberado se convierte en tierra de nadie: nadie sabe qué rango usa quién, las IPs se asignan por WhatsApp, y dos años después nadie se atreve a tocar nada por miedo a romper algo. La máscara grande no da orden; da permiso para el caos.
La regla mental: un rango grande no es capacidad, es deuda técnica latente. El espacio que no planificas hoy es el conflicto que negociarás mañana.
Planificación de crecimiento: Capacity Planning real
Dimensionar una red no es preguntar "¿cuántas IPs necesito?", sino "¿cuántas necesitaré cuando esto funcione demasiado bien?". El escenario que mata no es el fracaso, es el éxito: el servicio despega, el Horizontal Pod Autoscaler dispara réplicas, y de repente tu subnet /26 de 62 hosts se queda sin direcciones a mitad de un pico de tráfico de Black Friday.
En Kubernetes esto es especialmente traicionero. Cada pod consume una IP del CIDR de la subnet (con CNIs como el VPC CNI de AWS, la IP sale directamente del espacio del VPC). Un HPA configurado para escalar de 3 a 40 réplicas no solo necesita CPU: necesita 40 direcciones IP disponibles ya. Si no están, los pods se quedan en Pending con un elegante failed to assign an IP address to container, y tu autoescalado se convierte en autobloqueo.
La fórmula práctica para dimensionar cada subnet o clúster:
- Cuenta la carga base actual (pods, nodos, endpoints, IPs de servicios internos).
- Suma el techo del autoescalado (
maxReplicasde tus HPA, más los nodos que el Cluster Autoscaler puede añadir). - Añade las IPs reservadas del proveedor (AWS reserva 5 por subnet; nunca las olvides).
- Aplica la regla de oro.
Regla práctica innegociable: reserva siempre un 30% de IPs libres por encima de tu cálculo actual. No es desperdicio, es la amortiguación que te permite absorber picos, migraciones azul-verde (que duplican temporalmente los pods) y el crecimiento orgánico sin re-subnetear en caliente.
Ese 30% es la diferencia entre una migración blue-green tranquila y un incidente a las 3 de la mañana. Cuando despliegas la versión nueva junto a la vieja antes de cortar el tráfico, necesitas espacio para el doble de endpoints durante unos minutos. Si dimensionaste al límite, no hay despliegue sin downtime.
El dolor de cabeza del solapamiento (Overlapping CIDR)
Si hay una lección que todo arquitecto aprende por las malas, es esta: dos redes que se solapan no se pueden conectar. Punto. No hay peering, no hay VPN, no hay Transit Gateway que lo arregle sin renumerar.
El caso clásico, que he visto repetirse en decenas de organizaciones: el equipo A crea su VPC de producción como 10.0.0.0/16. Meses después, el equipo B —o una empresa que acabas de adquirir— crea el suyo, también como 10.0.0.0/16, porque es "el rango por defecto". Todo funciona perfectamente... hasta el día en que negocio pide integrar ambos entornos.
Entonces intentas el VPC Peering y AWS te devuelve el temido Blackhole / overlapping CIDR blocks. El peering se puede crear, pero las rutas no funcionan porque el router no sabe si 10.0.1.5 es de A o de B. Lo mismo ocurre con una VPN Site-to-Site hacia el datacenter on-premise si este ya usa 10.0.0.0/16, y con un Transit Gateway que se niega a propagar rutas ambiguas.
Las salidas son todas dolorosas: o renumeras uno de los entornos (semanas de trabajo y ventanas de downtime), o metes un NAT de traducción de direcciones en medio (complejidad y latencia extra), o levantas un Private NAT Gateway para enmascarar rangos. Ninguna es gratis.
La prevención, en cambio, es casi gratis. En lugar de dar a cada VPC un /16 codicioso, se asigna a la organización un supernet (por ejemplo 10.0.0.0/8 gestionado con IPAM) y se reparten retículas pequeñas y no solapadas:
- VPC de producción región 1:
10.10.0.0/20(4.096 IPs) - VPC de staging región 1:
10.20.0.0/22(1.024 IPs) - VPC de la filial adquirida:
10.30.0.0/20
Con /20 y /22 cada entorno tiene espacio de sobra para crecer, y aún quedan cientos de bloques libres para futuras VPCs, todos garantizadamente no solapados. El peering, la VPN y el Transit Gateway funcionan a la primera. La disciplina en la máscara hoy es lo que hace posible la interconexión mañana.
Casos de uso extremo: /32, /31 y /28
Las máscaras "raras" no son curiosidades académicas; resuelven problemas concretos de arquitectura:
/32 — La dirección única (host route). Un /32 describe una sola IP. Es el pan de cada día para loopbacks de routers y switches, para IPs de NAT (una Elastic IP en AWS es conceptualmente un /32), y para reglas de firewall quirúrgicas del tipo "solo esta IP exacta puede llegar al endpoint de administración". En BGP y en las tablas de rutas, los host routes /32 permiten anunciar servicios individuales con precisión milimétrica.
/31 — El enlace punto a punto. Durante años los enlaces entre dos routers desperdiciaban un /30 (4 direcciones: red, dos hosts y broadcast) para conectar solo dos interfaces. El /31 (RFC 3021) elimina ese desperdicio: 2 direcciones, ambas usables como hosts, sin red ni broadcast. En backbones con miles de enlaces P2P, pasar de /30 a /31 recupera la mitad del espacio de interconexión. Es la elección profesional para links entre routers y para interconexiones de fabric en datacenter.
/28 — El clúster de IPs fijas. Un /28 da 16 direcciones (14 útiles). Es el tamaño ideal para un conjunto pequeño y estable de recursos que necesitan direccionamiento predecible: los nodos de un clúster de base de datos, un grupo de balanceadores, un pool de appliances. Suficientes IPs para el clúster y sus miembros de reserva, lo bastante pequeño para documentarlo de un vistazo y protegerlo con reglas estrictas.
La cuadrícula mágica para arquitectos
Olvida la tabla de conversión binaria que memorizaste para la certificación. Lo que un arquitecto necesita no es saber cuántos hosts caben en un /26, sino qué máscara corresponde a qué intención de diseño. Esta es la tabla de decisiones que uso en las pizarras:
| Situación de diseño | Máscara | Por qué |
|---|---|---|
| Entre 10 y 20 servicios estables en una subnet | /24 (254 hosts) | El estándar mental de la industria: legible, documentable, cómodo. Si dudas, empieza aquí. |
| Microservicios efímeros con autoescalado agresivo | /23 (510 hosts) | El churn de IPs de pods efímeros agota rápido un /24; el /23 da colchón sin llegar al derroche. |
| DMZ expuesta a internet | /27 (30 hosts) | Pequeña a propósito: menos IPs = menor superficie, aislamiento estricto y reglas fáciles de auditar. |
| VPC completo de producción | /20 (4.094 hosts) | Suficiente para múltiples subnets internas sin caer en el /16 monolítico. |
| Enlace P2P entre routers | /31 (2 hosts) | Cero desperdicio en interconexiones. |
| Clúster de base de datos con IPs fijas | /28 (14 hosts) | Direccionamiento predecible y perímetro reducido. |
La lógica de fondo: el tamaño de la máscara debe reflejar el nivel de confianza y volatilidad del segmento. Cuanto más expuesto y sensible (DMZ), más pequeño y aislado. Cuanto más dinámico y efímero (microservicios), más holgura para el churn.
Tabla de Segmentos por Estrato Arquitectónico
Esta es la referencia que debería estar pegada en la pared de todo equipo de plataforma. No está ordenada por número, sino agrupada por propósito arquitectónico. Las filas en negrita son las que usarás a diario.
Estrato de núcleo y VPCs troncales
| CIDR | Total / Útiles | Segmento RFC 1918 | Caso de uso moderno | Riesgo principal | Escalado |
|---|---|---|---|---|---|
| /16 | 65.536 / 65.534 | 10.0.0.0 | Supernet corporativo gestionado por IPAM (no como VPC plano) | Broadcast innecesario y desorden documental si se usa plano | Solo como contenedor lógico; nunca asignar plano |
| /20 | 4.096 / 4.094 | 10.x.x.x | VPC completo de producción, subdividido internamente | Sobredimensión si el proyecto es pequeño | Divisible en 16 /24 sin recolocar |
| /22 | 1.024 / 1.022 | 172.16.x.x | Worker nodes de K8s y microservicios efímeros con HPA | Agotamiento por churn si el autoescalado es agresivo | Ampliable a /21 reservando el bloque contiguo |
Estrato de aplicación y datos
| CIDR | Total / Útiles | Segmento RFC 1918 | Caso de uso moderno | Riesgo principal | Escalado |
|---|---|---|---|---|---|
| /24 | 256 / 254 | 10.x.x.x / 192.168.x.x | Subnet de aplicación estándar, 10-20 servicios | Se queda corto para pods efímeros a gran escala | Ampliable a /23 sin recolocar si reservas el vecino |
| /25 | 128 / 126 | 172.16.x.x | Tier de aplicación de tamaño medio, backends internos | Re-subneting a los 2 años si el servicio crece | Migrar a /24 |
| /28 | 16 / 14 | 10.x.x.x | Bases de datos en clúster (RDS multi-AZ), pools de LB con IP fija | Agotamiento inmediato si se añaden réplicas | Planificar /27 desde el inicio si se prevé crecimiento |
Estrato de borde, seguridad e interconexión
| CIDR | Total / Útiles | Segmento RFC 1918 | Caso de uso moderno | Riesgo principal | Escalado |
|---|---|---|---|---|---|
| /27 | 32 / 30 | 192.168.x.x | DMZ con proxies inversos y appliances expuestos | Superficie de ataque si se sobredimensiona | Mantener pequeño a propósito; no ampliar sin revisión de seguridad |
| /29 | 8 / 6 | 172.16.x.x | Peering con redes de socios, subnets de tránsito | Alto riesgo de solapamiento si no se coordina el rango | Coordinar con IPAM central antes de asignar |
| /30 | 4 / 2 | 10.x.x.x | Enlaces punto a punto legacy, túneles VPN | Desperdicio del 50% frente a /31 | Migrar a /31 en equipos que lo soporten |
Checklist final antes de definir el CIDR de un nuevo proyecto
Antes de escribir el bloque CIDR en Terraform y pulsar apply, respóndete estas cinco preguntas. Si fallas una, aún estás a tiempo de corregirlo gratis:
- ¿Este rango se solapa con ALGÚN entorno con el que podría necesitar conectarme jamás? (Otras VPCs, on-premise, redes de socios, futuras adquisiciones). Consúltalo contra el IPAM central, no contra tu memoria.
- ¿He dimensionado sumando el techo del autoescalado —no la carga actual— y he añadido el 30% de colchón?
- ¿La máscara refleja el nivel de exposición del segmento? (DMZ pequeña y aislada; backend interno holgado).
- ¿Puedo crecer sin renumerar? ¿Está libre el bloque contiguo para ampliar de
/24a/23cuando llegue el momento? - ¿Está documentado y registrado en el IPAM antes de crear el recurso, o lo estoy asignando "a ojo"?
Conclusión: el mantra que todo arquitecto debe memorizar
La máscara de red no es un detalle de configuración: es la primera decisión de escalabilidad que tomas en un proyecto, y la más cara de revertir. Un rango mal elegido no falla el día uno; falla el día en que por fin tienes éxito, cuando el tráfico crece, cuando llega la fusión, cuando el negocio pide integrar todo. Para entonces, cambiarlo cuesta ventanas de mantenimiento, riesgo y noches sin dormir.
Por eso conviene grabarse esta idea a fuego:
Elige tu máscara como eliges un contenedor: ni muy grande para que no se desperdicie espacio, ni muy pequeño para que no se desborde al primer pico de tráfico.
Dimensiona con intención, reserva con disciplina, documenta sin excepciones. Tu arquitectura —y tu yo del futuro— te lo agradecerán.
