VPC en AWS desde cero: la base real de toda arquitectura cloud

Cuando hablamos de arquitectura en Amazon Web Services, casi siempre pensamos en servicios: EC2, RDS, EKS, ALB, Lambda. Pero hay una capa previa, silenciosa y crítica, que condiciona absolutamente todo lo demás: la VPC.

Una VPC no es “una red en la nube”. Es el perímetro de control, el límite de seguridad, el espacio donde se decide qué puede hablar con qué, cómo y bajo qué condiciones. Si esta base está mal diseñada, da igual lo bien que escribas código o lo robustos que sean tus servicios: tarde o temprano, el sistema fallará.

He visto proyectos con código impecable que se han vuelto inoperables porque nadie entendía cómo estaba configurada la red. He visto migraciones que tardaron meses porque la VPC se diseñó pensando solo en el día de mañana, no en dentro de dos años.

Este artículo no es una definición rápida. Es una explicación práctica y realista de qué es una VPC, cómo se estructura y por qué es el punto de partida de cualquier arquitectura cloud seria.

Qué es realmente una VPC (y qué no)

Una Virtual Private Cloud es un espacio de red aislado lógicamente dentro de AWS. Tú defines su rango de direcciones IP (CIDR), sus subredes, sus rutas y sus reglas de acceso. Nada entra ni sale si tú no lo permites explícitamente.

Esto rompe con la mentalidad tradicional de “la red ya existe”. En AWS, la red la diseñas tú, y eso implica responsabilidad arquitectónica. La VPC no es un recurso más: es el marco en el que todos los demás recursos viven.

Un error común —sobre todo en perfiles backend que dan el salto a cloud— es crear una VPC con el asistente por defecto y no volver a pensar en ella. Ese enfoque funciona para pruebas o un MVP rápido, pero en producción suele traducirse en:

Recursos expuestos innecesariamente
Rutas confusas que nadie comprende tres meses después
Dificultad para escalar o separar entornos (dev, staging, prod)
Problemas de seguridad difíciles de auditar

Diseñar una VPC es pensar en cómo fluye el tráfico, no solo en dónde desplegar una instancia.

Y créeme, esta diferencia se nota cuando llega el primer incidente de producción a las 2 de la madrugada.

El CIDR: una decisión que no se puede deshacer

Todo empieza con el CIDR (Classless Inter-Domain Routing). Ese rango IP que defines al crear la VPC es el tamaño máximo de tu red. Si te quedas corto, no hay “resize”: hay migración.

Un /16 (por ejemplo 10.0.0.0/16) suele ser una elección sensata. Da margen para:

Crecer sin ahogarte en direcciones
Separar entornos (dev, staging, prod) si es necesario
Crear subredes por cada Availability Zone
No pensar en IPs durante años

Usar rangos pequeños “para no desperdiciar” suele ser un error clásico. Las IPs privadas son gratuitas y abundantes. No tiene sentido optimizar algo que no cuesta nada.

Un ejemplo práctico

Imagina que defines una VPC con 10.0.0.0/24. Tienes solo 256 direcciones IP. Suena suficiente, ¿no? Hasta que:

Creas 3 subredes públicas (una por AZ) → ~85 IPs cada una
Creas 3 subredes privadas → otra ronda de ~85 IPs
AWS reserva 5 IPs por subred (primera, última, DNS, router, futuro)
Despliegas un cluster de EKS con 20 nodos
Cada nodo necesita su IP, más las IPs de los pods…

Boom. Te quedaste sin espacio.

Aquí ya entra una mentalidad de ingeniería: planificar para el futuro, aunque hoy solo tengas dos servicios.

Subredes: donde empieza la arquitectura de verdad

Una VPC sin subredes bien pensadas es como un datacenter sin racks. Técnicamente funciona, pero no es operable.

Las subredes son divisiones lógicas del CIDR, asociadas siempre a una única Availability Zone. Y aquí aparece una distinción clave: subred pública vs subred privada.

No es un flag mágico.

Una subred es pública solo si su tabla de rutas tiene salida a un Internet Gateway. No hay checkbox. Es cuestión de configuración.

Diseño típico de subredes

En un diseño de producción estándar:

Subredes públicas (alojan recursos que necesitan acceso directo desde Internet):

Application Load Balancers (ALB)
NAT Gateways
Bastion hosts (si todavía usas alguno)

Subredes privadas (alojan el 90% de tu infraestructura):

Instancias EC2
Nodos de EKS/Kubernetes
Bases de datos RDS
Caches (ElastiCache, Redis)
Cualquier servicio que NO deba ser accesible desde Internet

Este patrón no es moda ni opinión: es aislamiento por diseño. El backend no necesita ser accesible desde Internet. Si lo es, algo está mal configurado.

