Guía Integral de Amazon VPC: Domina el “Diseño de Red Inquebrantable” con una Comparación Práctica frente a GCP VPC y Azure VNet

Introducción (Puntos Clave)

• Esta guía extensa, orientada a la práctica, se centra en Amazon VPC (Virtual Private Cloud) y la compara con GCP VPC y Azure Virtual Network (VNet) en mapeo de terminología, filosofía de diseño, alcance seguro a Internet, conectividad híbrida, observabilidad y coste.
• Conclusión primero: las “cinco decisiones de la primera semana” son (1) planificación de direcciones (IPv4/IPv6), (2) enrutamiento (hub-and-spoke), (3) fronteras (egress/ingress), (4) permisos basados en identidad (SG/IAM) y (5) auditoría (Flow Logs/Traffic Mirroring/CloudTrail). Con esto definido, las apps pueden desplegarse de forma fiable y con mínima fricción.
• La fortaleza de AWS es un amplio conjunto de bloques—NAT Gateway, PrivateLink, Endpoints de interfaz/pasarela, Network Firewall, Transit Gateway—que ofrecen alta flexibilidad. El “VPC global único” de GCP es directo, con Cloud NAT y Private Service Connect simples. Azure destaca por cohesión entre VNet/Subnet/NSG/Route Table e integración empresarial mediante Private Endpoint/Firewall/Virtual WAN.
• Incluye: plantillas de diseño CIDR, postura mínima segura, boilerplates de tablas de rutas, mapeo de términos SG/NSG, tres patrones hub-and-spoke (descritos), un runbook de incidentes y muestras conceptuales de Terraform.
• Audiencia: equipos de red/migración a cloud empresariales, ingenieros SRE/plataforma, desarrolladores de aplicaciones y personal de seguridad/gobernanza. Ideal para agilizar migración por fases desde on-prem y conectividad multi-cuenta/multi-cloud a la vez.

1. Conceptos Básicos de VPC y Terminología Cruzada entre Nubes

Una VPC es tu red virtual privada en la nube. Definirás el CIDR (rango de direcciones), dividirás en subnets, controlarás caminos con route tables y restringirás alcanzabilidad con Security Groups (SG) / Network ACLs (NACL).

• AWS: Crea una VPC por región, sitúa subnets por AZ y conéctate dentro/fuera con IGW/NAT GW/Endpoints/TGW, etc.
• GCP: La VPC es global; las subnets son regionales. Conecta mediante Cloud Router/Cloud NAT/PSC/VPN/Interconnect.
• Azure: VNet es regional; las subnets viven dentro de la VNet. Conecta con NAT Gateway/Private Endpoint/Firewall/ExpressRoute/VPN.

Modelo mental:

• La seguridad es primero por identidad (SG/NSG/identidad), el enrutamiento es tablas de rutas, las fronteras son NAT/Firewall/Endpoints.
• Sustituye el “dentro/fuera” físico por: “Qué identidad puede llegar a qué destino, por qué camino/cifrado/auditoría”.

2. Planificación de Direcciones (CIDR) y Nombres: Decide Una Vez, No Cambies

2.1 Estrategia CIDR

• Evita solapamientos: Planifica RFC1918 pensando en híbrido/multi-cloud/fusiones.
• Espacio para crecer: Asigna /16 (65.536 IPs) a una VPC; corta subnets /19–/24 (regla práctica).
• Separación por rol: Fija subnets por propósito—App/DB/Shared/Ingress/Egress/Admin, etc.

2.2 Nomenclatura (ejemplos)

• VPC: {org}-{env}-{region}-vpc (p. ej., acme-prod-apne1-vpc)
• Subnets: {vpc}-{az}-{purpose} (p. ej., acme-prod-apne1a-app)
• RouteTable/NACL/SG: {env}-{layer}-{purpose} para que la intención sea visible de un vistazo.

2.3 Asignación CIDR de Muestra (descrita)

• VPC: 10.64.0.0/16
  • Public (Ingress/Egress): 10.64.0.0/20 (repartido entre tres AZ a/c/e)
  • App (privada): 10.64.16.0/19
  • Data (privada): 10.64.48.0/20
  • Shared/Admin: 10.64.64.0/20
    Mantén un “libro mayor de reservas” a nivel organización para evitar solapamientos con on-prem/otras nubes.

3. Enrutamiento y Fronteras: Elige un Hub-and-Spoke sin Dudar

3.1 Tres Patrones Estándar

