Amazon ANS-C01: Rendimiento y Monitoreo de Red — 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.

Redes mejoradas y estructura de baja latencia

Las redes mejoradas (enhanced networking) en AWS son el conjunto de características a nivel de sistema operativo e hipervisor que aumentan significativamente los paquetes por segundo, reducen la latencia y la sobrecarga de la CPU, y exponen un mayor rendimiento por interfaz virtual. Las tecnologías principales son el Elastic Network Adapter (ENA), que proporciona redes de alto rendimiento basadas en SR-IOV para la mayoría de las familias de instancias EC2 modernas, y el Elastic Fabric Adapter (EFA), que es un dispositivo de tipo RDMA con omisión del SO (OS-bypass) diseñado para HPC y cargas de trabajo MPI/libfabric estrechamente acopladas. Para habilitar ENA, se debe confirmar que el tipo de instancia sea compatible con ENA y que la AMI de Linux tenga el controlador ENA; mediante programación, se puede habilitar o consultar con llamadas a la API de EC2 como RunInstances con InterfaceType=efa cuando sea necesario, o ModifyInstanceAttribute para la compatibilidad con ena. EFA se adjunta creando una interfaz de red con InterfaceType=efa (aws ec2 create-network-interface –interface-type efa) o lanzando instancias con una interfaz de red habilitada para EFA; la instancia debe ejecutar un kernel compatible y el módulo de kernel libfabric/efa y, por lo general, debe ubicarse en un grupo de ubicación de clúster para obtener la latencia más baja entre hosts y el mayor ancho de banda de bisección.

Los grupos de ubicación (placement groups) afectan el rendimiento al controlar la ubicación de las instancias dentro de la estructura de red subyacente. Un grupo de ubicación de clúster (cluster placement group) tiende a ubicar las instancias en un único rack o en un dominio de red de baja latencia para permitir el máximo ancho de banda este-oeste y una latencia consistente; esto es un requisito para muchos casos de uso de EFA. Un grupo de ubicación de dispersión (spread placement group) impone la distribución a nivel de host para evitar fallos correlacionados, pero no mejora la latencia. Para escenarios de alto rendimiento con ráfagas de tráfico, la familia de instancias y el número de vCPU definen las cuotas de ancho de banda de red de referencia; por ejemplo, ciertos tamaños de instancia anuncian hasta 25 Gbps o 100 Gbps, pero el procesamiento de paquetes y las pilas TCP pueden convertirse en cuellos de botella sin ENA/EFA. Al diseñar arquitecturas para miles de conexiones TCP concurrentes (gRPC sobre TLS, por ejemplo), elija tipos de instancia con alta capacidad de conexiones concurrentes, habilite ENA y prefiera NLB / target-type=ip para el direccionamiento directo de pods cuando se ejecute en EKS para evitar cuellos de botella en los puertos de los nodos.

Servicios clave y configuración para observabilidad y cumplimiento

La monitorización de la salud de la red y el diagnóstico de cuellos de botella se basan en una combinación de VPC Flow Logs, métricas de CloudWatch, Traffic Mirroring y los analizadores Reachability/Access Analyzer. VPC Flow Logs proporcionan metadatos por cada flujo (IP de origen/destino, puertos, paquetes, bytes, acción) que se pueden enviar a CloudWatch Logs o S3 y consultar con CloudWatch Logs Insights para encontrar prefijos de alto volumen o los principales comunicadores (“top talkers”). Para la inspección en vivo a nivel de paquete, Traffic Mirroring permite crear un destino de duplicación (mirror target) y un filtro, y luego crear sesiones (aws ec2 create-traffic-mirror-target, aws ec2 create-traffic-mirror-session) para copiar el tráfico de las ENI a un dispositivo de inspección que se ejecute en EC2 o a socios de AWS Network Packet Broker.