Multi-AZ: disponibilidad real

Un error frecuente es crear todas las subredes en una sola AZ “para simplificar”. Problema: si esa AZ cae (y sí, pasa), toda tu infraestructura se va con ella.

La arquitectura correcta distribuye recursos en al menos 2 AZs, idealmente 3:

VPC: 10.0.0.0/16

# Subredes públicas
10.0.1.0/24 → us-east-1a (pública)
10.0.2.0/24 → us-east-1b (pública)
10.0.3.0/24 → us-east-1c (pública)

# Subredes privadas
10.0.10.0/24 → us-east-1a (privada)
10.0.11.0/24 → us-east-1b (privada)
10.0.12.0/24 → us-east-1c (privada)

Así tienes redundancia real. Si una AZ falla, tus ALBs y servicios siguen vivos en las otras dos.

Route Tables: el cerebro silencioso de la VPC

Las route tables deciden por dónde viaja el tráfico. No son visibles a simple vista, pero son responsables del 80% de los “no funciona” que ves en AWS.

Cada subred está asociada a una tabla de rutas. Esa tabla define:

Tráfico local → siempre permitido dentro de la VPC
Salida a Internet → vía Internet Gateway (subredes públicas)
Salida controlada → vía NAT Gateway (subredes privadas)
Rutas a otros sistemas → VPN, peering, Transit Gateway, VPC endpoints

Ejemplo real de Route Table

Tabla para subred pública:

Destination       Target
10.0.0.0/16      local
0.0.0.0/0        igw-abc123

Tabla para subred privada:

Destination       Target
10.0.0.0/16      local
0.0.0.0/0        nat-def456

¿Ves la diferencia? La subred pública sale directamente por el Internet Gateway. La privada sale por el NAT Gateway (que está en la subred pública).

Una subnet privada no “es privada” porque AWS lo diga, sino porque no tiene ninguna ruta directa que apunte a Internet.

Este detalle es clave: la seguridad empieza en el routing, no en los firewalls.

Internet Gateway y NAT Gateway: entrada y salida no son lo mismo

El Internet Gateway (IGW) permite tráfico bidireccional entre Internet y la VPC. Solo debería estar asociado a subredes que realmente lo necesitan.

El NAT Gateway, en cambio, permite solo salida desde subredes privadas hacia Internet. No admite conexiones entrantes iniciadas desde fuera. Es perfecto para:

Instancias que necesitan descargar actualizaciones
Servicios que consumen APIs externas
Cualquier recurso privado que necesite acceso saliente a Internet

El dilema del coste del NAT Gateway

Un NAT Gateway cuesta dinero. No mucho, pero sí notable si tienes varios entornos. Aquí se comete un error frecuente: usar instancias EC2 como NAT “para ahorrar costes”.

No lo hagas.

En producción, esto suele acabar en:

Cuellos de botella de red
Fallos de disponibilidad (la instancia NAT es un single point of failure)
Problemas de mantenimiento que nadie quiere asumir
Un ahorro de $30/mes que te cuesta horas de ingeniería

El NAT Gateway gestionado existe por una razón. Úsalo.

Pro tip: Si tienes múltiples AZs, necesitas un NAT Gateway por AZ para evitar cargos de transferencia entre zonas. Sí, cuesta más. Pero es la forma correcta de hacerlo.

Security Groups y NACLs: control fino del tráfico

AWS ofrece dos capas de control de red:

Security Groups (SG)

Stateful → si permites tráfico de entrada, la respuesta está automáticamente permitida
Se aplican a recursos individuales (EC2, RDS, ALB, etc.)
Solo permiten lo que defines explícitamente (deny by default)
Puedes referenciar otros Security Groups (súper potente)

Network ACLs (NACLs)

Stateless → debes definir reglas de entrada y salida por separado
Se aplican a subredes enteras
Reglas de allow/deny procesadas por orden
Más granulares pero más complejos

¿Cuál usar?

En la práctica, los Security Groups son la herramienta principal. Son expresivos, fáciles de auditar y encajan bien con arquitecturas dinámicas.

# Ejemplo: permitir tráfico del ALB hacia las instancias
resource "aws_security_group_rule" "allow_alb_to_instances" {
  type                     = "ingress"
  from_port                = 8080
  to_port                  = 8080
  protocol                 = "tcp"
  source_security_group_id = aws_security_group.alb.id
  security_group_id        = aws_security_group.instances.id
}

Los NACLs se usan en escenarios concretos:

Requisitos regulatorios (compliance, auditorías)
Bloqueos a nivel de subnet (por ejemplo, denegar rangos IP completos)
Controles muy específicos de tráfico