1. Mínimo (pequeño/VPC única)
   • Subnets públicas: Internet vía IGW; coloca ALB/NLB aquí.
   • Subnets privadas: NAT GW para salida; entrada solo a través de ALB/NLB.
2. Hub-and-Spoke (medio/grande)
   • Centraliza NAT GW/Firewall/auditoría en una VPC hub de red.
   • Conecta VPCs de workload (spoke) mediante Transit Gateway (AWS)/VPC Peering al hub.
3. Multi-cloud/Híbrido
   • Termina VPN/circuitos dedicados (DX/Interconnect/ExpressRoute) en el hub para agregación de rutas y auditoría unificadas.

3.2 Boilerplate de Tabla de Rutas (ej.: spoke VPC/privada)

Destino          Target
10.64.0.0/16     local
0.0.0.0/0        tgw-xxxxxxxx   # Delegar al hub (NAT/Firewall)
::/0             tgw-xxxxxxxx   # Si usas IPv6
10.20.0.0/16     tgw-xxxxxxxx   # Prefijo on-prem/otra nube

Principio: Todo el egress de spokes va al hub; el control de salida vive allí. Sin Internet directo desde spokes, manteniendo control y auditoría centralizados.

3.3 Mapeo de Fronteras entre Nubes

• Egress (NAT): AWS NAT Gateway / GCP Cloud NAT / Azure NAT Gateway
• Acceso privado a servicios: AWS Interface/Gateway Endpoints & PrivateLink / GCP Private Service Connect / Azure Private Endpoint
• Agregación central: AWS Transit Gateway / GCP VPC Peering + Cloud Router / Azure Virtual WAN/Hub
• Exposición L7: Usa ALB / Cloud Load Balancing / Application Gateway; no expongas VMs/funciones directamente.

4. Modelo de Seguridad: SG vs. NACL vs. Firewall

4.1 Security Groups (SG)

• Filtros con estado adjuntos a instancias/ENI.
• Reglas de allowlist; prefiere permisos por ID (referencias SG → SG).
• Expresa capas de app (Web → App → DB) como fronteras SG para operaciones más limpias.

4.2 Network ACLs (NACL)

• Filtros sin estado a nivel subnet.
• Deny/allow ordenados y explícitos. Útiles para casos especiales (bloqueos temporales, enlaces externos mínimos).
• En el día a día, autoriza con SGs; trata los NACL como seguro adicional.

4.3 Firewalls/IDPS de Red

• Coloca AWS Network Firewall / Azure Firewall / Cloud Armor/Cloud IDS en el hub para control L3–L7 de tráfico N/S y E/W.
• Gateway Load Balancer (AWS) facilita appliances de seguridad en línea.

4.4 Mapeo Cruzado

• SG ↔ Azure NSG ↔ reglas de firewall de GCP
• NACL ↔ (sin equivalente exacto en Azure; usa NSG) ↔ firewall de GCP es a nivel VPC
• Network Firewall ↔ Azure Firewall ↔ GCP Cloud Firewall/IDS

5. Exposición a Internet: Por Defecto “CDN y LB L7”

• S3/estáticos: Usa CloudFront (GCP: Cloud CDN; Azure: Front Door/Azure CDN) con TLS/WAF/cache.
• API/app: ALB (GCP: HTTP(S) LB; Azure: App Gateway) para terminación TLS/enrutado; pon WAF en el LB/CDN.
• NLB/GLB: Uso L4 (gRPC/muy alto throughput/IP fija). AWS GWLB ayuda con appliances de seguridad en línea.
• Evita “exposición directa por IP pública” para compute: Dispersa mantenimiento/gobernanza/observabilidad y complica el triage de incidentes.

6. Conectividad Privada: Dónde Brillan Endpoints/PrivateLink

• Gateway Endpoints (S3/DynamoDB): Accede a S3/DynamoDB sin NAT; reduce riesgo de exfiltración/coste de egress.
• Interface Endpoints (PrivateLink): Llama servicios de AWS/propios por IP privada; potente para Zero Trust.
• Equivalentes: GCP Private Service Connect; Azure Private Endpoint. La tendencia es “acceso privado a servicios externos/SaaS” en las tres nubes.

7. Conectividad Híbrida: VPN/Líneas Dedicadas/DNS

