Qué es una VPC: la guía que evita errores de red

En pocas palabras: Una VPC (AWS, GCP) o VNet (Azure, de Microsoft) es una red privada y aislada dentro de un proveedor cloud. Ambas usan bloques CIDR, de /16 (65.536 IPs) a /28 (16 IPs) según AWS, y dos redes con el mismo rango no pueden conectarse entre sí.

Dos equipos planifican un despliegue en la nube, cada uno con su propio rango de direcciones, y nadie revisa si coinciden. Cuando llega el momento de conectar ambas redes, la respuesta es no: una VPC (en AWS o GCP) o una VNet (en Azure) con el mismo bloque CIDR que otra red no se puede unir a ella, ni con peering ni con Transit Gateway. Es un problema de diseño, no de configuración.

Una VPC o VNet es una red privada y aislada dentro de la infraestructura de un proveedor cloud, donde nada entra ni sale hasta que el usuario define las reglas. El bloque CIDR (Classless Inter-Domain Routing) es el rango de direcciones IP que esa red tiene permitido usar, y según la documentación oficial de AWS va de una máscara /16 (65.536 IPs) a /28 (16 IPs). Definir ese rango es el primer paso, antes de levantar cualquier servidor o cluster.

¿Qué es un bloque CIDR y por qué hay que definirlo antes de desplegar algo en la nube?

Un bloque CIDR es el rango de direcciones IP que le asignás a tu VPC o VNet, y determina cuántos recursos puede alojar esa red antes de necesitar expansión. No podés crear un servidor, una base de datos o un cluster de Kubernetes hasta decidir ese rango, porque todo lo que construyas después depende de esa decisión.

Pensalo como un barrio cerrado. El proveedor cloud es el país donde se ubica. Tu VPC o VNet es el barrio en sí, con su propio límite. Las subredes son las calles internas. El gateway es la entrada principal, por donde entra y sale el tráfico. Los security groups y las reglas de firewall son las cerraduras de cada puerta individual.

Ponele que estás armando la red para un cluster nuevo. Elegís el rango 10.0.0.0/16 porque es el que viene por default en casi todos los tutoriales. Funciona bárbaro en el ambiente de pruebas. El problema aparece cuando ese cluster necesita hablar con otra red que, adivinaste, también usa 10.0.0.0/16. Esto se conecta con lo que analizamos en conectarte por SSH a una VM en Azure.

¿Por qué dos redes con el mismo rango de IP no se pueden conectar?

Dos redes con bloques CIDR idénticos no se pueden conectar porque la tabla de enrutamiento no puede distinguir entre direcciones repetidas. No es una limitación técnica que se resuelve con más configuración: es matemáticamente imposible, según explica el caso documentado en el artículo de Pipeline & Prompts.

La analogía es simple: si tu barrio y el mío tienen una calle llamada “10.0.1.0”, y alguien construye un puente entre ambos, el cartero no sabe a cuál de las dos casas entregar la correspondencia. VPC peering, VNet peering, Transit Gateway, ninguno de estos mecanismos puede resolver esa ambigüedad.

¿Y esto pasa seguido? Más de lo que parece. El artículo describe un caso real: un cliente estaba planificando un despliegue de Azure Red Hat OpenShift (ARO) y, al comparar los rangos de red existentes con el nuevo ambiente que se estaba diseñando, aparecieron superpuestos. No se rompió nada porque lo detectaron antes de desplegar, pero hizo falta que un ingeniero de redes de Microsoft se sumara a la conversación para resolverlo.

¿Cómo funciona una VPC en AWS?

En AWS, una VPC es regional: cada subred dentro de ella vive en una única zona de disponibilidad. Si necesitás redundancia, tenés que crear subredes separadas en distintas zonas, y definir cuáles son públicas (accesibles desde internet) y cuáles privadas.

Según la documentación oficial de AWS, el bloque CIDR primario de una VPC admite entre /16 y /28, y se recomienda usar rangos privados de la RFC 1918 (10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16). Ojo con un detalle que no es obvio: AWS restringe la mezcla de rangos de distintos bloques RFC 1918 en la misma VPC. Si tu CIDR primario es 10.0.0.0/8, no podés asociar un bloque secundario de 172.16.0.0/12 ni de 192.168.0.0/16.

