Amazon VPC Lattice: Conectividad entre servicios en capa 7

Ejecutar microservicios en múltiples VPCs implica resolver siempre los mismos problemas: ¿cómo descubre el Servicio A al Servicio B? ¿quién puede llamarlo? ¿y cómo saber qué ha fallado cuando algo va mal? La respuesta habitual pasa por un Network Load Balancer por servicio, un endpoint de PrivateLink por VPC consumidora, un registro en Route 53 por entorno y una regla de security group que nadie recuerda haber añadido. Funciona, pero no escala — y no te dice nada cuando algo se rompe.

Amazon VPC Lattice lo hace de una manera diferente. En lugar de tener que combinar diferentes elementos de red, te da un servicio gestionado que trabaja en capa 7 del modelo OSI. Solo tienes que preocuparte de publicar el servicio una vez, el descubrimiento se hace por nombre DNS — sin IPs de por medio — y, además, y esto es lo más potente, el servicio queda protegido mediante políticas IAM. Ya no es una cuestión de permitir flujos de tráfico concretos, sino que estamos validando que el peticionario tenga realmente permisos para consumir el servicio.

En este post vamos a ver el patrón L7 de principio a fin: publicar un servicio, controlar el acceso con auth policies y firmar peticiones entre servicios con SigV4A.

VPC Lattice: dos modelos de conectividad

#

VPC Lattice resuelve dos problemas relacionados pero distintos, y utiliza construcciones diferentes para cada uno.

El primero es la conectividad entre servicios en capa 7: un microservicio en una VPC necesita llamar a una API HTTP en otra, con autenticación, autorización y descubrimiento basado en DNS. Este es el modelo Services — listeners, reglas, target groups y auth policies.

El segundo es la conectividad TCP entre CIDRs solapados: un workload necesita alcanzar un backend por TCP, pero las dos VPCs comparten el mismo espacio de direcciones y el enrutamiento directo no es posible. Este es el modelo Resource Configurations — resource gateways, resource configurations y SNAT implícito. Cubrimos este patrón en profundidad en VPC Lattice: Full NAT for Third-Party Connectivity.

Este post se centra en el modelo Services. Si tu caso de uso es conectividad TCP con CIDRs solapados, el post sobre Full NAT es el punto de partida adecuado.

Componentes principales

#

Service Network

#

Un Service Network es la unidad organizativa central en VPC Lattice. Piensa en él como un plano de conectividad compartido: los servicios se registran en él, las VPCs se conectan a él, y todo lo asociado al mismo Service Network puede comunicarse entre sí — sujeto a las auth policies que configures.

Las VPCs se conectan a un Service Network de dos maneras, y la diferencia importa:

• VPC Association: la VPC se asocia directamente al Service Network. Solo el tráfico originado dentro de esa VPC puede alcanzar los servicios registrados en él. No es transitivo — el tráfico que llega desde fuera (vía Transit Gateway, VPN o Direct Connect) no puede usar este camino.
• Service Network Endpoint (SNE): un VPC Endpoint de tipo ServiceNetwork creado dentro de la VPC. A diferencia de una VPC Association, permite tráfico transitivo — las peticiones que llegan de otras redes pueden alcanzar el Service Network a través de él.

Para un despliegue en una sola región donde los consumidores viven en la misma VPC, una VPC Association es suficiente. El Service Network Endpoint cobra relevancia cuando el tráfico llega desde fuera de la VPC — a través de un Transit Gateway, VPN o una red cross-region — ya que una VPC Association no es transitiva.

Services, Listeners y Target Groups

#

Un VPC Lattice Service es la unidad de publicación: representa una aplicación o API endpoint que quieres hacer accesible a través del Service Network. Los consumidores lo descubren por nombre DNS y se comunican con él sobre HTTP, HTTPS o gRPC — las IPs subyacentes son irrelevantes.

Un Service se compone de tres bloques:

• Listener: define el protocolo (HTTP o HTTPS) y el puerto en el que el servicio acepta tráfico. Un listener HTTPS requiere un certificado de AWS Certificate Manager (ACM) — lo veremos en la siguiente sección.
• Rules: reglas de enrutamiento evaluadas en cada petición entrante. La regla por defecto reenvía todo el tráfico a un target group, pero puedes añadir reglas basadas en path o en headers para enrutar a distintos backends.
• Target Group: el conjunto de backends al que el servicio reenvía el tráfico. VPC Lattice soporta cuatro tipos de target:
  • IP — direcciones IP individuales
  • Lambda — funciones AWS Lambda
  • ALB — un Application Load Balancer en la misma VPC
  • Instance — instancias EC2 por instance ID

Para workloads en ECS, la integración más limpia es un target de tipo ALB: registra el Application Load Balancer del servicio como target y deja que el ALB gestione el registro de tasks y los health checks. VPC Lattice enruta al ALB, que reenvía a las tasks de ECS activas.

Dominios personalizados y resolución DNS

#

Por defecto, VPC Lattice asigna a cada servicio un nombre de dominio autogenerado con el formato service-name-<random>.vpc-lattice-svcs.<region>.on.aws. Este dominio es resolvible públicamente y siempre apunta al data plane de VPC Lattice — no se necesita DNS privado.

En la mayoría de despliegues reales, sin embargo, querrás un dominio personalizado legible: algo como service-b.internal.example.com que tu código de aplicación pueda referenciar sin hardcodear el nombre generado. VPC Lattice soporta dominios personalizados en listeners HTTPS, con dos requisitos:

1. Un certificado ACM que cubra el dominio personalizado, en la misma región que el servicio.
2. Un registro DNS que resuelva el dominio personalizado al dominio generado por VPC Lattice.

El registro DNS es donde la mayoría de la gente se tropieza por primera vez. VPC Lattice no crea registros DNS por ti — tienes que crearlos en Route 53. El patrón recomendado es una Private Hosted Zone (PHZ) con un registro Alias apuntando al dominio generado del servicio:

service-b.internal.example.com  →  ALIAS  →  service-b-<random>.vpc-lattice-svcs.eu-west-1.on.aws

Y aquí está el paso crítico que es fácil pasar por alto: la Private Hosted Zone debe estar asociada a la VPC consumidora. Sin esa asociación, la resolución DNS dentro de la VPC cae al resolver público, que no puede encontrar el registro privado — y la llamada al servicio falla con un error de DNS que parece idéntico a un problema de conectividad.

Por último, activa los access logs en el Service Network y en el Service desde el primer día. Cada entrada del log incluye el código de respuesta, la decisión de autorización y la identidad del caller — lo que lo convierte en la forma más rápida de distinguir un problema de DNS de un rechazo por auth policy o de un problema de conectividad real. Nos apoyaremos mucho en estos logs en la sección de autenticación.

Arquitectura

#

Vamos a ver el problema y qué solución le damos. El Servicio A vive en una VPC y necesita llamar al Servicio B, que vive, como es de suponer, en otra VPC distinta. Ambas VPCs comparten el mismo CIDR (10.0.0.0/24), algo frecuente en entornos mal gobernados o fruto de adquisiciones y merges de organizaciones distintas. En este caso no podemos hacer un peering entre VPCs ni usar ninguna solución que requiera enrutamiento IP.

El modelo Services de VPC Lattice resuelve esto sin tocar una sola dirección IP. Así encajan las piezas:

Service B se registra en un VPC Lattice Service respaldado por un target group de tipo IP. El servicio expone un listener HTTPS en el puerto 443, usando un certificado ACM que cubre un dominio personalizado (service-b.internal.example.com). El target group apunta a la dirección IP de la instancia de Service B dentro de su VPC.

Service Network se sitúa en el centro, actuando como plano de conectividad. El VPC Lattice Service de Service B se asocia al Service Network, lo que lo hace accesible a cualquier consumidor conectado a él.

La VPC de Service A se conecta al Service Network mediante una VPC Association. Esto da a Service A acceso directo a todo lo registrado en el Service Network — sin peering de VPCs, sin route tables entre las dos VPCs, sin conocimiento del CIDR de la otra VPC.