CloudWatch expone las métricas relevantes para diferentes capas: métricas de instancia EC2 como NetworkIn/NetworkOut y NetworkPacketsIn/NetworkPacketsOut, métricas de Application Load Balancer bajo AWS/ApplicationELB como RequestCount, ActiveConnectionCount y ClientTLSNegotiationErrorCount, métricas de Network Load Balancer bajo AWS/NetworkELB como ProcessedBytes y NewFlowCount, y métricas de AWS/DirectConnect para la interfaz virtual como BytesIn/BytesOut. Utilice alarmas de CloudWatch y Contributor Insights sobre los flow logs para detectar flujos que saturan la red. Para la validación de rutas y configuración, Reachability Analyzer (a través de la API de EC2 StartNetworkInsightsAnalysis / CreateNetworkInsightsPath) permite modelar y probar rutas de paquetes de extremo a extremo a través de tablas de enrutamiento, NACL, grupos de seguridad y adjuntos de VPN/Direct Connect, mientras que Network Access Analyzer ayuda a detectar rutas de acceso a la red no deseadas a través de sus VPC y AWS Organizations.

Patrones de diseño y consideraciones sobre el balanceo de carga y el acceso seguro

Cuando se requiere TLS de extremo a extremo (end-to-end) con TLS mutuo en el backend y se soportan miles de conexiones gRPC, un Network Load Balancer en modo TCP es el patrón preferido. Un NLB preserva la IP de origen del cliente por defecto y puede ser creado por el AWS Load Balancer Controller para servicios de EKS usando anotaciones como

undefined

para enviar el tráfico directamente a las IPs de los pods. Usar el modo de paso a través (passthrough) de TCP en el puerto 443 significa que el pod del backend termina el TLS mutuo (verificación de certificados de cliente y servidor), por lo que el tráfico nunca se descifra en el balanceador de carga, preservando la autenticación bidireccional. Este patrón escala bien el número de conexiones porque el NLB está diseñado para millones de conexiones concurrentes y una baja sobrecarga por conexión.

Para arquitecturas que requieren la terminación de TLS en el balanceador de carga y enrutamiento basado en la ruta (path-based routing) hacia múltiples grupos de destino, el Application Load Balancer es la opción correcta porque soporta HTTP/2 y gRPC, enrutamiento basado en la ruta y reglas basadas en el host. Para proporcionar un registro preciso de la IP del cliente cuando el ALB termina la conexión TLS, asegúrese de que la aplicación del backend analice las cabeceras X-Forwarded-For (el ALB las inyecta automáticamente) o utilice el protocolo PROXY con un NLB si necesita preservar la IP de origen en la capa TCP. Si utiliza Global Accelerator para proporcionar IPs de frontend estáticas anycast y quiere evitar que los clientes eludan el acelerador y accedan directamente a la URL del ALB, restrinja el grupo de seguridad del ALB para que solo acepte tráfico entrante desde las IPs estáticas del acelerador (las dos direcciones estáticas asignadas al acelerador) para denegar el acceso directo desde internet.

Para servicios compartidos multicuenta con controles estrictos por unidad de negocio y a escala, AWS PrivateLink (VPC Endpoint Services respaldados por NLBs internos) es a menudo el patrón más seguro y escalable. La VPC de servicios compartidos publica servicios a través de endpoints de Network Load Balancer (

undefined

con grupos de destino) y los expone como un VPC Endpoint Service. Las cuentas consumidoras crean endpoints de interfaz en sus VPCs que se conectan al NLB del proveedor; el proveedor controla el acceso mediante políticas de endpoint y grupos de seguridad, y el tráfico nunca atraviesa un plano de enrutamiento centralizado. Transit Gateway es apropiado cuando se necesita visibilidad completa del enrutamiento y conectividad transitiva, pero centraliza el enrutamiento y es menos granular para el control de acceso por servicio que PrivateLink.

Errores comunes y criterios de decisión

Un error frecuente es suponer que el ancho de banda anunciado de la instancia es ilimitado; las familias y tamaños de instancia establecen límites de red estrictos y el escalado debe considerar la división entre ENIs y la ubicación en grupos de ubicación de clúster para un rendimiento consistente. Otro error común es depender únicamente de NetworkIn/NetworkOut de CloudWatch sin correlacionar los VPC Flow Logs para atribuir el tráfico a una VPC, subred o unidad de negocio en particular; los Flow Logs y Traffic Mirroring son necesarios para aislar qué interfaz virtual o aplicación está causando la saturación de Direct Connect. También evite terminar TLS en el ALB cuando se requiere TLS mutuo de extremo a extremo. Si la política exige que el backend vea el certificado del cliente, elija el paso a través de TLS (TLS passthrough) con un NLB o realice un puente TLS (TLS bridging) con la validación de certificados adecuada, pero sea explícito sobre dónde se establece la confianza.

