Amazon ANS-C01: Balanceo de Carga y Gestión de Tráfico — 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.

Concepto principal

El balanceo de carga en AWS opera en dos capas fundamentales: L4 (transporte) y L7 (aplicación). Network Load Balancer (NLB) proporciona distribución en L4 (TCP/UDP/TLS) y está optimizado para un rendimiento extremo, preservando la IP de origen del cliente y soportando millones de conexiones concurrentes con muy baja latencia y volatilidad de las conexiones. Application Load Balancer (ALB) opera en L7 (HTTP/HTTPS/WebSocket y HTTP/2/gRPC), proporciona enrutamiento basado en host y en ruta (path), inspección de cabeceras, comprobaciones de estado basadas en HTTP y adherencia (stickiness) por cookies, y realiza la terminación de TLS cuando se configura con certificados en ACM. Gateway Load Balancer (GWLB) es un balanceador de carga diseñado específicamente para escalar dispositivos virtuales (appliances) de terceros (firewalls, IDS/IPS) utilizando la encapsulación GENEVE y endpoints de Gateway Load Balancer (GWLBe), permitiendo la inspección de tráfico en línea (inline) sin escalado manual de los dispositivos.

Los listeners y las reglas de listener son los puntos de entrada L4/L7 que mapean protocolos/puertos a los grupos de destino (target groups). Un listener en un ALB puede tener reglas complejas que inspeccionan el host, la ruta, las cabeceras, el CIDR de la IP de origen y reenvían a diferentes grupos de destino; el ALB también puede descargar (terminar) el TLS y presentar las cabeceras X-Forwarded-For, X-Forwarded-Proto y X-Forwarded-Port a los destinos. Un listener de NLB es típicamente un listener TCP/UDP/TLS que reenvía el tráfico a los grupos de destino sin analizar el contenido (payload) (a menos que habilite la terminación de TLS en el NLB): cuando se utiliza el paso directo de TCP (passthrough), se preserva el TLS de extremo a extremo, por lo que el backend debe presentar y validar certificados para TLS mutuo (mTLS). Los grupos de destino son el vínculo entre un listener de balanceador de carga y el conjunto de puntos de conexión (endpoints), que pueden ser instancias, IPs o funciones Lambda, y exponen atributos como el protocolo/puerto/ruta para las comprobaciones de estado, el retraso de anulación de registro (drenaje de conexiones o connection draining) y las propiedades de adherencia (stickiness).

Servicios clave y configuración

Elija el balanceador adecuado según las características del tráfico y los requisitos de seguridad. Use ALB cuando necesite enrutamiento basado en host/ruta, características HTTP/HTTPS como WebSockets o HTTP/2/gRPC con enrutamiento consciente de la aplicación, y adherencia (stickiness) basada en cookies. Configure los listeners de ALB con

undefined

o a través de

undefined

, adjunte certificados de ACM y establezca reglas de listener usando

undefined

con condiciones (

undefined

). Habilite la adherencia en los grupos de destino de ALB con

undefined

estableciendo

undefined

para usar cookies generadas por el balanceador de carga.

Use NLB para conexiones TCP de alto rendimiento y larga duración, y cuando se requiere preservar la IP de origen del cliente en el backend. Cree un NLB con

undefined

y añada un listener TCP con

undefined

. Para TLS de paso directo (passthrough) y mTLS, configure el listener del NLB como TCP para que el TLS sea terminado por el backend; establezca el tipo de destino del grupo como

undefined

al registrar IPs de pods para Kubernetes. Use

undefined

para establecer

undefined

para permitir el drenaje de conexiones (connection draining); para NLB también puede habilitar la afinidad por IP de origen (adherencia o stickiness en el grupo de destino) cuando sea apropiado.

Gateway Load Balancer se configura con

undefined

y está respaldado por grupos de destino de sus instancias de dispositivos (o un conjunto de escalado en un grupo de autoescalado), y utiliza un endpoint de Gateway Load Balancer en las VPC consumidoras para dirigir el tráfico hacia los dispositivos en la VPC de servicio. Utilice este patrón cuando necesite inspección transparente y desee que los dispositivos escalen automáticamente con el tráfico; cree listeners en el puerto 6081 (encapsulación GENEVE) y registre las ENI de los dispositivos en el grupo de destino del GWLB.