• Site-to-Site VPN: A corto plazo/menor disponibilidad; usa túneles redundantes para estabilidad.
• Líneas dedicadas (DX/Interconnect/ExpressRoute): Para ancho de banda/latencia/SLA.
• Resolución de nombres: Usa Private Hosted Zone (Route 53) / Cloud DNS / Private DNS para definir “qué nombres resuelven a dónde”.
• Para DNS de horizonte dividido (mismo FQDN dentro/fuera), gestiona cache/TTL y auditorías de frontera.

8. IPv6, Egress, Zero Trust: Visión Pragmática 2025

• IPv6: Además de espacio, menos NAT unidireccionales simplifican el troubleshooting. Refuerza el control de egress en consecuencia.
• Control de egress: Combina FQDN/destinos etiquetados (PrivateLink/Endpoints/WAF) y declara destinos permitidos.
• Zero Trust: Permisos por identidad (SG/NSG/firewall) + mTLS/OIDC para verificar quién → dónde siempre; asume acceso sin bastión (SSM/IAP/Bastion JIT).

9. Observabilidad: Flow Logs + los “Cuatro Esenciales”

• VPC Flow Logs: Captura src/dst/puerto/allow/deny; detecta egress anómalo/escaneos.
• Traffic Mirroring: Profundiza a nivel paquete; vital en incidentes.
• CloudWatch/Cloud Logging/Azure Monitor: Dashboards de conexiones/denegaciones/ancho de banda/latencia.
• CloudTrail/Audit Logs/Activity Log: Quién cambió configuraciones de red.
  Agrega logs en una cuenta/proyecto separado para mayor resistencia a manipulación.

10. Optimización de Costes: Sé Inteligente con Egress/NAT/Auditoría

• Cantidad de NAT y pathing: Centraliza en el hub para rutas más cortas/menos instancias.
• Usa Endpoints: Gateway Endpoints (S3/DynamoDB) para recortar NAT/egress.
• Granularidad/retención de logs: Ajusta Flow Logs/Traffic; agrega → conserva resúmenes para suavizar coste.
• Cache en CDN: Reduce salida y carga al origen; baja fees de egress.
• Estandariza arquitectura: IaC (Terraform/CloudFormation/Bicep/DM) para un mínimo reproducible—evita proliferación.

11. Fraseario Cruzado (Esenciales)

• Red virtual: VPC (AWS) / VPC (GCP: global) / VNet (Azure)
• Grupo de seguridad: SG (AWS) / Regla de firewall (GCP) / NSG (Azure)
• Acceso privado a servicios: Interface/Gateway Endpoint & PrivateLink / Private Service Connect / Private Endpoint
• NAT/Egress: NAT Gateway / Cloud NAT / NAT Gateway
• Conectividad central: Transit Gateway / VPC Peering + Cloud Router / Virtual WAN (Hub & Spoke)
• Firewall: Network Firewall / Cloud Firewall/IDS / Azure Firewall
• Logs: VPC Flow Logs / VPC Flow Logs (GCP) / NSG Flow Logs/Diagnostics

12. Postura Mínima Segura (descrita)

1. Spoke VPCs (App/Data) usan subnets privadas únicamente.
2. ALB/NLB viven en subnets públicas del hub.
3. App → externo va TGW → NAT GW del hub.
4. S3/DynamoDB vía Gateway Endpoints; otros AWS/SaaS internos vía Interface Endpoint/PrivateLink.
5. SGs: mínimo dos saltos—ALB → App, App → DB.
6. Flow Logs ACTIVOS + CloudTrail centralizado; Network Firewall en el hub.

13. Configuraciones de Ejemplo

13.1 Security Groups (mínimo; inbound solo desde ALB)

# SG App: permite solo 80/443 desde el SG del ALB; el acceso a DB se maneja con otro SG
APP_SG=$(aws ec2 create-security-group --group-name app-sg --description "app" --vpc-id vpc-xxx --query GroupId --output text)
ALB_SG=$(aws ec2 create-security-group --group-name alb-sg --description "alb" --vpc-id vpc-xxx --query GroupId --output text)

aws ec2 authorize-security-group-ingress --group-id $APP_SG --protocol tcp --port 80  --source-group $ALB_SG
aws ec2 authorize-security-group-ingress --group-id $APP_SG --protocol tcp --port 443 --source-group $ALB_SG

13.2 Tabla de Rutas (spoke privada → hub)

aws ec2 create-route --route-table-id rtb-xxxx --destination-cidr-block 0.0.0.0/0 --transit-gateway-id tgw-xxxx
aws ec2 create-route --route-table-id rtb-xxxx --destination-ipv6-cidr-block ::/0 --transit-gateway-id tgw-xxxx