Al diagnosticar la saturación intermitente en enlaces físicos compartidos como Direct Connect, correlacione las métricas entre capas: métricas de AWS/DirectConnect para las interfaces virtuales, VPC Flow Logs para los recuentos de bytes por subred/ENI y métricas de red de EC2 (Network*) para el comportamiento a nivel de instancia. Utilice Reachability Analyzer para validar si el enrutamiento asimétrico o una propagación de rutas errónea está causando problemas en la ruta de retorno, y use Traffic Mirroring para capturar volcados de paquetes para una inspección profunda de protocolos.

Problema práctico: Escenario de caso de uso

AcmeIoT se enfrenta a un problema en el que máquinas expendedoras de todo el mundo deben conectarse a través de gRPC con TLS mutuo a un backend alojado en EKS. Las conexiones deben ser miles, el servicio debe permanecer cifrado de extremo a extremo y los pods del backend deben escalar dinámicamente con el Cluster Autoscaler y el HPA.

Cree un AWS LoadBalancer de tipo Network Load Balancer para el servicio de Kubernetes, utilizando el AWS Load Balancer Controller y anotaciones para especificar NLB y target-type=ip (service.beta.kubernetes.io/aws-load-balancer-type: “nlb” y service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: “ip”). Configure un listener TCP en el puerto 443 para que el NLB realice un paso a través de TCP puro (TCP passthrough); no configure certificados TLS en el NLB.
Implemente la terminación y validación de TLS mutuo en los pods de la aplicación. Cada pod debe presentar un certificado de servidor y validar los certificados de cliente, utilizando un proceso de rotación de certificados de corta duración integrado con AWS Secrets Manager o SSM Parameter Store. Asegúrese de que las IP de los pods sean alcanzables utilizando target-type ip y que las comprobaciones de estado sean comprobaciones de estado TCP o gRPC configuradas en el grupo de destino.
Asegure una alta escalabilidad de conexiones eligiendo instancias con soporte para ENA y ancho de banda de red suficiente, habilite ENA (confirme con el controlador ENA en la AMI y use aws ec2 modify-instance-attribute para habilitar ena-support donde sea necesario), y despliegue los pods en múltiples nodos con el Cluster Autoscaler escalando los nodos según las solicitudes de los pods. Use grupos de ubicación (placement groups) para clústeres estrechamente acoplados que necesiten una latencia consistente y despliegue un número suficiente de nodos en varias Zonas de Disponibilidad (AZ).
Supervise y valide usando CloudWatch y VPC Flow Logs. Cree métricas y alarmas de CloudWatch para ActiveFlowCount/NewFlowCount del NLB y NetworkIn/Out de los nodos de trabajo EC2 de EKS. Use VPC Flow Logs para identificar a los “top-talkers” (principales comunicadores) y Reachability Analyzer (StartNetworkInsightsAnalysis/CreateNetworkInsightsPath) para validar las rutas de enrutamiento durante los eventos de autoescalado. Si necesita depuración a nivel de paquete, cree sesiones de Traffic Mirroring hacia una instancia de inspección.

Justificación de AWS: un Network Load Balancer en modo TCP preserva la IP de origen, admite una cantidad masiva de conexiones concurrentes y permite TLS de extremo a extremo porque no termina la conexión TLS. El tipo de destino ip (target-type ip) con el AWS Load Balancer Controller se integra con la semántica de autoescalado de EKS, de modo que las nuevas IP de los pods se registran como destinos dinámicamente. ENA y el dimensionamiento adecuado de las instancias proporcionan la capacidad de red bruta para manejar miles de conexiones TLS concurrentes sin agotar la CPU del host, y la combinación de CloudWatch, VPC Flow Logs, Reachability Analyzer y Traffic Mirroring proporciona la observabilidad necesaria para detectar y remediar problemas de saturación o enrutamiento.

← Entrega de Contenido y Redes de Borde · Todos los dominios · Automatización →

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