Amazon ANS-C01: Redes de Contenedores y Serverless — 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 en EKS (CNI, redes de pods)

Las redes de pods en Amazon EKS están dominadas por el plugin Amazon VPC CNI (amazon-vpc-cni-k8s), que asigna a cada pod una dirección IP de la VPC y coloca el tráfico del pod directamente en la red de la VPC. Este diseño ofrece un control de seguridad predecible a nivel de VPC (grupos de seguridad, NACL) y un enrutamiento de baja latencia, pero requiere una planificación cuidadosa de la capacidad de direcciones IP y ENIs, ya que el número de direcciones IPv4 secundarias por ENI y el número de ENIs por tipo de instancia están limitados por el hardware. El daemonset aws-node gestiona la asignación de IP y las operaciones de asociación/desasociación; su ConfigMap se edita con kubectl para ajustar el comportamiento (por ejemplo, estableciendo WARM_IP_TARGET, WARM_ENI_TARGET o ENABLE_PREFIX_DELEGATION). Los modos de delegación de prefijos y de ENI para pods reducen el agotamiento de IP por nodo al permitir que un nodo asigne prefijos /28 completos a una ENI (ENABLE_PREFIX_DELEGATION=true) o al asignar una ENI dedicada por pod (útil para un aislamiento de alta seguridad).

Alternativas al Amazon VPC CNI como Cilium (eBPF) o Calico pueden ofrecer diferentes contrapartidas. Cilium puede reemplazar a kube-proxy e implementar reenvío L3/L4 de alto rendimiento usando eBPF, habilitar el cifrado transparente entre nodos (WireGuard o IPsec) y reducir la presión de IP a nivel de nodo mediante enfoques de superposición (overlay) o enmascaramiento (masquerading). Con Cilium, todavía te integras con el enrutamiento de la VPC para el tráfico de salida y entrada, pero evitas las frecuentes operaciones de asociación/desasociación de ENIs; esto es importante con altas tasas de rotación de pods. Para un número muy alto de conexiones y un comportamiento estricto en L7, también debes considerar el ajuste del modo de kube-proxy (IPVS) y la configuración del kernel del nodo: ajusta conntrack_max, tcp_tw_recycle/tcp_tw_reuse y ip_local_port_range, y exponlos a través de kubelet o scripts de inicialización de daemonsets para evitar el agotamiento de puertos efímeros bajo miles de conexiones gRPC concurrentes y de larga duración.

Modos de red de ECS e integración de Lambda con VPC

Las redes de tareas de ECS tienen tres modos principales: bridge, host y awsvpc. El modo awsvpc es el más comparable a las redes de pods de Kubernetes porque asocia una ENI a cada tarea (o grupo de tareas) y asigna una IP privada y grupos de seguridad directamente a la tarea. Configura awsvpc especificando awsvpcConfiguration con subnets y securityGroups en las llamadas a la API RunTask o CreateService. Fargate impone el uso de awsvpc y, por lo tanto, proporciona aislamiento de red a nivel de tarea y se integra con AWS Cloud Map para el descubrimiento de servicios. Usa awsvpc cuando necesites filtrado de tráfico basado en grupos de seguridad por tarea, o cuando necesites exponer el enrutamiento y las métricas estándar de la VPC.

Las funciones Lambda que necesitan acceso a una VPC se conectan a ella a través de ENIs en las subredes y grupos de seguridad configurados para la función. Estas ENIs son creadas y gestionadas por el plano de control de Lambda, pero el aprovisionamiento de ENIs puede añadir latencia de arranque en frío (cold-start) y ha limitado históricamente el escalado rápido, a menos que se mitigue con concurrencia aprovisionada o mediante el uso de VPC endpoints (AWS PrivateLink) y una arquitectura de subredes cuidadosamente diseñada. Al colocar muchas funciones Lambda en una VPC, asegúrate de que las subredes tengan IPs disponibles, usa un NAT Gateway o instancias NAT para el tráfico de salida según sea necesario, y prefiere los VPC endpoints (endpoints com.amazonaws.* a través de AWS::EC2::VPCEndpoint) para evitar enrutar el tráfico de salida a través de internet siempre que sea posible. Supervisa la asociación/desasociación de ENIs usando CloudWatch Logs y VPC Flow Logs para observar el comportamiento de escalado y solucionar problemas de throttling relacionados con la concurrencia.

App Mesh y descubrimiento de servicios

AWS App Mesh utiliza sidecars de Envoy como plano de datos y proporciona observabilidad L3-L7, modelado de tráfico, reintentos y controles de origen/terminación de TLS. Define mallas (meshes), nodos virtuales y servicios virtuales a través de la API de App Mesh (CreateMesh, CreateVirtualNode, CreateVirtualService) o el controlador de App Mesh para Kubernetes. App Mesh soporta mTLS configurando el bloque TLS de un listener de VirtualNode con una clientPolicy y una autoridad de certificación, y puedes integrarlo con AWS Certificate Manager (ACM) o SDS para la distribución de certificados. Sin embargo, ten en cuenta que los sidecars de App Mesh, por diseño, terminan y vuelven a cifrar el tráfico; si un requisito exige que el tráfico de la aplicación permanezca cifrado de extremo a extremo entre el cliente y el pod de la aplicación (sin descifrado en el proxy de red), debes asegurarte de que TLS termine solo en el pod y evitar terminarlo en la entrada de la malla o en el balanceador de carga.

El descubrimiento de servicios se realiza comúnmente con Kubernetes Services y CoreDNS para EKS, con Cloud Map (CreateService, RegisterInstance) para entornos multiplataforma, y con zonas alojadas privadas de Route 53 para búsquedas basadas en DNS. AWS Cloud Map se integra directamente con ECS y App Mesh, permitiendo registros SRV o A y comprobaciones de estado controladas por API. Para entornos dinámicos donde las instancias escalan rápidamente, combina TTLs de DNS cortos y comprobaciones de estado de Cloud Map para evitar la resolución de DNS obsoleta; si necesitas consistencia inmediata, utiliza una API del plano de control de la malla de servicios para obtener los endpoints en lugar de depender de la caché de DNS.

Patrones de diseño y consideraciones

Al diseñar para gRPC a gran escala sobre TLS con mTLS, debe decidir dónde termina TLS. Terminar en el balanceador de carga (ALB) permite descargar los certificados en ACM y simplifica la rotación de certificados, pero rompe el cifrado de extremo a extremo y no puede proporcionar TLS mutuo a los pods de backend a menos que el backend restablezca TLS con la información del certificado del cliente reenviada. Para un mTLS de extremo a extremo verdadero donde los endpoints de la aplicación autentican a los clientes directamente, use un gateway de paso a nivel L4 como un Network Load Balancer y deje que el pod/aplicación gestione TLS/mTLS. Combine el tipo de destino ip del NLB con la anotación del AWS Load Balancer Controller

undefined

para registrar las IP de los pods directamente; este patrón escala bien porque el NLB está diseñado para millones de conexiones y soporta sesiones TCP/gRPC de larga duración sin terminar TLS.

Para el enrutamiento de entrada (ingress) y basado en rutas (path) con terminación de HTTPS, Application Load Balancer es más apropiado porque soporta reglas de host/ruta, redirecciones e integración con WAF. Para preservar las IP de los clientes cuando el ALB termina TLS, confíe en las cabeceras X-Forwarded-For; los servidores web de backend deben consumir y registrar X-Forwarded-For, y debería habilitar los registros de acceso del ALB para su verificación. Si necesita la dirección de socket real del cliente en la capa del servidor (para software heredado), use NLB con proxy protocol v2 y asegúrese de que los servicios de backend soporten el proxy protocol.

La conectividad de servicios entre múltiples cuentas de AWS y VPC escala de manera diferente según el patrón. El peering de VPC es simple pero su gestión es N^2; Transit Gateway centraliza el enrutamiento y escala mejor para muchas VPC con segregación de tablas de rutas; AWS PrivateLink (Interface VPC Endpoints) proporciona el modelo de acceso más granular por servicio y consciente de la identidad, porque expone un servicio de endpoint a través de un NLB y los consumidores crean endpoints de interfaz en sus VPC. Para servicios compartidos multicuenta con un control de acceso estricto y una incorporación (onboarding) escalable, prefiera PrivateLink porque aísla el enrutamiento (sin cambios en las tablas de rutas en las VPC de los consumidores) y usa grupos de seguridad para controles de grano fino.

Errores comunes y criterios de decisión

Un error recurrente es asumir que el mismo modelo de red se adapta a todas las cargas de trabajo. Las cargas de trabajo con estado o de conexión de larga duración (gRPC, bases de datos) favorecen el paso directo de capa 4 (NLB) con terminación de TLS a nivel de pod o patrones hostPort/hostNetwork para evitar la latencia inducida por el proxy; los microservicios HTTP que necesitan enrutamiento basado en la ruta, WAF o terminación de WebSocket se benefician de las características de ALB y App Mesh. Otro error es no tener en cuenta los límites de ENI/IP al escalar nodos de EKS o tareas de ECS en modo awsvpc: consulte siempre la tabla de ENI y de IP por ENI para el tipo de instancia EC2 y utilice la delegación de prefijos o las redes superpuestas (overlays) de Cilium cuando necesite una alta densidad de pods.

