En los posts anteriores de esta serie, hemos visto los fundamentos de AWS Cloud WAN, la inspección de tráfico este-oeste mediante Network Function Groups y la acción send-via, y cómo migrar una red basada en Transit Gateway a Cloud WAN. En este último post abordamos uno de los retos más comunes en entornos multi-cuenta: el egress centralizado a internet.
AWS Cloud WAN ofrece una alternativa declarativa a través de la acción send-to de service insertion. Añadiendo un único bloque a la Core Network Policy, Cloud WAN inyecta automáticamente la ruta 0.0.0.0/0 en cada segmento de workload apuntando a un Network Function Group de egress centralizado. Añadir una nueva región o segmento no requiere ningún cambio manual de rutas.
send-to vs send-via#
En el segundo post de esta serie, exploramos los Network Function Groups y la acción send-via para la inspección de tráfico este-oeste. La acción send-to sigue el mismo modelo, pero está diseñada para el tráfico norte-sur — tráfico que sale completamente de la red de Cloud WAN.
La diferencia clave es lo que ocurre después de que el tráfico pasa por el NFG:
send-via | send-to | |
|---|---|---|
| Tipo de tráfico | Este-oeste (VPC ↔ VPC) | Norte-sur (VPC → internet) |
| Vuelve a Cloud WAN | Sí | No |
Parámetro mode | single-hop / dual-hop | No aplica |
| Ruta por defecto inyectada | No | 0.0.0.0/0 en el segmento |
| Caso de uso | Inspección entre segmentos | Egress centralizado |
Con send-to, el tráfico sale del backbone de Cloud WAN a través de la VPC de egress y no regresa. El tráfico de respuesta desde internet entra por el Internet Gateway, pasa por Network Firewall para su inspección y es devuelto a la instancia origen a través de Cloud WAN — pero ese camino de retorno se gestiona mediante rutas estáticas en la VPC de egress, no mediante la política de service insertion.
La configuración de la Core Network Policy es sencilla:
{
"segment-actions": [
{
"action": "send-to",
"segment": "prod",
"via": {
"network-function-groups": ["egress"]
}
}
]
}Cloud WAN inyecta automáticamente una ruta estática 0.0.0.0/0 en el segmento prod apuntando al NFG egress. No es necesaria ninguna configuración adicional de rutas en el segmento.
Arquitectura#
El patrón se compone de tres capas. La idea clave es que las VPCs de workload no tienen Internet Gateway — no pueden acceder a internet directamente. El único punto de salida es Cloud WAN, que redirige todo el tráfico de salida hacia una VPC de egress centralizada por región.
VPCs de workload conectadas al segmento prod. No tienen Internet Gateway — todo el tráfico de salida se enruta a Cloud WAN mediante una ruta por defecto.
Cloud WAN Core Network con un segmento prod y un Network Function Group egress. La política de service insertion send-to redirige todo el tráfico con destino a internet desde prod hacia el NFG egress.
VPCs de egress conectadas al NFG egress, una por región. Cada VPC de egress contiene tres niveles de subnets: una subnet de attachment (donde se conecta Cloud WAN), una subnet de firewall (endpoint de AWS Network Firewall) y una subnet pública (NAT Gateway + Internet Gateway).
Flujo de tráfico#
Vamos a trazar el camino de un paquete desde una instancia de workload hasta internet y de vuelta.
Salida (outbound):
La instancia envía un paquete con destino a internet. La tabla de rutas de la subnet tiene una única ruta por defecto apuntando a Cloud WAN:
0.0.0.0/0 → Core Network.El paquete llega al segmento
prodde Cloud WAN. La políticasend-toha inyectado una ruta estática por defecto apuntando al attachment del NFGegressen la misma región. La tabla de rutas del segmento eneu-west-1es la siguiente:CIDR Destino Tipo 0.0.0.0/0Egress-A (NFG) STATIC 10.0.0.0/24VPC-A PROPAGATED 10.1.0.0/24prod / us-east-1 PROPAGATED El paquete se reenvía a la subnet de attachment de la VPC de egress.
La tabla de rutas de la subnet de attachment envía todo el tráfico al endpoint de Network Firewall:
0.0.0.0/0 → NFW endpoint.Network Firewall inspecciona el paquete y lo reenvía a la tabla de rutas de la subnet de firewall, que dirige el tráfico de salida hacia el NAT Gateway:
0.0.0.0/0 → NAT GW.El NAT Gateway realiza Source NAT (SNAT): reemplaza la IP privada de la instancia por su propia Elastic IP y registra la traducción en su tabla de conexiones. El paquete se reenvía al Internet Gateway, que lo entrega a internet. La IP de origen que ve el exterior es la Elastic IP del NAT Gateway. Cuando llega la respuesta, el NAT Gateway usa su tabla de conexiones para revertir la traducción y reenviar el paquete a la IP privada correcta — Cloud WAN no interviene en este paso.
Retorno (return):
El NAT Gateway recibe la respuesta desde internet a través del Internet Gateway y la reenvía a la subnet de firewall. La tabla de rutas de la subnet pública devuelve el tráfico RFC1918 a través del endpoint de Network Firewall:
10.0.0.0/8 → NFW endpoint.Network Firewall inspecciona el paquete de retorno y lo reenvía a la subnet de firewall. La tabla de rutas de la subnet de firewall enruta el tráfico RFC1918 de vuelta a Cloud WAN:
10.0.0.0/8 → Core Network.La tabla de rutas del NFG tiene los CIDRs de las VPCs de workload propagados desde los attachments del segmento:
CIDR Destino Tipo 10.0.0.0/24VPC-A PROPAGATED 10.1.0.0/24egress / us-east-1 PROPAGATED Cloud WAN reenvía el paquete a la VPC de workload correcta, que lo entrega a la instancia.
Por eso el camino de retorno funciona sin necesidad de una política
send-toinversa: Cloud WAN no la necesita. El NFG tiene los CIDRs de los workloads propagados automáticamente desde los attachments del segmento, por lo que sabe exactamente a dónde reenviar la respuesta. La políticasend-tosolo controla la dirección de salida — del segmento al NFG. El retorno se gestiona mediante propagación normal de rutas.
Nota: Si inspeccionas la tabla de rutas del NFG, verás una ruta apuntando al attachment de egress de la otra región — por ejemplo, 10.1.0.0/24 → egress / us-east-1 en el NFG de eu-west-1. Esta ruta existe porque Cloud WAN propaga todos los CIDRs de workload en cada edge del NFG, independientemente de dónde esté la VPC de egress para ese CIDR. En condiciones normales no transporta tráfico — las instancias en eu-west-1 salen por el NAT Gateway de eu-west-1 y las respuestas vuelven por el mismo camino. Esta ruta solo se usaría si el attachment de egress de eu-west-1 no estuviera disponible, en cuyo caso Cloud WAN reenviaría el tráfico de retorno a través del backbone a la VPC de egress de us-east-1 — exactamente el escenario cross-region descrito en la sección de limitaciones.
Además, la tabla de rutas del NFG solo contiene CIDRs de VPCs de workload — no tiene ruta por defecto. Esto es por diseño: las tablas de rutas de los NFG están completamente gestionadas por Cloud WAN y no pueden modificarse manualmente. La política send-to gestiona el camino de salida; el retorno se apoya en los CIDRs propagados de los workloads.
Demo#
Aquí tienes el código Terraform para desplegar esta arquitectura en tu propia cuenta de AWS:
La demo despliega dos VPCs de workload (una en eu-west-1, otra en us-east-1) conectadas a un segmento prod, y dos VPCs de egress conectadas al NFG egress. Cada VPC de egress tiene un endpoint de AWS Network Firewall configurado con una política allow-all para la demo, y un NAT Gateway para el acceso a internet. Las instancias de workload no tienen Internet Gateway en su VPC y son accesibles exclusivamente a través de AWS Systems Manager Session Manager.
terraform destroy cuando termines.
Para desplegar:
terraform init
terraform applyUna vez desplegado, conéctate a cada instancia a través de SSM Session Manager y verifica que el tráfico de salida sale por el NAT Gateway regional. Los IDs de las instancias y las IPs esperadas de los NAT Gateways están disponibles en los outputs de Terraform:
terraform output# Instancia A (eu-west-1)
aws ssm start-session --target <instance-a-id> --region eu-west-1
sh-5.2$ curl https://checkip.amazonaws.com
108.128.39.93La IP devuelta debe coincidir con el output nat-gateway-a-ip de Terraform — confirmando que la instancia no tiene acceso directo a internet y que todo el tráfico fluye a través de la VPC de egress centralizada.
# Instancia B (us-east-1)
aws ssm start-session --target <instance-b-id> --region us-east-1
sh-5.2$ curl https://checkip.amazonaws.com
3.225.50.74Cada región usa su propio NAT Gateway, como se esperaba. El tráfico nunca cruza regiones para llegar a internet.
Para limpiar los recursos:
terraform destroyConsideraciones y limitaciones#
send-to aplica a todo el segmento. No es posible excluir attachments específicos dentro del mismo segmento de la política de egress. Si necesitas que algunas VPCs tengan acceso directo a internet y otras pasen por el egress centralizado, deben estar en segmentos separados. Además, si tu segmento prod tiene attachments en varias regiones pero el NFG egress solo tiene una VPC en una de ellas, Cloud WAN enrutará el tráfico de las regiones sin cobertura a través del backbone hacia la VPC de egress disponible — aumentando la latencia y los costes de transferencia de datos entre regiones. Despliega siempre una VPC de egress en cada región donde tengas attachments de workload.
La firewall policy de NFW es regional. Las políticas de AWS Network Firewall son recursos regionales. No puedes referenciar una firewall policy de otra región — cada firewall requiere su propia policy en la misma región. Si despliegas VPCs de egress en varias regiones, asegúrate de crear una firewall policy separada en cada una.
send-to no aplica al tráfico hacia on-premises. La ruta por defecto inyectada por send-to cubre el tráfico con destino a internet, pero el tráfico hacia destinos on-premises (a través de VPN o Direct Connect) sigue las rutas aprendidas por BGP de forma normal. Si necesitas inspeccionar el tráfico hacia on-premises, necesitas send-via.
Una VPC de egress por región. Los NFGs son construcciones regionales dentro de Cloud WAN. Cada región donde tengas attachments de workload necesita su propia VPC de egress en el NFG. Intentar usar una única VPC de egress entre regiones enrutaría todo el tráfico a través de una región antes de salir — aumentando significativamente la latencia y los costes de procesamiento del NAT Gateway.
Comparativa de costes con el patrón de egress con Transit Gateway. El patrón de egress centralizado con Transit Gateway requiere mantener rutas estáticas en todas las tablas de rutas del TGW. Con Cloud WAN, el enrutamiento es automático, pero el coste base de la infraestructura es mayor:
| TGW + VPC de egress | Cloud WAN + VPC de egress | |
|---|---|---|
| Coste de la red core | ~$0.05/h por attachment | $0.50/h por edge location |
| Coste de la VPC de egress | NAT GW + NFW | NAT GW + NFW |
| Mantenimiento de rutas | Manual | Automático |
| Consistencia multi-región | Manual | Basada en política |
Para despliegues en una sola región, Transit Gateway es casi siempre más rentable. Para arquitecturas multi-región que ya usan Cloud WAN, el patrón send-to elimina la carga operativa sin coste adicional de infraestructura más allá de las propias VPCs de egress.
Conclusiones#
La acción send-to de service insertion completa el conjunto de herramientas de Cloud WAN para el control del tráfico. Combinada con send-via para la inspección este-oeste (vista en el segundo post de esta serie), proporciona un enfoque completamente declarativo tanto para el egress a internet como para la inspección entre segmentos — con Cloud WAN gestionando automáticamente toda la propagación de rutas.
El beneficio práctico respecto al patrón tradicional con Transit Gateway no es el coste — es la simplicidad operativa. Añadir un nuevo segmento o una nueva región a la red requiere un cambio de política, no una ronda de actualizaciones manuales de tablas de rutas en múltiples Transit Gateways. Para equipos que gestionan entornos complejos multi-cuenta y multi-región, esa diferencia se acumula con el tiempo.
Este post cierra la serie de AWS Cloud WAN. Hemos cubierto el recorrido completo: desde los fundamentos del servicio, pasando por la inspección de seguridad, la migración desde Transit Gateway, y finalmente el egress centralizado. Los cuatro repositorios de demo están disponibles públicamente en Codeberg si quieres explorar cualquiera de ellos.