Hay otro dato que conviene tener presente: algunos servicios de AWS, como Cloud9 y SageMaker AI, usan por default el rango 172.17.0.0/16. Si tu VPC ocupa ese mismo rango, te vas a encontrar con conflictos de IP que no tienen nada que ver con tu diseño de red, sino con un servicio interno de AWS. Ya lo cubrimos antes en certificarte en Azure según tu rol.

¿Cómo funciona una VNet en Azure?

Una VNet en Azure funciona bajo el mismo principio que una VPC: es regional, y su bloque CIDR tiene que planificarse antes de desplegar cualquier recurso encima. La diferencia es de nombre, no de lógica.

El caso real que mencionamos arriba es justamente sobre esto. El cliente estaba armando un ambiente de Azure Red Hat OpenShift, y el CIDR de la VNet tenía que coexistir con la red que el cliente ya tenía corriendo. Nadie había chequeado esa superposición antes, y resolverla implicó frenar la planificación hasta revisar el diseño completo de la VNet contra los rangos existentes.

Ese tipo de freno, cuando se detecta a tiempo, cuesta una reunión. Cuando se detecta después del despliegue, cuesta rediseñar un ambiente que ya está en producción: el mismo tipo de trabajo costoso y mal documentado que aparece cuando la Infraestructura como Código no fue planificada para absorber cambios de este tipo, y termina resolviéndose con parches manuales por fuera del código original.

¿Por qué las VPC de Google Cloud son globales y no regionales?

En Google Cloud, la VPC es global: una sola VPC puede abarcar todas las regiones del proveedor, mientras que en AWS y Azure cada VPC o VNet está atada a una región específica. Las subredes dentro de esa VPC global siguen siendo regionales, pero el contenedor de arriba no tiene ese límite. Tema relacionado: cómo se compara Microsoft frente a GitHub.

Es una diferencia estructural real, no un detalle cosmético. Dicho esto, la disciplina de fondo no cambia: necesitás reservar rangos de direcciones que no se superpongan con nada a lo que esa red vaya a tener que conectarse, sea cual sea la forma que tome la arquitectura.

¿En qué situaciones reales aparece el problema del solapamiento de direcciones IP?

El solapamiento de rangos CIDR aparece sobre todo en tres escenarios: fusiones y adquisiciones de empresas, proyectos híbridos entre infraestructura on-premise y la nube, y despliegues de Kubernetes administrado como ARO. En los tres casos, dos redes que nacieron por separado de golpe necesitan hablarse.

• Fusiones y adquisiciones: dos organizaciones con sus propias redes necesitan integrarse, y lo más probable es que ambas hayan elegido el mismo rango popular (10.0.0.0/16, por ejemplo) sin coordinar nunca entre sí.
• Proyectos multi-cloud o híbridos: una red on-premise tiene que conectarse a una VPC en la nube, y si el rango interno de la empresa coincide con el de la VPC, no hay forma de establecer esa conexión sin renumerar una de las dos redes.
• Despliegues de Kubernetes administrado: en casos como ARO, el cluster necesita coexistir con lo que el cliente ya tiene corriendo, y el CIDR tiene que planificarse pensando en esa coexistencia desde el día uno.

La diferencia de costo entre detectarlo antes o después es enorme. Detectarlo durante la planificación es una conversación de diseño. Detectarlo después del despliegue significa rediseñar un ambiente que ya está corriendo, con todo lo que eso implica: downtime, migraciones de IP y, en el peor caso, interrupciones de servicio que nadie había presupuestado.

¿Qué partes componen una VPC o VNet?

Una VPC o VNet se compone de subredes, un gateway y reglas de seguridad, cada uno con una función específica dentro de la analogía del barrio cerrado. Entender cada pieza ayuda a ver dónde se puede romper algo. Sobre eso hablamos en la comparativa entre Microsoft y Google.

• El proveedor cloud es el país donde se ubica todo: AWS, Azure o GCP.
• La VPC o VNet es el barrio cerrado, tu límite de propiedad dentro de ese país.
• Las subredes son las calles internas del barrio, cada una con su propio sub-rango de direcciones.
• El gateway es la entrada principal, el único punto por donde entra y sale tráfico hacia afuera del barrio.
• Los security groups y reglas de firewall son las cerraduras de cada puerta individual, que deciden qué tráfico puede llegar a cada recurso puntual.