El monitoreo y la depuración requieren múltiples fuentes: VPC Flow Logs y métricas de ENI para ver el egreso/ingreso de tráfico, métricas de CloudWatch para los AWS Load Balancers (ActiveFlowCount, ProcessedBytes) y telemetría a nivel de aplicación desde Envoy/App Mesh o el agente de AWS X-Ray. Para Lambda y Fargate, recuerde que los arranques en frío ligados a operaciones de ENI pueden mitigarse con la concurrencia aprovisionada o rediseñando los patrones de acceso para usar endpoints de VPC y PrivateLink, de modo que las funciones no necesiten un egreso amplio.

Problema práctico: Escenario de caso de uso

Nombre de la empresa: Acme Payments Inc. Desafío: Acme Payments ejecuta un servicio gRPC en Amazon EKS que debe soportar miles de conexiones TLS concurrentes en el puerto TCP 443, usar TLS mutuo (mTLS) para que el certificado del cliente sea validado por el servicio de backend, y permitir que el clúster de EKS se autoescale mediante Cluster Autoscaler y HPA sin interrumpir la conectividad ni requerir la terminación de TLS en el balanceador de carga.

Enfoque numerado:

1. Desplegar el servicio con TLS a nivel de pod y autenticación mutua implementada en la aplicación o en un sidecar que no termine el TLS de extremo a extremo para los clientes externos. Almacenar los certificados de servidor/cliente en AWS Secrets Manager y montarlos a través del almacén de secretos CSI de Kubernetes o usar un mecanismo de distribución de certificados que funcione con el ciclo de vida del pod.
2. Usar el AWS Load Balancer Controller para crear un Network Load Balancer anotando el Service (

undefined

) y establecer el tipo de destino en IP (

undefined

), luego crear un listener TCP en el puerto 443. Esto asegura que el NLB realice un paso directo de capa 4 (passthrough de L4) y no termine el TLS. 3. Configurar el grupo de destino del NLB con el protocolo TCP y registrar las IP de los pods dinámicamente (el Load Balancer Controller llamará a CreateTargetGroup y RegisterTargets). Asegurarse de que las comprobaciones de estado estén configuradas en TCP o en una sonda de estado personalizada basada en TCP con un intervalo corto para que los destinos se marquen como saludables rápidamente durante el autoescalado (

undefined

). 4. Ajustar el CNI de Amazon VPC para soportar una alta densidad de pods y reducir la rotación de ENI: habilitar la delegación de prefijos si es compatible (establecer ENABLE_PREFIX_DELEGATION=true en el ConfigMap aws-node), configurar WARM_IP_TARGET para mantener direcciones de repuesto y monitorear las métricas de aws-node (logs del daemonset de kube-system y métricas personalizadas de CloudWatch). Si los límites de IP a nivel de nodo son una preocupación, considere Cilium con eBPF para una mayor densidad de pods y operaciones de ENI reducidas. 5. Escalar el clúster de forma segura: asegurarse de que el Cluster Autoscaler tenga las etiquetas de grupo de nodos y los permisos de IAM adecuados, establecer PodDisruptionBudgets y verificar que las comprobaciones de estado del grupo de destino y el drenaje de conexiones del NLB estén configurados para evitar interrumpir las conexiones gRPC de larga duración durante el escalado hacia abajo. 6. Asegurar la rotación y confianza de los certificados: automatizar la rotación de certificados con ACM Private CA o Secrets Manager y asegurarse de que los pods recuperen los paquetes de confianza (trust bundles) actualizados sin requerir una reconfiguración del NLB. Usar sondas de readiness/liveness de Kubernetes que reflejen la disponibilidad del handshake de mTLS.

Justificación de AWS: Un Network Load Balancer en modo de destino IP preserva el TLS hasta el pod (cifrado real de extremo a extremo) y soporta millones de conexiones TCP persistentes, lo que lo hace apropiado para miles de sesiones gRPC concurrentes. Registrar las IP de los pods directamente evita la complejidad del registro de destinos por hostPort a nivel de nodo o por instancia y se integra sin problemas con Cluster Autoscaler/HPA porque el AWS Load Balancer Controller registrará y anulará el registro de las IP de los pods a medida que estos escalan. Ajustar el CNI de VPC o adoptar un plano de datos basado en eBPF previene el agotamiento de IP y reduce la latencia de adjuntar/desadjuntar ENI, lo cual es esencial para un autoescalado rápido y cargas de trabajo con muchas conexiones. Almacenar y entregar los artefactos de mTLS a través de Secrets Manager o un proveedor CSI hace que el ciclo de vida del certificado sea manejable sin tocar el balanceador de carga.

← Automatización · Todos los dominios

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

Explorar Amazon →