La resolución DNS la gestiona una Route 53 Private Hosted Zone asociada a la VPC de Service A. Un registro Alias mapea service-b.internal.example.com al dominio autogenerado de VPC Lattice. Cuando Service A llama a service-b.internal.example.com, la PHZ lo resuelve al data plane de VPC Lattice, que actúa de proxy para la petición hacia Service B — realizando SNAT de forma transparente. Service B ve una dirección de VPC Lattice como origen, no la IP real de Service A.

Flujo de tráfico

#

Veamos qué ocurre cuando Service A llama a service-b.internal.example.com:

1. Service A envía una consulta DNS para service-b.internal.example.com. El resolver de Route 53 en la VPC hace match con la Private Hosted Zone.
2. La PHZ devuelve el dominio autogenerado de VPC Lattice, que resuelve a una dirección del data plane.
3. Service A envía la petición HTTPS. Como la VPC tiene una VPC Association con el Service Network, la petición llega a VPC Lattice. En este punto VPC Lattice evalúa la auth policy — si la petición no está permitida, devuelve 403 aquí.
4. VPC Lattice reenvía la petición al Servicio B (proveedor), enrutándola a la IP registrada en el target group. VPC Lattice realiza SNAT — Service B ve una dirección de VPC Lattice como origen, nunca la IP real de Service A.
5. Service B procesa la petición y devuelve la respuesta a través de VPC Lattice.
6. La respuesta llega a Service A.

En ningún momento hay enrutamiento IP directo entre VPC A y VPC B. VPC Lattice actúa como un proxy L7 transparente, y los CIDRs solapados son completamente irrelevantes.

Demo

#

La demo despliega una versión simplificada de la arquitectura descrita arriba:

• VPC A (10.0.0.0/24) — consumidora. Una instancia EC2 que llama a Service B.
• VPC B (10.0.0.0/24) — proveedora. Una instancia EC2 ejecutando un servidor HTTP en Python, expuesta a través de VPC Lattice.
• Service Network con auth type AWS_IAM y una auth policy de dos capas.
• VPC Lattice Service con listener HTTP y un target group de tipo IP apuntando a Instance B.
• SSM VPC Endpoints en ambas VPCs para acceso via Session Manager — sin internet gateway.

Ambas VPCs usan intencionalmente el mismo CIDR para demostrar que VPC Lattice resuelve el solapamiento de forma transparente.

Despliegue

#

git clone https://codeberg.org/scambelo/aws-vpc-lattice-services-demo.git
cd aws-vpc-lattice-services-demo
terraform init
terraform apply

Verificación

#

Conéctate a Instance A usando SSM Session Manager:

aws ssm start-session --target <instance_a_id> --region <aws_region>

Paso 1 — Petición sin firmar (espera 403)

sh-5.2$ curl http://<service_b_domain>

AccessDeniedException: User: anonymous is not authorized to perform: vpc-lattice-svcs:Invoke
[...] because no network-based policy allows the vpc-lattice-svcs:Invoke action

El User: anonymous en el error confirma que la petición llegó a VPC Lattice pero fue rechazada por la auth policy del service network — una petición sin firmar no tiene identidad.

Paso 2 — Petición firmada con SigV4 (espera 200)

Recupera las credenciales de la instancia desde el endpoint de metadatos de EC2 y firma la petición con el flag --aws-sigv4 de curl:

sh-5.2$ TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

sh-5.2$ CREDS=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/vpc-lattice-demo-instance-a)

sh-5.2$ export AWS_ACCESS_KEY_ID=$(echo $CREDS | python3 -c "import sys,json; print(json.load(sys.stdin)['AccessKeyId'])")
sh-5.2$ export AWS_SECRET_ACCESS_KEY=$(echo $CREDS | python3 -c "import sys,json; print(json.load(sys.stdin)['SecretAccessKey'])")
sh-5.2$ export AWS_SESSION_TOKEN=$(echo $CREDS | python3 -c "import sys,json; print(json.load(sys.stdin)['Token'])")

sh-5.2$ curl --aws-sigv4 "aws:amz:<aws_region>:vpc-lattice-svcs" \
     --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
     -H "x-amz-security-token: $AWS_SESSION_TOKEN" \
     -H "x-amz-content-sha256: UNSIGNED-PAYLOAD" \
     http://<service_b_domain>

Hello from Service B (10.0.0.x)

