複数VPCで1つのVPC Endpointを共有する：アーキテクチャと構築の完全ガイド

🗺️ 基本トポロジー

                         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

🧰 中核となる4つのサービス

• AWS PrivateLink / Interface VPC Endpoint：アプリケーションVPCからリージョナルAWSサービスへのプライベート接続を提供します。
• AWS Transit Gateway：Endpoint VPCと複数の業務VPCを接続し、TGW Route Tableで到達範囲を制御します。
• Route 53 Profiles：Interface EndpointのPrivate DNSを一元管理し、複数VPCに関連付けます。
• AWS RAM：Transit GatewayとRoute 53 Profileを複数AWSアカウント間で共有します。

🏢 オンプレミス環境も接続する場合

オンプレミスからVPNまたはDirect ConnectでAWSへ接続する場合は、Route 53 Resolver Inbound Endpointを追加し、社内DNSからAWSサービス名をResolverへ転送します。VPCの「CIDR + 2」にあるResolverアドレスへ直接問い合わせる構成は避けます。

1️⃣ 専用Endpoint VPCを作成

• Network AccountまたはShared Services AccountにEndpoint-VPCを作成します。ここでは10.100.0.0/16を使用します。
• 本番では最低2つのAZを使い、AZ-aに10.100.10.0/24、AZ-cに10.100.20.0/24など、各AZにEndpoint Subnetを用意します。
• Interface Endpointは選択したEndpoint SubnetごとにENIを作成します。2AZ構成にすることでAZ障害の影響を抑えられます。
• 共有Endpointを任意のApplication VPCへ置くと、ネットワーク所有権や権限境界、障害対応が特定のワークロードに依存するため避けます。

2️⃣ Transit GatewayまたはVPC Peeringを構成

• 中央Transit Gatewayを作成し、Endpoint VPC、VPC-A、VPC-B、VPC-CのAttachmentを接続します。
• マルチアカウント環境ではAWS RAMでTGWを共有し、各業務アカウントがAttachmentを作成または承認します。
• 業務VPCが2～3個だけなら、それぞれをEndpoint VPCへ直接Peeringし、TGWのレイヤーと費用を省けます。
• Peeringには推移的ルーティングがありません。規模が大きくなると接続数とルート管理が膨らむため、TGWのHub-and-Spoke構成へ移行します。

3️⃣ 業務VPCのRoute Table

Endpointへ接続する各業務サブネットで、Endpoint VPCのCIDRをTGWへ向けます。VPC-Aの例：

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

VPC-BとVPC-Cも10.100.0.0/16を同じTGWへ送ります。Peeringの場合は、対応するPeering ConnectionをTargetにします。

4️⃣ Endpoint VPCの戻りルート

Endpoint Subnetに関連付けたRoute Tableには、各業務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

往路と復路の両方が必要です。往路だけ設定されていると、TCP SYNにSYN/ACKが返らず、最終的に接続タイムアウトになります。

5️⃣ TGW Route Table

• 業務VPC側のルートで10.100.0.0/16をEndpoint VPC Attachmentへ送ります。
• Endpoint VPC側では、10.1.0.0/16、10.2.0.0/16、10.3.0.0/16を各VPC Attachmentへ向けます。
• Route PropagationまたはStatic Routeで構成できます。厳密なセグメント分離が必要なら、複数のTGW Route Tableで伝播関係を明示します。

6️⃣ Endpoint VPCにサービスEndpointを追加

• VPC → Endpoints → Create endpointを開き、東京リージョンのSystems Managerならcom.amazonaws.ap-northeast-1.ssmを選びます。
• VPCはEndpoint-VPC、Subnetはendpoint-subnet-aとendpoint-subnet-cを選択します。
• Route 53 Profilesを使う構成では、Private DNSをEnabledのままにします。SDKやCLIは標準サービス名を使いながらPrivateLinkのプライベートIPへ接続できます。
• 実際に必要なサービスだけを作成します。Interface EndpointごとにAZ時間料金とデータ処理料金が増えます。

📦 集中配置されることが多いEndpoint

• Systems Manager：SSM、SSM Messages、EC2 Messages。
• 基盤サービス：EC2 API、KMS、Secrets Manager、STS、Lambda、EventBridge。
• 監視とメッセージング：CloudWatch、CloudWatch Logs、SNS、SQS。
• コンテナと配信：ECR API、ECR DKR、ECS、CodeArtifact。
• アプリケーション接続：API Gatewayのexecute-apiなどPrivateLink対応サービス。

7️⃣ Endpoint Security Group

• Endpoint ENI専用のSecurity Groupとしてsg-vpce-centralなどを作成します。
• InboundはHTTPS TCP 443を、必要な業務VPCのCIDR（10.1.0.0/16、10.2.0.0/16、10.3.0.0/16など）からのみ許可します。
• 本番環境で0.0.0.0/0を許可しないでください。組織、環境、機密度、専用Endpointなどに応じて送信元を絞ります。
• Security Groupはステートフルですが、インスタンスの送信ルール、NACL、中間アプライアンスでもTCP 443と戻り通信を許可する必要があります。

8️⃣ Endpoint Policy

• Endpoint Policyは、その入口を通じて誰がどのサービス操作を実行できるかを制御します。フルアクセスは疎通確認には便利ですが、本番の恒久設定には不向きです。
• KMS Endpointなら、許可するアカウント、IAM Role、KMS Keyを限定できます。他のサービスでも対応する条件キーとリソース制約を利用します。
• 最終的な認可はEndpoint Policy、IAM Policy、SCP、Resource Policy、Bucket Policy、Key Policyなどの組み合わせで決まります。
• 共有VPCが増えるほど最小権限Policyは複雑になり、Policy文書のサイズ上限にも注意が必要です。必要に応じて環境や信頼境界ごとにEndpointを分割します。

