Amazon SAP-C02: Redes y Conectividad Híbrida — Guía de estudio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Forma parte de la AWS Solutions Architect Professional SAP-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Arquitectura de VPC y patrones de segmentación

El diseño de la topología de VPC comienza con la gestión del radio de impacto (blast radius) y un enrutamiento predecible. Para despliegues pequeños, una única VPC con múltiples subredes y security groups estrictos puede ser eficiente, pero a medida que los equipos y las aplicaciones crecen, el patrón de una sola VPC se vuelve frágil: las cuotas de recursos, la gobernanza entre equipos y los “vecinos ruidosos” (noisy neighbors) aumentan el riesgo operativo. El modelo de múltiples VPC por equipo o de una cuenta por equipo mejora el aislamiento y los límites de IAM; utilice AWS Organizations con cuentas separadas para los equipos y una cuenta de servicios compartidos para DNS, registros (logging) e identidad. Para la conectividad entre VPC, el VPC peering es simple y de baja latencia, pero no es transitivo y es operacionalmente pesado a escala. Transit Gateway (TGW) reemplaza el patrón de “VPC de tránsito”: soporta miles de adjuntos (attachments), centraliza las tablas de rutas y simplifica los patrones de multicast o hub-and-spoke. PrivateLink (Interface VPC Endpoints) permite el aislamiento a nivel de servicio sin exponer los servicios a internet, lo cual es crítico para los microservicios entre cuentas (cross-account). Las trampas comunes incluyen confiar únicamente en los security groups para la segmentación (son stateful y demasiado generales para el filtrado este-oeste), olvidar el comportamiento stateless de las NACL y no planificar la asignación de CIDR (los solapamientos dificultan el peering y DX). Las decisiones dependen del costo frente a la gestionabilidad: TGW tiene costos por adjunto (attachment) pero reduce la complejidad por cada peering; el aislamiento multicuenta aumenta la sobrecarga de la landing zone pero reduce el radio de impacto. Documente siempre el plan de CIDR, las reglas de propagación de rutas y la propiedad de los servicios compartidos para evitar desviaciones (drift).

Conectividad híbrida, enrutamiento y resiliencia

Las opciones de conectividad híbrida dependen del rendimiento (throughput), el jitter, la latencia y el direccionamiento de egreso público consistente. Las VIF privadas de AWS Direct Connect (DX) proporcionan un ancho de banda determinista y costos de egreso más bajos en comparación con una VPN por internet para flujos grandes y constantes; utilice un Direct Connect Gateway para abarcar múltiples regiones o adjuntarlo a un Transit Gateway para un enrutamiento centralizado. La Site-to-Site VPN (IPsec gestionado con BGP) se utiliza para una configuración rápida o como un respaldo resiliente para DX; configure BGP con los ASN y las prioridades de ruta adecuados para evitar el enrutamiento asimétrico. Las trampas clave de enrutamiento son el solapamiento de CIDR on-premise y en la nube, la propagación incorrecta de rutas en TGW y asumir un enrutamiento transitivo a través de VPC interconectadas con peering. El MTU y la fragmentación pueden interrumpir el tráfico de la VPN: pruebe el path MTU y ajuste el MSS en los dispositivos. Para entornos multirregión, considere un DX activo/activo en múltiples ubicaciones o un DX combinado con failover a una VPN. Compensaciones (Trade-offs): los enlaces DX dedicados cuestan más pero reducen el jitter y los cargos de egreso; la VPN es más barata y simple pero menos estable con un alto rendimiento (throughput). Diseñe para un failover predecible con dos túneles independientes, conexiones DX redundantes en ubicaciones separadas y tablas de rutas de TGW explícitas para controlar la selección de rutas y los límites.

DNS, PrivateLink y patrones de conectividad de servicios

El DNS es fundamental para las redes híbridas y multicuenta. Utilice Route 53 Private Hosted Zones para la resolución dentro del ámbito de una VPC y los endpoints de entrada/salida (inbound/outbound) de Route 53 Resolver para habilitar el reenvío condicional entre el DNS on-premise y el de AWS. Esto soporta un DNS de horizonte dividido (split-horizon) donde los nombres internos se resuelven a IP privadas mientras que los registros públicos permanecen globales. PrivateLink (interface endpoints) proporciona conectividad privada, respaldada por ENI, a servicios de AWS o a socios SaaS sin enrutar el tráfico a través de la internet pública; compare esto con los Gateway Endpoints para S3 y DynamoDB, que son más baratos y utilizan tablas de rutas en lugar de ENI. PrivateLink evita exponer los servicios a conflictos de CIDR de VPC y soporta consumidores en otras cuentas (cross-account) con políticas de aceptación del servicio. Los errores comunes incluyen olvidar asociar las zonas alojadas privadas (private hosted zones) a todas las VPC consumidoras, no crear reglas en Route 53 Resolver para los dominios on-premise y subestimar el consumo de IP por cada ENI de endpoint. Criterios de decisión: prefiera los Gateway endpoints para el acceso de alto rendimiento a S3/DynamoDB para evitar costos de NAT; utilice Interface endpoints cuando necesite acceso privado a endpoints de API o a servicios de terceros con una seguridad más estricta. Supervise la latencia del DNS y establezca los TTL con un control de cambios para gestionar el comportamiento del failover.