Las configuraciones operativas que debe controlar programáticamente incluyen el balanceo de carga entre zonas (cross-zone), el retraso de anulación de registro (connection draining) y el ajuste de las comprobaciones de estado. Para el balanceo entre zonas, establezca atributos en el balanceador de carga (

undefined

) para asegurar la distribución del tráfico entre las AZ en lugar de sesgar la capacidad por AZ. Establezca el intervalo, el tiempo de espera y los umbrales de estado saludable/no saludable en los grupos de destino para evitar estados intermitentes (flapping) durante eventos de autoescalado.

Patrones de diseño y contrapartidas

Para TLS de extremo a extremo y TLS mutuo (mTLS), donde el tráfico debe permanecer cifrado y los certificados de cliente deben presentarse al backend, prefiere el paso directo (passthrough) de capa 4 (L4) usando un NLB con listeners TCP. Esto mantiene intacta la sesión TLS para que los backends puedan validar los certificados X.509 del cliente; configura los grupos de destino (target groups) para usar destinos IP (IP targets) de modo que las IP de los pods de Kubernetes puedan registrarse directamente y el AWS Load Balancer Controller pueda gestionar el ciclo de vida de los destinos. La contrapartida es perder las características de capa 7 (L7) del ALB, como el enrutamiento por host/ruta, las integraciones con Web Application Firewall y la persistencia de sesión (stickiness) nativa por cookies HTTP en la capa del balanceador de carga.

Cuando necesites enrutamiento basado en contenido, terminación de TLS y características HTTP avanzadas, usa un ALB y termina la sesión TLS en el ALB (con certificados gestionados por ACM). Para conservar la IP del cliente para registros (logging) y reglas de WAF, lee la cabecera X-Forwarded-For que el ALB rellena o usa una capa que inyecte la IP original del cliente en las cabeceras. Si requieres que el sistema operativo o la pila de red del backend vea la IP del cliente a nivel de socket, usa un NLB (o habilita el Proxy Protocol para pasar la IP original), pero ten en cuenta que el Proxy Protocol debe estar habilitado en el grupo de destino y tu aplicación o proxy (por ejemplo, Envoy) debe ser capaz de analizarlo.

Manejar sesiones persistentes (sticky sessions) en un entorno de autoescalado requiere una consideración cuidadosa. La persistencia de sesión por cookies del ALB puede vincular a un cliente con un destino durante un tiempo determinado, lo que puede inhibir un escalado equilibrado entre los pods si el tráfico de la sesión es intenso; los patrones alternativos incluyen usar persistencia de corta duración combinada con la externalización del estado de la sesión a ElastiCache (Redis) o DynamoDB, o usar un proxy sidecar (Envoy) para manejar la afinidad de sesión con hashing consistente. El drenaje de conexiones (connection draining o deregistration delay) es crítico para un apagado ordenado (graceful shutdown): establece deregistration_delay.timeout_seconds a una duración mayor que la solicitud RPC/HTTP más larga para evitar terminaciones abruptas y errores del cliente durante la terminación del pod; configura los hooks preStop de Kubernetes para coordinar el ciclo de vida del pod con la anulación del registro (deregistration).

GWLB es el patrón apropiado cuando necesitas una inspección en línea (inline) escalable a través de muchas VPC y deseas controles de seguridad centralizados. Combina GWLB con arquitecturas de Transit Gateway o VPC peering según sea necesario; el costo y la complejidad operativa de la gestión de los dispositivos (appliances) son las contrapartidas en comparación con el uso de servicios gestionados como AWS Network Firewall.

Errores comunes y criterios de decisión

Un error frecuente es terminar TLS en el ALB sin tener en cuenta las necesidades de los servicios posteriores para la autenticación del cliente o la IP de origen original. Si los backends requieren el certificado del cliente o la IP de origen real en la capa TCP (para registro o autorización), termine TLS en el backend mediante el modo passthrough de un NLB o utilice Proxy Protocol y asegúrese de que la aplicación lo analice. Otro error común es habilitar sesiones persistentes (sticky sessions) sin un almacenamiento de sesión externo mientras se utiliza Horizontal Pod Autoscaler: a medida que los pods escalan horizontalmente (hacia afuera o hacia adentro), la afinidad persistente puede crear puntos calientes y capacidad desperdiciada; prefiera backends sin estado o externalice el estado de la sesión.