La respuesta confirma conectividad extremo a extremo a través de VPC Lattice. La IP de Service B está en VPC B, que comparte el mismo CIDR 10.0.0.0/24 que VPC A — no existe enrutamiento IP directo entre las dos VPCs.

Limpieza

#

terraform destroy

Auth policies y Zero Trust

#

Tener conectividad está muy bien, pero ahora necesitamos controlar quién puede acceder al servicio. Las auth policies de VPC Lattice proporcionan autorización para acceder al servicio mediante políticas IAM sin tener que tocar el código de la aplicación ni las NACLs.

Cómo funciona la evaluación

#

La autorización en VPC Lattice es un AND lógico entre dos capas de políticas independientes:

1. Política de identidad del caller — la política IAM adjunta al rol o usuario del caller debe permitir vpc-lattice-svcs:Invoke en el servicio destino.
2. Auth policy en el Service Network y/o Service — la política basada en recursos adjunta al Service Network o al Service debe permitir explícitamente el principal del caller.

Ambas deben permitir la petición. Un deny explícito en cualquiera de los dos lados gana, y el comportamiento por defecto cuando auth_type = AWS_IAM es un deny implícito — sin allow explícito no hay acceso.

Esta es la fuente de confusión más habitual: puedes tener una política de identidad IAM perfectamente válida y aun así recibir un 403 si la auth policy no lista tu principal. Comprueba siempre las dos capas cuando depures.

Patrón de dos capas

#

La demo usa dos auth policies que reflejan un patrón real:

Capa 1 — Guardarrail del Service Network (granularidad gruesa, propiedad del equipo de red):

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "vpc-lattice-svcs:Invoke",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "aws:PrincipalType": "Anonymous" },
    "StringEquals": { "aws:PrincipalAccount": "<account-id>" }
  }
}

Esta política permite cualquier principal autenticado de la misma cuenta. La clave es la condición StringNotEquals sobre aws:PrincipalType — una petición sin firmar se trata como Anonymous, por lo que falla esta comprobación y recibe 403. Firmar la petición le da una identidad que satisface ambas condiciones.

Capa 2 — Política del Service (granularidad fina, propiedad del equipo del servicio):

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::<account-id>:role/vpc-lattice-demo-instance-a" },
  "Action": "vpc-lattice-svcs:Invoke",
  "Resource": "*"
}

Solo el rol IAM de Instance A puede invocar Service B. Cualquier otro principal autenticado de la cuenta pasa el guardarrail del service network pero falla aquí.

Los access logs como herramienta principal de depuración

#

Activa los access logs en el Service Network y en el Service desde el primer día. Cada entrada del log muestra el código de respuesta, la decisión de autorización y la identidad del caller — lo que lo convierte en la forma más rápida de distinguir un problema de DNS de un rechazo por auth policy o de un problema de conectividad.

SigV4 y SigV4A: firmando peticiones entre servicios

#

Cuando auth_type = AWS_IAM está habilitado, los callers deben firmar sus peticiones usando AWS Signature Version 4 (SigV4) o SigV4A. La diferencia importa en despliegues multi-región: SigV4 requiere especificar una región concreta, mientras que SigV4A usa region: * — una firma válida desde cualquier región AWS. Para despliegues en una sola región cualquiera de las dos vale; para patrones cross-region SigV4A es la opción correcta.

Dos requisitos se aplican independientemente de la variante de firma:

• El nombre del servicio de firma debe ser vpc-lattice-svcs.
• La petición debe incluir el header x-amz-content-sha256: UNSIGNED-PAYLOAD — VPC Lattice no soporta payload signing.

Los siguientes ejemplos están basados en la documentación oficial de AWS. En todos los casos, las credenciales se resuelven automáticamente desde el entorno de ejecución (instance profile de EC2, rol de ejecución de Lambda, task role de ECS, etc.) — sin claves hardcodeadas. El ejemplo de Python usa SigV4A (agnóstico de región); el ejemplo de Java usa SigV4 con región explícita — ambos son válidos para despliegues en una sola región.

# pip install botocore awscrt requests
from botocore import crt
from botocore.awsrequest import AWSRequest
import botocore.session
import requests

