Amazon ANS-C01: Conectividad Híbrida: VPN y Direct Connect — 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.
Conceptos básicos
La conectividad híbrida en AWS es la combinación de circuitos de red aprovisionados de forma privada y túneles IP cifrados para extender las redes locales (on-premises) a la nube de AWS. Site-to-Site VPN proporciona túneles IPsec (IKEv1/IKEv2) que terminan en un Virtual Private Gateway (VGW) o en un Transit Gateway; AWS aprovisiona dos túneles independientes por cada conexión VPN para resiliencia y admite BGP para enrutamiento dinámico o rutas estáticas si es necesario. Client VPN es un punto de conexión (endpoint) gestionado basado en OpenVPN que admite autenticación mutua por certificados (ACM Private CA o certificados de cliente cargados) o federación SAML para la identidad del usuario, propagación de rutas a una VPC o Transit Gateway y túnel dividido (split-tunnelling) del lado del cliente para limitar el tráfico que pasa a AWS.
AWS Direct Connect ofrece una conexión física dedicada entre sus instalaciones y AWS. Las conexiones pueden ser dedicadas (aprovisionadas con AWS) u hospedadas (aprovisionadas por un socio); puede agregar múltiples conexiones usando un Link Aggregation Group (LAG) para presentar una única interfaz lógica y aumentar el ancho de banda; Direct Connect admite interfaces virtuales privadas (private VIF) a VPCs, VIF públicas para puntos de conexión públicos de AWS y VIF de tránsito a un Direct Connect Gateway para conectividad multirregional o con Transit Gateway. Para la protección de datos en el enlace físico, MACsec está disponible en ubicaciones compatibles para proporcionar cifrado de tramas de capa 2 entre el borde del cliente y el borde de AWS, y el cifrado en tránsito en la capa 3 sigue siendo responsabilidad de los puntos de conexión IPsec o TLS.
La fiabilidad y el enrutamiento requieren un control explícito de la conmutación por error (failover) y la selección de rutas. Los atributos de BGP (local-preference, AS path prepending) se utilizan para preferir Direct Connect sobre VPN para baja latencia y alto rendimiento, con Site-to-Site VPN o una conexión DX secundaria actuando como respaldo automático. Cuando se requiere TLS de extremo a extremo, o cuando las aplicaciones necesitan preservar la IP de origen del cliente y un número muy grande de conexiones TCP de larga duración (por ejemplo, gRPC sobre TLS en el puerto 443), utilice patrones de paso directo (passthrough) de TCP/TLS como un Network Load Balancer (NLB) o puntos de conexión públicos directos en nodos de EKS con los controles de seguridad adecuados; cuando la terminación en el borde es aceptable, Application Load Balancer (ALB) admite HTTP/2 y gRPC y termina la conexión TLS, insertando cabeceras X-Forwarded-For para que los pods de backend puedan registrar las IP de los clientes.
Servicios y configuración clave
Al crear una Site-to-Site VPN, se utiliza la API de EC2 CreateVpnConnection (aws ec2 create-vpn-connection) y, por lo general, se adjunta la vpn-connection resultante a un virtual private gateway (create-vpn-gateway y attach-vpn-gateway) o a un transit gateway especificando el transit-gateway-id. Configure el dispositivo de gateway de cliente con los parámetros del túnel generados: versión de IKE, algoritmos de cifrado (AES-GCM), hashing (SHA-2), grupo Diffie-Hellman, tiempo de vida (lifetime) y la clave precompartida. Para el enrutamiento dinámico, habilite BGP y configure el ASN y la IP del vecino BGP; para una detección más rápida de la conmutación por error a nivel de enrutador, utilice BFD donde sea compatible entre los dispositivos locales (on-prem) y el borde de AWS.
Los puntos de conexión de Client VPN se crean a través de la API de EC2 CreateClientVpnEndpoint (aws ec2 create-client-vpn-endpoint). Se proporciona un certificado de servidor de ACM, una opción de autenticación (certificado o SAML) y se asocia el punto de conexión con una o más subredes de VPC para crear interfaces de red elásticas. Utilice authorize-client-vpn-ingress para abrir las redes permitidas por cada regla de autorización y create-client-vpn-route para insertar rutas en la VPC. Para grandes poblaciones de usuarios y acceso condicional, integre Client VPN con AWS Directory Service o proveedores de identidad SAML, y escale de forma concurrente asignando rangos de direcciones CIDR suficientes al punto de conexión de Client VPN.
El aprovisionamiento de Direct Connect utiliza las API de Direct Connect como create-connection o, para conexiones de socios, el socio aprovisiona una conexión hospedada y usted utiliza las API allocate-hosted-connection o accept-virtual-interface. Para agregar enlaces físicos, llame a create-lag y luego a create-private-virtual-interface o create-transit-virtual-interface para adjuntar una interfaz virtual a una VPC o a un Direct Connect Gateway. Para MACsec, trabaje con el socio o el portal de pedidos de AWS para solicitar MACsec en la conexión; la configuración incluye el intercambio de claves y la coincidencia de la suite de cifrado en el switch del borde del cliente, y los comandos operativos generalmente se coordinan en el momento del aprovisionamiento. Para arquitecturas multi-VPC, prefiera un Direct Connect Gateway con una VIF de tránsito para conectarse a un Transit Gateway; esto escala mejor que crear muchas VIF privadas y permite un enrutamiento centralizado a través de las tablas de rutas del TGW.
Patrones de diseño y contrapartidas
Elija una arquitectura activo-activo para obtener un alto rendimiento y un bajo tiempo de conmutación por error, ubicando dos conexiones de Direct Connect en diferentes ubicaciones, anunciando prefijos idénticos con BGP y usando LAG para la agregación de enlaces dentro de un sitio. El modo activo-activo con BGP multipath ofrece un rendimiento superior y un verdadero reparto de carga; sin embargo, esto requiere enrutamiento simétrico, un BGP on-premise compatible y un ajuste cuidadoso de AS-path y local-preference. Utilice Site-to-Site VPN como un respaldo activo-pasivo automático porque los túneles IPsec son resilientes y tienen alcance global, pero espere un mayor jitter, un menor rendimiento y tiempos de conmutación por error más largos en comparación con Direct Connect. Donde la conectividad determinista y de baja latencia es obligatoria, es preferible una segunda conexión de DX a pesar de su mayor costo.
Para los requisitos de TLS a nivel de aplicación, las decisiones de diseño dependen de si se permite que el balanceador de carga vea el tráfico descifrado. Si se requiere TLS mutuo de extremo a extremo (mTLS), termine el TLS en el backend utilizando un NLB en modo de paso a través (passthrough) de TCP/TLS y deje que los pods de Kubernetes Ingress gestionen el mTLS; utilice el tipo de destino (target type) ip para EKS para que los pods puedan escalar y el Cluster Autoscaler pueda añadir nodos sin cambiar la configuración del NLB, y habilite el proxy protocol v2 si necesita la IP de origen del cliente original en el pod. Si la terminación de TLS en el ALB es aceptable, utilice un ALB con un listener HTTPS, configure los certificados en ACM, habilite HTTP/2 para el soporte de gRPC y confíe en X-Forwarded-For para las IP de los clientes; el ALB proporciona enrutamiento basado en la ruta (path-based routing) a múltiples grupos de destino para el despacho basado en URL.
Para la conectividad multicuenta y multi-VPC donde se requiere seguridad granular y escala, un patrón de tipo hub-and-spoke con Transit Gateway y un Direct Connect Gateway centralizado proporciona la mejor escala. Conecte cada VPC de unidad de negocio a un Transit Gateway (TGW) y asocie el TGW con un Direct Connect Gateway a través de una VIF de tránsito (transit VIF). Utilice las tablas de rutas del TGW para forzar la segregación y use políticas a nivel de recurso, Security Groups y ACL de red para controles granulares. La contrapartida es la complejidad operativa en la gestión de las tablas de rutas del TGW y la necesidad de diseñar cuidadosamente los límites de las cuentas y de IAM.
Errores comunes y criterios de decisión
Un error frecuente es depender de una única VIF por VPC sin considerar los límites de las VIF y la complejidad operativa a medida que crece el número de VPC; utilice Direct Connect Gateway y VIF de tránsito cuando prevea muchas VPC o múltiples Regiones. Otro error común es suponer que la VPN y Direct Connect se comportan de forma idéntica: los reintercambios de claves de IPsec, las implicaciones del MTU y las diferencias de rendimiento por túnel significan que la VPN es un respaldo fiable, pero no un equivalente en rendimiento. Configurar incorrectamente la terminación TLS y las expectativas de la IP del cliente descendente es otra fuente de errores: elija el modo passthrough del NLB para un verdadero TLS de extremo a extremo con mTLS, o la terminación en el ALB con procesamiento de X‑Forwarded‑For si el borde puede terminar el TLS.
Finalmente, el monitoreo y la visibilidad son esenciales. Habilite las métricas de CloudWatch para Direct Connect (ConnectionBpsEgress/Ingress), los flow logs para la visibilidad de la VPC y utilice las alarmas de CloudWatch para activar la automatización que desvíe el tráfico o notifique a los ingenieros de red. Para la atribución forense del tráfico cuando varias unidades de negocio comparten el ancho de banda en un LAG, correlacione las estadísticas de las VIF y los flow logs de la VPC, y considere controles de ancho de banda por VPC en el borde para evitar problemas de “vecino ruidoso” (noisy neighbor).
Problema práctico: Escenario de caso de uso
Empresa: Meridian Medical Analytics. Desafío: Meridian opera una flota global de dispositivos de imágenes médicas que utilizan gRPC sobre el puerto TCP 443 para cargar flujos cifrados de gran volumen a un backend alojado en un clúster de Amazon EKS en us-east-1. Los dispositivos requieren TLS mutuo (mTLS) para la autenticación bidireccional de clientes y miles de conexiones concurrentes y de larga duración. El clúster de EKS escala automáticamente con Cluster Autoscaler y HPA. Meridian necesita una latencia baja y determinista desde su centro de datos principal y una conmutación por error (failover) automática a la VPN en la nube.
Enfoque:
- Aprovisionar un Network Load Balancer (NLB) delante del servicio de EKS con listeners TCP en el puerto 443 y el tipo de destino (target type) configurado como IP para que los endpoints de los pods puedan ser destinos directamente; configurar el NLB para TLS passthrough (no terminar TLS en el NLB) para que el TLS mutuo se negocie con los pods del backend. Utilice
aws elbv2 create-load-balancerycreate-listenerpara configurar el NLB y los target groups. - Configurar los contenedores de los pods de EKS (Ingress o sidecar) para terminar el TLS mutuo utilizando certificados de servidor y cliente de una CA privada (ACM Private CA para emitir los certificados de servidor; los certificados de cliente se aprovisionan en los dispositivos). Asegurarse de que los pods soporten gRPC sobre HTTP/2 y escalen mediante HPA y Cluster Autoscaler; utilizar un retardo de anulación de registro del target group (deregistration delay) ajustado para conexiones de larga duración.
- Para la conectividad on-premise, aprovisionar una conexión dedicada de Direct Connect (
create-connection) agregada con un LAG si hay múltiples circuitos físicos disponibles, y crear una interfaz virtual privada (create-private-virtual-interface) hacia un Direct Connect Gateway conectado a su Transit Gateway para el enrutamiento hacia la VPC de EKS. Habilitar MACsec durante el aprovisionamiento si el proveedor y la ubicación lo soportan para asegurar el transporte de capa 2. - Implementar una Site-to-Site VPN (
aws ec2 create-vpn-connectionhacia un Transit Gateway) como una ruta de conmutación por error (failover) automática; controlar el failover con atributos de BGP prefiriendo Direct Connect (mayorlocal-preference) y permitiendo que la VPN herede una preferencia menor. Utilizar BFD donde esté soportado para una detección más rápida de fallos en la ruta. Monitorear las métricas de Direct Connect y VPN en CloudWatch y configurar alarmas para activar cambios de ingeniería de tráfico o notificaciones.
Justificación de AWS: El modo TCP passthrough del NLB preserva el TLS mutuo de extremo a extremo, de modo que los certificados de cliente de los dispositivos son validados por los pods del backend, lo que satisface el requisito de que el tráfico no se descifre en el borde. El tipo de destino IP y el NLB soportan la escala para miles de conexiones concurrentes de larga duración, preservando al mismo tiempo la IP del cliente con el protocolo proxy o leyendo la IP del cliente de la sesión TLS si es necesario. Direct Connect proporciona conectividad determinista y de gran ancho de banda a us-east-1 con LAG para capacidad y MACsec para el cifrado del enlace físico; la Site-to-Site VPN proporciona una ruta de respaldo cifrada y accesible globalmente con conmutación por error (failover) mediada por BGP. Este diseño equilibra la seguridad, el rendimiento y la escalabilidad, al tiempo que se alinea con las mejores prácticas de configuración de AWS Direct Connect y VPN.
← Diseño de VPC y Redes Avanzadas · Todos los dominios · Transit Gateway y Topología de Red →
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 →