También surgen errores operativos por comprobaciones de estado mal configuradas y retrasos en la anulación del registro que provocan la pérdida de solicitudes durante el escalado. Configure siempre las rutas y los umbrales de las comprobaciones de estado para reflejar el calentamiento de la aplicación y utilice deregistration_delay.timeout_seconds para permitir que las conexiones de larga duración se drenen. El balanceo de carga entre zonas (cross-zone load balancing) debe configurarse de forma intencionada: habilitarlo reduce la latencia de cola e iguala la carga, pero puede aumentar los costos de transferencia de datos entre AZ; evalúe esta opción en función de la capacidad de las AZ y los patrones de tráfico. Finalmente, GWLB introduce una sobrecarga por encapsulación (GENEVE) y gestión de appliances: automatice el registro de los appliances utilizando las API de AWS (CreateTargetGroup/RegisterTargets) e instruméntelos con métricas de CloudWatch para impulsar las políticas de autoescalado.

Problema práctico: escenario de caso de uso

Empresa: Acme Telemetry. Desafío: Proporcionar cifrado de extremo a extremo para un servicio gRPC (gRPC sobre TLS en el puerto TCP 443) desplegado en un clúster de Amazon EKS, soportar miles de conexiones concurrentes de larga duración, utilizar Kubernetes Cluster Autoscaler y HPA, y requerir TLS mutuo (mTLS) para que el certificado del cliente sea validado por el backend (es decir, el tráfico no debe ser descifrado por ningún balanceador de carga intermedio).

Enfoque de implementación del caso de uso: Aprovisione un Network Load Balancer con un listener TCP en el puerto 443 y un grupo de destino de tipo “ip” que apunte a las IP de los pods. Cree el NLB con aws elbv2 create-load-balancer --name acme-nlb --type network --subnets <subnet-ids>, cree el grupo de destino con aws elbv2 create-target-group --name tg-grpc --protocol TCP --port 443 --target-type ip --vpc-id <vpc-id>, registre los destinos a través de las anotaciones del AWS Load Balancer Controller para Kubernetes (service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip") para que el controlador registre las IP de los pods automáticamente, y cree el listener con aws elbv2 create-listener --load-balancer-arn <arn> --protocol TCP --port 443 --default-actions Type=forward,TargetGroupArn=<tg-arn>. Establezca el atributo del grupo de destino deregistration_delay.timeout_seconds a un valor apropiado (por ejemplo, 300) usando aws elbv2 modify-target-group-attributes para habilitar el drenaje ordenado de conexiones.
Configuración de TLS y mTLS en el backend: Termine TLS y realice el TLS mutuo en la capa de los pods. Despliegue sidecars de Envoy o haga que los servidores gRPC acepten TLS directamente, almacenando los certificados del servidor y los paquetes de CA en Kubernetes Secrets y montándolos en el pod. Configure los backends para validar los certificados de cliente contra su CA y configure las comprobaciones de estado para que usen TCP y así evitar la terminación de TLS en el balanceador de carga. Asegúrese de que los hooks de ciclo de vida de HPA y Cluster Autoscaler se coordinen con la anulación del registro del grupo de destino implementando hooks preStop que permitan a los pods terminar el drenaje de conexiones antes de cerrarse.
Escalabilidad y controles operativos: Habilite el balanceo de carga entre zonas en el NLB si es necesario con aws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn> --attributes Key=load_balancing.cross_zone.enabled,Value=true para distribuir uniformemente las conexiones entre las AZ. Supervise las conexiones concurrentes y las tasas de flujo con las métricas de CloudWatch (NetworkPackets, ActiveFlowCount para NLB) y establezca políticas de autoescalado para el appliance (si usa un sidecar) y para los nodos de trabajo. Utilice ModifyTargetGroupAttributes para el drenaje de conexiones y ajuste los intervalos de las comprobaciones de estado para una detección de fallos más rápida y sin oscilaciones. Finalmente, automatice la rotación de certificados utilizando AWS Secrets Manager y la integración con cert-manager de Kubernetes.

Justificación de AWS: El NLB en modo TCP preserva la sesión TLS de extremo a extremo para que el backend pueda realizar la validación mTLS; su arquitectura de capa 4 (L4) está diseñada para millones de flujos concurrentes y conexiones de larga duración, y el uso de target-type ip permite que el AWS Load Balancer Controller registre las IP de los pods directamente, lo que posibilita que HPA/Cluster Autoscaler escalen de forma transparente. El drenaje de conexiones (deregistration_delay) y las comprobaciones de estado evitan la pérdida de solicitudes durante la terminación de los pods, y el balanceo de carga entre zonas garantiza una distribución uniforme entre las AZ, sacrificando el costo de transferencia entre AZ a cambio de un mayor rendimiento.

← DNS y Route 53 · Todos los dominios · Seguridad de Red y Cumplimiento →

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