Sharing AWS VPC Endpoints Across VPCs: A Guide to Centralized Architecture and Configuration

Suppose you currently have:

VPC-A
VPC-B
VPC-C

All three VPCs need:

SSM
EC2 API
ECR
CloudWatch
KMS
Secrets Manager
STS
...

You have two designs.

Option A: Each VPC creates its own Endpoint.

VPC-A
 ├─ SSM Endpoint
 ├─ EC2 Endpoint
 ├─ ECR Endpoint
 ├─ Logs Endpoint
 └─ KMS Endpoint

VPC-B
 ├─ SSM Endpoint
 ├─ EC2 Endpoint
 ├─ ECR Endpoint
 ├─ Logs Endpoint
 └─ KMS Endpoint

VPC-C
 ├─ SSM Endpoint
 ├─ EC2 Endpoint
 ├─ ECR Endpoint
 ├─ Logs Endpoint
 └─ KMS Endpoint

This is the simplest and most isolated design.

However, the number of endpoints will expand rapidly.

for example:

10 VPCs × 20 AWS Service Endpoints × 2 AZs = 400 Endpoint ENIs

Interface Endpoint is based on Endpoint × AZ × HourThere is a fee, plus a data processing fee.

Therefore, as the scale increases, the costs and maintenance will increase significantly.

Establish a:

Network VPC / Shared Services VPC

All endpoints are placed here.

For example:

                  AWS Services
                       │
                PrivateLink
                       │
             ┌───────────────────┐
             │  Network VPC      │
             │  10.0.0.0/16      │
             │                   │
             │ SSM Endpoint      │
             │ KMS Endpoint      │
             │ ECR Endpoint      │
             │ Logs Endpoint     │
             │ STS Endpoint      │
             │ Secrets Endpoint  │
             └─────────┬─────────┘
                       │
                Transit Gateway
             ┌─────────┼─────────┐
             │         │         │
             │         │         │
          VPC-A      VPC-B      VPC-C
       10.10/16   10.20/16   10.30/16

then:

EC2 in VPC-A ↓ ssm.ap-northeast-1.amazonaws.com ↓ Route 53 ↓ Resolves to Private IP of SSM Endpoint in Shared VPC ↓ Transit Gateway ↓ Interface Endpoint ENI ↓ AWS PrivateLink ↓ SSM

AWS officially supports this centralized design.

This needs to be discussed separately.

Gateway endpoints cannot be shared in this way.

S3 and DynamoDB have:

Gateway VPC Endpoint

For example:

com.amazonaws.ap-northeast-1.s3
com.amazonaws.ap-northeast-1.dynamodb

It is completely different from a regular Interface Endpoint.

Gateway Endpoint：

• Do not use PrivateLink
• Do not create ENI
• Essentially, it's a combination of Route Table and AWS Managed Prefix List.
• free
• It can only be used by the VPC it resides in.

AWS has officially stated:

Gateway Endpoints cannot extend beyond the VPC; resources from the other end of a VPC Peering, Transit Gateway, VPN, or Direct Connect cannot borrow from this Gateway Endpoint.

Therefore, it should not be designed as follows:

VPC-A ──TGW── Shared VPC ── S3 Gateway Endpoint

Then we want VPC-A to use the S3 Gateway Endpoint of Shared VPC.

no.

Normally it should be:

VPC-A → Your own S3 Gateway Endpoint VPC-B → Your own S3 Gateway Endpoint VPC-C → Your own S3 Gateway Endpoint

because:

Gateway endpoints are not charged extra.

Therefore, there is no need to centralize the S3 Gateway Endpoint in order to "reduce the number of Endpoints".

recommend:

                  S3
             ↑     ↑     ↑
             │     │     │
           GW EP  GW EP  GW EP
             │     │     │
           VPC-A VPC-B VPC-C

and:

SSM
KMS
STS
ECR
ECR Docker
CloudWatch
CloudWatch Logs
Secrets Manager
SNS
SQS
etc.

These Interface VPC Endpoint That's what makes centralization suitable.

Because an Interface Endpoint is essentially:

Create an ENI with a Private IP address in your specified subnet.

According to AWS's official documentation, an Interface Endpoint creates an Endpoint Network Interface in the subnet you choose and assigns a private IP address to that subnet.

For example:

Shared VPC
10.0.0.0/16

AZ-a:
Endpoint ENI
10.0.10.50

AZ-c:
Endpoint ENI
10.0.20.60

For the other VPC, as long as:

VPC-A → Can route to 10.0.10.50

and:

Security Group 10.0.10.50 allows VPC-A

In reality, the network can already access the Endpoint.

Therefore, the so-called:

Shared VPC Endpoint

What actually happened was:

Other VPCs ↓ Cross-VPC Network ↓ Access Central VPC Endpoint ENI

No:

A vpce-xxx can be attached to three VPCs simultaneously.

These are two completely different concepts.

In reality, it can be divided into three types.

This is the most common solution for enterprise environments.

Assuming Tokyo Region:

ap-northeast-1

network:

Network VPC
10.0.0.0/16

App VPC-A
10.10.0.0/16

App VPC-B
10.20.0.0/16

App VPC-C
10.30.0.0/16

Architecture:

                       AWS SSM
                          ▲
                          │
                     PrivateLink
                          │
                 SSM Interface EP
                 10.0.10.50
                 10.0.20.50
                          │
                ┌─────────────────┐
                │   Network VPC   │
                │   10.0.0.0/16   │
                └────────┬────────┘
                         │
                       TGW
              ┌──────────┼──────────┐
              │          │          │
            VPC-A      VPC-B      VPC-C
          10.10/16   10.20/16   10.30/16

Transit Gateway (TGW) is designed by AWS for central routing across multiple VPCs and supports transient routing; AWS also recommends prioritizing TGW for large-scale multi-VPC networks.

The following is a breakdown of the actual configuration.

Step 1: Create a Network VPC

For example:

VPC:
shared-endpoint-vpc

CIDR:
10.0.0.0/16

Two AZs:

ap-northeast-1a
Endpoint subnet:
10.0.10.0/24

ap-northeast-1c
Endpoint subnet:
10.0.20.0/24

It is recommended to have at least 2 AZs.

VPC Console：

Transit Gateways
→ Create transit gateway

For example:

Name:
core-tgw

Then create a VPC Attachment:

core-tgw
│
├─ shared-endpoint-vpc
├─ app-vpc-a
├─ app-vpc-b
└─ app-vpc-c

If you have different AWS accounts, you can also share the Transit Gateway via AWS RAM. AWS officially supports sharing the TGW across accounts.

Assumption:

Shared VPC:
10.0.0.0/16

VPC-A:
10.10.0.0/16

VPC-B:
10.20.0.0/16

VPC-A：

Destination        Target

10.10.0.0/16       local
10.0.0.0/16        tgw-xxxxxxxx

VPC-B：

Destination        Target

10.20.0.0/16       local
10.0.0.0/16        tgw-xxxxxxxx

Shared Endpoint VPC：

Destination        Target

10.0.0.0/16        local
10.10.0.0/16       tgw-xxxxxxxx
10.20.0.0/16       tgw-xxxxxxxx

Otherwise, the following will occur:

VPC-A → Endpoint

You can go, but:

Endpoint → VPC-A

They can't come back.

TGW Route Table：

10.0.0.0/16
    → shared-endpoint-vpc attachment

10.10.0.0/16
    → VPC-A attachment

10.20.0.0/16
    → VPC-B attachment

10.30.0.0/16
    → VPC-C attachment

If there is no special need for network isolation, route propagation can be used.

The corporate environment is usually broken down:

Spoke TGW RT
Shared Services TGW RT
Inspection TGW RT

Avoid allowing all VPCs to communicate with each other by default.

For example, if sharing is required:

AWS Systems Manager

create:

VPC
→ Endpoints
→ Create endpoint

Service：

com.amazonaws.ap-northeast-1.ssm

VPC：

shared-endpoint-vpc

Subnets：

ap-northeast-1a
10.0.10.0/24

ap-northeast-1c
10.0.20.0/24

Thus, the following arises:

vpce-0123456789

ENI-A:
10.0.10.50

ENI-C:
10.0.20.50

When a VPC normally uses its own Endpoint:

Enable Private DNS
✓

Very convenient.

For example, originally:

ssm.ap-northeast-1.amazonaws.com

It will automatically parse into:

10.0.10.50
10.0.20.50

The AWS SDK requires absolutely no modification.

However, centralized architecture has a problem.

Private DNS automatically creates an AWS-managed Private Hosted Zone, which only works within the VPC where the Endpoint resides.

therefore:

Shared VPC

Know:

ssm.ap-northeast-1.amazonaws.com
=
10.0.10.50

but:

VPC-A
VPC-B

I don't know.

Therefore, AWS's official central endpoint architecture recommends:

In the Central Endpoint scenario, disable the automatic Private DNS for Endpoint and then manually create the Route 53 Private Hosted Zone.

create:

Route 53
→ Hosted zones
→ Create hosted zone

Domain：

ssm.ap-northeast-1.amazonaws.com

Type：

Private Hosted Zone

First, associate:

shared-endpoint-vpc

Enter:

ssm.ap-northeast-1.amazonaws.com

Create record。

Record：

ssm.ap-northeast-1.amazonaws.com

Type：

A

choose:

Alias

Target selection:

VPC Endpoint

Then:

vpce-0123456789...

AWS's official central endpoint solution is:

AWS Service DNS
↓
Route53 PHZ
↓
Alias
↓
Central Interface Endpoint

Instead of manually making the application use the Endpoint IP.

Private Hosted Zone：

ssm.ap-northeast-1.amazonaws.com

Related:

shared-endpoint-vpc
app-vpc-a
app-vpc-b
app-vpc-c

A Private Hosted Zone in AWS Route 53 can be associated with multiple VPCs.

then:

VPC-A

implement:

nslookup ssm.ap-northeast-1.amazonaws.com

get:

10.0.10.50
10.0.20.50

VPC-B

same:

nslookup ssm.ap-northeast-1.amazonaws.com

Too:

10.0.10.50
10.0.20.50

At this time:

VPC-A
   │
   │ DNS
   ▼
ssm.ap-northeast-1.amazonaws.com
   │
   ▼
10.0.10.50
   │
   ▼
Transit Gateway
   │
   ▼
Central VPC
   │
   ▼
SSM VPC Endpoint

That completes the story.

This is the second very common pitfall.

Endpoint ENI has Security Group.

For example:

endpoint-sg

Inbound：

HTTPS
TCP 443

Source:
10.10.0.0/16
10.20.0.0/16
10.30.0.0/16

It can be made even finer.

For example, only:

10.10.10.0/24
10.20.20.0/24

Allow access to the Endpoint.

If passage is not permitted here:

DNS OK
Routing OK
TGW OK

still:

timeout

For example, EC2 in VPC-A:

aws ssm describe-instance-information \
    --region ap-northeast-1

SDK request:

https://ssm.ap-northeast-1.amazonaws.com

① DNS：

ssm.ap-northeast-1.amazonaws.com
↓
Route53 Private Hosted Zone
↓
10.0.10.50

② Routing：

EC2
10.10.1.50
↓
VPC-A route table
↓
10.0.0.0/16 → TGW

③ TGW：

10.0.10.50
↓
Shared VPC attachment

④ Shared VPC：

Endpoint ENI
10.0.10.50

⑤ Endpoint：

PrivateLink
↓
AWS SSM

The following is not required throughout the process:

Internet Gateway
NAT Gateway
Public IP

This is one of its greatest significances. The purpose of PrivateLink is to allow access to AWS services through a private network without the need for IGW, NAT, or public IP addresses.

Suppose you need:

SSM
EC2 Messages
SSM Messages
KMS
CloudWatch
CloudWatch Logs
Secrets Manager
ECR API
ECR DKR
STS

Central VPC：

Network VPC

├─ vpce-ssm
├─ vpce-ssmmessages
├─ vpce-ec2messages
├─ vpce-kms
├─ vpce-monitoring
├─ vpce-logs
├─ vpce-secretsmanager
├─ vpce-ecr-api
├─ vpce-ecr-dkr
└─ vpce-sts

Route53：

ssm.ap-northeast-1.amazonaws.com
→ SSM Endpoint

ssmmessages.ap-northeast-1.amazonaws.com
→ SSM Messages Endpoint

ec2messages.ap-northeast-1.amazonaws.com
→ EC2 Messages Endpoint

kms.ap-northeast-1.amazonaws.com
→ KMS Endpoint

logs.ap-northeast-1.amazonaws.com
→ Logs Endpoint

secretsmanager.ap-northeast-1.amazonaws.com
→ Secrets Manager Endpoint

Then PHZ simultaneously associate:

VPC-A
VPC-B
VPC-C
VPC-D
...

Some AWS services have unique DNS structures, such as ECR Docker/OCI endpoints. AWS also notes that some services may require wildcard aliases, so it cannot be assumed that all endpoints have only one simple record.

For example:

Network Account
111111111111

App Account A
222222222222

App Account B
333333333333

The architecture is perfectly acceptable.

recommend:

AWS Organizations

Network Account
 ├─ TGW
 ├─ Shared VPC
 ├─ Interface Endpoints
 └─ Route53 PHZ

       ↓ AWS RAM

App Account A
 └─ VPC-A

App Account B
 └─ VPC-B

TGW can be accessed through:

AWS Resource Access Manager

share.

Cross-account associations for Private Hosted Zones are a bit more complicated.

for example:

Network Account:
PHZ Z123456

App Account:
VPC vpc-abcdef

Network Account First:

aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z123456 \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdef

Then App Account:

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z123456 \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdef

The official AWS process for cross-Account Private Hosted Zones is as follows:

PHZ Owner
↓
CreateVPCAssociationAuthorization

VPC Owner
↓
AssociateVPCWithHostedZone

Furthermore, this cross-account operation cannot be completed entirely by relying on the Route 53 Console; it requires CLI/API/SDK.

If you only have two or three VPCs, you don't necessarily need a TGW.

For example:

           Central VPC
          Endpoint VPC
        10.0.0.0/16
          /       \
         /         \
      Peering     Peering
       /             \
   VPC-A             VPC-B
10.10/16           10.20/16

Configuration:

VPC-A ↔ Central VPC
VPC-B ↔ Central VPC

Then:

VPC-A：

10.0.0.0/16
→ pcx-aaa

Central：

10.10.0.0/16
→ pcx-aaa

10.20.0.0/16
→ pcx-bbb

Endpoint SG：

443
10.10.0.0/16

443
10.20.0.0/16

DNS still:

PHZ
↓
Endpoint Alias
↓
associate VPC-A
associate VPC-B

it:

Transitive Routing is not supported.

AWS has made this clear in official statements.

For example:

VPC-A
  │
peering
  │
Central
  │
peering
  │
VPC-B

This cannot be used to conclude that:

A → Central → B

It's possible.

Therefore, if:

2 VPC
3 VPC

Peering is very comfortable.

if:

20 VPC
50 VPC
100 VPC

It will become increasingly difficult to maintain.

Therefore, generally speaking:

Small: VPC Peering Large: Transit Gateway

There is also a very simple method, which is especially suitable for testing.

After creating an Endpoint, AWS will generate something like this:

vpce-0123456789abcdef-xxxx.ssm.ap-northeast-1.vpce.amazonaws.com

AWS will create Regional and Zone DNS names for the Interface Endpoint.

Therefore, as long as the VPC-A network can reach the Shared VPC, it can directly:

aws ssm describe-instance-information \
  --endpoint-url \
  https://vpce-xxxx.ssm.ap-northeast-1.vpce.amazonaws.com

This way, you don't even need to do it yourself:

ssm.ap-northeast-1.amazonaws.com

Private Hosted Zone。

advantage

Super easy.

Ideal for:

Validate Routing, Validate SG, Validate TGW, Validate Endpoint

shortcoming

The application must have its configuration modified.

original:

AWS SDK
↓
ssm.ap-northeast-1.amazonaws.com

Now it becomes:

AWS SDK
↓
vpce-xxx....

Many applications are not convenient to modify in this way.

Therefore, the production environment is generally:

PHZ + Alias

most.

① Significantly reduce Endpoint

Assumption:

20 VPC
15 Interface Endpoints
2 AZ

Distributed：

20 × 15 × 2
=
600 Endpoint AZ instances

Centralization:

15 × 2
=
30

The difference is huge.

Interface Endpoint received:

Endpoint/AZ/hour
+
Data Processing / GB

AWS PrivateLink pricing includes an hourly charge per AZ plus data processing. The baseline data processing rate for the first 1 PB is about $0.01/GB; hourly prices vary by Region.

Distributed：

VPC × Service × AZ × endpoint-hour

Central：

Service × AZ × endpoint-hour
+
TGW

The more VPCs there are, the more significant the difference in the number of Endpoints.

Many architecture diagrams here deliberately ignore this point.

Transit Gateway received:

Attachment hourly rate + Data Processing / GB

AWS officially charges based on the number of attachment hours and the amount of data flowing through the TGW.

Therefore, what should really be calculated is:

Per VPC Endpoint

Cost = Number of VPCs × Number of Endpoints × Number of AZs × Endpoint hourly + PrivateLink data

Centralized

Cost = Number of Endpoints × Number of AZs × Endpoint hourly + TGW attachment hourly + TGW data processing + PrivateLink data processing + possible cross-AZ data

so:

If a company already has a TGW (Township Gateway), a Central Endpoint is usually very attractive.

But if:

There are only 2 VPCs, only 3 endpoints, and no TGW.

Building a TGW specifically to save on endpoint costs may not be cost-effective.

This is a very important issue.

turn out to be:

VPC-A → Endpoint-A
VPC-B → Endpoint-B
VPC-C → Endpoint-C

There is a problem with Endpoint-A:

Only A has a problem.

Centralization:

A ─┐
B ─┼→ Central Endpoint
C ─┘

Central Endpoint, Shared VPC routing, DNS, or TGW misconfiguration:

A
B
C
D
E
...

They might both be suspended.

so:

The cost of saving money and managing costs is an increased blast radius for shared infrastructure.

AWS also specifically points out that a central endpoint can broaden the scope of policy and failure impacts.

Distributed：

Dev VPC endpoint → Dev permissions Prod VPC endpoint → Prod permissions Security VPC endpoint → Security permissions

Very easy to manage.

Centralization:

A KMS Endpoint for Dev Prod Test Security Monitoring...

All shared.

Endpoint Policy：

Principal
Resource
Action
Conditions

It will become increasingly complicated.

AWS has also issued a special reminder regarding this:

Centralization increases the difficulty of managing least-privilege endpoint policies, and the blast radius of a single endpoint policy is larger; the endpoint policy document itself also has size limitations.

for example:

Production VPC
Development VPC

All use:

Central S3 Interface Endpoint

Although:

IAM
Bucket Policy
Endpoint Policy
SG

Permissions can still be controlled, but the physical/network boundaries are no longer completely independent.

Therefore, for particularly demanding environments:

PCI FinancialProduction Security tooling

Possible designs:

Prod Endpoint VPC

NonProd Endpoint VPC

Instead of the whole company:

An Endpoint VPC

It's not that there's only one in the entire company, but rather:

                   AWS Services
                        │
          ┌─────────────┴──────────────┐
          │                            │
   Prod Endpoint VPC           NonProd Endpoint VPC
          │                            │
        TGW                         TGW
     ┌────┼────┐                 ┌────┼────┐
     │    │    │                 │    │    │
   Prod Prod Prod              Dev  Test Sandbox
   VPC1 VPC2 VPC3

even:

Security
Production
NonProduction

Create a Shared Endpoint VPC separately.

This way, we can take both into account:

Cost Management Security Isolation Blast Radius

For example, VPC-A already had its own:

SSM Endpoint
Private DNS = Enabled

Then you associate again:

ssm.ap-northeast-1.amazonaws.com

This is the Central PHZ.

This could lead to DNS namespace conflicts.

Therefore, migration should generally be:

① Create a central endpoint ② Create a central pHZ ③ Test endpoint-specific DNS ④ Associate spoke VPC ⑤ Verify DNS ⑥ Delete the Spoke VPC's own endpoint ⑦ Verify services ⑧ Migrate to the next VPC

Instead of deleting them all at once.

For example:

Tokyo VPC
ap-northeast-1

Osaka VPC
ap-northeast-3

In theory:

Tokyo VPC
    ↓
TGW
    ↓
TGW Peering
    ↓
Osaka
    ↓
Central Endpoint

AWS also offers a cross-Region Centralized Endpoint architecture, via:

TGW Peering
+
Private Hosted Zones

accomplish.

However, it is generally recommended to:

Tokyo Endpoint VPC
   ↓
Tokyo VPCs

Osaka Endpoint VPC
   ↓
Osaka VPCs

That is to say:

One Region, one Central Endpoint VPC.

so:

Lower latency, simpler network, better disaster isolation, lower cross-region traffic costs

Assume the company has:

30 VPCs, 5 AWS Accounts, Tokyo Region

It can be established:

Network Account
│
├─ Transit Gateway
│
├─ Endpoint VPC
│   │
│   ├─ SSM
│   ├─ SSM Messages
│   ├─ EC2 Messages
│   ├─ ECR API
│   ├─ ECR DKR
│   ├─ STS
│   ├─ KMS
│   ├─ Secrets Manager
│   ├─ CloudWatch
│   ├─ CloudWatch Logs
│   ├─ SNS
│   └─ SQS
│
└─ Route53 Private Hosted Zones

Then:

Account A
├─ VPC1 ─┐
├─ VPC2 ─┤
└─ VPC3 ─┤
         │
Account B│
├─ VPC4 ─┤
├─ VPC5 ─┤
└─ VPC6 ─┤
         ▼
        TGW
         │
         ▼
 Endpoint VPC
         │
         ▼
 AWS PrivateLink

but:

S3 Gateway Endpoint
DynamoDB Gateway Endpoint

It is still recommended:

Created separately for each VPC

Because it's free, and Gateway Endpoint itself cannot be used from other VPCs via TGW/Peering.

In fact, when you troubleshoot problems in the future, you only need to remember these four layers:

             ┌─────────────────┐
             │      DNS        │
             │   Route53 PHZ   │
             └────────┬────────┘
                      │
                      ▼
             Endpoint Private IP
                      │
             ┌────────┴────────┐
             │     Routing     │
             │   TGW/Peering   │
             └────────┬────────┘
                      │
             ┌────────▼────────┐
             │    Security     │
             │ Endpoint SG/NACL│
             └────────┬────────┘
                      │
             ┌────────▼────────┐
             │    IAM Policy   │
             │ Endpoint Policy │
             │ Service Policy  │
             └─────────────────┘

If access is unavailable, please follow these steps:

① DNS
② Route
③ Security Group/NACL
④ IAM / Endpoint Policy

Through investigation, problems can usually be found.

The most memorable sentence

A VPC Endpoint is not itself "shared with multiple VPCs" via RAM.

The centralized nature of Interface Endpoints is:

Central VPC
    ↓
Interface Endpoint ENI
    ↑
TGW / VPC Peering
    ↑
Other VPCs

Passed again:

Route53 Private Hosted Zone

In all VPCs:

ssm.ap-northeast-1.amazonaws.com

All were analyzed to be:

Central VPC Endpoint

This completes the whole process. Shared/Centralized VPC Endpoint。

and Don't do this with S3/DynamoDB Gateway Endpoints; build your own for each VPC.Because it's free, and AWS explicitly prohibits its use from the other end, such as TGW or Peering.