🧭 アカウントの役割分担

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からAWS RAMを使い、同一リージョンのProduction、Development、SecurityなどのアカウントへRoute 53 Profileを共有します。
• 各アカウントは自分のVPCを共有Profileへ関連付け、サービスとVPCごとにPrivate Hosted Zoneを作ることなく中央EndpointのDNSを再利用します。
• AWS Organizations、Control Tower、Landing Zoneに適した役割分担で、ネットワークチームがVPCE、DNS、TGW、ログを、アプリチームがコンピュートと業務リソースを管理します。

① DNS解決

VPC-Aの10.1.10.50にあるEC2がSecrets Manager APIを呼ぶと、SDKはsecretsmanager.ap-northeast-1.amazonaws.comを検索します。Route 53 Resolverと関連付けたProfileが中央VPCEのプライベートIPを返します。

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

② ネットワーク経路

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

AWSサービスまでの経路はプライベートに保たれ、NAT GatewayやInternet Gatewayを必要としません。ただしネットワーク制御とID認可の両方を通過する必要があります。

• ECS、EKS、EC2がECRからイメージをPullする場合、通常はecr.apiだけでなくecr.dkrも必要です。
• コンテナイメージのLayerはS3に保存されるため、2つのECR Interface EndpointがあってもPullに失敗することがあります。
• 一般的にはECR APIとECR DKRを中央配置し、各Application VPCにS3 Gateway Endpointを作成します。
• Pull障害ではDNS、2つのECR Endpoint、S3 Gateway Endpoint、ルート、Security Group、タスクまたはインスタンスのIAM権限を確認します。

現在も利用できる構成

• 集中型Interface EndpointのPrivate DNSを無効にします。
• ssm.ap-northeast-1.amazonaws.comなど、AWSサービス名に一致するRoute 53 Private Hosted Zoneを手動作成します。
• VPCEを指すA Alias Recordを作成し、PHZをEndpoint VPCとすべての業務VPCへ関連付けます。

新規環境で優先されなくなった理由

• 30個のEndpointと100個のVPCがあると、手動のPHZ Associationは巨大な管理マトリクスになります。
• Route 53 Profilesなら中央VPCEを一度関連付け、同じ設定を多数のVPCへ適用できるため、Hosted Zone、Record、Associationの重複を減らせます。
• 既存環境や特殊なDNS要件では従来方式も有効ですが、新規構築ではRoute 53 Profilesを先に検討します。

集中型で発生する費用

• Transit Gateway Attachmentの時間料金。
• Transit Gatewayのデータ処理料金。
• 各AZに配置したInterface Endpointの時間料金。
• PrivateLinkのデータ処理料金、およびAZ間・リージョン間のデータ転送料。

費用を抑えやすい条件

VPC数と必要なEndpoint数が多く、VPCごとの通信量が比較的小さい環境ほど、集中化の効果が出やすくなります。50 VPC、20サービス、2 AZなら、分散型は2,000個のEndpoint ENI、集中型は約40個で済みますが、TGW費用も必ず加えて比較します。

大容量通信は個別に試算

1つのVPCから毎日数TBのS3通信が発生する場合、TGW経由でS3 Interface Endpointへ送る構成は割高になりがちです。ローカルのS3 Gateway Endpointが適しています。AWS料金はリージョンと時期で変わるため、最新のリージョン別料金を基に、すべて日本円へ換算して予算を比較します。

1～3個のVPC

• 各VPCへの個別配置が最も単純で、分離性にも優れます。
• 数を減らしたい場合はPeering + Route 53 Profile + 小規模Central Endpoint VPCを使います。
• 少数のEndpoint共有だけを目的にTransit Gatewayを導入する必要は通常ありません。

5～20個のVPC

• Endpoint VPC + TGW + Route 53 Profilesを本格的に検討します。
• 重複Endpointの固定費、TGW費用、実トラフィック量を同じ費用モデルで比較します。
• 大容量通信や強い分離が必要なワークロードだけ個別Endpointを残すハイブリッド構成も有効です。

20～数百個のVPC

• Network AccountにTGWまたはCloud WAN、Endpoint VPC、Route 53 Profiles、Resolver、Network Firewall、DNS Firewallを集約するのが一般的です。
• IaC、標準タグ、ログ、監視、変更管理でEndpointとアカウント関連付けを管理します。
• 全ワークロードが1つの中央スタックへ依存しないよう、リージョン、環境、信頼境界で分割します。

1. DNS：dig ssm.ap-northeast-1.amazonaws.comを実行し、パブリックIPではなく10.100.x.xのようなVPCEのプライベートIPが返ることを確認。
2. Spoke VPC Route Table：Endpoint VPCのCIDRがTGWまたはPeeringへ向いているか確認。
3. TGW Route Table：業務VPCからEndpoint VPCまでの往路と復路を確認。
4. Endpoint VPC Route Table：Endpoint Subnetから各業務VPCへ戻れるか確認。
5. VPCE Security Group：業務VPCのCIDRからTCP 443を許可しているか確認。
6. NACL：Inbound、Outbound、エフェメラルポート範囲を確認。
7. Endpoint Policy：Principal、Action、Resourceが拒否されていないか確認。
8. IAM / Resource Policy / SCP：最後にID権限、リソースポリシー、組織レベル制御を確認。

「名前解決 → ルーティング → ネットワーク制御 → 認可」の順に確認すると、コンソールを手当たり次第に調べるより早く原因を特定できます。