Sharing One VPC Endpoint Across Multiple VPCs: A Complete Architecture and Implementation Guide

🗺️ Core Topology

                         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

🧰 Four Core Services

• AWS PrivateLink / interface VPC endpoints: Provide private connectivity from application VPCs to Regional AWS services.
• AWS Transit Gateway: Connects the Endpoint VPC to multiple application VPCs, while TGW route tables control reachability.
• Route 53 Profiles: Centrally manage interface endpoint private DNS and associate that DNS configuration with multiple VPCs.
• AWS RAM: Shares Transit Gateway and Route 53 Profiles across AWS accounts.

🏢 When an On-Premises Data Center Is Involved

When the on-premises network reaches AWS through VPN or Direct Connect, add a Route 53 Resolver inbound endpoint so on-premises DNS can forward AWS service names to Route 53 Resolver. Do not send queries directly to a VPC's “CIDR + 2” resolver address.

1️⃣ Create a Dedicated Endpoint VPC

• Create Endpoint-VPC in a Network or Shared Services account. This example uses 10.100.0.0/16.
• Use at least two AZs in production, such as 10.100.10.0/24 in AZ-a and 10.100.20.0/24 in AZ-c, with one Endpoint Subnet in each.
• An interface endpoint creates an ENI in every selected Endpoint Subnet. A two-AZ deployment reduces exposure to an AZ-level outage.
• Avoid placing shared endpoints in an arbitrary application VPC, where network ownership, access boundaries, and incident response become tied to one workload.

2️⃣ Add Transit Gateway or VPC Peering

• Create a central Transit Gateway and VPC attachments for the Endpoint VPC, VPC-A, VPC-B, and VPC-C.
• In a multi-account environment, share the TGW through AWS RAM, then let application accounts create or accept attachments.
• For only two or three application VPCs, peer each one directly with the Endpoint VPC to avoid another network layer and TGW charges.
• Peering is not transitive. As the environment grows, connection and route-table sprawl make the TGW hub-and-spoke model more practical.

3️⃣ Application VPC Route Tables

Every application subnet that needs an endpoint must route the Endpoint VPC CIDR to the TGW. For VPC-A:

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

VPC-B and VPC-C also send 10.100.0.0/16 to the TGW. With peering, use the appropriate peering connection as the target.

4️⃣ Return Routes in the Endpoint VPC

The route table associated with the Endpoint Subnets must return traffic to every application 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

Both directions are required. A forward route without a return route commonly produces a TCP SYN with no SYN/ACK and eventually a connection timeout.

5️⃣ TGW Route Tables

• Routes associated with application VPCs must send 10.100.0.0/16 to the Endpoint VPC attachment.
• On the Endpoint VPC side, routes for 10.1.0.0/16, 10.2.0.0/16, and 10.3.0.0/16 must point to their respective VPC attachments.
• Use route propagation or static routes. Environments with strict segmentation often use multiple TGW route tables to control propagation explicitly.

6️⃣ Create Service Endpoints in the Endpoint VPC

• Open VPC → Endpoints → Create endpoint and choose the Regional service, such as com.amazonaws.ap-northeast-1.ssm for Systems Manager in Tokyo.
• Select Endpoint-VPC and the two subnets endpoint-subnet-a and endpoint-subnet-c.
• With the Route 53 Profiles design, keep Private DNS enabled. AWS SDKs and the CLI can continue using standard service names while resolving them to private PrivateLink addresses.
• Create only the endpoints required by actual workloads. Every interface endpoint adds AZ-hour and data-processing charges.

📦 Common Centralized Endpoints

• Systems Manager: SSM, SSM Messages, and EC2 Messages.
• Core services: EC2 API, KMS, Secrets Manager, STS, Lambda, and EventBridge.
• Monitoring and messaging: CloudWatch, CloudWatch Logs, SNS, and SQS.
• Containers and delivery: ECR API, ECR DKR, ECS, and CodeArtifact.
• Application access: supported PrivateLink services such as API Gateway execute-api.

7️⃣ Endpoint Security Group

• Create a dedicated security group for the endpoint ENIs, such as sg-vpce-central.
• Allow inbound HTTPS over TCP 443 only from application CIDRs that need access, such as 10.1.0.0/16, 10.2.0.0/16, and 10.3.0.0/16.
• Do not allow 0.0.0.0/0 in production. Narrow the source by organization, environment, sensitivity, or dedicated endpoint where appropriate.
• Security groups are stateful, but instance egress rules, NACLs, and intermediate appliances must still permit TCP 443 and return traffic.

8️⃣ Endpoint Policy

• The endpoint policy controls which principals can perform which service actions through that entry point. A full-access policy is useful for connectivity testing, not as a long-term production default.
• A KMS endpoint can be limited to approved accounts, IAM roles, and KMS keys. Apply supported condition keys and resource constraints to other services as well.
• Effective authorization is the combination of endpoint policies, IAM policies, SCPs, resource policies, and policies such as bucket or key policies.
• Least-privilege policies become more complex as more VPCs share an endpoint, and policy document size limits still apply. Split endpoints by environment or trust boundary when necessary.

🧭 Account Responsibilities

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

• The Network Account shares the Route 53 Profile through AWS RAM with Production, Development, Security, and other accounts in the same Region.
• Each account associates its VPCs with the shared profile, reusing centralized endpoint DNS without creating a private hosted zone for every service and VPC.
• This division fits AWS Organizations, Control Tower, and Landing Zone operating models: the network team owns VPCEs, DNS, TGW, and logging, while application teams own compute and workload resources.

① DNS Resolution

When an EC2 instance at 10.1.10.50 in VPC-A calls Secrets Manager, the SDK looks up secretsmanager.ap-northeast-1.amazonaws.com. Route 53 Resolver and the associated profile return the private addresses of the centralized VPCE.

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

② Network Path

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

This path to the AWS service stays private and does not require a NAT Gateway or Internet Gateway. The request must still pass both network controls and identity authorization.

• When ECS, EKS, or EC2 pulls an image from ECR, ecr.api alone is usually not enough; ecr.dkr is also required.
• Container image layers are backed by S3, so pulls may still fail even when both ECR interface endpoints exist.
• A typical design centralizes ECR API and ECR DKR interface endpoints while creating an S3 gateway endpoint in every application VPC.
• When troubleshooting image pulls, check DNS, both ECR endpoints, the S3 gateway endpoint, routing, security groups, and the task or instance IAM permissions.

A Traditional Design That Still Works

• Disable Private DNS on the centralized interface endpoint.
• Manually create a Route 53 private hosted zone matching the AWS service name, such as ssm.ap-northeast-1.amazonaws.com.
• Create an A alias record pointing to the VPCE, then associate the PHZ with the Endpoint VPC and every application VPC.

Why It Is No Longer the First Choice for New Environments

• With 30 endpoints and 100 VPCs, manual PHZ associations turn into a very large management matrix.
• Route 53 Profiles can associate all centralized VPCEs once and then apply the configuration to many VPCs, reducing repeated hosted zones, records, and associations.
• The legacy approach remains useful for existing systems or specialized DNS requirements; evaluate Route 53 Profiles first for greenfield deployments.

Centralized Cost Components

• Transit Gateway attachment hourly charges.
• Transit Gateway data-processing charges.
• Interface endpoint hourly charges for each deployed AZ.
• PrivateLink data processing, plus possible cross-AZ or cross-Region data transfer charges.

When Centralization Is More Likely to Save Money

The strongest business case appears when there are many VPCs, many required endpoints, and relatively low traffic per VPC. With 50 VPCs, 20 services, and two AZs, a distributed design can create 2,000 endpoint ENIs, versus roughly 40 in a centralized design. TGW costs must still be included.

High-Traffic Workloads Need Their Own Calculation

If one VPC moves several TB of S3 data every day, sending it through TGW to an S3 interface endpoint is often a poor value. A local S3 gateway endpoint is usually the better design. AWS prices vary by Region and over time, so build the budget from current Regional pricing and compare everything in U.S. dollars.

1–3 VPCs

• Start with endpoints in each VPC for the simplest architecture and strongest isolation.
• If reducing endpoint count matters, use peering, a Route 53 Profile, and a small Central Endpoint VPC.
• Introducing Transit Gateway solely to share a few endpoints is usually unnecessary.

5–20 VPCs

• Seriously evaluate Endpoint VPC + TGW + Route 53 Profiles.
• Compare duplicated endpoint fixed charges, TGW charges, and real traffic volume in the cost model.
• Keep dedicated endpoints for high-volume or strongly isolated workloads, creating a hybrid design.

20 to Hundreds of VPCs

• A Network Account typically centralizes TGW or Cloud WAN, Endpoint VPCs, Route 53 Profiles, Resolver, Network Firewall, and DNS Firewall.
• Manage endpoints and account associations with infrastructure as code, standard tags, logs, monitoring, and formal change controls.
• Split resources by Region, environment, and trust boundary so every workload does not depend on a single central stack.

1. DNS: Run dig ssm.ap-northeast-1.amazonaws.com. It should return a private VPCE address such as 10.100.x.x, not a public IP.
2. Spoke VPC route table: Confirm that the Endpoint VPC CIDR points to TGW or peering.
3. TGW route table: Check routes from the application VPC to the Endpoint VPC and back.
4. Endpoint VPC route table: Make sure Endpoint Subnets can return traffic to every application VPC.
5. VPCE security group: Verify that TCP 443 is allowed from application CIDRs.
6. NACL: Check inbound, outbound, and ephemeral port ranges.
7. Endpoint policy: Confirm that the principal, action, and resource are not denied.
8. IAM / resource policy / SCP: Finally inspect identity permissions, resource policies, and organization-level controls.

Working in the order of resolution, routing, network controls, and authorization is much faster than jumping randomly between console pages.