Compartir un VPC Endpoint entre varias VPC: guía de arquitectura, DNS y enrutamiento

🚀 Conclusión: qué endpoints conviene compartir

Para compartir endpoints de servicios de AWS entre varias VPC, la combinación empresarial más completa es Central Endpoint VPC + Interface VPC Endpoint + Transit Gateway + Route 53 Profiles. Con pocas VPC, Transit Gateway puede sustituirse por VPC Peering.

🎯 Interface Endpoint: es idóneo para centralizar. Los endpoints de SSM, KMS, ECR, STS, Secrets Manager, CloudWatch, SNS o SQS pueden residir en una VPC dedicada y utilizarse de forma privada desde las demás.
🪣 Gateway Endpoint: los endpoints de S3 y DynamoDB no se extienden a otras VPC. Deben crearse en cada VPC de aplicaciones y no tienen un cargo adicional por endpoint.
🌐 Conectividad: para dos o tres VPC suele bastar el peering; a medida que crece el entorno, Transit Gateway simplifica la gestión.
🧭 DNS: en instalaciones nuevas, Route 53 Profiles lleva el DNS privado de los Interface Endpoint centralizados a las VPC de aplicaciones.
🌍 Regiones: en producción conviene desplegar un Endpoint Hub por región de AWS para evitar latencia, transferencia entre regiones y fallos acoplados.

🧩 Qué significa realmente «compartir un endpoint»

El recurso Endpoint no se comparte directamente. El Interface Endpoint permanece en la Shared Endpoint VPC y crea ENI con IP privadas en las subredes elegidas. Las otras VPC enrutan el tráfico hacia esas ENI mediante Transit Gateway o VPC Peering.

Supongamos que VPC-A, VPC-B y VPC-C usan 10.1.0.0/16, 10.2.0.0/16 y 10.3.0.0/16, y que la Endpoint VPC usa 10.100.0.0/16.
Si 20 VPC despliegan 15 Interface Endpoint en dos zonas de disponibilidad, se generan 20 × 15 × 2 = 600 ENI de endpoint.
Al centralizar, los mismos servicios solo se despliegan en dos AZ de la Endpoint VPC, reduciendo recursos fijos, políticas y objetos de mantenimiento.
Los Interface Endpoint se facturan por hora y AZ, además del procesamiento de datos; duplicarlos encarece el entorno conforme aumenta el número de VPC.

🏗️ Arquitectura centralizada recomendada

🗺️ Topología principal

                         AWS SERVICES
                               ▲
                               │
                         PrivateLink
                               │
             ┌──────────────────────────┐
             │ NETWORK ACCOUNT          │
             │ Central Endpoint VPC     │
             │                          │
             │ AZ-A             AZ-C    │
             │ VPCE ENI         VPCE ENI│
             │                          │
             │ SSM / KMS / STS / ECR    │
             │ Secrets / CloudWatch     │
             │ SNS / SQS / EC2 API      │
             │ Route 53 Profile         │
             └────────────┬─────────────┘
                          │
                    Transit Gateway
               ┌──────────┼───────────┐
               │          │           │
             PROD        DEV         TEST
               │          │           │
            VPC-A       VPC-B       VPC-C
               │          │           │
        S3 Gateway   S3 Gateway   S3 Gateway
        DDB Gateway  DDB Gateway  DDB Gateway

🧰 Los cuatro servicios básicos

AWS PrivateLink / Interface VPC Endpoint: ofrece conectividad privada desde las VPC de aplicaciones a servicios regionales de AWS.
AWS Transit Gateway: conecta la Endpoint VPC con muchas VPC y controla la conectividad mediante tablas de rutas de TGW.
Route 53 Profiles: centraliza el DNS privado de los Interface Endpoint y lo asocia a varias VPC.
AWS RAM: comparte Transit Gateway y Route 53 Profiles entre cuentas de AWS.

🏢 Si también hay un centro de datos local

Cuando la red local entra en AWS mediante VPN o Direct Connect, se añade un Route 53 Resolver Inbound Endpoint para que el DNS corporativo reenvíe los nombres de servicios de AWS al Resolver. No conviene consultar directamente la dirección «CIDR + 2» de una VPC.

⚙️ Paso 1: crear la Endpoint VPC y la conectividad

1️⃣ Crear una Endpoint VPC dedicada

Crea Endpoint-VPC en una cuenta de red o de servicios compartidos. El ejemplo usa 10.100.0.0/16.
En producción, utiliza al menos dos AZ: por ejemplo, 10.100.10.0/24 en AZ-a y 10.100.20.0/24 en AZ-c, con una subred de endpoints en cada una.
Cada Interface Endpoint crea una ENI por subred seleccionada. Dos AZ reducen el impacto de una caída de zona.
No coloques los endpoints compartidos en cualquier Application VPC: la propiedad de red, los permisos y la respuesta a incidentes quedarían ligados a una carga concreta.

2️⃣ Incorporar Transit Gateway o VPC Peering

Crea un Transit Gateway central y attachments para Endpoint VPC, VPC-A, VPC-B y VPC-C.
En un entorno multicuenta, comparte el TGW con AWS RAM y deja que las cuentas de aplicaciones creen o acepten sus attachments.
Con solo dos o tres VPC de aplicaciones, conéctalas directamente a Endpoint VPC mediante peering para evitar otra capa y los cargos de TGW.
El peering no es transitivo. Cuando crecen las conexiones y rutas, el modelo hub-and-spoke de TGW resulta más manejable.

🛣️ Paso 2: configurar rutas en ambos sentidos

3️⃣ Tablas de rutas de las VPC de aplicaciones

Cada subred que necesite los endpoints debe dirigir el CIDR de Endpoint VPC hacia TGW. Para VPC-A:

Destination       Target
10.1.0.0/16       local
10.100.0.0/16     tgw-xxxx

VPC-B y VPC-C también envían 10.100.0.0/16 al TGW. Con peering, el destino será la conexión de peering correspondiente.

4️⃣ Rutas de retorno en Endpoint VPC

La tabla asociada a las subredes de endpoints debe devolver el tráfico a cada VPC:

10.100.0.0/16      local
10.1.0.0/16        tgw-xxxx
10.2.0.0/16        tgw-xxxx
10.3.0.0/16        tgw-xxxx

Ambos sentidos son imprescindibles. Si falta el retorno, sale el TCP SYN pero no vuelve el SYN/ACK y la conexión acaba agotando el tiempo de espera.

5️⃣ Tablas de rutas de TGW

Las rutas asociadas a las VPC de aplicaciones deben enviar 10.100.0.0/16 al attachment de Endpoint VPC.
Desde Endpoint VPC, 10.1.0.0/16, 10.2.0.0/16 y 10.3.0.0/16 deben apuntar a sus respectivos attachments.
Puede usarse propagación o rutas estáticas. Para segmentación estricta, varias tablas de TGW permiten controlar explícitamente qué rutas se propagan.

🔌 Paso 3: crear los Interface Endpoint

6️⃣ Crear endpoints de servicio en Endpoint VPC

Ve a VPC → Endpoints → Create endpoint y elige el servicio regional; por ejemplo, com.amazonaws.ap-northeast-1.ssm para Systems Manager en Tokio.
Selecciona Endpoint-VPC y las subredes endpoint-subnet-a y endpoint-subnet-c.
Con Route 53 Profiles, mantén Private DNS habilitado. Los SDK y la CLI siguen usando los nombres estándar, que se resuelven a direcciones privadas de PrivateLink.
Crea solo los endpoints que necesiten las cargas reales. Cada Interface Endpoint añade coste por hora/AZ y procesamiento de datos.

📦 Endpoints que suelen centralizarse

Systems Manager: SSM, SSM Messages y EC2 Messages.
Servicios básicos: EC2 API, KMS, Secrets Manager, STS, Lambda y EventBridge.
Supervisión y mensajería: CloudWatch, CloudWatch Logs, SNS y SQS.
Contenedores y distribución: ECR API, ECR DKR, ECS y CodeArtifact.
Acceso de aplicaciones: servicios compatibles con PrivateLink, como execute-api de API Gateway.

🔐 Paso 4: Security Group y Endpoint Policy

7️⃣ Security Group del endpoint

Crea un grupo dedicado para las ENI de endpoint, como sg-vpce-central.
Permite HTTPS TCP 443 solo desde los CIDR de aplicaciones necesarios: 10.1.0.0/16, 10.2.0.0/16 y 10.3.0.0/16, por ejemplo.
No permitas 0.0.0.0/0 en producción. Limita el origen por organización, entorno, sensibilidad o endpoints dedicados.
Los Security Group son stateful, pero las reglas de salida, NACL y dispositivos intermedios también deben permitir TCP 443 y el tráfico de retorno.

8️⃣ Endpoint Policy

La política determina qué identidades pueden ejecutar qué operaciones a través de ese punto de entrada. El acceso total sirve para probar conectividad, no como configuración permanente.
Un endpoint de KMS puede limitarse a cuentas, roles IAM y claves KMS concretas. En otros servicios, aplica las condiciones y recursos compatibles.
La autorización efectiva combina Endpoint Policy, IAM Policy, SCP, Resource Policy y políticas de bucket o de clave.
Las políticas de mínimo privilegio se complican cuando muchas VPC comparten un endpoint y siguen sujetas a límites de tamaño. Separa endpoints por entorno o frontera de confianza cuando haga falta.

🌐 Paso 5: centralizar DNS con Route 53 Profiles

Que haya conectividad IP no garantiza que la aplicación use el endpoint. Las aplicaciones llaman a nombres como ssm.ap-northeast-1.amazonaws.com; ese nombre debe resolverse a las IP privadas de las ENI del endpoint, no a direcciones públicas del servicio.

Abre Route 53 → Profiles → Create Profile y crea, por ejemplo, central-vpce-profile.
Un Route 53 Profile puede asociar zonas privadas, reglas de Resolver, DNS Firewall, Interface VPC Endpoint y registros de consultas.
En VPC endpoints del perfil, asocia SSM, KMS, STS, ECR, Secrets Manager y demás endpoints centrales. La consola selecciona hasta 10 endpoints existentes de una vez; para más, repite la operación o usa la API.
Asocia VPC-A, VPC-B y VPC-C al perfil. Una VPC solo puede estar asociada a un perfil a la vez, así que planifica antes los recursos DNS existentes.
Después, las consultas de nombres estándar devuelven IP de VPCE centralizadas como 10.100.10.25 y 10.100.20.41.

🏢 Compartir DNS en una Landing Zone multicuenta

🧭 Responsabilidades por cuenta

AWS Organizations

Network Account
├ Endpoint VPC
├ Transit Gateway
└ Route 53 Profile

Production Account
├ VPC-A
└ VPC-B

Development Account
├ VPC-C
└ VPC-D

Security Account
└ VPC-E

Network Account comparte el Route 53 Profile mediante AWS RAM con Production, Development, Security y otras cuentas de la misma región.
Cada cuenta asocia sus VPC al perfil compartido y reutiliza el DNS central sin crear una Private Hosted Zone por servicio y VPC.
El reparto encaja con AWS Organizations, Control Tower y Landing Zone: redes administra VPCE, DNS, TGW y logs; aplicaciones administra cómputo y recursos de negocio.

🔄 Flujo completo de una petición

① Resolución DNS

Cuando una EC2 con 10.1.10.50 en VPC-A llama a Secrets Manager, el SDK consulta secretsmanager.ap-northeast-1.amazonaws.com. Route 53 Resolver y el perfil asociado devuelven las IP privadas del VPCE central.

EC2 → Route 53 Resolver → Route 53 Profile
    → VPCE Private DNS → 10.100.10.25 / 10.100.20.25

② Ruta de red

10.1.10.50
    │ HTTPS 443
    ▼
VPC-A Route Table
    ▼
Transit Gateway
    ▼
Endpoint VPC
    ▼
VPCE ENI 10.100.10.25
    ▼
AWS PrivateLink
    ▼
Secrets Manager

El acceso al servicio permanece privado y no requiere NAT Gateway ni Internet Gateway. La petición debe superar tanto los controles de red como los de identidad.

🪣 Por qué los Gateway Endpoint no se pueden centralizar

Interface Endpoint y Gateway Endpoint son recursos distintos. Los segundos se usan principalmente con S3 y DynamoDB, no utilizan AWS PrivateLink y no extienden su conectividad fuera de la VPC.

Los recursos al otro lado de VPN, VPC Peering, Transit Gateway o Direct Connect no pueden usar un Gateway Endpoint de S3 o DynamoDB situado en Endpoint VPC.
Crea endpoints de S3 y DynamoDB por separado en VPC-A, VPC-B y VPC-C, y asocia sus tablas de rutas locales.
Los Gateway Endpoint no tienen cargo adicional, por lo que centralizarlos tampoco aportaría ahorro fijo.
El patrón empresarial habitual es Interface Endpoint centralizados y Gateway Endpoint distribuidos.

📦 ECR: una dependencia que se suele pasar por alto

Para descargar imágenes de ECR desde ECS, EKS o EC2, normalmente hacen falta ecr.api y ecr.dkr.
Las capas de las imágenes se almacenan en S3, así que la descarga puede fallar aunque existan ambos Interface Endpoint de ECR.
El diseño habitual centraliza ECR API y ECR DKR, y crea un S3 Gateway Endpoint en cada Application VPC.
Al diagnosticar, revisa DNS, ambos endpoints de ECR, el endpoint de S3, rutas, grupos de seguridad y permisos IAM de la tarea o instancia.

🕰️ Diseño clásico: Private Hosted Zone

Una alternativa que sigue funcionando

Desactiva Private DNS en el Interface Endpoint central.
Crea manualmente una zona privada con el nombre del servicio, como ssm.ap-northeast-1.amazonaws.com.
Crea un registro A Alias hacia el VPCE y asocia la PHZ a Endpoint VPC y a todas las VPC de aplicaciones.

Por qué ya no es la primera opción

Con 30 endpoints y 100 VPC, las asociaciones manuales forman una enorme matriz de gestión.
Route 53 Profiles asocia los VPCE centrales una vez y aplica la configuración a muchas VPC, reduciendo zonas, registros y asociaciones repetidas.
La alternativa clásica sigue siendo válida para sistemas existentes o requisitos DNS especiales; en proyectos nuevos se evalúan primero los Profiles.

🌍 Entornos con varias regiones

Es posible usar Inter-Region TGW Peering o VPC Peering entre regiones para que una VPC de Singapur acceda a Endpoint VPC en Tokio.
El trayecto añade transferencia entre regiones y latencia; además, la mayoría de los endpoints de servicios de AWS son regionales.
En producción es más robusto crear un Endpoint Hub y un Route 53 Profile en cada región.
La separación reduce el radio de impacto y aclara DNS, rutas, dependencias de servicios y límites normativos.

💶 Modelo de costes: centralizar no siempre es más barato

Partidas de una arquitectura centralizada

Horas de los attachments de Transit Gateway.
Procesamiento de datos de Transit Gateway.
Horas de Interface Endpoint por cada AZ desplegada.
Procesamiento de PrivateLink y posibles transferencias entre AZ o regiones.

Cuándo suele ahorrar

La centralización resulta más atractiva con muchas VPC, muchos endpoints y poco tráfico por VPC. Con 50 VPC, 20 servicios y dos AZ, el modelo distribuido puede generar 2.000 ENI, frente a unas 40 centralizadas, aunque siempre hay que sumar TGW.

El tráfico elevado requiere una cuenta aparte

Si una VPC mueve varios TB de S3 al día, enviarlos por TGW a un Interface Endpoint de S3 suele ser poco rentable; el Gateway Endpoint local es mejor. Como las tarifas cambian por región y fecha, prepara el presupuesto con los precios regionales vigentes y compara todos los importes en euros.

✅ Ventajas principales

📉 Menos recursos: se evita duplicar las mismas ENI en muchas VPC.
🧰 Operación centralizada: políticas, grupos, etiquetas, DNS privado y logs se administran en Network Account.
🔐 Base de seguridad uniforme: el equipo central gestiona VPCE, DNS, TGW y acceso; los equipos de aplicaciones se centran en EC2, ECS, EKS, Lambda y RDS.
🌐 Menos dependencia de NAT: los servicios compatibles con PrivateLink ya no necesitan NAT Gateway ni API pública.
🏢 Buen encaje multicuenta: funciona bien con AWS Organizations, Control Tower, RAM y Landing Zone.

⚠️ Inconvenientes principales

💥 Mayor radio de impacto: un fallo del endpoint central, DNS o una política puede afectar a muchas VPC.
📜 Políticas más complejas: varias cuentas, roles y recursos amplían la política de mínimo privilegio y acercan sus límites de tamaño.
🧭 Cadena DNS más larga: aparecen Profiles, TGW, VPCE central y asociaciones entre cuentas.
💸 Coste adicional de TGW: el procesamiento puede ser importante con mucho tráfico Application VPC → TGW → VPCE.
🔒 Menor aislamiento: se comparten capacidad, grupos y políticas, por lo que hacen falta más supervisión, control de cambios y segmentación.

📊 Endpoint central frente a endpoint por VPC

Categoría	Central Endpoint	Endpoint por VPC
Cantidad y coste fijo	Menos recursos y mejor escalado al crecer las VPC	Crece con las VPC y los servicios
Coste de red	Incluye attachments y procesamiento de TGW	El VPCE local no necesita TGW
DNS y operación	Más componentes, pero gobierno central	Simple por VPC, pero gestión dispersa
Aislamiento e impacto	Controles compartidos y mayor impacto	Mayor aislamiento; el fallo suele quedar en una VPC
Endpoint Policy	Central pero compleja entre cuentas	Límites claros y políticas más sencillas
Entorno idóneo	Landing Zone grande y multicuenta	Entorno pequeño o carga aislada y de gran volumen

🧭 Elección según el número de VPC

1–3 VPC

Los endpoints en cada VPC ofrecen el diseño más sencillo y mejor aislamiento.
Para reducir su número, usa peering, Route 53 Profile y una pequeña Central Endpoint VPC.
No suele compensar añadir TGW solo para compartir unos pocos endpoints.

5–20 VPC

Evalúa seriamente Endpoint VPC + TGW + Route 53 Profiles.
Compara costes fijos duplicados, costes de TGW y tráfico real.
Mantén endpoints dedicados para cargas de gran volumen o fuerte aislamiento, creando un modelo híbrido.

De 20 a cientos de VPC

Network Account suele concentrar TGW o Cloud WAN, Endpoint VPC, Profiles, Resolver, Network Firewall y DNS Firewall.
Administra endpoints y asociaciones con infraestructura como código, etiquetas, logs, monitorización y control de cambios.
Separa por región, entorno y frontera de confianza para no depender de una única plataforma central.

🏁 Patrón de despliegue recomendado

🔌 Interface Endpoint: centralizados en una Endpoint VPC dedicada.
🪣 Gateway Endpoint de S3 y DynamoDB: uno en cada VPC de aplicaciones.
🛣️ Red: peering con pocas VPC y Transit Gateway en entornos medianos y grandes.
🌐 DNS: Route 53 Profiles en instalaciones nuevas; PHZ clásico solo donde sea necesario.
🏢 Varias cuentas: gestión en Network Account y uso compartido mediante AWS RAM.
🌍 Varias regiones: un Endpoint Hub por región.
🔐 Seguridad: combina Security Group, Endpoint Policy, IAM, SCP y Resource Policy.
💶 Costes: compara el coste total en euros con el número real de servicios, VPC, AZ y volumen de datos.

🛠️ Orden de diagnóstico si falla el acceso

DNS: ejecuta dig ssm.ap-northeast-1.amazonaws.com y comprueba que devuelve una IP privada como 10.100.x.x, no una pública.
Tabla de la Spoke VPC: confirma que el CIDR de Endpoint VPC apunta a TGW o peering.
Tabla de TGW: revisa la ida y el retorno entre la VPC de aplicaciones y Endpoint VPC.
Tabla de Endpoint VPC: comprueba el retorno desde las subredes de endpoints.
Security Group de VPCE: permite TCP 443 desde los CIDR de aplicaciones.
NACL: revisa entrada, salida y puertos efímeros.
Endpoint Policy: confirma que principal, acción y recurso no están denegados.
IAM / Resource Policy / SCP: por último, revisa identidad, recursos y controles de organización.

Seguir el orden «resolución, rutas, controles de red y autorización» permite localizar el fallo mucho más rápido que saltar entre páginas de la consola.

Compartir un VPC Endpoint entre varias VPC: guía completa de arquitectura e implementación