13.3 Flow Logs (a CloudWatch Logs)

aws ec2 create-flow-logs \
  --resource-type VPC --resource-ids vpc-xxxx \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --deliver-logs-permission-arn arn:aws:iam::123456789012:role/vpc-flow-logs-role \
  --log-group-name /vpc/flow/prod

14. Concepto Terraform (Destacados Hub-and-Spoke)

# VPC (spoke)
resource "aws_vpc" "spoke" {
  cidr_block           = "10.64.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "acme-prod-apne1-spoke" }
}

# Subnet privada (ejemplo)
resource "aws_subnet" "spoke_app_a" {
  vpc_id                  = aws_vpc.spoke.id
  cidr_block              = "10.64.16.0/20"
  availability_zone       = "ap-northeast-1a"
  map_public_ip_on_launch = false
  tags = { Name = "app-a" }
}

# Anclaje a Transit Gateway (hacia el hub)
resource "aws_ec2_transit_gateway_vpc_attachment" "spoke_attach" {
  subnet_ids         = [aws_subnet.spoke_app_a.id]
  transit_gateway_id = aws_ec2_transit_gateway.hub.id
  vpc_id             = aws_vpc.spoke.id
}

15. Errores Comunes y Remedios

• Solapamiento CIDR: Difícil de deshacer. Crea un libro mayor de reservas corporativo desde el día uno con un flujo de solicitudes.
• Exposición pública directa: No expongas VMs/DBs; usa ALB/CloudFront/PrivateLink.
• Proliferación de NAT: Demasiados NAT por VPC inflan coste; centraliza en el hub y usa Endpoints.
• Confusión SG vs. NACL: Lidera con SGs, NACL como complemento. Abraza “allow por identidad”.
• Logs ausentes: Diagnóstico a ciegas—haz Flow Logs/CloudTrail kit estándar.
• DNS ad-hoc: Define Private DNS/Hosted Zones y nombres/TTL desde el inicio.

16. Casos de Estudio (3 Patrones)

16.1 Portal Empresarial (de cara a Internet + API interna)

• Diseño: VPC hub (ALB/Firewall/NAT) + VPC spoke (App/Data). Camino externo: CloudFront → ALB; interno vía PrivateLink.
• Notas: Egress agregado simplifica auditoría; WAF en CDN/L7. Flow Logs en cuenta separada.
• GCP/Azure: Cloud CDN → HTTP(S) LB / Front Door → App Gateway, con PSC/Private Endpoint—misma idea.

16.2 Plataforma SaaS (multi-tenant + zero trust)

• Diseño: Aísla inquilinos en spokes; IdP central + mTLS; Interface Endpoints para SaaS interno.
• Notas: Referencias SG-a-SG aplican cero alcanzabilidad inter-tenant; centraliza logs de auditoría.
• GCP/Azure: VPC Peering + reglas de firewall / VNet Peering + NSG; apalanca PSC/Private Endpoint.

16.3 Híbrido (plantas/sucursales × nube)

• Diseño: VPN dual on-prem → futuro circuito dedicado; rutas agregadas en hub; prefijos mínimos planta → nube.
• Notas: Define DNS de horizonte dividido, monitorización de ancho de banda y criterios de local breakout.
• GCP/Azure: Cloud Router + HA VPN / Virtual WAN + VPN Gateway para simetría.

17. Checklist de Diseño de la Primera Semana (10 Ítems)

1. Reglas de CIDR/nombres: libro mayor de reservas compartido + flujo de solicitud.
2. Hub-and-spoke: qué VPC es hub; zona de aterrizaje para egress/firewall/auditoría.
3. Roles de subnets: separa Public/Private/Admin; reparte entre AZs.
4. Rutas: envía 0.0.0.0/0 al TGW/hub; gestiona prefijos on-prem/otras nubes.
5. SG/NACL: SG-first; NACL complementario; referencias SG→SG por defecto.
6. Endpoints: Gateway (S3/DynamoDB); Interface/PrivateLink para el resto.
7. DNS: Private Hosted Zones/Private DNS; nombres; TTLs.
8. Observabilidad: Flow Logs/CloudTrail/Traffic Mirroring; guarda en cuenta separada.
9. Zero Trust: sin bastión (SSM/IAP/Bastion JIT), mTLS/OIDC, mínima alcanzabilidad.
10. Coste: revisa ciclos de NAT/Endpoints/retención de logs.