Usarlos sin necesidad suele añadir complejidad sin valor. Mi regla: si puedes hacerlo con Security Groups, hazlo con Security Groups.

Una buena VPC tiene pocas reglas, claras y con intención explícita.

VPC Endpoints: optimización y seguridad

Aquí viene una optimización que pocos conocen al principio: VPC Endpoints.

Imagina que tienes instancias EC2 en subredes privadas que necesitan acceder a S3. Lo normal sería:

Tráfico sale por NAT Gateway
Va a Internet
Llega a S3
Vuelve por NAT Gateway

Estás pagando por NAT Gateway y por transferencia de datos para hablar con un servicio de AWS que está en la misma región.

Con un VPC Endpoint, el tráfico va directamente desde tu VPC a S3 sin salir a Internet. Ventajas:

Más rápido (menor latencia)
Más barato (sin costes de NAT)
Más seguro (tráfico privado)

Hay dos tipos:

Gateway Endpoints (S3, DynamoDB) → gratuitos Interface Endpoints (la mayoría de servicios AWS) → de pago pero valen la pena

Si trabajas con servicios AWS intensivamente (Lambda, ECS, ECR, SSM, Secrets Manager), los Interface Endpoints son casi obligatorios en producción.

Pensar la VPC como sistema, no como requisito

El mayor salto mental es este: una VPC no es algo que “se crea y se olvida”. Es un sistema vivo, que evoluciona con tu producto.

Cuando crecen los equipos, aparecen nuevos servicios, se separan entornos o se endurece la seguridad, la VPC debe acompañar. Si la base está bien diseñada, el cambio es incremental. Si no, cada modificación es un riesgo.

Por eso, entender la VPC es uno de los puntos donde muchos perfiles backend empiezan a dar el salto a Cloud Engineer o SRE: porque aquí el código deja de ser suficiente.

Patrones comunes que deberías conocer

1. VPC Multi-Tier (3 capas)

El clásico. Tres capas de subredes:

Public tier → ALB, Bastion
Private tier → Aplicaciones, servicios
Data tier → Bases de datos

Cada capa con sus propios Security Groups y rutas. Aislamiento progresivo.

2. VPC Peering entre entornos

Necesitas que staging hable con prod para probar integraciones, pero sin exponerlo todo. VPC Peering te permite conectar VPCs de forma privada, con rutas controladas.

3. Transit Gateway para arquitecturas complejas

Cuando tienes 5+ VPCs (multi-cuenta, multi-región), gestionar peerings se vuelve un infierno. Transit Gateway centraliza la conectividad. Es como un hub central donde todas las VPCs se conectan.

4. VPC con VPN híbrida

Necesitas conectar tu VPC con tu datacenter on-premise. AWS ofrece Site-to-Site VPN o Direct Connect (más caro, más fiable). La VPC se convierte en extensión de tu red corporativa.

Herramientas que te hacen la vida más fácil

Terraform / OpenTofu → Define tu VPC como código. Versionable, reproducible, auditable.
AWS VPC Flow Logs → Debugging de red. Indispensable cuando algo no funciona.
VPC Reachability Analyzer → Te dice si dos recursos pueden comunicarse. Ahorra horas de troubleshooting.
CloudMapper → Visualiza tu VPC. Útil para auditorías y documentación.

Errores que he visto (y cometido)

No documentar la VPC → Nadie sabe qué hace cada subred 6 meses después.
CIDR demasiado pequeño → Quedarse sin IPs en producción duele.
Todo en una AZ → Un apagón de AWS y adiós infraestructura.
Security Groups permisivos → 0.0.0.0/0 en todas partes no es seguridad.
No usar VPC Endpoints → Pagar de más por tráfico innecesario.
Olvidar los costes del NAT Gateway → Factura sorpresa a fin de mes.

Conclusión: domina la base antes de construir el edificio

Antes de hablar de microservicios, Kubernetes o alta disponibilidad, hay que dominar la VPC. No por certificación, sino por criterio técnico.

Una VPC bien diseñada:

✅ Reduce la superficie de ataque
✅ Simplifica el troubleshooting (sabes por dónde va el tráfico)
✅ Permite escalar sin rediseñar desde cero
✅ Hace que el resto de la arquitectura sea predecible
✅ Te ahorra dinero (optimización de tráfico)
✅ Te ahorra tiempo (menos incidentes tontos)

Todo lo demás se apoya aquí.

Si estás empezando con AWS, dedica tiempo a entender la VPC. Si ya llevas tiempo, revisa tu diseño actual. Seguro que encuentras algo que mejorar.

Y si alguna vez te encuentras debuggeando un problema de conectividad a las 3 de la madrugada, recuerda: la mayoría de errores de red en AWS se resuelven mirando las route tables y los security groups. No es magia, es configuración.