Redes virtuales y CIDR sin fórmulas de memoria
Toda arquitectura en la nube arranca por una red privada partida en subredes. Leer la notación CIDR y planificar los rangos antes de crear nada evita el error más caro de corregir después.
Para este tema conviene tener claro:Direccionamiento IP y ruteo
Datos de proveedores verificados contra la documentación oficial el 15 de sept de 2026.
Lo primero que se crea en una cuenta de nube casi nunca es un servidor: es una red. Y
lo primero que te pregunta esa red es un número raro, algo como 10.0.0.0/16. Casi todos
aceptan el valor por defecto y siguen. Funciona hasta el día en que hay que conectar esa
red con otra que eligió el mismo número, y ahí no hay botón para arreglarlo.
Una red propia dentro de la nube
Cada proveedor te da una red privada y aislada donde viven tus recursos. Se llama distinto y tiene un alcance distinto, pero la idea es la misma: un rango de direcciones que es tuyo, partido en subredes.
| AWS | Google Cloud | Azure | |
|---|---|---|---|
| Cómo se llama | VPC | VPC | Virtual Network (VNet) |
| Alcance de la red | Una región | Global: abarca todas las regiones | Una región |
| Alcance de una subred | Una zona de disponibilidad | Una región | Una región, con todas sus zonas |
| Direcciones reservadas por subred | 5 | 4 | 5 |
La consecuencia más práctica de la tabla: en AWS, para repartir un servicio en dos zonas necesitás dos subredes, una por zona. En Google Cloud y en Azure, una sola subred ya cubre todas las zonas de la región.
Leer una notación CIDR
Una dirección IPv4 son 32 bits, escritos como cuatro números de 0 a 255. La notación CIDR agrega una barra y un número: cuántos de esos 32 bits están fijos. Los que quedan libres son las direcciones del bloque.
Qué dice 10.0.0.0/16
- El
/16fija los primeros 16 bits, que son los dos primeros números:10.0. - Quedan 32 − 16 = 16 bits libres, así que el bloque tiene direcciones.
- Va desde
10.0.0.0hasta10.0.255.255: los dos últimos números recorren todo. - Cada bit más en el prefijo parte el bloque a la mitad: una
/17tiene 32.768.
Antes de seguir, predecí
| Prefijo | Direcciones | Uso típico |
|---|---|---|
| /16 | 65.536 | La red entera de un entorno |
| /20 | 4.096 | Subred privada para aplicaciones o contenedores |
| /24 | 256 | Subred pública para balanceadores |
| /28 | 16 | Lo mínimo que acepta AWS |
Partir la red en subredes
Las subredes son bloques más chicos dentro del de la red, y no se pueden pisar entre sí. Antes de probar:
Antes de seguir, predecí
Esta es una red típica de AWS: dos subredes públicas chicas y dos privadas grandes. Probá
cambiar publica-b a 10.0.0.128/25 y mirá cómo se marca la superposición. Después pasá el
proveedor a Google Cloud o Azure y fijate qué cambia en las direcciones utilizables.
Escena 1 — Una red partida en subredes
partila
Cargando la escena…
Direcciones que no podés usar
Una /24 tiene 256 direcciones, pero no podés asignar las 256. Cada proveedor se guarda
algunas en cada subred:
- AWS reserva 5: la dirección de red, la siguiente para el router de la VPC, la siguiente para el DNS, una más para uso futuro y la última.
- Google Cloud reserva 4: la dirección de red, la siguiente para el gateway, la anteúltima y la última.
- Azure reserva 5: la dirección de red, la siguiente para el gateway, dos más para el DNS de Azure y la última.
Planificar antes de crear
Las redes privadas usan los rangos que el RFC 1918 reserva para eso: 10.0.0.0/8,
172.16.0.0/12 y 192.168.0.0/16. Dentro de esos rangos elegís libremente, y justamente
por eso todo el mundo elige lo mismo.
Escribir la red como código ayuda a que el plan sea explícito. En Terraform, la función
cidrsubnet hace la misma cuenta que el planificador de arriba:
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
}
resource "aws_subnet" "private" {
count = 2
vpc_id = aws_vpc.main.id
cidr_block = cidrsubnet(aws_vpc.main.cidr_block, 4, count.index + 1)
availability_zone = data.aws_availability_zones.available.names[count.index]
}cidrsubnet("10.0.0.0/16", 4, 1) suma 4 bits al prefijo y toma el bloque número 1: da
10.0.16.0/20. El siguiente es 10.0.32.0/20. Son las dos subredes privadas de la escena.
Más a fondo · nivel seniorUn plan de direcciones para toda la organización
Cuando hay varias cuentas, regiones y entornos, el rango de cada red deja de ser una decisión local y pasa a ser un recurso compartido que alguien tiene que administrar:
- Reservá por jerarquía: un bloque grande por región, adentro uno por entorno, y adentro las redes de cada equipo. Dejá huecos para crecer: agregar una región no tendría que obligar a renumerar nada.
- Contá los pods de Kubernetes. En EKS, con el plugin de red de AWS, cada pod toma una dirección privada de la VPC, así que el tamaño de las subredes limita cuántos pods entran. GKE toma las direcciones de los pods de un rango secundario de la subred, que también hay que planificar. En AKS depende del modo de red: con overlay, que hoy es el predeterminado, los pods usan un rango aparte y no gastan direcciones de la VNet.
- Usá una herramienta de administración de direcciones en vez de una planilla: AWS tiene VPC IPAM, y en las otras nubes lo mismo se resuelve con la infraestructura como código y un registro central de rangos.
- Considerá IPv6 para lo que tiene que escalar mucho: el problema de quedarse sin direcciones privadas desaparece, aunque aparecen otros de compatibilidad.
Lo que preguntan sobre esto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica