Amazon ANS-C01: Diseño de VPC y Redes Avanzadas — 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

Para un servicio central compartido consumido por muchas unidades de negocio a través de varias cuentas, PrivateLink y los servicios de punto de conexión son el patrón más seguro y escalable cuando se requiere control y aislamiento por conexión. Aloje el servicio detrás de un Network Load Balancer en la VPC de servicios compartidos, cree un servicio de punto de conexión de VPC (CreateVpcEndpointServiceConfiguration) y haga que las cuentas consumidoras creen puntos de conexión de interfaz que usted apruebe. Esto evita una malla completa e impide el enrutamiento transitivo, y los grupos de seguridad en los puntos de conexión de interfaz le permiten restringir qué consumidores pueden conectarse. La contrapartida es el costo por cada punto de conexión y una cierta carga administrativa para aceptar y auditar las conexiones de los puntos de conexión.

Transit Gateway destaca cuando se tienen muchas VPC que necesitan conectividad amplia, inspección centralizada y un único lugar para anunciar prefijos on-premise a través de Direct Connect (CreateTransitGatewayRoute, CreateTransitGatewayRouteTable). Utilice la segmentación de tablas de rutas y los controles de propagación para evitar movimientos laterales accidentales; Transit Gateway admite la priorización de rutas y las asociaciones de tablas de rutas para que pueda aislar el tráfico de producción de las redes de menor confianza. La contrapartida es que Transit Gateway centraliza el tráfico y puede incurrir en costos por el tráfico entre VPC que de otro modo sería local; también cambia los dominios de fallo y requiere una planificación cuidadosa de CIDR para evitar la superposición de direcciones.

Para arquitecturas híbridas con reutilización limitada de CIDR, considere combinar Direct Connect con Transit Gateway y Direct Connect Gateway (CreateDirectConnectGateway) para reducir el número de interfaces virtuales. Si necesita aislamiento de ancho de banda por unidad de negocio en el enlace físico compartido, coloque múltiples interfaces virtuales privadas y monitoree las métricas de CloudWatch por VIF (nombres de métricas como AWS/DX: BytesIn, BytesOut) y use alarmas de CloudWatch a nivel de VIF. Para identificar a los consumidores intensivos, habilite VPC Flow Logs (CreateFlowLogs) hacia S3 o CloudWatch Logs y analice con Athena o CloudWatch Logs Insights; para la captura de paquetes por VM, utilice Traffic Mirroring (CreateTrafficMirrorSession) durante ventanas de tiempo cortas.

La adopción de IPv6 y los diseños de pila dual (dual-stack) reducen la dependencia de NAT, disminuyen los costos de rendimiento del NAT Gateway y simplifican el direccionamiento de cara al cliente. Utilice la llamada a la API

undefined

para asignar un prefijo IPv6 proporcionado por Amazon y crear subredes con bloques CIDR IPv6. Tenga en cuenta que algunos servicios y dispositivos de terceros pueden no estar preparados para IPv6; utilice la pila dual en los balanceadores de carga (CreateLoadBalancer con IpAddressType dualstack) para dar soporte tanto a clientes IPv4 como IPv6 mientras los sistemas backend permanecen en IPv4.

Errores comunes y criterios de decisión

Ignorar el consumo de direcciones IP por parte de los pods de Kubernetes es una fuente frecuente de interrupción del servicio. Tenga en cuenta los límites de ENI e IP secundarias por tipo de instancia y utilice configuraciones de VPC CNI como WARM_IP_TARGETS o la delegación de prefijos para mejorar la disponibilidad de IP. No preservar las IP de los clientes en L7 es otro error común: si el TLS debe terminarse en el balanceador de carga, debe asegurarse de que la aplicación lea el encabezado X-Forwarded-For y que los controles de seguridad del ALB restrinjan el acceso directo para que se pueda confiar en los encabezados. Asumir que el VPC peering escalará indefinidamente a menudo conduce a mallas inmanejables; prefiera Transit Gateway para la exposición de servicios de muchos a muchos y PrivateLink para la de uno a muchos, donde se requiera seguridad granular y aislamiento de tráfico.

Las políticas de seguridad deben utilizar grupos de seguridad y ACL de red en combinación con controles a nivel de espacio de nombres (namespace). Para una aplicación estricta del acceso a través de Global Accelerator en lugar de las URL directas del ALB, confíe en una combinación de conjuntos de IP de AWS WAF que se pueblan con los rangos de IP de Global Accelerator (automatizado a través del archivo ip-ranges.json publicado) o diseñe el ALB como interno y póngale en frente un NLB al que apunte Global Accelerator, para luego exponer solo la puerta de entrada de Global Accelerator. Siempre automatice las actualizaciones de cualquier control basado en IP y valide usando DescribePrefixLists y la ingesta regular de ip-ranges.json.

Problema práctico: Escenario de caso de uso

Empresa: Equinox Payments. Desafío: Equinox opera un servicio gRPC respaldado por EKS que necesita mTLS de extremo a extremo para miles de conexiones concurrentes, autoescalado mediante Cluster Autoscaler y HPA, y la preservación de las IP de los clientes para el registro (logging). Enfoque: 1) Desplegar el servicio detrás de un Network Load Balancer configurado con un listener TCP en el puerto 443 a través del AWS Load Balancer Controller, usando la anotación service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" para que las IP de los pods se registren como destinos; 2) terminar el TLS en los pods (no en el NLB) e implementar TLS mutuo en la aplicación (validación de certificados de servidor y cliente), con Kubernetes Secrets para los certificados y sondas de preparación (readiness probes) para impulsar el registro de destinos; 3) usar el tipo de destino ip para preservar las IP de origen del cliente, habilitar el protocolo proxy solo si es necesario para dispositivos intermedios, y depender del registro del lado del pod para capturar la IP del cliente desde la conexión TCP; 4) configurar las comprobaciones de estado como sondas de preparación TCP o compatibles con gRPC, y asegurar que las políticas del Cluster Autoscaler y los tipos de instancia de los nodos tengan suficiente capacidad de ENI e IP; 5) implementar CloudWatch Container Insights y VPC Flow Logs (CreateFlowLogs) para monitorear los recuentos de conexiones y la telemetría a nivel de VPC. Justificación de AWS: El NLB con listeners TCP preserva las sesiones cifradas y las IP de origen mientras escala a millones de conexiones; el tipo de destino ip permite que los pods reciban la IP de origen directamente sin NAT; terminar el mTLS en los pods satisface el cifrado de extremo a extremo y la autenticación bidireccional; el autoescalado funciona porque la preparación del pod afecta directamente el registro de destinos y el NLB escala de forma transparente con la carga de conexiones.

Todos los dominios · Conectividad Híbrida: VPN y Direct Connect →

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

Explorar Amazon →