Las preguntas de networking en el SAP-C02 siempre involucran múltiples cuentas y VPCs. Entender cuándo usar VPC Peering, Transit Gateway, PrivateLink o RAM — y sus limitaciones — es fundamental para el examen profesional.
Contenido
| Servicio | Topología | Transitividad | Cross-account | Mejor para |
|---|---|---|---|---|
| VPC Peering | Punto a punto (malla) | NO | Sí (con aceptación) | Pocas VPCs, bajo volumen, misma región o inter-región |
| Transit Gateway | Hub-and-spoke | SÍ | Sí (via RAM) | Muchas VPCs, tráfico centralizado, on-premises + cloud |
| PrivateLink | Unidireccional | N/A | Sí (VPC Endpoint) | Exponer servicios/APIs privadas entre cuentas sin peering |
| AWS RAM | Compartir subnets | N/A | Sí (org o cuenta) | Compartir subnets de una VPC central con otras cuentas |
| VPN Gateway | Sitio a sitio | Con TGW | Sí | Conectar on-premises a una sola VPC o via TGW |
| Direct Connect | Dedicado (física) | Con TGW | Sí | Conectividad privada de alto rendimiento desde on-premises |
VPC Peering establece una conexión de red privada punto a punto entre dos VPCs. El tráfico no atraviesa internet público y usa la red backbone de AWS.
Características
Limitaciones críticas
Regla de oro del examen
VPC Peering es ideal para pocas VPCs con comunicación bidireccional necesaria. Cuando el escenario menciona "decenas o cientos de VPCs" o "comunicación con on-premises desde múltiples VPCs" → Transit Gateway.
Transit Gateway (TGW) es un router regional gestionado que actúa como hub central. Todas las VPCs y conexiones on-premises se conectan al TGW, que enruta el tráfico entre ellas. Soporta hasta 5,000 adjuntos (attachments).
Attachments soportados
Tablas de rutas TGW
Funciones avanzadas
El TGW permite segmentar el tráfico con múltiples route tables. Es el patrón para aislar prod de dev, o crear zonas de inspección con appliances de seguridad.
Patrón: Aislamiento Prod/Dev
Dos route tables: una asociada a VPCs-Prod y otra a VPCs-Dev. Las rutas de Prod no propagan a Dev y viceversa. Ambas pueden alcanzar una VPC-Shared-Services.
Patrón: Inspección inline con firewall
Todo el tráfico E-W pasa por una VPC de inspección con AWS Network Firewall. TGW Appliance Mode mantiene la simetría de flujos para stateful inspection.
PrivateLink permite exponer un servicio de una VPC a otras VPCs (o cuentas) sin crear VPC Peering ni exponer la VPC completa. El consumidor crea un Interface VPC Endpoint que aparece como una ENI (Elastic Network Interface) en su VPC.
| Componente | Descripción | Dónde vive |
|---|---|---|
| Endpoint Service (Provider) | NLB frente al servicio que quieres exponer. El provider crea el Endpoint Service. | VPC del proveedor del servicio |
| Interface VPC Endpoint (Consumer) | ENI en la subnet del consumidor. DNS apunta a la IP privada de la ENI. | VPC del consumidor |
| Allowlist de cuentas | El proveedor puede limitar qué cuentas o principals pueden crear endpoints al servicio. | Configuración del Endpoint Service |
| DNS privado | Habilitar Private DNS overrides el DNS público del servicio (ej: api.svc.com → IP privada ENI) | VPC del consumidor |
Cuándo usar PrivateLink vs VPC Peering
PrivateLink cuando:
VPC Peering cuando:
RAM permite compartir recursos de AWS entre cuentas de la misma organización o con cuentas externas. El caso de uso más común en networking es compartir subnets de una VPC compartida.
VPC Subnets
Compartir subnets de una VPC central. Cuentas miembro despliegan recursos en esas subnets.
Transit Gateway
Compartir un TGW central con múltiples cuentas sin crear un TGW por cuenta.
Route 53 Resolver Rules
Compartir reglas de DNS forward/conditional para resolución DNS centralizada.
Prefix Lists
Compartir listas de CIDRs administradas centralmente para SGs y route tables.
Direct Connect Gateway + TGW
Para conectar on-premises a múltiples VPCs en múltiples cuentas y regiones, la arquitectura recomendada es: DX → DXGW → TGW → VPCs.
VPN Site-to-Site a escala con ECMP
AWS VPN con TGW soporta ECMP (Equal-Cost Multi-Path) para agregar múltiples túneles VPN y aumentar el throughput.
¿Necesitas conectar 2–5 VPCs con comunicación full-mesh?
→ VPC Peering
¿Tienes 10+ VPCs o necesitas conectar on-premises a múltiples VPCs?
→ Transit Gateway
¿Quieres exponer un microservicio específico a otras cuentas sin compartir toda la VPC?
→ PrivateLink
¿Necesitas compartir subnets de una VPC central entre cuentas de la org?
→ AWS RAM con VPC Sharing
¿Conectividad privada dedicada desde datacenter propio a AWS?
→ Direct Connect (+ DXGW + TGW para escala)
¿Los CIDRs de las VPCs se solapan?
→ PrivateLink (VPC Peering y TGW requieren no solapamiento)
Trampa: "Transit Gateway es transitivo como VPC Peering"
Realidad: TGW SÍ es transitivo — esa es su ventaja clave sobre VPC Peering. VPC Peering es el que NO es transitivo.
Trampa: "PrivateLink requiere que los CIDRs no se solapen"
Realidad: FALSO. PrivateLink funciona incluso con CIDRs solapados — es una de sus ventajas principales sobre Peering.
Trampa: "Un Direct Connect puede conectarse directamente a múltiples VPCs en diferentes regiones sin DXGW"
Realidad: FALSO. Necesitas un Direct Connect Gateway (DXGW) para conectar un DX a VPCs en múltiples regiones.
Trampa: "RAM solo funciona dentro de la misma organización"
Realidad: RAM puede compartir recursos con cuentas externas a la organización también (requiere aceptación manual).
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa tiene 50 VPCs distribuidas en 5 cuentas AWS dentro de una organización. Todas las VPCs necesitan comunicarse entre sí y también acceder a un datacenter on-premises via Direct Connect existente. El equipo de red quiere una arquitectura centralizada que minimice la complejidad operacional. ¿Cuál es la solución más apropiada?
Inicia sesión para llevar tu progreso.