Comparativa: VPC en AWS vs VNet en Azure vs VPC en GCP

Proveedor	Nombre	Alcance	Rango CIDR permitido
AWS	VPC	Regional	/16 a /28
Azure	VNet	Regional	Definido por el usuario al crear la VNet
Google Cloud	VPC	Global (subredes regionales)	Definido por el usuario por subred

Si tu empresa está evaluando dónde alojar la infraestructura de base, antes de meterte en el diseño de VPCs o VNets conviene tener resuelto el hosting y los dominios. Para proyectos en Argentina, donweb.com es una opción local para ese primer escalón antes de escalar a una nube pública.

Errores comunes al planificar bloques CIDR

• Usar siempre el mismo rango “default”: copiar 10.0.0.0/16 de un tutorial sin pensar en qué otras redes existen en la empresa es la causa número uno de solapamientos.
• No documentar el rango asignado: si nadie anota qué CIDR usa cada ambiente, la próxima persona que arme una red nueva va a repetir un rango sin saberlo.
• Ignorar los rangos reservados por el proveedor: en AWS, por ejemplo, usar 172.17.0.0/16 genera conflictos con Cloud9 y SageMaker aunque tu diseño esté bien pensado.
• Asumir que GCP funciona igual que AWS: tratar una VPC de Google Cloud como si fuera regional lleva a subestimar cuántas subredes de otras regiones comparten el mismo espacio de direcciones.

Preguntas Frecuentes

¿Qué es una VPC en AWS?

Una VPC en AWS es una red privada y aislada, regional, donde el usuario define subredes, rangos de IP y reglas de tráfico antes de desplegar cualquier recurso. Admite un bloque CIDR primario entre /16 y /28, según la documentación oficial de AWS.

¿Qué es una VNet en Azure?

Una VNet en Azure es el equivalente conceptual a una VPC de AWS: una red privada regional con su propio bloque CIDR, dentro de la cual se despliegan subredes y recursos. Funciona bajo la misma lógica de aislamiento, solo que con otro nombre.

¿Cuál es la diferencia entre VPC y VNet?

La diferencia principal es de nombre y proveedor: VPC es el término que usan AWS y Google Cloud, VNet es el que usa Azure. Conceptualmente son lo mismo, aunque GCP agrega una diferencia estructural real al hacer que sus VPC sean globales en vez de regionales.

¿Por qué dos redes con el mismo rango de IP no se pueden conectar?

Porque la tabla de enrutamiento no puede distinguir entre dos rangos de direcciones idénticos, sin importar qué mecanismo de conexión se use: peering o Transit Gateway. Es una limitación matemática del enrutamiento, no algo que se arregle con configuración adicional.

¿Las VPC de Google Cloud funcionan igual que las de AWS?

No del todo: las VPC de Google Cloud son globales, mientras que las de AWS son regionales. Las subredes siguen siendo regionales en ambos casos, pero el contenedor de arriba cambia de alcance según el proveedor.

Conclusión

El caso documentado por Pipeline & Prompts deja un criterio práctico y reproducible: antes de diseñar cualquier VPC o VNet, listá todos los rangos CIDR que ya existen en tu empresa (on-premise, otras nubes, ambientes de otros equipos) y chequeá manualmente que el rango nuevo no se superponga con ninguno. Esto no reemplaza una auditoría de red formal, pero es el filtro mínimo que evita la reunión de emergencia con un ingeniero de redes del proveedor.

Lo que las fuentes no permiten concluir es cuánto tiempo o costo exacto implica rediseñar una red ya desplegada: el artículo original menciona que es “costoso” y compara el caso con fallas de Infraestructura como Código, pero no da cifras de horas, dólares ni downtime específico. Si tu equipo necesita ese dato para justificar una revisión de arquitectura, hay que medirlo en el propio ambiente, no asumirlo de un caso ajeno.

Fuentes

• Amazon Web Services – Documentación oficial sobre bloques CIDR en VPC
• Pipeline & Prompts – Cloud Fundamentals: VPCs and VNets Explained