Por Oscar A. Gaviria González — Cloud Architect Lead, NTT DATA | AWS Golden Jacket

Introducción

El túnel VPN está UP. El attachment del TGW existe. El BGP está establecido. Y el ping no llega.

En un engagement reciente, un equipo pasó casi una tarde completa en ese escenario. La causa raíz no estaba en el enlace: faltaba una ruta estática en la route table de la VPC spoke apuntando al TGW. Estaban 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 una causa frecuente de decisiones de diseño equivocadas, troubleshooting innecesariamente largo y arquitecturas que fallan cuando aparecen nuevos requisitos.

En un post anterior (https://dev.to/oscar_gaviria_2b862594738/disenando-vpcs-en-aws-patrones-reales-hub-spoke-mesh-multi-account-3953) 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

En el día a día usamos un lenguaje deliberadamente impreciso: decimos "conecté mi datacenter a la VPC", "el TGW une las redes", "la VPN llega a producción". Son atajos útiles en una reunión, y nadie los corrige porque todos entienden la intención.

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): dónde termina la conectividad. Los componentes que AWS provisiona, las adyacencias entre ellos y las restricciones que impone la plataforma. Aquí viven: puertos, VLANs, VIFs, attachments, túneles, sesiones BGP e interfaces de red. Su pregunta es binaria: ¿el componente existe, está available y la adyacencia está establecida?

Figura 1. La VPC no tiene un cable conectado. Lo que tiene son route tables. Algunas rutas llegan por propagación (VGW); otras deben declararse estáticamente (TGW, peering). Ese detalle explica una buena parte de los casos de “attachment available, pero no llega”.

Esta distinción 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 de las decisiones de diseño: routing (route tables de subnet y de TGW), filtrado (NACLs, Security Groups) y simetría del tráfico a través de la inspección. 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?".

Figura 2. Dónde termina el plano físico y empieza el funcional: la VPC no conoce el túnel, solo las rutas de su route table, ya sean propagadas o estáticas.

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 o estáticas según el target
  • Security Groups y NACLs que permitan el tráfico
  • VPC endpoint policies y resource policies, si el destino es un servicio AWS vía endpoint
  • Si hay inspección: simetría. La ida y la vuelta deben recorrer el mismo appliance. En hub-spoke con TGW, esto exige habilitar appliance mode en el attachment de la inspection VPC.

Este es un punto frecuente de falla en incidentes de conectividad: el enlace físico está activo, el VGW está adjunto y el attachment del TGW está disponible, pero el tráfico no llega al destino. En estos casos, la causa suele estar en alguna de las capas funcionales, como el routing, los controles de seguridad o la simetría del tráfico.

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í, la Virtual Interface se asocia según su tipo:

  • Private VIF → VGW directamente, o → Direct Connect Gateway.
  • El Direct Connect Gateway puede asociarse con VGW.
  • Transit VIF → Direct Connect Gateway → Transit Gateway.
  • Public VIF → servicios y direcciones públicas de AWS.

Por qué VPC Peering y una VPN terminada en VGW no proporcionan transitividad

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. AWS documenta que una conexión de peering no soporta edge-to-edge routing: si la VPC A tiene peering con B y B con C, A no alcanza C. Cada peering establece una relación estrictamente punto a punto entre las dos VPC involucradas, y el tráfico que requiere un segundo salto se descarta.

Lo mismo con VPN: el VGW termina en esa VPC. No tiene visibilidad ni capacidad de reenvío hacia otra VPC con peering. El tráfico que entra por la VPN existe en el contexto de esa VPC únicamente.

Esa restricción es de la plataforma, por lo tanto vive en el plano físico: ninguna regla funcional la va a resolver. La conectividad transitiva sí se resuelve cambiando de componente, no burlando el peering: el Transit Gateway hace routing transitivo entre attachments por diseño, y dentro de una VPC un appliance de capa 3 con Source/Destination Check deshabilitado puede recibir y reenviar tráfico activamente. Lo que no existe es encadenar dos peerings, ni siquiera poniendo un appliance en medio: AWS no soporta edge-to-edge routing a través de una conexión de peering.

Nota: si olvidas deshabilitar el Source/Destination Check en la ENI del appliance, el plano funcional se rompe por completo, porque 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.

Figura 3. Las cuatro capas que debe atravesar un paquete. El enlace físico activo solo garantiza la capa 1; las demás son decisiones de plano funcional independientes.

Un matiz que merece atención especial: en una arquitectura hub-spoke, el TGW resuelve la adyacencia (plano físico) y centraliza la decisión de routing entre VPCs y hacia on-premise (plano funcional). 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.

Separar el plano de conectividad del plano de seguridad en una arquitectura hub-spoke tiene suficiente profundidad para un artículo propio, y lo desarrollo en AWS Network Firewall vs Gateway Load Balancer: la decisión que nadie explica bien (https://dev.to/oscar_gaviria_2b862594738/aws-network-firewall-vs-gateway-load-balancer-la-decision-que-nadie-explica-bien-3omi).

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 y los túneles están UP?
Si usas TGW: ¿el attachment está en estado available y asociado a la route table de TGW correcta?
Si usas DX: ¿el VIF está en estado available? ¿La sesión BGP está established? ¿Se están recibiendo prefijos del lado on-premise?

Plano funcional después:
¿La route table del TGW asociada al attachment de origen tiene la ruta hacia el destino, y la del destino tiene la ruta de retorno?
¿La route table de la subnet tiene la ruta con el target correcto (VGW, TGW, o ENI del appliance)?
Si el target es VGW, ¿está habilitada la route propagation en las route tables de las subnets relevantes?
¿Las rutas hacia el TGW o el peering existen como rutas estáticas? (No se propagan solas.)
¿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?
Si hay inspección: ¿el attachment de la inspection VPC tiene appliance mode habilitado?

La herramienta nativa para validar estas condiciones de forma estática es VPC Reachability Analyzer: analiza la configuración entre un origen y un destino e identifica el componente que bloquea el path, sin enviar tráfico. Su límite es que no ve el lado on-premise. Para validar con tráfico real, complementa con VPC Flow Logs y Transit Gateway Flow Logs. Para el routing del TGW, aws ec2 search-transit-gateway-routes y aws ec2 get-transit-gateway-route-table-propagations te muestran en segundos qué ruta existe y de dónde viene.

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 puede reducir el tiempo de diagnóstico de un incidente de conectividad, porque permite validar primero dónde termina la conectividad y después revisar qué rutas, controles o componentes permiten o bloquean el flujo. Esta misma separación ayuda a diseñar arquitecturas que puedan incorporar nuevos requisitos, como inspección de tráfico, sin tener que replantear toda la conectividad, y facilita que los equipos técnicos utilicen un lenguaje común al analizar un problema.

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 🚀