セクション 01 · タスク 1.1 · SAP-C02-004

AWS Transit Gatewayによる大規模ネットワーク設計

AWS Transit Gateway / アタッチメント / TGWルートテーブル / 関連付け / ルート伝達 / ネットワークセグメンテーション

このページのゴール

Transit Gatewayを選択した後、どのVPCからどのVPCへ通信させるかをTGWルートテーブルで設計できることを完成条件にします。

本番VPC × 20
開発VPC × 15
共有サービスVPC × 2
オンプレミス

要件：
本番同士          → 通信可能
開発同士         → 通信可能
本番 ↔ 開発 → 通信禁止
本番 → 共有      → 通信可能
開発 → 共有     → 通信可能
共有 → 双方             → 戻り通信可能

Transit Gatewayを1台作り、すべてをアタッチするだけでは完成ではありません。通信関係を決定するのがTransit Gatewayルートテーブルです。

1. Transit Gatewayを構造として見る

Transit Gatewayを中央ルーターとして使う場合、

        VPC-A
          │
        VPC-B
          │
VPC-C ── TGW ── VPC-D
          │
      オンプレミス

実際の通信経路を理解するには、次の構成要素を分けて考えます。

VPC-A
  │
  │ アタッチメント
  ▼
Transit Gateway
  │
  ├─ TGWルートテーブル A
  ├─ TGWルートテーブル B
  └─ TGWルートテーブル C

アタッチメント
関連付け
ルート伝達
TGWルート

2. アタッチメント

Transit GatewayへVPCなどのネットワークを接続するための接続点がアタッチメントです。

アタッチメント	主な用途
VPC	Amazon VPCを接続
Site-to-Site VPN	VPN接続
Direct Connectゲートウェイ	AWS Direct Connect関連の接続
Transit Gatewayピアリング	別Transit Gateway
Connect	SD-WAN等のサードパーティーアプライアンス
VPN Concentrator	VPNコンセントレータ接続
クライアントVPN	クライアントVPNエンドポイント
ネットワーク機能	AWS Network Firewall等のネットワーク機能

Transit Gatewayの基本となるVPCアタッチメントを中心に仕組みを確認します。

3. VPCアタッチメントではAZごとにサブネットを選択する

VPCをTransit Gatewayへアタッチするときは、Transit Gatewayとの通信に使用するAZについて、各AZから1つのサブネットを指定します。Transit Gatewayは選択されたサブネットへネットワークインターフェイスを配置して通信します。

VPC-A

AZ-A
├─ TGWアタッチメント用サブネット A
├─ アプリ サブネット A
└─ DB サブネット A

AZ-B
├─ TGWアタッチメント用サブネット B
├─ アプリ サブネット B
└─ DB サブネット B

TGWアタッチメント用サブネットだけがTGWを利用できるという意味ではありません。適切なVPCルートがあれば、同じAZ内のほかのサブネットからもTGWへ通信できます。

4. VPCアタッチメントでAZ選択を忘れない

AZ-A → TGWアタッチメントあり
AZ-B → TGWアタッチメントあり
AZ-C → TGWアタッチメントなし

あるAZのリソースからTGWへトラフィックを送るには、そのAZでTransit Gatewayアタッチメント用サブネットが有効になっている必要があります。

VPCをTGWへアタッチした = 全AZが自動的にTGWへ接続された、ではありません。

5. ルーティングは2段階ある

VPC-AからVPC-Bへ送信するとき、ルーティングは1回ではありません。

EC2
 │
 ▼
VPC-Aルートテーブル
 │
 ▼
Transit Gateway
 │
 ▼
TGWルートテーブル
 │
 ▼
VPC-Bアタッチメント
 │
 ▼
VPC-B

VPCルートテーブルとTransit Gatewayルートテーブルは別物です。

6. VPCルートテーブルの役割

例えば、VPC-Aが10.1.0.0/16、VPC-Bが10.2.0.0/16なら、VPC-A側には次のようなルートが必要です。

宛先    ターゲット
10.1.0.0/16    local
10.2.0.0/16    tgw-xxxx

組織のアドレス計画に応じて、10.0.0.0/8 → tgw-xxxxのような集約ルートを使うこともできます。VPCからTransit Gatewayへトラフィックを送るには、VPCサブネットのルートテーブルにTGWをターゲットとするルートが必要です。

7. TGWルートテーブルの役割

パケットがTGWまで到達した後、どのアタッチメントへ転送するかを決めるのがTransit Gatewayルートテーブルです。

TGWルートテーブル

宛先    ターゲット
10.1.0.0/16    VPC-Aアタッチメント
10.2.0.0/16    VPC-Bアタッチメント
10.3.0.0/16    VPC-Cアタッチメント

TGWは送信先IPアドレスを見てネクストホップのアタッチメントを選択するレイヤー3 ルーターとして動作します。

8. 関連付け（Association）

標準の宛先ベースのルートテーブル方式では、関連付け（Association）が、そのアタッチメントからTransit Gatewayへ入ってきたトラフィックがどのTGW ルートテーブルを参照するかを決めます。

本番VPC アタッチメント
        │
        │ 関連付け
        ▼
      RT-Prod

設計上は「この送信元ネットワークへ、どのルーティングポリシーを適用するか」と考えます。

制約	意味
標準方式：1 アタッチメント → 1 TGW ルートテーブル	同時に複数のTGW ルートテーブルへ関連付けできない
1 TGW ルートテーブル ← 複数アタッチメント	複数の送信元へ同じ宛先ベースルーティングポリシーを適用できる
PBR方式：1 アタッチメント → 1 ポリシーテーブル	ポリシーテーブルを関連付ける場合、そのアタッチメントへ標準TGW ルートテーブルを同時には関連付けない

9. ルート伝達（伝播）と関連付けの違い

ルート伝達は、アタッチメントが持つ到達可能なプレフィックスを、どのTGW ルートテーブルへ知らせるかを決めます。

VPC-A アタッチメント
  10.1.0.0/16
       │
       ├─ 伝播 → RT-Prod
       └─ 伝播 → RT-Shared

1つのアタッチメントのルートは、必要に応じて複数のTGW ルートテーブルへ伝播できます。

機能	設計責任
関連付け	送信元アタッチメントがどのルートテーブルを見るか
伝播	アタッチメントの到達可能プレフィックスをどのルートテーブルへ知らせるか

この2つを分けることが、複数のルーティングドメインを設計する中心です。

現行仕様：ポリシーベースのルーティング（PBR）とポリシーテーブル

ポリシーベースのルーティング（PBR）では、アタッチメントへ標準TGW ルートテーブルの代わりにポリシーテーブルを関連付けられます。1つのアタッチメントはポリシーテーブルまたはTGW ルートテーブルのどちらか一方に関連付け、両方へ同時には関連付けません。

ポリシーテーブルはトラフィックを分類するルールを持ちます。独自に設定するカスタマーマネージドルールは番号の小さい順に評価され、送信元CIDR / 宛先CIDR / プロトコル、TCP / UDPでは送信元ポート / 宛先ポートも条件にできます。最初に一致したルールが対象 TGW ルートテーブルを選び、どのルールにも一致しなければパケットは暗黙的な拒否として破棄されます。

送信元アタッチメント
        │
        ▼
   ポリシーテーブル
   ├─ ルール 10: 本番 + TCP/443 → RT-Inspection
   └─ ルール 20: 任意           → RT-Default
        │
        ▼
対象TGWルートテーブル
        │
        ▼
宛先アタッチメント

方式	転送判断	向く要件
標準TGW ルートテーブル	宛先 IPとルートテーブルのルート	送信先プレフィックス中心のルーティング / 分離
ポリシーベースのルーティング	送信元 / 宛先 IP、ポート、プロトコル → 対象ルートテーブル	同じ宛先でもアプリケーションやトラフィック種別ごとに経路を変える

判断ポイント：ポリシーテーブルはTGW ルートテーブルそのものを不要にする機能ではありません。パケット属性でどのTGW ルートテーブルを使うかを選ぶ前段として働きます。

10. 単純な全VPC相互通信

VPC-A / B / Cをすべて相互通信させるだけなら、全アタッチメントを同じTGW ルートテーブルへ関連付けし、各VPCのルートを同じテーブルへ伝播する構成が単純です。

RT-All
10.1.0.0/16 → VPC-A
10.2.0.0/16 → VPC-B
10.3.0.0/16 → VPC-C

VPC-A ─┐
VPC-B ─┼─ RT-All
VPC-C ─┘

ただし、本番と開発を分離したいなど通信方針が異なる場合は、同じルートテーブルへすべてを集約しません。

11. ネットワークセグメンテーション

標準のルートテーブル方式では、Transit GatewayにACLのような拒否ルールを書くのではなく、送信元ごとに参照するTGW ルートテーブルを分け、到達させたくないプレフィックスを持たせないことでルーティングドメインを分離します。PBRを採用する場合は、ポリシールールでトラフィックを分類して適切な対象ルートテーブルへ振り分ける設計も選択できます。

本番 ↔ 本番      許可
開発  ↔ 開発       許可
本番 ↔ 開発       拒否
本番 → 共有    許可
開発  → 共有    許可

Transit GatewayではACLのように「本番→開発を拒否」と書くのではなく、送信元ごとに参照するTGW ルートテーブルを分け、到達させたくないプレフィックスを持たせないことでルーティングドメインを分離します。

本番 アタッチメント
      │ 関連付け
      ▼
    RT-Prod
      ├─ 本番 プレフィックス
      └─ 共有 プレフィックス
      × 開発 プレフィックス

開発 アタッチメント
      │ 関連付け
      ▼
    RT-Dev
      ├─ 開発 プレフィックス
      └─ 共有 プレフィックス
      × 本番 プレフィックス

共有 アタッチメント
      │ 関連付け
      ▼
   RT-Shared
      ├─ 本番 プレフィックス
      ├─ 開発 プレフィックス
      └─ 共有 プレフィックス

この構造により本番と開発を分離しながら、双方から共有サービスを利用できます。

12. 静的ルートと補足機能

TGW ルートテーブルには伝播で学習したルートだけでなく、管理者が明示する静的ルートも設定できます。

0.0.0.0/0
   ↓
検査VPC / エグレスVPCのアタッチメント

集中型の外向き通信や検査など、明示的に次ホップを決めたい場合に利用します。

現在仕様の補足： Transit Gateway ピアリングアタッチメントへのルートは静的ルートとして設定します。また、特定プレフィックスを明示的に破棄するブラックホールルートも利用できます。ネットワーク分離ではまず関連付け / 伝播によって必要な到達性だけを構成し、ブラックホールルートは明示的な破棄要件がある場合に使用します。

13. TGW ルートの選択

標準方式では関連付け先TGW ルートテーブル、PBR方式ではポリシールールが選んだ対象 TGW ルートテーブルの中でルート選択を行います。ルートテーブルに複数候補がある場合は、まず最長プレフィックス一致でより具体的な宛先が選ばれます。

10.0.0.0/8   → Attachment-A
10.10.0.0/16 → Attachment-B

宛先: 10.10.5.10
→ /16 の Attachment-B

同じ宛先 CIDRが競合する場合は、静的ルートが伝播ルートより優先します。

10.20.0.0/16 → VPC-A  伝播
10.20.0.0/16 → VPC-B  静的

→ VPC-B

接続種別ごとの詳細な優先順位も現行仕様として存在しますが、ルート選択ではまず静的ルートと伝播ルートの関係を確実に区別します。

14. 通信成立にはVPC側とTGW側の両方が必要

Transit Gateway通信はTGW ルートテーブルだけでは完成しません。

送信元リソース
↓
送信元サブネットルートテーブル
↓
Transit Gateway
↓
送信元アタッチメントの関連付け先TGWルートテーブル
↓
宛先ルート
↓
宛先アタッチメント
↓
宛先VPC
↓
戻りルートも同様に確認

関連付けだけ設定しても宛先ルートは増えません。伝播してもVPC側からTGWへ向けるルートがなければパケットはTGWへ届きません。また往路だけでなく復路のルーティングも必要です。

15. デフォルトルートテーブルと明示的な分離

全VPC相互通信が要件の小規模構成なら、デフォルト TGW ルートテーブルへ集約する方式でも成立します。

一方、本番 / 開発 / 共有 / セキュリティ / オンプレミスで通信方針が異なる環境では、ルーティングドメインを明示的に分けた方が設計意図を表現しやすくなります。

RT-Prod
RT-Dev
RT-Shared
RT-Security

ルートテーブル数を増やすこと自体が目的ではなく、異なる通信方針を別ルーティングポリシーとして表現する必要があるかで判断します。

16. SAP-C02での設計手順

Transit Gatewayを採用
        │
        ▼
何を接続する？
→ アタッチメント
        │
        ▼
VPC アタッチメントで利用するAZを確認
        │
        ▼
VPCからTGWへ送るルートを設定
        │
        ▼
転送判断は宛先プレフィックスだけで足りる？
   ├─ はい → 標準TGWルートテーブルを関連付け
   │          │
   │          └→ 伝播 / 静的ルート
   │
   └─ いいえ  → ポリシーテーブルを関連付け
              │
              └→ 送信元 / 宛先 / ポート / プロトコルで分類
                         │
                         └→ 対象TGWルートテーブル
        │
        ▼
必要なルーティングドメイン / ネットワーク分離を構成
        │
        ▼
往路・復路を確認

17. 混同ポイント

アタッチメントしただけでは全VPCが自動相互通信しない：VPC ルートとTGW ルートの両方が必要です。
関連付けはルート登録ではない：標準方式では送信元アタッチメントが参照するTGW ルートテーブルを決めます。
標準方式では1 アタッチメントのTGW ルートテーブル関連付け先は1つ：PBRを使うアタッチメントは、TGW ルートテーブルではなくポリシーテーブルを関連付けます。両方へ同時には関連付けません。
ポリシーテーブルはルートテーブルの代替データベースではない：ルールでトラフィックを分類し、使用する対象 TGW ルートテーブルを選びます。
PBRは宛先だけでなく送信元 / ポート / プロトコルも判断材料にできる：同一宛先でもトラフィック種別により経路を変えたい場合の決定打になります。
ネットワーク分離は不要なルートを見せないことが標準方式の基本：PBRではポリシールールによる分類も組み合わせられます。
最長プレフィックス一致が先：対象 TGW ルートテーブル内で同じCIDRなら静的ルートが伝播ルートより優先します。
往路だけでは不十分：宛先側から送信元へ戻るルートも確認します。

18. 設計要素の比較

要素	何を決めるか
アタッチメント	Transit Gatewayへ何を接続するか
VPC ルートテーブル	VPCからどのトラフィックをTGWへ送るか
TGW ルートテーブル	TGW内部でどこへ転送するか
関連付け	標準方式で、送信元アタッチメントがどのTGW ルートテーブルを見るか
ポリシーテーブル / PBR	送信元 / 宛先 / ポート / プロトコルでトラフィックを分類し、対象 TGW ルートテーブルを選ぶ
伝播	アタッチメントのルートをどのTGW ルートテーブルへ知らせるか
静的ルート	管理者が明示的に宛先と次ホップを決める
ネットワーク分離	ルートテーブルを分け、必要なルートだけ保持する

19. まとめ

アタッチメント
→ ネットワークとTransit Gatewayの接続点

標準ルートテーブル方式
→ 送信元アタッチメントをTGWルートテーブルへ関連付け
→ 宛先プレフィックスでルート選択

ポリシーベースルーティング
→ アタッチメントをポリシーテーブルへ関連付け
→ 送信元 / 宛先 / ポート / プロトコルでルール評価
→ 最初に一致したルールが対象TGWルートテーブルを選択
→ 一致なしは暗黙的な拒否

伝播
→ 宛先情報
→ TGWルートテーブルへプレフィックスを知らせる

ネットワーク分離
→ ルートテーブルまたはポリシールールでルーティングドメインを分ける

ルーティング成立
→ VPC ルートテーブル
+
TGW転送ポリシー
+
対象TGWルートテーブル
+
戻り経路

最重要ポイント：Transit Gatewayを「全部をつなぐ装置」ではなく、複数ネットワークのルーティングポリシーを中央で設計する装置として理解します。

主要AWS公式資料

理解確認

このページの内容を18問で確認します。

理解確認18問へ →