Cuando trabajamos en entornos empresariales con AWS, uno de los retos recurrentes es la conectividad con terceros: proveedores, partners, clientes o incluso sistemas legacy internos que operan fuera de tu control. En un mundo ideal, cada parte tendría un espacio de direccionamiento IP único y bien planificado. En la práctica, esto rara vez ocurre.
El problema es conocido: no podemos garantizar que los rangos CIDR de los terceros no solapen con los tuyos. Y cuando hay solapamiento, la conectividad IP directa simplemente no funciona — las tablas de rutas no pueden distinguir entre un destino local y uno remoto si ambos comparten el mismo rango.
En redes on-premises, este problema se resuelve de forma habitual con SNAT y DNAT en un firewall o router frontera. El dispositivo traduce las direcciones de origen y destino, creando un puente entre dos espacios de direccionamiento que de otro modo serían incompatibles. Es un patrón maduro y bien entendido.
¿Cómo llevamos este patrón a AWS? Históricamente, las opciones no han sido especialmente elegantes:
- NAT instances: Instancias EC2 haciendo NAT manualmente. Funcional, pero difícil de escalar, mantener y hacer altamente disponible.
- NLB + PrivateLink: Permite exponer servicios sin solapamiento, pero requiere un Network Load Balancer por cada servicio, no resuelve el caso bidireccional de forma sencilla y escala mal cuando el número de servicios a exponer es elevado — cada servicio necesita su propio NLB y su propio endpoint, multiplicando costes y complejidad operativa.
- Tablas de rutas complejas con CIDRs secundarios: Añadir rangos no solapados a las VPCs y enrutar a través de ellos. Funciona, pero la complejidad operativa crece rápidamente.
Ninguna de estas soluciones ofrece una experiencia verdaderamente cloud-native. Aquí es donde entra Amazon VPC Lattice con su capacidad de VPC Resources: una forma de exponer y consumir recursos entre VPCs que, por diseño, realiza NAT de forma transparente en el plano de datos del servicio.
En este artículo vamos a ver cómo aprovechar VPC Lattice y VPC Resources para construir un patrón de full NAT bidireccional que resuelve el problema de solapamiento de CIDRs con terceros de forma escalable y gestionada.
VPC Lattice y VPC Resources#
Antes de entrar en la arquitectura, repasemos los componentes de VPC Lattice que vamos a utilizar. Si ya estás familiarizado con el servicio, puedes saltar directamente a la sección de arquitectura.
Service Network#
Un Service Network es la agrupación lógica central de VPC Lattice. Actúa como un plano de conectividad compartido al que se asocian servicios, recursos y VPCs. Todo lo que esté asociado al mismo Service Network puede comunicarse entre sí, sujeto a las políticas de autenticación y autorización que se configuren.
Las VPCs se pueden conectar a un Service Network de dos formas:
- VPC Association: asociación directa de la VPC al Service Network. Sencilla, pero solo el tráfico originado dentro de la propia VPC puede alcanzar el Service Network — no es transitiva.
- Service Network Endpoint: un VPC Endpoint de tipo ServiceNetwork que se crea en la VPC consumidora. A diferencia de la VPC Association, permite que el tráfico que llega a la VPC desde fuera — a través de VPC Peering, Transit Gateway, Direct Connect o VPN — pueda alcanzar los recursos del Service Network.
La diferencia es análoga a la de VPC Peering frente a Transit Gateway: con VPC Peering la conectividad no es transitiva, mientras que con Transit Gateway el tráfico de otras redes puede fluir a través de él. En este caso de uso con terceros, donde el tráfico llega desde redes externas, el Service Network Endpoint es la opción necesaria.
Resource Configuration#
Una Resource Configuration define un recurso concreto que queremos hacer accesible a través del Service Network. A diferencia de un VPC Lattice Service (que requiere target groups, listeners y rules), una Resource Configuration permite exponer directamente:
- Una dirección IP (
ip_resource) - Un nombre de dominio (
dns_resource) - Un ARN de un recurso AWS (
arn_resource)
Cada Resource Configuration especifica el protocolo (actualmente solo TCP) y los rangos de puertos en los que el recurso es accesible.
Resource Gateway#
Un Resource Gateway es el punto de entrada al recurso dentro de la VPC donde este reside. Se despliega en las subnets de la VPC y actúa como intermediario: recibe el tráfico que llega desde el Service Network y lo dirige al recurso real.
Es importante entender que el Resource Gateway se crea en la VPC del proveedor del recurso — es decir, en la VPC donde está el servicio que queremos exponer.
Service Network Endpoint#
El Service Network Endpoint es un VPC Endpoint de tipo ServiceNetwork que se crea en la VPC consumidora. A través de este endpoint, los clientes de la VPC pueden acceder a todos los recursos y servicios asociados al Service Network.
La diferencia clave con una VPC Association es que el Service Network Endpoint permite que el tráfico que llega a la VPC desde fuera (vía Transit Gateway, VPN, Direct Connect o VPC Peering) pueda alcanzar el Service Network. Con una VPC Association simple, solo el tráfico originado dentro de la propia VPC tiene acceso.
El NAT implícito#
Y aquí está la clave de todo el patrón: cuando el tráfico fluye a través de VPC Lattice — ya sea mediante un Service o una Resource Configuration — el servicio realiza SNAT de forma transparente. El recurso de destino ve como IP de origen una dirección del propio VPC Lattice, no la IP real del cliente.
Esto significa que no importa si los CIDRs de las VPCs solapan: el tráfico nunca se enruta directamente entre ellas. VPC Lattice actúa como intermediario y traduce las direcciones, exactamente como haría un firewall frontera en una red on-premises.
Arquitectura: el patrón de doble VPC#
Ahora que conocemos los componentes, veamos cómo se combinan para resolver la conectividad con terceros.
La arquitectura se basa en dos VPCs conectadas a través de un VPC Lattice Service Network:
VPC 3P Hub#
La VPC 3P Hub es el punto de aterrizaje de los terceros. Aquí es donde terminan las conexiones de los partners, proveedores o sistemas legacy:
- Conectividad: VPN site-to-site, Transit Gateway Peering, Transit Gateway Edge (para Direct Connect) — según las necesidades de cada tercero.
- CIDR: Este es un punto crítico. El CIDR de esta VPC debe ser compatible con todos los terceros que se conecten a ella. Hay varias estrategias:
- Usar un rango CGNAT (
100.64.0.0/10), que rara vez se usa en redes corporativas. - Usar un rango privado poco común que no solape con los terceros conocidos.
- En casos extremos, usar un rango de IP pública de uso privado (si se dispone de uno).
- Usar un rango CGNAT (
- Tamaño: La VPC puede ser relativamente pequeña. Una /24 distribuida en dos AZs es suficiente para la mayoría de los casos, ya que no aloja cargas de trabajo — solo los componentes de conectividad.
En esta VPC se despliegan:
- Un Service Network Endpoint para consumir servicios internos expuestos a través del Service Network.
- Un Resource Gateway para exponer los recursos de los terceros hacia el Service Network.
VPC 3P Inspection#
La VPC 3P Inspection es el lado interno de la arquitectura. Está conectada a la red corporativa a través del Transit Gateway Central (o Cloud WAN, según la topología de red).
En esta VPC se despliegan:
- Un Resource Gateway para exponer servicios internos hacia el Service Network (para que los terceros puedan consumirlos).
- Un Service Network Endpoint para consumir los recursos de los terceros expuestos a través del Service Network.
VPC Lattice Service Network#
El Service Network actúa como puente entre las dos VPCs. Las Resource Configurations definen qué se expone en cada dirección:
- Recursos del tercero → expuestos desde la VPC 3P Hub mediante su Resource Gateway, consumidos desde la VPC 3P Inspection mediante su Service Network Endpoint.
- Servicios internos → expuestos desde la VPC 3P Inspection mediante su Resource Gateway, consumidos desde la VPC 3P Hub mediante su Service Network Endpoint.
El punto fundamental es que no existe conectividad IP directa entre las dos VPCs. Todo el tráfico pasa por el plano de datos de VPC Lattice, que realiza el SNAT de forma transparente. Esto es lo que permite que ambas VPCs — e incluso los terceros detrás de la VPC Hub — puedan tener CIDRs solapados sin ningún problema.
Flujos de tráfico#
Veamos en detalle cómo fluye el tráfico en cada dirección.
Consumir un servicio del tercero desde la red interna#
Cuando un recurso de la red interna necesita acceder a un servicio expuesto por un tercero, el flujo es el siguiente:
- El tráfico sale del recurso interno y llega a la VPC 3P Inspection a través del Transit Gateway Central.
- En la VPC 3P Inspection, el tráfico se dirige al Service Network Endpoint, que lo envía al VPC Lattice Service Network.
- VPC Lattice identifica la Resource Configuration correspondiente y enruta el tráfico hacia el Resource Gateway de la VPC 3P Hub.
- El Resource Gateway entrega el tráfico al recurso del tercero. La IP de origen que ve el tercero es una IP de VPC Lattice, no la IP real del recurso interno.
- La respuesta sigue el camino inverso.
Exponer un servicio interno al tercero#
Cuando un tercero necesita acceder a un servicio que exponemos nosotros, el flujo se invierte:
- El tráfico del tercero llega a la VPC 3P Hub a través de la VPN, TGW Peering o Direct Connect.
- En la VPC 3P Hub, el tráfico se dirige al Service Network Endpoint, que lo envía al VPC Lattice Service Network.
- VPC Lattice identifica la Resource Configuration correspondiente y enruta el tráfico hacia el Resource Gateway de la VPC 3P Inspection.
- El Resource Gateway entrega el tráfico al servicio interno. La IP de origen que ve el servicio interno es una IP de VPC Lattice, no la IP real del tercero.
- La respuesta sigue el camino inverso.
En ambos casos, VPC Lattice actúa como un proxy transparente con NAT, eliminando cualquier dependencia del espacio de direccionamiento IP de cada parte.
Consideraciones#
- Latencia: VPC Lattice añade un salto adicional en el camino del tráfico. En la mayoría de los casos, la latencia añadida es mínima (del orden de milisegundos), pero es importante tenerlo en cuenta para aplicaciones sensibles a la latencia.
- Throughput: VPC Lattice escala automáticamente, pero conviene revisar las cuotas del servicio para asegurarse de que se ajustan a los requisitos de ancho de banda.
- Health checks: Las Resource Configurations no tienen health checks nativos como los Target Groups de un VPC Lattice Service. Si necesitas detección de fallos, tendrás que implementarla a nivel de aplicación o mediante monitorización externa.
Demo#
Vamos a desplegar una demo que ilustra el patrón completo. Para demostrar que el full NAT funciona, ambas VPCs usarán el mismo CIDR (10.0.0.0/24), simulando un escenario de solapamiento total.
La demo despliega:
- VPC A (
10.0.0.0/23): simula la VPC 3P Hub. Contiene una instancia EC2 con un servidor web (Python HTTP server). - VPC B (
10.0.2.0/23): simula la VPC 3P Inspection (sin firewall). Contiene otra instancia EC2 con un servidor web. - VPC Lattice Service Network: conecta ambas VPCs.
- Resource Configurations: una por cada recurso (la instancia de cada VPC), exponiendo el puerto 80.
- Resource Gateways: uno en cada VPC, para exponer el recurso local.
- Service Network Endpoints: uno en cada VPC, para consumir el recurso remoto. Esto permite que el tráfico transitivo (desde VPN, Direct Connect o Transit Gateway) pueda alcanzar el Service Network.
- VPC Associations: una por cada VPC, necesarias para que los Resource Gateways puedan servir tráfico al Service Network.
El resultado es que la instancia de la VPC A puede acceder al servidor web de la VPC B y viceversa, sin que exista conectividad IP directa entre ambas VPCs. Todo el tráfico pasa por VPC Lattice, que realiza SNAT de forma transparente.
Aquí puedes acceder al código de la demo:
Despliegue#
terraform init
terraform apply
Verificación#
Una vez desplegada la infraestructura, vamos a verificar que la conectividad bidireccional funciona y que el NAT se aplica correctamente.
vpce-xxx-snra-xxx.rcfg-xxx...vpc-lattice-rsc.region.on.aws. Este DNS es públicamente resoluble y apunta a las IPs secundarias de las ENIs del endpoint dentro de tu VPC. Puedes obtenerlo con aws ec2 describe-vpc-endpoint-associations.Conéctate a la Instancia A a través de SSM Session Manager. Esta instancia está en la VPC A (
10.0.0.0/23).Primero, comprobamos la IP local de la instancia:
sh-5.2$ hostname -I 10.0.0.137Ahora, accedemos al servidor web de la Instancia B a través del DNS que el Service Network Endpoint asigna a la Resource Configuration:
sh-5.2$ curl http://vpce-0835440315e44ed1a-snra-06828d84e5edce152.rcfg-02071b3b63c375b09.4232ccc.vpc-lattice-rsc.eu-west-1.on.aws Hello from Instance B (10.0.2.45)La conexión funciona a pesar de que no existe conectividad IP directa entre ambas VPCs.
Repite la prueba en sentido inverso: desde la Instancia B, accede al servidor web de la Instancia A:
sh-5.2$ hostname -I 10.0.2.45 sh-5.2$ curl http://vpce-0739555d6f9d529a9-snra-03a882c66a1033b4b.rcfg-08c054c34657731be.4232ccc.vpc-lattice-rsc.eu-west-1.on.aws Hello from Instance A (10.0.0.137)La conectividad bidireccional funciona correctamente.
Ahora verifiquemos el NAT. Desde la Instancia B, ejecutamos
tcpdumpmientras la Instancia A hace una petición:sh-5.2$ tcpdump -i any -c 5 port 80 -nn 12:59:31.408712 ens5 In IP 10.0.2.166.58602 > 10.0.2.45.80: Flags [S], seq 3388593410, win 62727, length 0 12:59:31.408789 ens5 Out IP 10.0.2.45.80 > 10.0.2.166.58602: Flags [S.], seq 4158802459, ack 3388593411, win 62643, length 0 12:59:31.409942 ens5 In IP 10.0.2.166.58602 > 10.0.2.45.80: Flags [.], ack 1, win 491, length 0 12:59:31.409986 ens5 In IP 10.0.2.166.58602 > 10.0.2.45.80: Flags [P.], seq 1:174, ack 1, win 491, length 173: HTTP: GET / HTTP/1.1 12:59:31.409994 ens5 Out IP 10.0.2.45.80 > 10.0.2.166.58602: Flags [.], ack 174, win 489, length 0La IP de origen que ve la Instancia B es
10.0.2.166— la IP del Resource Gateway en la VPC B, no la IP real de la Instancia A (10.0.0.137). Esto confirma que VPC Lattice realiza SNAT a través del Resource Gateway, ocultando la IP de origen real.
Siéntete libre de modificar el código Terraform proporcionado para experimentar con diferentes configuraciones: cambiar los CIDRs, añadir más Resource Configurations, o probar con recursos de tipo DNS en lugar de IP.
Recuerda destruir los recursos de Terraform cuando hayas terminado de usarlos.
terraform destroy
Consideraciones y limitaciones#
Antes de adoptar este patrón, es importante tener en cuenta las siguientes consideraciones:
Solo TCP#
Como hemos mencionado, VPC Lattice solo soporta tráfico TCP. Si tu caso de uso con terceros requiere UDP (por ejemplo, DNS sobre UDP, SNMP, syslog, o protocolos de streaming), este patrón no es aplicable. En esos casos, las alternativas siguen siendo:
- NAT instances con reglas de iptables/nftables para SNAT/DNAT.
- NLB con PrivateLink para servicios específicos (solo TCP/UDP, pero sin el full NAT — SNAT + DNAT — transparente de Lattice).
Cuotas del servicio#
VPC Lattice tiene cuotas que conviene revisar antes de escalar el patrón:
- Resource Configurations por Service Network.
- Resource Gateways por VPC.
- Service Network Endpoints por VPC.
Consulta las cuotas actualizadas en la documentación oficial.
Dimensionamiento de subnets#
Los Resource Gateways y Service Network Endpoints consumen direcciones IP de las subnets donde se despliegan. Según la documentación de AWS:
“We assign IP addresses to each elastic network interface from its subnet in multiples of /28. The number of IP addresses assigned in each subnet depends on the number of resource configurations and we add additional IPs in /28 blocks as needed.”
En mis pruebas empíricas observé que:
- El Resource Gateway consume 16 IPs (un bloque /28) por subnet, independientemente del número de Resource Configurations que sirva.
- El Service Network Endpoint consume pocas IPs visibles por ENI, pero AWS reserva internamente bloques /28 de espacio de direcciones por cada Resource Configuration asociada al Service Network.
Esto significa que aunque las IPs asignadas visibles sean pocas, AWS necesita espacio contiguo disponible en la subnet para su infraestructura interna. En mis pruebas, una VPC /24 con 2 subnets /25 (123 IPs usables por subnet) falló con InsufficientFreeAddressesInSubnet con solo 2 Resource Configurations.
/23 como mínimo para este patrón con 2 AZs. En mis pruebas, una VPC /24 (subnets /25) falló con InsufficientFreeAddressesInSubnet con solo 2 Resource Configurations y 2 AZs. Con /23 (subnets /24) funcionó correctamente incluso con 3 Resource Configurations. Planifica las subnets con margen, ya que AWS reserva espacio de direcciones internamente en bloques /28 que no son visibles como IPs asignadas en las ENIs.A día de hoy, AWS no documenta la fórmula exacta de cuánto espacio de direcciones consume cada Resource Configuration en el Service Network Endpoint. Si tu caso de uso implica exponer decenas de servicios a través de este patrón, te recomiendo validar el dimensionamiento de subnets en un entorno de pruebas antes de ir a producción.
Comparativa con PrivateLink + NLB#
| PrivateLink + NLB | VPC Lattice SNE | |
|---|---|---|
| NLB necesario | Sí (uno por servicio) | No |
| Endpoints necesarios | 1 por servicio | 1 para todos los servicios |
| NAT transparente | No (solo DNAT) | Sí (full SNAT + DNAT) |
| Transitivo (VPN/TGW) | No | Sí |
| Sizing subnets | 1 IP por endpoint por AZ | Requiere subnets más amplias (ver nota arriba) |
VPC Lattice simplifica la operación y ofrece NAT transparente con transitividad, pero consume más espacio de direcciones IP que PrivateLink clásico. Es un trade-off a considerar en entornos con restricciones de direccionamiento IP.
Costes#
Los costes de VPC Lattice se componen de:
- Coste por hora de los VPC Endpoints (tipo ServiceNetwork) y Resource Gateways.
- Coste por GB de datos procesados.
Para escenarios con alto volumen de tráfico, conviene comparar el coste de VPC Lattice con alternativas como NAT instances (coste de EC2) o NLB + PrivateLink (coste de NLB + PrivateLink por hora y por GB).
Múltiples terceros#
El patrón escala bien para múltiples terceros. Hay dos estrategias:
- Un Service Network por tercero: mayor aislamiento, pero más componentes que gestionar. Cada tercero tendría su propio Service Network, Resource Configurations y Service Network Endpoints.
- Un solo Service Network para todos los terceros: menos componentes, pero requiere auth policies para segmentar el acceso entre terceros.
La elección depende del nivel de aislamiento requerido y del número de terceros.
Wrapping up#
En este artículo he mostrado cómo VPC Lattice y VPC Resources permiten resolver el problema clásico de solapamiento de CIDRs en la conectividad con terceros de una forma cloud-native. El patrón de doble VPC con Resource Gateways y Service Network Endpoints proporciona full NAT bidireccional sin necesidad de gestionar instancias de NAT, tablas de rutas complejas ni dispositivos de red adicionales.
La clave del patrón es que VPC Lattice actúa como intermediario transparente, realizando SNAT en todo el tráfico que pasa por su plano de datos. Esto elimina la dependencia del espacio de direccionamiento IP y permite conectar redes con CIDRs solapados de forma completamente gestionada.
¿Te ha gustado este artículo? ¡Suscríbete al boletín y sé el primero en saber cuándo se publica uno nuevo!
Subscribir