18. Runbook de Operaciones (Respuesta Inicial a Incidente de Red)

1. Detecta: alerta sobre latencia p95/fallos de ruta/picos de denegación.
2. Aísla: recorre DNS → SG → route table → NAT/Firewall → peer; confirma allow/deny con Flow Logs.
3. Mitiga: habilita caminos alternos (NAT en standby/otra AZ); ajusta umbrales de salud del LB.
4. Causa raíz: revisa diffs de IaC/CloudTrail; profundiza con Traffic Mirroring.
5. Corrige: mejora convergencia de rutas, TTL de DNS y referencias por ID en SG.
6. Retro: actualiza dashboards/runbooks; añade “revisión de impacto de rutas” al control de cambios.

19. Lectores y Resultados Concretos

• IT Empresarial (muchos sitios/integración)
  Con libro mayor CIDR + hub-and-spoke + Private Endpoint, elimina colisiones/backdoors; logs centralizados simplifican cumplimiento.
• Ingeniería SRE/Plataforma
  Convierte el patrón mínimo seguro (ALB al frente/SG-first/Endpoints) en IaC para lanzar nuevos productos en un día con el mismo patrón.
• Desarrolladores de apps
  Con “L7 en el LB, alcance por SG, salida vía hub”, despliega con seguridad sin diseño de red profundo.
• Seguridad/Gobernanza
  Estandariza acceso sin bastión, mínima alcanzabilidad, zero trust; logra auditoría y cambios no dependientes de personas.
• CTO de startup/Líderes técnicos
  Empieza pequeño, pero conserva centralización de hub y holgura CIDR para crecer; mecaniza control de coste de NAT/logs.

20. Preguntas Frecuentes (FAQ)

• P: ¿SG o NACL como control primario?
  R: SG-first. Obtienes allow por identidad y estado. Usa NACL como barrera suplementaria.
• P: ¿Dónde deben vivir los NAT Gateways?
  R: En el hub, unificando el egress. Combínalo con Endpoints para minimizar tráfico por NAT.
• P: ¿Adoptamos IPv6?
  R: Sí—espacio de direcciones y menos NAT valen. Refuerza control de egress y auditoría.
• P: ¿Transit Gateway vs. VPC Peering?
  R: Para escala y operaciones centralizadas, TGW. Para punto-a-punto, Peering sirve. Si habrá crecimiento, empieza con un hub.

21. Apéndice A: Libro Mayor de Reservas CIDR (Extracto)

• Entornos: dev / stg / prod
• VPCs: 10.64.0.0/16 (prod) / 10.65.0.0/16 (stg) / 10.66.0.0/16 (dev)
• Roles de subnets: public-ingress / private-app / private-data / shared-admin
• Reglas: Sin solape a /16, deja ≥ /19 libre, solicitudes con tickets.

22. Apéndice B: Estándares de Nombres y Tags (Ejemplo)

• Tags: env=prod, owner=platform, data-classification=internal, egress=hub, zone=apne1
• Nombres de SG: prod-app-web-in (ALB → App), prod-app-db-in (App → DB)
• Nombre de RouteTable: prod-spoke-private-rt (0/0 → tgw)

23. Apéndice C: Tres Cosas que Puedes Hacer Hoy

1. Documenta CIDR de VPC/roles de subnets/nombres y establece un “libro mayor de reservas.”
2. Activa Flow Logs/CloudTrail en cada VPC y centraliza en cuenta separada.
3. Añade Endpoints (S3/DynamoDB) para reducir inmediatamente egress por NAT y riesgo.

Resumen: Permitir por Identidad, Agregar Caminos y Hacerlo Observable

Diseña Amazon VPC estandarizando en este orden: plan CIDR → hub-and-spoke → SG-first → Endpoints → observabilidad—equilibrarás seguridad, escalabilidad y coste.
Los mismos principios aplican a GCP VPC y Azure VNet: impón conectividad privada, egress unificado y logs centralizados. Agrega L7 en el LB y permite alcance por identidad—sigue esta vía y crecerás una red inquebrantable sin importar el tamaño del equipo o la nube.
La próxima vez profundizaremos en Amazon CloudFront, comparándolo con Cloud CDN (GCP) y Azure Front Door, y exploraremos WAF/diseño de origen/cache/coste para hallar el óptimo de front-end en detalle. Mantente al tanto.