1.3マルチ VPC・マルチアカウントの接続設計

VPC が増えると、どうつなぐかが設計の中心になります。少数なら ピアリング、多数のハブ接続なら Transit Gateway、単一サービスの公開なら PrivateLink が基本です。

1.3.1接続方式の使い分け

• VPC ピアリング：1 対 1・非推移的。少数の VPC を低コストでつなぐ。CIDR が重複していると不可。
• Transit Gateway：多数の VPC とオンプレのハブ。推移的で数百規模に拡張でき、ルーティングを一元管理。
• PrivateLink（VPC エンドポイントサービス）：特定のサービスだけを相手 VPC に公開。ネットワーク全体は結合しない。
• 使い分け：フルメッシュ/多数→TGW、ペア接続→ピアリング、サービス提供→PrivateLink。

ANS-C01 の接続設計は「規模・推移性・CIDR 重複・サービス公開」の観点で最適な方式を選ぶことを問います。VPC ピアリングは 2 つの VPC を直接結ぶ 1 対 1 で、非推移的（A-B、B-C があっても A-C は通らない）、リージョン間も可（インターリージョンピアリング）、CIDR 重複は不可、多数になるとフルメッシュで管理が破綻します。Transit Gateway（TGW）は多数の VPC/VPN/Direct Connect を束ねるハブで、推移的ルーティング、TGW ルートテーブルでアタッチメント間の到達性を制御（本番/開発のセグメント分離、共有サービスへの集約）、リージョン間は TGW ピアリングで接続、数百〜数千 VPC に拡張します。PrivateLink（VPC エンドポイントサービス）は提供側の NLB をエンドポイントサービスとして公開し、利用側はインターフェイスエンドポイント（ENI）で接続——ネットワーク全体を結合せず単一サービスのみを一方向に公開するため、CIDR が重複していても接続可能で、SaaS 提供や厳格な公開制御に向きます。選択軸は、少数のペア＝ピアリング、多数/オンプレ込みのハブ＝TGW、サービス単位の公開＝PrivateLink。コストは、ピアリング（同一 AZ 内は無料、データ転送のみ）、TGW（アタッチメント時間課金＋データ処理料）、PrivateLink（エンドポイント時間＋データ処理）で異なります。設計の要は、「非推移＝ピアリング」「推移ハブ＝TGW」「単一サービス公開・CIDR 非依存＝PrivateLink」を正確に使い分けることです。

1.3.2サービスメッシュ・発見・クライアント接続の in-scope サービス

ネットワーク設計では、アプリ層の通信制御や接続手段も問われます。AWS App Mesh は Envoy ベースのサービスメッシュで、マイクロサービス間の通信に可観測性（メトリクス/トレース）・リトライ・トラフィック分割を、アプリのコードを変えずに与えます（※AWS App Mesh は 2026 年 9 月 30 日にサポート終了予定で、2024 年 9 月以降は新規オンボード不可。後継は Amazon ECS Service Connect）。AWS Cloud Map はリソースにカスタム名を付けて登録するマネージドなサービスディスカバリで、IP/ポートの変化に追従しながらアプリが「名前」でサービスを発見できます（ヘルスチェック連動）。 リモート接続では、拠点間は Site-to-Site VPN、個々の従業員端末からは AWS Client VPN を使い分けます。Client VPN は端末からの TLS ベースのマネージド VPN で、証明書認証や Active Directory 連携で接続を認可します。

1.3.3この節のまとめ

• 少数=ピアリング／多数ハブ=Transit Gateway／単一サービス=PrivateLink
• ピアリングは非推移的・CIDR 重複不可
• メッシュ＝App Mesh／発見＝Cloud Map／端末VPN＝Client VPN