Amazon ANS-C01: Entrega de Contenido y Redes de Borde — Guía de estudio

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Forma parte de la AWS Advanced Networking Specialty ANS-C01 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Patrones de diseño y contrapartidas

Cuando el requisito es almacenamiento en caché de contenido, además de computación en el borde y respuestas HTTP de baja latencia, CloudFront es la herramienta adecuada. CloudFront debe terminar TLS en el borde cuando no se requiere la confidencialidad del origen; utilice CachePolicy y OriginRequestPolicy para minimizar las solicitudes al origen excluyendo cabeceras y cookies de la clave de caché cuando sea seguro. Para la personalización dinámica que aún se beneficia del almacenamiento en caché, utilice la normalización de la clave de caché (variando según un conjunto mínimo de cabeceras o cookies firmadas) y diseñe la invalidación de caché mediante claves de objeto versionadas en lugar de llamadas frecuentes a CreateInvalidation.

Para protocolos que requieren TLS de extremo a extremo, flujos HTTP/2 y gRPC que no deben descifrarse hasta el backend (para mTLS), coloque una ruta TCP/L4 al frente utilizando Global Accelerator + NLB con TLS passthrough. La contrapartida es perder las capacidades de almacenamiento en caché HTTP y de computación en el borde de CloudFront; sin embargo, Global Accelerator proporciona IP estáticas anycast, enrutamiento mejorado y conmutación por error regional. ALB soporta HTTP/2 y gRPC cuando el ALB termina el TLS, lo que permite el enrutamiento a nivel de aplicación (basado en host/ruta) y la integración con WAF, pero la terminación en el ALB rompe el mTLS de extremo a extremo y sitúa la gestión de certificados en el balanceador de carga. Para conexiones simultáneas masivas, los NLB escalan mejor en L4: los NLB están optimizados para la tasa de conexión y conservan la IP de origen, mientras que los ALB están diseñados para el enrutamiento a nivel HTTP y características como reglas de escucha (listener rules) para el enrutamiento a nivel de host/ruta y la integración con Cognito/OIDC.

Los controles de seguridad y los patrones de aislamiento regional requieren una selección cuidadosa entre VPC peering compartido, Transit Gateway, PrivateLink y puntos de conexión de Load Balancer. PrivateLink proporciona controles de acceso granulares a nivel de servicio y escala bien para muchos consumidores porque cada consumidor crea un punto de conexión de interfaz en su VPC. Transit Gateway es apropiado para la centralización de alto ancho de banda, pero carece de los controles granulares por servicio y la visibilidad a nivel de SNI/host que proporciona un punto de conexión de PrivateLink. El diseño debe considerar los límites de enrutamiento, los permisos entre cuentas y la capacidad de aplicar grupos de seguridad en el límite del servicio.

Errores comunes y criterios de decisión

Un error frecuente es mezclar incorrectamente los controles de caché: permitir que las cabeceras Cache-Control establecidas por el origen dirijan el almacenamiento en caché en el borde mientras también se aplican las políticas de caché de CloudFront puede crear TTLs inesperados; prefiera objetos CachePolicy explícitos y no dependa únicamente de las cabeceras del origen a menos que sea deliberado. Otro error es seleccionar un ALB cuando se necesita TLS de extremo a extremo o millones de conexiones TCP simultáneas; la terminación de TLS en el ALB impide el mTLS y puede convertirse en el cuello de botella para una concurrencia de conexiones muy alta. Las configuraciones de seguridad que intentan restringir el acceso a un ALB orientado a Internet a menudo olvidan bloquear el acceso utilizando la lista de prefijos de Global Accelerator o una regla de WAF; sin reglas de permiso explícitas, el ALB seguirá siendo accesible a través de su DNS público. Finalmente, los despliegues de Lambda@Edge que no utilizan funciones Lambda versionadas pueden causar un comportamiento inconsistente durante las implementaciones, ya que la asociación en la distribución se vincula a una versión publicada específica.

Problema práctico: Escenario de caso de uso

Empresa: AcmeTelemetrics — desafío: una flota global de máquinas expendedoras de IoT utiliza gRPC sobre TCP:443 hacia un backend en us-east-1 que se ejecuta en Amazon EKS; el requisito es TLS mutuo de extremo a extremo (mTLS) para que el tráfico nunca se descifre en tránsito, soportar miles de conexiones simultáneas y se deben programar IP estáticas en las máquinas.

Enfoque:

1. Crear un Global Accelerator (aws globalaccelerator create-accelerator) con dos IP estáticas anycast y un listener TCP en el puerto 443 (create-listener). Configurar un grupo de puntos de conexión que apunte a un Network Load Balancer regional en us-east-1 (create-endpoint-group).
2. Aprovisionar un NLB en us-east-1 con un listener TCP en el puerto 443 y un grupo de destino (target group) de tipo ip. En Kubernetes, crear un Service de tipo LoadBalancer con las anotaciones service.beta.kubernetes.io/aws-load-balancer-type: “nlb” y service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”, establecer externalTrafficPolicy: Local y registrar las IP de los pods como destinos para que el TLS pase directamente a los pods.
3. Desplegar los servidores gRPC en EKS y terminar TLS/mTLS en los procesos del pod. Almacenar los certificados y el material de confianza en Kubernetes Secrets; configurar el servidor para que requiera la verificación del certificado del cliente para el TLS mutuo.
4. Restringir el acceso directo al NLB para que solo Global Accelerator pueda alcanzarlo, actualizando el grupo de seguridad del NLB para permitir el ingreso (ingress) solo desde la lista de prefijos de Global Accelerator gestionada por AWS (descubrir mediante aws ec2 describe-managed-prefix-lists y hacer referencia a esa lista de prefijos en las reglas del grupo de seguridad), evitando que las máquinas eludan el acelerador y accedan directamente al NLB.
5. Monitorear la concurrencia de conexiones y el escalado configurando Kubernetes HorizontalPodAutoscaler y Cluster Autoscaler, y asegurarse de que el inicio lento (slow start) y el retardo de anulación de registro (deregistration delay) del grupo de destino del NLB estén ajustados para un escalado hacia adentro (scale-in) gradual (modify-target-group-attributes). Usar las métricas de CloudWatch de Global Accelerator, NLB y EKS para vigilar los recuentos de conexiones y el estado de salud.

Justificación de AWS: Global Accelerator proporciona las IP estáticas anycast requeridas por las máquinas expendedoras y enruta los flujos TCP a través de la red troncal (backbone) de AWS hacia el NLB regional, mejorando la fiabilidad y la latencia. El NLB conserva la conexión TCP y la IP de origen del cliente original y soporta conexiones simultáneas masivas, permitiendo que los pods realicen la terminación de mTLS sin una terminación de TLS intermedia. El uso de la lista de prefijos gestionada de Global Accelerator en las reglas del grupo de seguridad impide el desvío directo del acelerador y garantiza que el tráfico llegue únicamente a través de las IP anycast. Esta combinación satisface los requisitos de cifrado de extremo a extremo, mTLS, alta concurrencia, IP estáticas y autoescalado en EKS.

← Seguridad de Red y Cumplimiento · Todos los dominios · Rendimiento y Monitoreo de Red →

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

Explorar Amazon →