Amazon ANS-C01: Automatización, IaC y Operaciones de Red — Guía de estudio
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
La Infraestructura como Código para redes en AWS convierte la topología de red, las políticas de seguridad y el enrutamiento en plantillas declarativas y operaciones de ciclo de vida deterministas. Las plantillas de CloudFormation (AWS::EC2::VPC, AWS::EC2::Subnet, AWS::EC2::RouteTable, AWS::EC2::TransitGateway, AWS::EC2::TransitGatewayAttachment, AWS::ElasticLoadBalancingV2::LoadBalancer, AWS::EC2::VPCEndpoint, AWS::EC2::NetworkAcl, AWS::EC2::SecurityGroup) codifican el estado deseado, mientras que las API de CloudFormation —las operaciones CreateStack, UpdateStack, DeleteStack, DescribeStacks y ChangeSet— aplican los cambios de forma atómica. Utilice pilas anidadas y plantillas modulares para aislar dominios de red (servicios compartidos, VPC de aplicaciones por cuenta, zonas de entrada/salida) y StackSets para propagar pilas de red consistentes a través de AWS Organizations. La detección de desviaciones (DetectStackDrift) y los conjuntos de cambios (change sets) proporcionan barreras de protección para que la automatización pueda detectar y requerir una revisión humana para los cambios de red realizados fuera de banda.
La automatización también debe cubrir las partes de la red que CloudFormation no puede expresar de forma nativa o que requieren ganchos de ciclo de vida (lifecycle hooks): el uso compartido de recursos entre cuentas, las integraciones locales (on-prem) y la configuración en tiempo de ejecución en los hosts. Los recursos personalizados de CloudFormation (respaldados por Lambda) o los módulos de CloudFormation pueden llamar a API como CreateResourceShare (AWS RAM) para compartir un Transit Gateway o una subred, o llamar a Systems Manager (SSM) SendCommand para inyectar certificados o políticas de enrutamiento en las instancias. Para Kubernetes en EKS, el AWS Load Balancer Controller se instala a través de Helm y se gestiona mediante anotaciones de Service; CloudFormation puede aprovisionar el rol de IAM, el proveedor OIDC y los objetos HelmRelease a través de AWS::EKS::Cluster y recursos personalizados, pero el mapeo en tiempo de ejecución de las IP de los pods a los grupos de destino del NLB es manejado por el controlador.
Servicios y configuración clave
Hay servicios y API principales de AWS que utilizará repetidamente al automatizar las operaciones de red: CloudFormation (CreateStack, UpdateStack, DetectStackDrift), AWS Resource Access Manager (CreateResourceShare, AssociateResourceShare), AWS Transit Gateway (CreateTransitGateway, CreateTransitGatewayAttachment, CreateTransitGatewayRoute), Elastic Load Balancing V2 (CreateLoadBalancer, CreateTargetGroup, ModifyTargetGroupAttributes), AWS Lambda (CreateFunction, AddPermission, Invoke), Systems Manager (PutParameter, SendCommand, CreateDocument) y AWS Config (PutEvaluations, StartConfigurationRecorder). Estos servicios forman una pila de automatización típica para redes seguras y auditables.
Al diseñar plantillas y automatización, preste atención a los atributos de recursos específicos y a las anotaciones del controlador. Para los balanceadores de carga, elija el tipo y los atributos correctos: un NLB con listeners TCP preserva la IP de origen y soporta Proxy Protocol v2 a través de CreateLoadBalancer/ModifyTargetGroupAttributes y estableciendo “proxy_protocol_v2.enabled” en los grupos de destino; un ALB (Application Load Balancer) termina TLS e inserta las cabeceras X-Forwarded-For para las IP de los clientes y soporta gRPC/HTTP2 cuando se configura con listeners HTTPS. Para EKS, se utilizan anotaciones como service.beta.kubernetes.io/aws-load-balancer-type: “nlb” o las anotaciones de Ingress/Service del AWS Load Balancer Controller para controlar el paso directo de TLS (passthrough) frente a la terminación y para establecer el tipo de destino (target type) en ip para apuntar directamente a los pods. Para el uso compartido entre cuentas y redes multicuenta, utilizará AWS RAM para compartir Transit Gateways, y CloudFormation StackSets combinado con roles de administrador delegado para crear adjuntos (attachments) y acceso en las cuentas consumidoras.
Patrones de diseño y contrapartidas
Dos patrones comunes y contrapuestos son el modelo hub-and-spoke con Transit Gateway y la VPC compartida a través de AWS RAM. El modelo hub-and-spoke con un Transit Gateway centraliza el enrutamiento, la inspección y la conectividad entre VPC; escala porque los adjuntos (attachments) y las tablas de rutas permiten la segmentación, y se puede compartir el TGW usando RAM para que diferentes cuentas puedan crear adjuntos sin transferir la propiedad completa. La contrapartida son los límites de propagación y de las tablas de rutas: los límites de las tablas de rutas y de los adjuntos del Transit Gateway requieren planificación y pueden introducir puntos únicos donde se debe aplicar la política (utilice múltiples tablas de rutas y AWS Network Firewall para aislar el tráfico). La VPC compartida (compartición de VPC con AWS RAM) ubica las subredes en una cuenta anfitriona y permite a las cuentas consumidoras lanzar recursos en esas subredes, lo que simplifica los controles de seguridad centrales para la conectividad, pero reduce la autonomía a nivel de cuenta y complica el aislamiento de la red por unidad de negocio porque la propiedad de los grupos de seguridad y los límites de IAM deben gestionarse con cuidado.
Para la entrada de tráfico (ingress) y la terminación TLS, debe equilibrar la necesidad de cifrado de extremo a extremo con la escala y la preservación de la IP del cliente. Si requiere la terminación TLS en el balanceador de carga (para WAF, centralización de certificados y enrutamiento HTTP), ALB es la herramienta adecuada; añade X-Forwarded-For para que los registros de la aplicación puedan capturar las IP de los clientes, y ALB soporta el enrutamiento basado en ruta (path) y en host a múltiples grupos de destino. Si requiere un verdadero TLS de extremo a extremo o mTLS donde el balanceador de carga no debe descifrar el tráfico, utilice un NLB en modo TCP para pasar el TLS directamente a los puntos finales del backend (pod o instancia) y configure el target type como ip y externalTrafficPolicy: Local en Kubernetes para preservar la IP de origen. Para miles de conexiones gRPC bidireccionales concurrentes con mTLS, un NLB que reenvía el TLS sin procesar a los puertos de los pods, combinado con pods que terminan el mTLS, proporciona escalabilidad y un verdadero cifrado de extremo a extremo, mientras se utilizan las anotaciones del AWS Load Balancer Controller para crear los listeners y grupos de destino del NLB adecuados.
Errores comunes y criterios de decisión
Un error común es confundir la ubicación de la terminación TLS con los requisitos de la IP del cliente: ALB proporciona X-Forwarded-For cuando termina la conexión TLS, pero no conserva la IP de origen hasta el destino como lo hace NLB. Si necesita tanto las características de ALB (enrutamiento por host/ruta, WAF) como la IP de origen original en el backend, considere usar ALB para la terminación HTTP y reenviar el tráfico a proxies inversos o sidecars que reconstruyan las IP de origen a partir de X-Forwarded-For, o use una arquitectura donde un NLB realice un pass-through de TLS a servicios que implementen mTLS y deleguen el enrutamiento HTTP a proxies dentro del clúster. Otro error común es configurar incorrectamente los permisos entre cuentas: al compartir un Transit Gateway u otro recurso de red con RAM, asegúrese de usar un recurso compartido explícito y el rol de IAM y el principal de RAM correctos; no hacerlo produce errores opacos de “permission denied” (permiso denegado).
En cuanto a la automatización del cumplimiento, no almacene claves privadas ni material de la CA sin cifrar en texto plano. Use SSM Parameter Store SecureString con una clave de KMS que tenga una política de clave mínima que permita el acceso únicamente a los roles y principales que lo requieran. Use las reglas administradas de AWS Config (por ejemplo, vpc-flow-logs-enabled, restricted-common-ports, security-group-rule-check) y, cuando las reglas administradas no cubran sus criterios, implemente reglas de Config respaldadas por Lambda que llamen a PutEvaluations. La remediación debe automatizarse a través de documentos de SSM Automation o Systems Manager Run Command que la acción de remediación de Config pueda invocar, pero siempre proporcione una ruta de alerta y aprobación para los cambios de alto riesgo.
Problema práctico: Escenario de caso de uso
Empresa: ApexTelemetrics — desafío: proporcionar un servicio gRPC alojado en EKS y accesible globalmente que requiera TLS mutuo (mTLS) verdaderamente de extremo a extremo (el cliente y el servidor se autentican con mTLS), soporte miles de conexiones concurrentes de larga duración sobre TCP 443, debe autoescalar los pods y garantizar que la distribución y rotación de certificados esté automatizada y sea auditable.
Enfoque:
- Aprovisionar la red y el balanceador de carga con CloudFormation: crear un NLB a través de AWS::ElasticLoadBalancingV2::LoadBalancer configurado con un listener TCP en el puerto 443 y grupos de destino con targetType establecido en “ip” y comprobaciones de estado sobre TCP. Usar CreateStack/UpdateStack de CloudFormation y pilas anidadas modulares para la VPC, las subredes y el NLB. Usar las anotaciones del AWS Load Balancer Controller en el Service de EKS (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”, service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”) para que cada Service cree el grupo de destino del NLB directamente en los pods.
- Garantizar el pass-through de TLS y la terminación de mTLS en los pods: configurar el Service de EKS para que reenvíe el tráfico TCP 443 directamente a los puertos de los pods; implementar un sidecar o un proxy envoy dentro de cada pod que realice la terminación de mTLS con el cliente e imponga la autenticación mutua. Establecer externalTrafficPolicy: Local en el Service para que la IP de origen se conserve si es necesario, y usar el autoescalado a nivel de Pod (Horizontal Pod Autoscaler) junto con Cluster Autoscaler para escalar nodos y pods conjuntamente.
- Automatizar el ciclo de vida y la distribución de certificados: almacenar las claves privadas de la CA y del certificado del servidor en SSM Parameter Store SecureString, cifradas con una clave de KMS. Crear un recurso personalizado respaldado por AWS Lambda en CloudFormation para crear parámetros de SSM durante la creación de la pila (CreateFunction con el rol de IAM adecuado, y luego el recurso personalizado de CloudFormation para llamar a PutParameter). Usar SSM Run Command o un DaemonSet inmutable que extrae secretos de SSM a través de un rol de IAM vinculado al pod (a través de IRSA) para inyectar los certificados en el sidecar. Para la rotación, programar funciones Lambda (CreateFunction + regla de EventBridge) para generar nuevos certificados, llamar a PutParameter y usar SSM o Kubernetes Jobs para realizar reinicios progresivos (rolling restarts).
- Cumplimiento y auditoría: habilitar reglas de AWS Config (reglas administradas como vpc-flow-logs-enabled y reglas personalizadas respaldadas por Lambda usando PutEvaluations) para verificar que los listeners del NLB son TCP y que ningún ALB está terminando la conexión TLS para este servicio. Configurar la remediación de Config para invocar documentos de SSM Automation si se detecta una configuración incorrecta y enviar los hallazgos a AWS Security Hub y CloudWatch Events. Justificación de AWS: NLB en modo TCP proporciona el verdadero pass-through de TLS requerido para mTLS de extremo a extremo y escala a miles de conexiones concurrentes con una huella de CPU pequeña por conexión en el balanceador de carga. Apuntar a los pods mediante targetType=ip elimina un salto adicional y mantiene la capacidad de respuesta del autoescalado. Almacenar y rotar las claves en SSM Parameter Store, protegido por KMS, proporciona una gestión de secretos centralizada y auditable con controles de IAM, y el uso de CloudFormation junto con recursos personalizados de Lambda y EventBridge garantiza que todo el ciclo de vida está codificado, es repetible y observable.
← Rendimiento y Monitoreo de Red · Todos los dominios · Redes de Contenedores y Serverless →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →