AWS Transit Gateway (TGW) は、複数 VPC とオンプレミスを ハブアンドスポーク で接続するクラウドスケールのルーティングハブです。VPC ピアリングの組み合わせ爆発を解消します。本記事では TGW のルート設計とセグメンテーションを SAA / SAP 両面から整理します。

SAA レベル：基礎概念

VPC ピアリングの限界と TGW の利点

VPC ピアリングは VPC 間を直接接続しますが、接続数が N×(N-1)/2 に爆発 する課題があります。また、ピアリングは 推移的ではない（A-B, B-C があっても A-C は自動接続されない）という制約もあります。

TGW は 中央ハブに全 VPC を接続 することで、これらの課題を解決します。

SAA レベル：基礎概念

TGW は 「ネットワークのハブアンドスポーク化」 です。全 VPC が TGW に接続すれば、TGW 経由で任意の VPC 間通信が可能になります。 N 個の VPC の接続管理が O(N) に簡素化 される点が SAA の核心メリットです。

# VPC ピアリング（組み合わせ爆発）
VPC-A ── VPC-B
  │  ╲   ╱  │
  │   ╲ ╱   │
  │   ╱ ╲   │
  │  ╱   ╲  │
VPC-C ── VPC-D    ← 6 本のピアリングが必要

# Transit Gateway（集約）
VPC-A ─┐
VPC-B ─┼─ [TGW]    ← 4 本のアタッチメントで済む
VPC-C ─┤
VPC-D ─┘

TGW の接続対象

TGW は以下のアタッチメント（接続）をサポートします。

アタッチメント種別	説明
VPC	VPC のサブネットを TGW に接続
VPN	Site-to-Site VPN を TGW に集約
Direct Connect (Transit VIF)	DX 経由オンプレミス接続
TGW Peering	リージョン間 TGW 同士の接続
TGW Connect	GRE カプセル化でのサードパーティ機器連携

SAA 試験のポイント

TGW は VPN, Direct Connect, VPC, リージョン間 Peering をすべて 1 箇所に集約 できます。これが「ネットワークの単一管理ポイント」を実現する根拠です。

TGW ルートテーブルの基本

TGW は 1 つ以上のルートテーブル を持ちます。各アタッチメントは 伝播 (Propagation) で経路をルートテーブルに自動登録します。

TGW ルートテーブル (デフォルト):
  10.0.0.0/16   → VPC-A アタッチメント (伝播)
  10.1.0.0/16   → VPC-B アタッチメント (伝播)
  192.168.0.0/16 → VPN アタッチメント (伝播)

動的ルーティング (BGP): VPN/DX は BGP で経路を自動伝播
静的ルーティング: VPC アタッチメントは VPC の CIDR が自動伝播

SAP レベル：高度な設計シナリオ

複数ルートテーブルによるセグメンテーション

SAP では 複数の TGW ルートテーブル を使ってネットワークをセグメンテーションします。これは本番/非本番、部門間、コンプライアンス境界などの分離に使われます。

SAP レベル：高度な設計シナリオ

TGW の真の力は ルートテーブルを複数持ち、アタッチメントごとに適用テーブルを切り替えられる 点です。「本番 VPC は本番ルートテーブル、開発 VPC は開発ルートテーブル」と分けることで、意図しない経路交差を防ぐ セグメンテーション を実現します。

TGW Route Table: "Production"
  - VPC-Prod-App     (アタッチ、伝播: yes)
  - VPC-Prod-Data    (アタッチ、伝播: yes)
  - DX-Transit       (アタッチ、伝播: yes)
  → Dev VPC の経路は伝播なし（通信不可）

TGW Route Table: "Development"
  - VPC-Dev-App      (アタッチ、伝播: yes)
  - VPC-Dev-Data     (アタッチ、伝播: yes)
  → Prod VPC への経路は伝播なし（通信不可）

TGW Route Table: "Shared Services"
  - VPC-Shared       (アタッチ、伝播: yes)
  → 全 VPC からアクセス可能、ただし Shared から各 VPC へは制限

アタッチメントと伝播の設計

各アタッチメントには 「関連付け (Association)」 と 「伝播 (Propagation)」 の 2 つの概念があります。

概念	意味	設計論点
関連付け (Association)	アタッチメントがどのルートテーブルを見るか	デフォルトゲートウェイの決定
伝播 (Propagation)	アタッチメントの経路をどのルートテーブルに書き込むか	他セグメントからの到達性制御

関連付けと伝播の混同

関連付け は「そのアタッチメントからパケットを送る際に参照するルートテーブル」、伝播は「そのアタッチメントの経路をどのテーブルに広告するか」です。この 2 つを混同すると、片方向のみ通信できる奇妙な状態になります。SAP の典型的な落とし穴です。

TGW Peering によるマルチリージョン接続

リージョン間で VPC を接続するには TGW Peering を使います。

TGW Peering は AWS バックボーン網を経由（インターネット不使用）
リージョン間通信が 暗号化不要（AWS 内部通信）
データ転送料金が発生（リージョン間転送）

[TGW 東京] ──peering── [TGW バージニア]
   │                       │
 VPC-JP-A, VPC-JP-B     VPC-US-A, VPC-US-B

Peering の制約

TGW Peering は 1 対 1 で、推移的ではありません（A-B, B-C があっても A-C は直接必要）。ただし、TGW Peering 経由で オンプレミスに横流し することは可能です。

TGW Network Manager による可視化

Transit Gateway Network Manager は、グローバルネットワークの可视化と管理を提供します。

トポロジーのグラフィカル可視化
リアルタイムの経路・接続状態監視
イベント通知（接続断、経路変更）

運用設計のコツ

Network Manager の Events を EventBridge に連携し、接続断を Slack や PagerDuty に通知する仕組みを構築すると、大規模ネットワークの運用負荷が大幅に低下します。

TGW と VPC のサブネット設計

TGW に VPC をアタッチする際、TGW 専用のサブネット を用意するのがベストプラクティスです。

VPC-A (10.0.0.0/16):
  Subnet-A-Private (10.0.1.0/24)   ← アプリ用
  Subnet-A-TGW     (10.0.2.0/28)   ← TGW 専用 (/28 で十分)
    └── TGW ENI が配置される

TGW 専用サブネットは /28 以上 であれば十分
TGW ENI は各 AZ に 1 つ配置されるため、複数 AZ にサブネットを用意 すると冗長化
TGW サブネットへの経路は 0.0.0.0/0 → TGW に設定

コスト最適化設計

TGW のコストは アタッチメント時間料金 + データ転送料金 です。

コスト要素	説明	最適化手法
アタッチメント料金	VPC/VPN アタッチメント毎の時間課金	不要アタッチメントの削除
データ転送 (GB 単位)	TGW 経由のトラフィック	同一アタッチメント内通信は課金なし
リージョン間転送	TGW Peering 経由	リージョン間通信の最小化

コスト増の典型パターン

「全 VPC を 1 TGW に集約→リージョン間通信がすべて TGW Peering 経由」 になると、リージョン間データ転送料金が想定以上に増加します。リージョン内完結のトラフィックとリージョン間トラフィックを TGW を分けて 設計する判断も SAP には求められます。

制約とクォータ

項目	デフォルト	備考
TGW あたりアタッチメント	100	クォータ拡張可能
TGW あたりルートテーブル	50	セグメンテーション設計に影響
TGW あたり経路数	10,000	BGP 経路集約で管理
TGW Peering	リージョン間 1 対 1	推移的ではない

まとめ

SAA: TGW はハブアンドスポークで VPC ピアリングの組み合わせ爆発を解消。 VPN/DX/VPC を 1 箇所に集約できる点を理解する。
SAP: 複数ルートテーブルによるセグメンテーション、関連付け vs 伝播の設計、 TGW Peering によるマルチリージョン、コスト最適化の判断が求められる。

次は VPC Peering vs Transit Gateway vs PrivateLink の比較 で、 3 つの接続手法の使い分けを整理します。