session = botocore.session.Session()
signer = crt.auth.CrtSigV4AsymAuth(
  session.get_credentials(), 'vpc-lattice-svcs', '*'  # '*' = válido desde cualquier región
)

endpoint = 'http://<service-b-domain>'
headers = {
  'Content-Type': 'application/json',
  'x-amz-content-sha256': 'UNSIGNED-PAYLOAD',  # obligatorio — VPC Lattice no soporta payload signing
}

request = AWSRequest(method='GET', url=endpoint, headers=headers)
request.context['payload_signing_enabled'] = False
signer.add_auth(request)

prepped = request.prepare()
response = requests.get(prepped.url, headers=prepped.headers)
print(response.text)

// npm install aws-crt
const https = require('https')
const crt = require('aws-crt')
const { HttpRequest } = require('aws-crt/dist/native/http')

function signRequest(method, endpoint, service, algorithm) {
  const host = new URL(endpoint).host
  const request = new HttpRequest(method, endpoint)
  request.headers.add('host', host)
  request.headers.add('x-amz-content-sha256', 'UNSIGNED-PAYLOAD')

  const config = {
      service: service,
      region: process.env.AWS_REGION || 'us-east-1',
      algorithm: algorithm,
      credentials: crt.auth.AwsCredentialsProvider.newDefault()
  }
  return crt.auth.aws_sign_request(request, config)
}

const algorithm = crt.auth.AwsSigningAlgorithm.SigV4Asymmetric

signRequest('GET', '<service-b-domain>', 'vpc-lattice-svcs', algorithm).then(
  httpResponse => {
      const headers = {}
      for (const header of httpResponse.headers) {
          headers[header[0]] = header[1]
      }
      const options = {
          hostname: new URL('<service-b-domain>').host,
          path: '/',
          method: 'GET',
          headers: headers
      }
      const req = https.request(options, res => {
          res.on('data', d => process.stdout.write(d))
      })
      req.end()
  }
)

// Maven: software.amazon.awssdk:auth + software.amazon.awssdk:apache-client
import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider;
import software.amazon.awssdk.http.auth.aws.signer.AwsV4HttpSigner;
import software.amazon.awssdk.http.apache.ApacheHttpClient;
import software.amazon.awssdk.http.*;

AwsV4HttpSigner signer = AwsV4HttpSigner.create();
var credentials = DefaultCredentialsProvider.create().resolveCredentials();

SdkHttpRequest httpRequest = SdkHttpRequest.builder()
  .uri(URI.create("<service-b-domain>"))
  .method(SdkHttpMethod.GET)
  .build();

SignedRequest signedRequest = signer.sign(r -> r
  .identity(credentials)
  .request(httpRequest)
  .putProperty(AwsV4HttpSigner.SERVICE_SIGNING_NAME, "vpc-lattice-svcs")
  .putProperty(AwsV4HttpSigner.PAYLOAD_SIGNING_ENABLED, false)  // UNSIGNED-PAYLOAD
  .putProperty(AwsV4HttpSigner.REGION_NAME, "eu-west-1"));

try (SdkHttpClient httpClient = ApacheHttpClient.create()) {
  HttpExecuteResponse response = httpClient.prepareRequest(
      HttpExecuteRequest.builder()
          .request(signedRequest.request())
          .build()
  ).call();
  System.out.println(response.httpResponse().statusCode());
}

Consideraciones y limitaciones

#

Solo HTTP, HTTPS y gRPC

#

Los Services de VPC Lattice operan exclusivamente en capa 7. Si tu caso de uso requiere conectividad TCP — conexiones a bases de datos, protocolos binarios propietarios o cualquier tráfico no HTTP — el modelo Services no aplica. Para esos escenarios, Resource Configurations con un Resource Gateway es la herramienta adecuada, y gestiona los CIDRs solapados igual de bien. Cubrimos ese patrón en VPC Lattice: Full NAT for Third-Party Connectivity.

Evaluación de auth policies: el AND lógico

#

La fuente de confusión más habitual con las auth policies de VPC Lattice es entender cuándo deben acordar ambas partes. Para que una petición tenga éxito, dos condiciones independientes deben ser verdaderas:

