El bloque donde más cuesta a quien viene de on-premise. Aquí se diseña la red en la que vivirá todo lo demás: la VPC, las subredes públicas y privadas, las rutas, los Security Groups y las NACLs. Trabajamos sobre topologías reales — frontend público, backend privado, salida controlada a Internet, conexión a la oficina.
Objetivos de aprendizaje
Diseñar una VPC con CIDR razonable y subredes públicas y privadas en varias AZ.
Configurar route tables, IGW y NAT Gateway para los flujos típicos.
Usar VPC Endpoints para evitar tráfico innecesario a Internet.
Distinguir cuándo usar Security Groups y cuándo NACLs.
Conectar varias VPCs con VPC Peering o Transit Gateway según el caso.
Configurar zonas y políticas básicas en Route 53.
Entender en qué consiste una VPN site-to-site y cuándo usar Direct Connect.
3.1 Por qué AWS exige diseñar las redes
En un centro de datos físico la red la diseña otro equipo y tú "vives" en ella. En AWS, la red es tuya desde el primer minuto: tú creas la VPC, eliges el CIDR, decides cuántas subredes y dónde está la frontera con Internet. Hacerlo mal cuesta tiempo (rediseñar) y dinero (NAT Gateways de más, tráfico cross-AZ).
Patrón canónico que vais a usar 9 de cada 10 veces: una VPC con CIDR 10.x.0.0/16, tres AZ, en cada AZ una subred pública y una privada, un Internet Gateway, uno o tres NAT Gateways (según presupuesto vs HA), Security Groups por capa (web, app, DB) y endpoints para S3 y SSM. Lo construimos paso a paso a lo largo del módulo.
3.2 La VPC: el primer bloque
Una VPC (Virtual Private Cloud) es tu red privada lógica dentro de una región. Aislada del resto del mundo (incluidas otras VPCs) hasta que tú decidas lo contrario. Cuando creas una VPC, lo único obligatorio es darle un CIDR (rango de direcciones IPv4 privadas).
Planificación del CIDR
CIDR
Hosts disponibles
Cuándo
/16 (p.ej. 10.0.0.0/16)
65.536
Recomendado por defecto. Margen para crecer y para 3+ AZ.
/20
4.096
VPCs auxiliares pequeñas o sandbox.
/24
256
Demasiado pequeño para producción seria.
Reglas del CIDR que ahorran disgustos: (1) no solapes con la red de la oficina ni con la de otros clientes — si algún día hay VPN o peering, te bloquean; (2) reserva rangos por cliente, no por proyecto; (3) usa siempre rangos privados RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16); (4) elige /16 aunque parezca grande, los costes son los mismos.
3.3 Subredes públicas y privadas
Una subred es un trozo del CIDR de la VPC asignado a una sola AZ. La diferencia entre "pública" y "privada" no la marca AWS: la marca su route table.
🌐 Subred pública
Tiene una ruta a un Internet Gateway (0.0.0.0/0 → igw-…). Las instancias con IP pública pueden hablar con Internet de ida y vuelta.
🔒 Subred privada
No tiene ruta al IGW. Las instancias no son accesibles desde Internet. Si necesitan salir (descargar paquetes), pasan por un NAT Gateway que vive en una subred pública.
En las subredes privadas, la route table dice 0.0.0.0/0 → nat-…. En las públicas, 0.0.0.0/0 → igw-…. Eso es lo único que las diferencia.
3.4 IGW, NAT Gateway y VPC Endpoints
Los tres puentes con los que tu VPC habla con el exterior — Internet, otras cuentas o servicios AWS.
Componente
Para qué
Coste
Internet Gateway (IGW)
Tráfico bidireccional con Internet. Una por VPC.
Gratis (pero pagas la salida de datos)
NAT Gateway
Permite salida a Internet desde subredes privadas, sin permitir entrada.
~33 €/mes por NAT + por GB procesado
VPC Endpoint Gateway
Acceso privado a S3 y DynamoDB sin pasar por Internet.
Gratis
VPC Endpoint Interface
Acceso privado al resto de servicios AWS (SSM, ECR…).
~7 €/mes por endpoint por AZ + por GB
Optimización clave: si tus EC2 privadas leen mucho de S3, mete un Gateway Endpoint de S3 — es gratis y elimina ese tráfico del NAT Gateway (que sí cobra). Lo mismo con SSM, ECR y CloudWatch Logs si tienes muchas instancias hablando con esos servicios.
Trampa habitual: desplegar un único NAT Gateway "para ahorrar". Si esa AZ cae, todas las subredes privadas pierden salida — aunque los servidores estén en otras AZ. Para producción, uno por AZ (o ningún NAT y solo endpoints, cuando la app solo habla con AWS).
3.5 Security Groups vs NACLs
Las dos capas de filtrado de paquetes en una VPC. Su confusión es el error más típico de quien empieza.
Security Group (SG)
Network ACL (NACL)
Nivel
Instancia (ENI)
Subred
Reglas
Solo permitir (allow)
Permitir y denegar (allow/deny)
Estado
Stateful · la respuesta sale aunque no haya regla outbound
Stateless · hay que abrir entrada y salida por separado
Procesamiento
Todas las reglas evaluadas
Por orden de número (la primera que matchea gana)
Por defecto en una VPC nueva
SG default: todo cerrado fuera del propio SG
NACL default: todo abierto
✓ Usa SG (regla general)
Es donde se hace el filtrado de verdad: por instancia, por rol (web, app, DB). Más fácil de mantener y stateful. Truco profesional: referencia un SG desde otro (app-sg permite tráfico de web-sg) en vez de IPs — sigue funcionando aunque escalen.
! Usa NACL solo para
Bloqueos amplios y explícitos: "deniega toda esta IP problemática", "subred X no habla con Y a nivel red". Si te ves escribiendo muchas reglas en NACL, probablemente debería ir en SG.
Practica · ¿SG o NACL?
Pulsa una necesidad y luego la herramienta correcta. Después, "Comprobar".
Solo el ALB puede hablar con las EC2 de la capa de aplicación por el puerto 8080
Las EC2 de la capa app pueden hablar con RDS PostgreSQL por el 5432
Bloquear toda una IP atacante a nivel subred
Una subred jamás debe hablar con otra subred determinada
Security Group (ALB → app)
Security Group (app → RDS)
NACL · deny inbound de IP
NACL · deny entre subredes
3.6 Multi-VPC: Peering y Transit Gateway
Tarde o temprano hay que conectar varias VPCs entre sí: distintos entornos del mismo cliente, varios clientes en una consultora, o una VPC compartida con servicios comunes.
🔗 VPC Peering
Conexión 1-a-1 entre dos VPCs. CIDRs no deben solaparse. Sin transitividad (A↔B y B↔C no implica A↔C). Útil hasta 3-4 VPCs.
🚌 Transit Gateway (TGW)
Hub central que enruta tráfico entre N VPCs y on-premise. Es la respuesta cuando hay muchas conexiones o se necesita topología hub-and-spoke. Más caro pero escalable y manejable.
Regla rápida: con 2-3 VPCs, peering. A partir de 4-5 o cuando hay on-premise, Transit Gateway. Migrar de peering a TGW se hace en caliente cuando hace falta.
3.7 Route 53: DNS gestionado
Aunque no es "red" en sentido estricto, Route 53 entra aquí porque sostiene cualquier arquitectura. Es el servicio DNS de AWS — autoritativo, gestionado y con políticas de enrutamiento que van más allá del DNS clásico.
Zonas hospedadas: una pública por dominio (cliente.com) y zonas privadas asociadas a una VPC para nombres internos.
Políticas de enrutamiento: simple, weighted (A/B testing), latency-based (servir desde la región más cercana), failover (DR), geolocation.
Health checks: monitorización de endpoints y conmutación automática.
Para una consultora, lo más habitual: weighted en despliegues progresivos y failover para alta disponibilidad cross-region.
3.8 Conectividad con on-premise
Dos vías para conectar la VPC con la oficina o el data center del cliente:
Servicio
Qué es
Cuándo
Site-to-Site VPN
Túnel IPsec sobre Internet hacia un Virtual Private Gateway o un TGW.
Por defecto. Tarda minutos en montarse, va por Internet, ancho de banda moderado.
Direct Connect
Enlace privado físico desde un PoP de AWS a la oficina del cliente.
Cuando el tráfico es alto, sensible o con SLA estricto. Caro y semanas de instalación.
El patrón habitual en consultora: VPN como base + Direct Connect solo cuando el volumen o el cumplimiento lo justifican. Direct Connect suele ir también con VPN encima como backup.
Práctica del módulo
Ejercicio 3.1 · Diseña una VPC para tu cliente
Para una pyme con una web pública, una API privada y una base de datos, diseña la VPC en un papel:
CIDR de la VPC.
Subredes (cuántas, en qué AZ, qué rango cada una, pública o privada).
Dónde va el IGW, dónde los NAT y cuántos.
Qué Security Groups crearías y cómo se referencian entre ellos.
Qué VPC Endpoints añadirías para ahorrar coste de NAT.
Pista: VPC 10.0.0.0/16 · 3 AZ · 2 subredes por AZ (pública /24, privada /24) · 1 IGW · 1 NAT Gateway por AZ si HA, o 1 solo si presupuesto justo · SGs: alb-sg, app-sg (acepta de alb-sg), db-sg (acepta de app-sg) · Endpoints: S3 (gateway, gratis) y SSM (interface, en las 3 AZ).
Ejercicio 3.2 · Lab guiado · Web pública + DB privada
En tu sandbox: (1) crea la VPC del ejercicio 3.1 con AWS CLI o consola; (2) lanza una EC2 con Nginx en una subred pública; (3) lanza una EC2 "DB" en una subred privada; (4) configura SGs para que la web hable con la DB pero nada más entre por Internet; (5) comprueba con curl desde fuera y desde dentro; (6) destruye la VPC y todos sus recursos.
Test de comprensión
1. ¿Qué hace que una subred sea "pública" en AWS?
Que la marques como "pública" en la consola.
Que tenga una ruta a un Internet Gateway en su route table.
Que use un CIDR especial.
Que esté en una AZ específica.
Respuesta correcta: B. Lo que distingue pública de privada es su route table: 0.0.0.0/0 → igw-… vs 0.0.0.0/0 → nat-….
2. ¿Cuál de estas afirmaciones sobre Security Groups es correcta?
Tienen reglas allow y deny.
Son stateless: hay que abrir entrada y salida por separado.
Son stateful: si una conexión entra, la respuesta sale aunque no haya regla outbound.
Funcionan a nivel subred.
Respuesta correcta: C. SG es stateful y por instancia, con solo reglas allow. NACL es stateless y por subred.
3. Tus EC2 privadas leen mucho de S3. Para reducir coste del NAT Gateway, ¿qué añades?
Más NAT Gateways.
Un VPC Endpoint Gateway de S3.
Un IGW adicional.
Una VPN site-to-site.
Respuesta correcta: B. El endpoint gateway de S3 es gratuito y elimina ese tráfico del NAT.
4. Tienes que conectar 7 VPCs entre sí más la red on-premise. ¿Qué arquitectura es la adecuada?
VPC Peering entre todas (malla completa).
Transit Gateway como hub central.
Un IGW gigante.
Una única VPC enorme.
Respuesta correcta: B. Más de 3-4 VPCs y/o on-premise → Transit Gateway. Peering no es transitivo y la malla completa se vuelve inmanejable rápido.
Resumen del módulo
La VPC es tu red privada lógica en una región. Diséñala con margen: CIDR /16 que no solape con la oficina.
Subredes públicas vs privadas se distinguen por su route table (IGW vs NAT).
IGW, NAT Gateway, VPC Endpoints: cada uno tiene su uso y su coste. Los endpoints de S3 ahorran mucho.
Security Groups (instancia, stateful, allow) para el día a día; NACLs (subred, stateless, allow/deny) solo para bloqueos amplios.
Multi-VPC: peering hasta 3-4 VPCs; Transit Gateway cuando son más o hay on-premise.
Route 53 aporta DNS gestionado y políticas avanzadas (failover, latency, weighted).
Siguiente: el almacenamiento. EBS, S3 y EFS — decidir cuál usar y cómo evitar la trampa de la factura.