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 (SNE): 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.
Un detalle importante: los Service Network Endpoints funcionan de forma independiente, sin necesidad de que la VPC tenga una VPC Association al mismo Service Network. Esto es clave para el modelo de aislamiento con múltiples Service Networks que veremos más adelante.
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 con Service Networks direccionales#
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 dos VPC Lattice Service Networks — una por cada sentido del tráfico:
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 conectado a la SN Outbound para consumir servicios internos.
- Un Resource Gateway que expone los recursos de los terceros. Las Resource Configurations asociadas a este gateway se publican en la SN Inbound.
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 que expone servicios internos. Las Resource Configurations asociadas a este gateway se publican en la SN Outbound.
- Un Service Network Endpoint conectado a la SN Inbound para consumir los recursos de los terceros.
VPC Lattice Service Networks#
A diferencia de un modelo con una única Service Network, esta arquitectura utiliza dos Service Networks direccionales:
- SN Inbound (tercero → interno): contiene las Resource Configurations que exponen los recursos de los terceros. El Resource Gateway de la VPC 3P Hub publica aquí, y el SNE de la VPC 3P Inspection consume.
- SN Outbound (interno → tercero): contiene las Resource Configurations que exponen los servicios internos. El Resource Gateway de la VPC 3P Inspection publica aquí, y el SNE de la VPC 3P Hub consume.
La separación en dos Service Networks es deliberada: permite aislar completamente los flujos de tráfico y, como veremos en la sección de múltiples terceros, es la base para escalar el patrón a N terceros con aislamiento bidireccional.
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 de la SN Inbound, que lo envía al VPC Lattice Service Network.
- VPC Lattice identifica la Resource Configuration correspondiente en la SN Inbound 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 de la SN Outbound, que lo envía al VPC Lattice Service Network.
- VPC Lattice identifica la Resource Configuration correspondiente en la SN Outbound 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.
La demo despliega:
- VPC A (
10.0.0.0/24): simula la VPC 3P Hub. Contiene una instancia EC2 con un servidor web (Python HTTP server). - VPC B (
10.0.1.0/24): simula la VPC 3P Inspection (sin firewall). Contiene otra instancia EC2 con un servidor web. - Dos VPC Lattice Service Networks: SN Inbound (VPC A expone → VPC B consume) y SN Outbound (VPC B expone → VPC A consume).
- Resource Configurations: una por cada recurso (la instancia de cada VPC), exponiendo el puerto 80. Cada una asociada a la Service Network del lado consumidor.
- Resource Gateways: uno en cada VPC, para exponer el recurso local.
- Service Network Endpoints: uno en cada VPC, para consumir el recurso remoto a través de la Service Network correspondiente.
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/24).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 por defecto 16 IPs (un bloque /28) por subnet. Sin embargo, este valor es configurable mediante el parámetro
ipv4_addresses_per_enidel Resource Gateway. Reducirlo a1permite operar con subnets más pequeñas. No escala con el número de Resource Configurations. - El Service Network Endpoint (sin VPC Association) crea 2 ENIs por AZ, cada una con 1 IP. Este consumo es fijo e independiente del número de Resource Configurations y del valor de
ipv4_addresses_per_enidel Resource Gateway.
La siguiente tabla resume el consumo de IPs por AZ observado con el modelo 2N (sin VPC Associations):
| Componente | ENIs por AZ | IPs por ENI | Total IPs por AZ | Escala con nº de RCs |
|---|---|---|---|---|
| Resource Gateway | 1 | configurable (default 16, mínimo 1) | 1–16 | No |
| SNE (sin VPC Association) | 2 | 1 | 2 | No |
| Total Lattice | 3–18 |
/24 o menores), configura ipv4_addresses_per_eni en el Resource Gateway con un valor bajo (por ejemplo, 1). El valor por defecto de 16 consume un bloque /28 completo por subnet, lo que puede agotar rápidamente el espacio de direcciones disponible.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 y aislamiento#
Cuando hay varios terceros, surge la necesidad de aislarlos entre sí. Dentro de una misma Service Network, todas las Resource Configurations son visibles desde todos los Service Network Endpoints conectados a ella. Además, las auth policies del Service Network no aplican a Resource Configurations. Esto significa que no es posible segmentar el acceso a nivel de recurso dentro de una misma Service Network.
La solución es usar Service Networks separadas por tercero — concretamente, 2 Service Networks por tercero (una por sentido), siguiendo el mismo modelo direccional de la arquitectura base:
3P-A: SN-Inbound-A (3P-A expone → red interna consume)
SN-Outbound-A (red interna expone → 3P-A consume)
3P-B: SN-Inbound-B (3P-B expone → red interna consume)
SN-Outbound-B (red interna expone → 3P-B consume)
Cada tercero solo tiene visibilidad de sus propias Service Networks. El tercero A no puede ver las Resource Configurations del tercero B porque están en Service Networks completamente separadas.
La VPC interna crea Service Network Endpoints a cada SN Inbound para consumir los recursos de cada tercero, y publica sus servicios en cada SN Outbound mediante Resource Configurations. Cada VPC de tercero solo tiene un SNE a su SN Outbound y un Resource Gateway publicando en su SN Inbound.
Este modelo funciona porque los Service Network Endpoints no requieren VPC Association. Una VPC puede crear SNEs a múltiples Service Networks sin restricciones, lo que permite a la VPC interna conectarse a tantos terceros como sea necesario.
Para N terceros, el modelo requiere 2N Service Networks, N SNEs en la VPC interna (uno por SN Inbound), y las Resource Configurations de servicios internos replicadas en cada SN Outbound. El coste operativo crece linealmente, pero el aislamiento es completo.
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 Service Networks direccionales, 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. Y gracias a que los Service Network Endpoints funcionan sin VPC Associations, el modelo escala a múltiples terceros con aislamiento completo usando 2 Service Networks por tercero.
¿Te ha gustado este artículo? ¡Suscríbete al boletín y sé el primero en saber cuándo se publica uno nuevo!
Subscribir