1. La política de identidad IAM del caller debe permitir vpc-lattice-svcs:Invoke en el servicio destino.
2. La auth policy en el Service Network y/o Service debe permitir explícitamente el principal del caller.

Ambas deben permitir la petición. Un deny explícito en cualquiera de los lados gana. Esto significa que puedes tener una política de identidad IAM perfectamente válida y aun así recibir un 403 si la auth policy no lista tu principal — y viceversa. Cuando depures fallos de autenticación, comprueba siempre los dos lados. Los access logs de VPC Lattice son la forma más rápida de identificar qué capa está rechazando la petición.

VPC Association no es transitiva

#

Una VPC Association solo da acceso al tráfico que se origina dentro de esa VPC. Si el tráfico llega desde fuera — a través de un Transit Gateway, una VPN o Direct Connect — no puede usar una VPC Association para alcanzar el Service Network. Para esos escenarios necesitas un Service Network Endpoint (SNE). El SNE crea ENIs con IPs enrutables dentro de la VPC, permitiendo que el tráfico transitivo alcance el Service Network desde cualquier red conectada.

Dimensionamiento de subnets para VPC Association

#

Cuando una VPC se asocia a un Service Network, VPC Lattice crea Elastic Network Interfaces (ENIs) en las subnets que especifiques — una por Availability Zone. Cada ENI consume direcciones IP de la subnet. Para la mayoría de despliegues esto no es un problema, pero en VPCs con subnets pequeñas (/27 o menor) conviene reservar subnets dedicadas para las asociaciones de VPC Lattice.

Quotas del servicio

#

Algunas quotas a tener en cuenta antes de escalar:

• Services por Service Network: 500 (límite flexible, ampliable)
• VPC Associations por Service Network: 500
• Target Groups por Service: 10 (por regla de listener)

Consulta las quotas actuales en la documentación oficial antes de diseñar para despliegues a gran escala.

Coste vs. NLB + PrivateLink

#

El precio de VPC Lattice se basa en coste por hora de endpoint más coste por GB procesado. Para la mayoría de patrones de comunicación entre servicios, compara favorablemente con la alternativa:

La ventaja operacional de VPC Lattice crece con el número de servicios: un único Service Network con 20 servicios requiere una VPC Association por VPC consumidora, frente a 20 endpoints de PrivateLink. A pequeña escala la diferencia de coste es mínima; a gran escala VPC Lattice es más barato y significativamente más sencillo de operar.

Conclusión

#

La gran fortaleza de VPC Lattice frente a configuraciones más clásicas como PrivateLink + NLB es la capa de autorización. Conectar servicios es relativamente sencillo en AWS y hay distintas formas de hacerlo: PrivateLink, Transit Gateway, Cloud WAN, Service Discovery… pero solo VPC Lattice incorpora una capa de autorización nativa basada en IAM. Olvídate de NLBs, un service endpoint por cada servicio y tener que gestionar security groups para filtrar a los consumidores. Publica el servicio, descúbrelo por DNS y protégelo con IAM.

Hemos visto cómo encajan las piezas: un Service Network como plano de conectividad compartido, una VPC Association para conectar consumidores, un Service con listener HTTPS y target group para publicar backends, una Private Hosted Zone para resolver dominios personalizados, y auth policies con firma SigV4A para aplicar Zero Trust a nivel de servicio. Los CIDRs solapados entre VPC A y VPC B nunca fueron un problema — VPC Lattice realiza SNAT de forma transparente, y el espacio de direcciones IP subyacente deja de ser relevante.

Esta es la base para un despliegue en una sola región. El mismo modelo se extiende de forma natural a topologías transitivas — tráfico que llega vía Transit Gateway, VPN o redes cross-region — sustituyendo la VPC Association por un Service Network Endpoint, que le da a VPC Lattice IPs enrutables que cualquier red conectada puede alcanzar.

Referencias

#

• Documentación de Amazon VPC Lattice
• Auth policies de VPC Lattice
• Firma de peticiones AWS con Signature Version 4A
• Gestión de resolución DNS con Amazon VPC Lattice
• Quotas de VPC Lattice
• VPC Lattice: Full NAT for Third-Party Connectivity — este blog