Introducción
El túnel VPN está UP. El attachment del TGW existe. El BGP está establecido. Y el ping no llega.
Si alguna vez pasaste más de 30 minutos en ese escenario, el problema probablemente no estaba en el enlace — estaba en que estabas buscando en el plano equivocado.
Hay una confusión que aparece constantemente en diseños de conectividad cloud, en reviews de arquitectura y en conversaciones con equipos técnicos muy capaces: mezclar el plano físico con el plano funcional. No es una confusión menor. Es la raíz de decisiones de diseño equivocadas, de troubleshooting que tarda horas en lugar de minutos, y de arquitecturas que funcionan… hasta que no funcionan.
En un post anterior hablé de patrones de VPC: hub-spoke, mesh, multi-account. Hoy vamos más profundo. Vamos a separar conscientemente cómo está construida la red de qué puede hacer esa red — y por qué esa separación cambia la forma en que diseñas.
🔴 Preámbulo
El problema es que ese nivel de imprecisión, tolerable en conversaciones informales, rompe diseños en producción.
Un equipo puede pasar semanas debatiendo si una arquitectura "funciona" porque la mitad del equipo está pensando en topología física y la otra mitad en flujos funcionales. El diagrama muestra lo mismo para los dos grupos. Las conclusiones son distintas.
Ese es el momento en que la distinción entre plano físico y plano funcional deja de ser académica.
🗺️ Los dos planos: definición operativa
Antes de los diagramas, la definición que usamos en la práctica:
Plano físico (o de infraestructura): los componentes que AWS provisiona, las conexiones físicas o lógicas entre ellos, y las restricciones que vienen de la plataforma. Aquí viven: puertos, VLANs, VIFs, attachments, instancias, interfaces de red. Son hechos, no decisiones.
Este diagrama muestra algo que casi ningún curso de certificación explica con suficiente claridad: la VPC no tiene un cable conectado. Lo que tiene son route tables con rutas propagadas desde los componentes de terminación.
Eso cambia completamente cómo razonas sobre transitividad, sobre fallo de conectividad, y sobre dónde aplicar políticas de seguridad.
Plano funcional (qué puede hablar con qué): el comportamiento resultante — es una capa de abstracción superior. Describe flujos de comunicación permitidos, no endpoints físicos. Es la respuesta a "¿puede el servidor A llegar al servidor B?" — no a "¿dónde termina el túnel?".
El problema ocurre cuando tratamos hechos del plano físico como si fueran decisiones del plano funcional, o viceversa.
Y aquí está la trampa: el plano físico no garantiza el plano funcional.
Tener un VGW adjunto a una VPC no significa que el tráfico fluye. Necesitas:
- Route tables con las rutas correctas propagadas
- Security Groups y NACLs que permitan el tráfico
- Políticas IAM si hay servicios en juego
Y si hay inspección: un diseño de routing asimétrico explícito
Este es el punto donde la mayoría de los incidentes de conectividad tienen su causa raíz: el enlace físico está activo, el VGW está adjunto, el TGW tiene el attachment — y sin embargo el tráfico no llega. Porque alguna de las capas funcionales está bloqueando.
🔌 El caso concreto: VPN y Direct Connect
Este es el ejemplo más frecuente donde la confusión aparece.
Cuando alguien provisiona una VPN Site-to-Site en AWS, la descripción natural es "conecté mi datacenter a mi VPC". Funcionalmente eso es correcto. Físicamente, no.
Lo que ocurrió realmente:
AWS creó un Virtual Private Gateway (VGW) — El VGW es un componente de borde administrado que actúa como el agregador de terminación de túneles IPsec para la VPC. No reside dentro del direccionamiento CIDR de tus subnets, sino que se inyecta como un target lógico en el sistema de enrutamiento implícito de la VPC..
El VGW se asoció a tu VPC.
Con route propagation activada, las rutas del lado on-premise aparecen en las route tables de tus subnets.
El tráfico entra al VGW y AWS lo enruta internamente hacia las instancias.
La VPC nunca "ve" la VPN. Ve rutas. Esa distinción importa.
Con Direct Connect hay una capa adicional: el DX termina físicamente en una ubicación de colocation. Desde ahí, un Virtual Interface (VIF) — que puede ser Private, Public o Transit — se asocia al VGW o al TGW. El VIF es el objeto que cruza el plano físico al plano lógico de AWS.
Segundo diagrama — el flujo real de una conexión híbrida:
🚫 Por qué VPN y Peering no son transitivos — y por qué importa entenderlo bien.
Aquí es donde la confusión de planos genera errores de diseño reales.
VPC Peering no es transitivo por diseño del data plane, no por una limitación arbitraria. Cuando una instancia en la VPC A intenta alcanzar la VPC C pasando por la VPC B, el sustrato SDN de AWS (el servicio de mapeo del hipervisor) evalúa el paquete. Como el encapsulado de un Peering es estrictamente punto a punto entre las VPCs involucradas, el data plane no permite re-encapsular o encadenar un segundo salto de peering para proteger la red de bucles (packet looping). El paquete simplemente se descarta en el origen.
Lo mismo con VPN: el VGW termina en esa VPC. No tiene visibilidad ni capacidad de reenvío hacia otra VPC pereada. El tráfico que entra por la VPN existe en el contexto de esa VPC únicamente.
Pero esta restricción vive en el plano físico (data plane de AWS), no en el plano funcional. Y ahí está la clave: si introduces un elemento que opera en capa 3 dentro de la VPC — un appliance, un NVA, una instancia con IP forwarding — ese elemento sí puede recibir el tráfico y reenviarlo activamente. No está rompiendo ninguna regla de AWS; está operando en un plano distinto.
Nota: el Source/Destination Check, si se olvida deshabilitar este atributo en la ENI del appliance, el plano funcional se rompe por completo, porque el hipervisor de AWS descarta cualquier paquete cuyo IP de origen o destino no coincida con la ENI de la instancia. Este es el ejemplo perfecto de interacción entre ambos planos.
Tercer diagrama — transitividad física vs funcional:
Un matiz técnico importante en un diseño de arquitectura.
Un matiz que merece atención especial: en una arquitectura hub-spoke, el TGW resuelve el plano físico — centraliza el routing entre VPCs y hacia on-premise. Pero el TGW no inspecciona tráfico. Para eso necesitas una Security VPC que opere en el plano funcional — con Network Firewall, appliances o Gateway Load Balancer. Son dos capas distintas resolviendo problemas distintos, y confundirlas lleva a diseños donde el tráfico fluye pero nadie lo está viendo.
Porque:
TGW sí crea una topología hub-and-spoke de routing.
Pero no necesariamente concentra servicios funcionales.
Este patrón — cómo separar el plano de conectividad del plano de seguridad en una arquitectura hub-spoke — tiene suficiente profundidad para un artículo propio. Lo cubro en el siguiente post.
🟢 Cómo aplicar esta separación en la práctica
La abstracción no es solo un ejercicio académico. Tiene consecuencias directas en cómo diseñas, debuggeas y explicas arquitecturas.
Cuando diseñas:
Define primero el plano funcional — qué necesita hablar con qué, con qué nivel de inspección, con qué latencia. Luego elige los componentes físicos que materializan esos flujos. Hacerlo al revés (elegir TGW o peering antes de saber qué flujos necesitas) es lo que genera rediseños costosos.
Cuando debuggeas conectividad:
Separa mentalmente los dos planos y recórrelos en orden.
Plano físico primero:
- Si usas VGW: ¿está adjunto a la VPC correcta? ¿Hay route propagation habilitada en las route tables de las subnets relevantes?
- Si usas TGW: ¿el attachment está en estado available? ¿La route table del TGW tiene la ruta hacia el destino? ¿El dominio de routing es el correcto?
- Si usas DX: ¿el VIF está en estado available? ¿El BGP session está established? ¿Se están recibiendo prefijos del lado on-premise?
Plano funcional después:
- ¿La route table de la subnet tiene la ruta con el target correcto (VGW, TGW, o ENI del appliance)?
- ¿El NACL de la subnet permite el tráfico en ambas direcciones? Recuerda: es stateless — inbound y outbound deben estar explícitamente permitidos.
- ¿El Security Group de la instancia destino permite el puerto y protocolo desde el CIDR o SG de origen?
- Si hay un appliance en el path: ¿tiene el Source/Destination Check deshabilitado en su ENI?
La herramienta nativa para recorrer estas capas es VPC Reachability Analyzer — trabaja sobre el plano funcional completo y te indica exactamente en qué capa se rompe el flujo, sin necesidad de enviar tráfico real.
Cuando explicas a un equipo:
Cuando alguien dice "la VPN no llega a la VPC", antes de responder, pregunta: ¿está hablando del enlace físico (¿está el VGW configurado?) o del flujo funcional (¿llega el paquete al destino?)? La respuesta es distinta en cada caso.
🧭 Conclusión
Separar el plano físico del plano funcional no es un ejercicio de semántica.
Es la diferencia entre diagnosticar un incidente de conectividad en 10 minutos o en 3 horas. Entre diseñar una arquitectura que aguante el crecimiento o una que requiera rediseño cuando aparece el primer requisito de inspección de tráfico. Entre tener una conversación técnica productiva con tu equipo o una donde todos hablan de cosas distintas con las mismas palabras.
El plano físico te dice dónde terminan los cables. El plano funcional te dice si el paquete llega. Necesitas ambos — y necesitas saber en cuál estás en cada momento del diseño.
El patrón para aplicar esto:
✔ Diseñar: empieza por el plano funcional (flujos requeridos) → elige los componentes físicos que los materialicen
✔ Debuggear: valida el plano físico primero → luego recorre las capas funcionales en orden
✔ Comunicar: antes de responder cualquier pregunta de conectividad, identifica en qué plano está la pregunta
Happy learning on AWS 🚀
Top comments (0)