Egreso, diseño de NAT, controles de seguridad y prácticas operativas

La arquitectura de egreso afecta el costo, la auditabilidad y las integraciones con terceros. NAT Gateway proporciona un egreso de IPv4 administrado y de alta disponibilidad para subredes privadas con escalado automático por AZ; las NAT Instances son más económicas para un uso de bajo rendimiento, pero exigen mantenimiento operativo y scripting para failover. Centralizar el egreso a través de una VPC de egreso dedicada conectada a un Transit Gateway impone IPs de salida consistentes, puntos de inspección y políticas simplificadas, pero introduce enrutamiento de horquilla (hairpin routing) y posibles cuellos de botella en el ancho de banda. Para IPv6, utilice un Egress-Only Internet Gateway. Reemplace los bastiones SSH con AWS Systems Manager Session Manager para la auditoría y para eliminar las credenciales de entrada públicas; Session Manager funciona a través del agente de SSM sin abrir puertos SSH. Para filtrado avanzado y DPI, despliegue AWS Network Firewall o dispositivos de terceros detrás del TGW. Compensaciones entre costo y rendimiento: los NAT Gateways son fáciles de usar pero añaden cargos por GB; utilice VPC endpoints para reducir los costos de egreso de S3 y de NAT. Las trampas operativas incluyen no habilitar VPC Flow Logs para la solución de problemas de tráfico, dejar reglas de egreso amplias que permiten la exfiltración de datos y usar SCPs o políticas de IAM que bloquean involuntariamente las operaciones del ciclo de vida; aplique el mínimo privilegio y registre todo en una cuenta central para su análisis.

Problema práctico: Acme Financial Services — Egreso centralizado y predecible para listas blancas de terceros

Escenario: Acme Financial Services ejecuta múltiples VPC de aplicaciones en dos Regiones de AWS, conectadas con un Transit Gateway y con centros de datos locales (on-premises) a través de Direct Connect y VPN. Varias aplicaciones en cuentas separadas deben llamar a una API de un socio que solo acepta solicitudes desde un único bloque CIDR público.

Desafío: Proporcionar una ruta de egreso de alta disponibilidad y auditable con un único bloque CIDR público predecible para todas las VPC de aplicaciones entre Regiones, minimizando al mismo tiempo la latencia y la sobrecarga operativa.

Enfoque recomendado:

Traer un CIDR de IPv4 público a AWS usando BYOIP (Bring Your Own IP) y asignar Elastic IPs de ese CIDR para usarlas como direcciones de egreso.
Construir una VPC de egreso centralizada en cada Región con NAT Gateways en múltiples AZ; asociar las Elastic IPs de BYOIP con esos NAT Gateways y conectar las VPC de egreso al Transit Gateway.
Actualizar las tablas de rutas del TGW para que todas las VPC de aplicaciones enruten 0.0.0.0/0 hacia el attachment de la VPC de egreso, habilitar la propagación de rutas y el failover con chequeos de salud (health-checked failover) entre AZs; configurar el enrutamiento on-prem para preferir el egreso local donde sea necesario.
Desplegar Network Firewall o un IDS gestionado en la VPC de egreso para el filtrado de salida, habilitar VPC Flow Logs y alarmas de CloudWatch, y usar Route 53 Resolver para cualquier necesidad de reenvío de DNS.

Justificación: Centralizar el egreso a través de TGW y NAT Gateways con un espacio de IP proporcionado por BYOIP ofrece un CIDR predecible para las listas blancas, al tiempo que se preserva la alta disponibilidad y la monitorización centralizada. Esto equilibra la simplicidad operativa, los controles de seguridad y el requisito del socio de tener un único CIDR público.

← Complejidad Organizacional y Estrategia de Múltiples Cuentas · Todos los dominios · Seguridad →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →