Amazon DOP-C02: Redes y Entrega de Contenido — Guía de estudio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Descripción general

Las redes y la entrega de contenido en AWS abarcan los constructos fundamentales de VPC, las opciones de interconexión para topologías híbridas y de múltiples cuentas, y los servicios de borde que exponen, protegen y aceleran las aplicaciones a nivel mundial. Dominar esto requiere comprender cómo se mueven los paquetes en una VPC (subredes, tablas de enrutamiento, gateways y filtrado), cómo interconectar VPC y redes locales (peering, Transit Gateway, PrivateLink, Direct Connect, VPN), y cómo distribuir y proteger el tráfico en el borde (CloudFront, AWS WAF, AWS Global Accelerator). Los puntos de entrada de las aplicaciones, como Amazon API Gateway, se integran luego con estas primitivas a través de dominios personalizados, certificados y tipos de endpoint.

Arquitectura de VPC y controles de seguridad

Una VPC es una red regional y lógicamente aislada con una o más subredes en cada Zona de Disponibilidad. Diseñe las subredes según los dominios de error y las funciones: subredes públicas para los balanceadores de carga orientados a internet y los NAT gateways; subredes de aplicación privadas para los nodos de EC2/ECS/EKS; y subredes de datos privadas para las bases de datos. Asigne tablas de enrutamiento distintas por tipo de subred para mantener la intención explícita y para soportar un diseño de egreso zonal.

La conectividad a internet es proporcionada por un internet gateway (IGW) adjuntado a nivel de la VPC. Una subred se vuelve “pública” cuando su tabla de enrutamiento tiene una ruta por defecto hacia el IGW y los recursos tienen IP públicas o Elastic IPs. Para el acceso a internet de solo salida desde subredes privadas, use NAT gateways. Coloque un NAT gateway por cada Zona de Disponibilidad, enrute cada subred privada al NAT gateway en la misma AZ y deshabilite el NAT entre zonas de disponibilidad para evitar puntos únicos de fallo y reducir los cargos por procesamiento de datos entre zonas de disponibilidad. Para IPv6, los egress-only internet gateways proporcionan conectividad de solo salida sin NAT.

Las tablas de enrutamiento determinan los siguientes saltos para los prefijos de destino. Los destinos comunes incluyen IGW, NAT gateway, adjuntos de VPC peering, adjuntos de Transit Gateway y local. Mantenga las tablas de enrutamiento simples: una ruta por defecto para el egreso y rutas explícitas para las interconexiones privadas. Prefiera las listas de prefijos (prefix lists) para hacer referencia a destinos compartidos entre cuentas y para reducir el error humano.

Los grupos de seguridad (security groups) y las ACL de red (network ACLs) proporcionan filtrado de red, pero con mecánicas diferentes:

• Los grupos de seguridad son con estado (stateful), se adjuntan a las ENI y se evalúan solo por reglas de permiso (allow). El tráfico de retorno se permite automáticamente. Soportan referencias a otros grupos de seguridad para expresar la topología de la aplicación de forma segura.
• Las ACL de red son sin estado (stateless), se aplican en el límite de la subred, se evalúan por orden de regla con permisos (allow) y denegaciones (deny) explícitos para la entrada y la salida. El tráfico de retorno debe permitirse explícitamente. Use las NACL con moderación para denegaciones generales a nivel de subred o para patrones de cumplimiento; mantenga los rangos de puertos efímeros requeridos por sus sistemas operativos y balanceadores de carga.

El filtrado con estado frente al sin estado es importante para la resolución de problemas. Si se usan ambos, ambos deben permitir el flujo. Habilite VPC Flow Logs hacia CloudWatch Logs o S3 para analizar el tráfico aceptado/denegado y para validar la postura de seguridad.

Conectividad entre VPC e híbrida

El VPC peering conecta dos VPC de forma privada sin un punto único de fallo ni un cuello de botella en el ancho de banda, pero no es transitivo y requiere CIDR que no se superpongan. Cada VPC debe agregar rutas estáticas para el par (peer) a través del adjunto de peering. Las referencias a grupos de seguridad entre VPC emparejadas no están soportadas; filtre con CIDR. El peering entre regiones (Cross-Region) está disponible y se cifra por defecto.

AWS Transit Gateway (TGW) simplifica la escala y la segmentación de la red. Actúa como un hub regional para VPC y adjuntos híbridos, soporta enrutamiento transitivo y escala a decenas de Gbps por adjunto. Use las tablas de enrutamiento de TGW para implementar la segmentación (p. ej., desarrollo vs. producción vs. servicios compartidos) y para controlar la propagación y la asociación. Los adjuntos incluyen VPC, Site-to-Site VPN y Direct Connect a través de una Transit VIF y un Direct Connect Gateway. Para un egreso centralizado, adjunte una VPC de egreso y propague/comparta rutas selectivamente. Planifique para múltiples regiones conectando los TGW con peering entre regiones.

AWS PrivateLink proporciona acceso privado de capa 4 (L4), iniciado por el consumidor, a servicios a través de los límites de VPC/cuenta/región sin exponer las subredes del proveedor ni requerir enrutamiento. El proveedor de servicios coloca un NLB frente a los endpoints; los consumidores crean endpoints de VPC de tipo interfaz en sus VPC con IP privadas y nombres DNS asignados. PrivateLink no es transitivo y solo soporta TCP. Use PrivateLink para publicar servicios internos o para consumir servicios de AWS de forma privada. Prefiera PrivateLink sobre el peering/TGW cuando necesite exposición a nivel de servicio, consumo basado en DNS o un aislamiento más estricto del productor.

La conectividad híbrida a menudo combina Direct Connect (DX) y Site-to-Site VPN. Direct Connect proporciona ancho de banda dedicado, privado y consistente con puertos de 1/10 Gbps (y capacidades alojadas). Use BGP para el enrutamiento dinámico y la conmutación por error (failover). Tipos de interfaz virtual (VIF):

• Private VIF: alcanzabilidad por IP privada a las VPC a través de un virtual private gateway (VGW) o a través de un Transit Gateway con una Transit VIF.
• Public VIF: alcanzabilidad por IP pública a los servicios públicos de AWS; anuncie sus prefijos públicos; AWS anuncia sus prefijos públicos globales.
• Transit VIF: conecta un Direct Connect gateway a uno o más TGW para una conectividad escalable multirregional y de múltiples VPC. Diseñe la redundancia utilizando dos conexiones físicas de DX en ubicaciones y dispositivos de DX separados, con LAG separados si es necesario, y routers duales en las instalaciones locales. Añada una VPN como respaldo (VPN por internet hacia un VGW o TGW) con BGP para que las rutas conmuten por error automáticamente cuando las sesiones BGP de DX se caigan. Para la VPN, use dos túneles por conexión para alta disponibilidad (HA); prefiera BGP sobre las rutas estáticas; valide los CIDR y la seguridad dentro del túnel.

Redes de Borde, Seguridad y Aceleración

Amazon CloudFront es una CDN global que acelera el contenido estático y dinámico con almacenamiento en caché en el borde y rutas de red optimizadas. Una distribución define:

• Orígenes: S3, orígenes personalizados (ALB/NLB/EC2/API Gateway) o grupos de origen para failover. Habilita Origin Shield para una capa de caché intermedia adicional que reduzca la carga en el origen.
• Comportamientos: enrutamiento a orígenes basado en rutas y métodos, políticas de caché y de solicitud de origen (reenvío de encabezados/cookies/consultas), políticas de protocolo del espectador (HTTP→HTTPS), compresión, URLs/cookies firmadas y hooks de funciones (CloudFront Functions para solicitudes ligeras del espectador; Lambda@Edge para manipulación de solicitudes/respuestas).
• Caché: ajusta los TTL a través de políticas de caché, varía las claves solo en las dimensiones necesarias y usa políticas de solicitud de origen para minimizar la fragmentación de la caché. Para las API, evita reenviar encabezados/cookies/consultas innecesarias. Usa el cifrado a nivel de campo donde sea necesario.
• Invalidación: emite invalidaciones para rutas modificadas o usa claves de objeto versionadas para actualizaciones de caché sin tiempo de inactividad. Automatiza las invalidaciones después del despliegue para activos no versionados.

AWS WAF protege las aplicaciones en la capa 7 (L7). Una ACL web contiene reglas y grupos de reglas que se evalúan en orden, con una acción predeterminada. Usa las Reglas Administradas de AWS (AWS Managed Rules) para protecciones base (p. ej., CommonRuleSet, WordPress, SQLi/XSS) y grupos de reglas de socios seleccionados cuando sea necesario. Añade reglas personalizadas usando sentencias de coincidencia (conjunto de IP, encabezado, URI, cuerpo JSON, coincidencia de etiquetas) y combínalas con operadores lógicos. Las reglas basadas en la tasa (rate-based rules) limitan a los clientes que exceden una tasa de solicitudes configurada en una ventana de tiempo, opcionalmente con sentencias de reducción de alcance (scope-down) para apuntar a rutas o encabezados específicos. Asocia las ACL web con distribuciones de CloudFront, Application Load Balancers, API Gateway (REST/HTTP) y AppSync. Monitorea la capacidad (WCU), habilita los registros muestreados en CloudWatch Logs o Kinesis Data Firehose, y usa las acciones CAPTCHA/Challenge para mitigar bots sin bloquear el tráfico legítimo.

AWS Global Accelerator proporciona IP estáticas anycast que actúan como fachada para los endpoints regionales y acelera el tráfico TCP/UDP a través de la red global de AWS. Opera en las capas 4/7 (L4/7) con enrutamiento basado en la salud y failover rápido. Configura:

• Grupos de endpoints por Región con health checks y pesos.
• Selectores de tráfico (traffic dials) para controlar el porcentaje de tráfico enviado a una Región (p. ej., 1% para un canary o 0% durante el mantenimiento) independientemente de los pesos de los endpoints. Los endpoints compatibles incluyen ALB, NLB, instancias EC2 y Elastic IPs. Usa Global Accelerator para protocolos que no son HTTP, que son sensibles a la latencia o con estado (stateful), o cuando se requieren IP estáticas y un failover determinista. CloudFront sigue siendo la opción principal para el almacenamiento en caché de HTTP/S y la ejecución de funciones en el borde; ambos servicios son complementarios.

Puertas de enlace de API: dominios, certificados y estrategia de puntos de conexión

Amazon API Gateway proporciona API REST y HTTP con tres tipos de puntos de conexión:

• Optimizados para la periferia (solo API REST): API Gateway crea y gestiona una distribución de CloudFront; es óptimo para clientes globales con terminación de TLS en las ubicaciones de borde. Los certificados de dominio personalizados deben estar en us-east-1 (Norte de Virginia) a través de ACM.
• Regionales: para clientes en la misma región o cuando se desea poner al frente de API Gateway una distribución de CloudFront propia o Global Accelerator. Los certificados de dominio personalizados deben estar en la misma región que la API.
• Privados: accesibles solo dentro de sus VPC a través de puntos de conexión de VPC de interfaz; no tienen una ruta pública a internet.

Los dominios personalizados unifican el enrutamiento y el TLS entre etapas y API. Utilice mapeos de rutas base para asignar rutas a etapas. Almacene los certificados en ACM; elija RSA/ECDSA según la compatibilidad del cliente. Para los puntos de conexión optimizados para la periferia, solicite o importe el certificado en us-east-1. Para los regionales, solicítelo o impórtelo en la región. Aplique políticas de TLS que coincidan con su postura de cumplimiento. Integre con WAF asociando una ACL web directamente a las API regionales o protegiendo la distribución de CloudFront que se encuentra al frente de la API. Para obtener las API globales de menor latencia con caché avanzado y normalización de encabezados, coloque una distribución de CloudFront delante de una API regional, use el control de acceso de origen y solicitudes firmadas si es necesario, y ajuste las políticas de caché y de solicitud de origen para evitar la inflación de la caché. Combine con autorizadores de Lambda o Amazon Cognito para la autenticación y aproveche la limitación controlada (throttling) y los planes de uso para proteger los backends, además de las reglas basadas en la tasa de WAF.

Escenario de un problema práctico

Shopify está implementando un nuevo microservicio de pago global para atender a comerciantes de todo el mundo. Los requisitos son: tráfico este-oeste privado entre microservicios en más de 20 cuentas, cero exposición pública para las API internas, baja latencia determinista para los usuarios finales en el proceso de pago, protecciones robustas de capa 7 (L7) con limitación de tasa adaptativa y conectividad híbrida resiliente a los motores de riesgo on-premises.

Enfoque paso a paso:

1. Segmentar la red con un diseño de Transit Gateway en modo hub-and-spoke

• Crear una cuenta de red centralizada con un AWS Transit Gateway regional. Adjuntar todas las VPC de cargas de trabajo (spokes) de cada cuenta a través de adjuntos de TGW compartidos con RAM. Usar múltiples tablas de rutas de TGW para forzar la segmentación (producción vs. servicios compartidos vs. desarrollo) y propagar solo las rutas necesarias.
• Por qué TGW: Escala el enrutamiento transitivo y simplifica la gestión de rutas en comparación con una malla completa de peering; admite adjuntos híbridos.

2. Publicar microservicios internos con AWS PrivateLink

• En cada VPC productora, colocar un NLB delante de los grupos de destino de los microservicios internos y crear un servicio de punto de conexión de VPC. En las VPC consumidoras, crear puntos de conexión de interfaz para esos servicios y habilitar el DNS privado específico del punto de conexión.
• Por qué PrivateLink: Conectividad a nivel de servicio, solo TCP y no transitiva sin exposición de rutas; los productores permanecen aislados y no necesitan permisos de entrada en los grupos de seguridad (SG) para bloques CIDR completos.

3. Establecer conectividad híbrida redundante con Direct Connect y VPN

• Provisionar dos conexiones de Direct Connect de 10 Gbps en ubicaciones de DX separadas, que terminen en routers on-premises distintos. Crear un Direct Connect Gateway con una VIF de tránsito hacia el TGW. Configurar BGP en ambos lados con ASN distintos y políticas de MED/local-pref. Añadir un adjunto de Site-to-Site VPN al TGW como respaldo con dos túneles, con BGP habilitado.
• Por qué esta combinación: DX proporciona un ancho de banda determinista y menor jitter; BGP más el respaldo de VPN ofrecen una conmutación por error automática y alta disponibilidad.

4. Poner AWS Global Accelerator al frente del proceso de pago público

• Crear un acelerador con dos listeners (80/443 → 443). Definir grupos de puntos de conexión en us-east-1 y eu-west-1, cada uno apuntando a los ALB para el servicio de pago. Establecer los selectores de tráfico en 50/50 para el estado estable y habilitar las comprobaciones de estado en los puntos de conexión de salud del ALB. Habilitar la afinidad de cliente si se requiere la fijación de sesión.
• Por qué Global Accelerator: IP estáticas anycast, conmutación por error regional rápida y optimización de TCP para flujos de pago con estado (stateful) y de baja latencia.

5. Proteger en el borde con CloudFront y AWS WAF

• Colocar CloudFront delante de la API Gateway regional (para los GET idempotentes y los activos estáticos) y directamente delante de los ALB que sirven contenido dinámico que puede beneficiarse de la normalización de encabezados y la descarga de TLS. Configurar políticas de caché para restringir la varianza a los encabezados/consultas necesarios, habilitar Origin Shield para reducir la carga en el origen y automatizar las invalidaciones para los activos no versionados.
• Adjuntar una ACL web de AWS WAF a CloudFront con las reglas administradas de AWS, un grupo de reglas personalizadas para el filtrado de lógica de negocio y una regla basada en la tasa con una declaración de alcance reducido en las rutas de pago. Habilitar CAPTCHA para picos sospechosos y registrar en Kinesis Data Firehose para análisis.
• Por qué CloudFront + WAF: Terminación de TLS global, almacenamiento en caché donde sea seguro, controles de L7 basados en el borde y absorción de DDoS a través de AWS Shield.

6. Exponer las API con dominios personalizados y TLS robusto

• Usar puntos de conexión regionales de API Gateway para los métodos de API con alta carga de escritura, protegidos detrás de CloudFront. Crear dominios personalizados en ACM por región, aplicar políticas de TLS estrictas y mapear las rutas base a las etapas. Para las API de administración internas, desplegar API privadas y acceder a ellas a través de puntos de conexión de interfaz; asociar grupos de seguridad de privilegio mínimo.
• Por qué esta división: Los puntos de conexión regionales junto con CloudFront ofrecen flexibilidad con controles en el borde; las API privadas mantienen las superficies internas fuera de internet.

7. Asegurar las VPC con controles en capas

• Aplicar grupos de seguridad con estado (stateful) y de privilegio mínimo, haciendo referencia a los SG de productor/consumidor siempre que sea posible. Mantener las NACL simples (permitir todo) excepto para denegaciones de subred específicas necesarias para el cumplimiento. Habilitar VPC Flow Logs con filtros de métricas de CloudWatch para detectar fuentes anómalas. Colocar un NAT gateway por AZ y enrutar las subredes privadas al NAT local para evitar dependencias entre AZ.
• Por qué controles en capas: Los SG gestionan la mayor parte de la intención con seguimiento de conexiones; las NACL proporcionan barreras de seguridad generales; el NAT zonal mejora la resiliencia y el costo.

Este diseño ofrece conectividad este-oeste privada y segmentada (Transit Gateway + PrivateLink), rutas híbridas norte-sur resilientes (DX + VPN con BGP), una entrada pública acelerada y protegida globalmente (Global Accelerator + CloudFront + WAF), y controles operativos alineados con las mejores prácticas de AWS para el enrutamiento, las puertas de enlace y el filtrado de VPC.

← Almacenamiento · Todos los dominios · Systems Manager →

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

Explorar Amazon →