こんにちは、シニアSREの私です。
プロダクトが急成長し、マルチVPC、マルチアカウントの荒波に揉まれるようになると、従来のVPCピアリング網（いわゆるフルメッシュの地獄）では管理しきれなくなりますよね。そこで登場するのが、AWSが誇るネットワークのハブ「AWS Transit Gateway（TGW）」です。
「とりあえずTGWを置いて、全部のVPCをアタッチすれば繋がるっしょ！」――そう考えて設計を始めると、数ヶ月後に「意図しないVPC同士が通信できてしまった」「セキュリティ要件を満たせない」という深夜のインシデント対応に怯えることになります。
今回は、TGWの真骨頂である「ルートテーブルの伝播（Propagation）と関連付け（Association）の分離設計」について、パケットの挙動から実践的な設定手法まで、現場の知見を交えて徹底的に解説します。
—
1. なぜ「関連付け」と「伝播」を分離する必要があるのか？
TGWのルートテーブルの仕組みを理解する上で、まず頭に叩き込んでおかなければならない大原則があります。それは、「どこからのパケットをどこに流すか（Association）」と、「TGWがどのVPCの存在を知っているか（Propagation）」は、完全に別物であるという点です。
デフォルトの状態のままVPCをTGWにアタッチすると、単一のデフォルトTGWルートテーブルにすべてのVPCが紐づき、すべての経路が自動伝播します。これは「全VPCがフルメッシュで通信できる状態」を意味し、PCI DSSやISMSなどのセキュリティ監査が入った瞬間に一発レッドカードを食らう構成です。
私たちが目指すべきは、「共有サービス（監視・踏み台など）やセキュリティVPCをハブにしつつ、各ワークロードVPC間は完全にアイソレーション（孤立）させるハブ＆スポークの厳格な制御」です。これを実現するのが、複数ルートテーブルの作成と、Association/Propagationの意図的な分離・制御なのです。
—
2. 通信フローの全体像とパケットの旅
言葉だけではイメージしにくいので、セキュアなハブ＆スポーク構成におけるパケットの往来をシーケンスとして追ってみましょう。
ここでは以下の3つを想定します。
1. VPC-A（クライアントワークロード）
2. VPC-B（バックエンドワークロード：VPC-Aとは通信させたくない）
3. VPC-Shared（セキュリティ検査・踏み台などの共有リソース）
[VPC-A] --(パケット送信)--> [TGW Attachment A]
│
(TGW: RouteTable-Workload)
- Association: VPC-A
- Propagation: VPC-Shared のみ
│
▼
[TGW Attachment Shared] --> [VPC-Shared]パケットが流れる瞬間のリアルな挙動
1. VPC-A のプライベートサブネットから、VPC-Shared 宛てのパケットが送出されます。
2. VPC-A のルートテーブルにある 0.0.0.0/0 または VPC-Shared のCIDRへのターゲットが TGW ID を向いているため、パケットは VPC-A のTGWアタッチメントへ飛び込みます。
3. TGWに到着したパケットは、まず 「どのTGWルートテーブルでルーティングを判定すべきか」 を探します。これは、アタッチメントがどのTGWルートテーブルに関連付け（Association）されているかで決まります。ここでは RouteTable-Workload が使われます。
4. RouteTable-Workload の中を検索し、宛先IPに合致するエントリを探します。この時、エントリは伝播（Propagation）によって動的に登録されたものか、静的ルートである必要があります。
5. 経路が見つかれば、パケットは宛先のTGWアタッチメント（例: VPC-Shared 用のアタッチメント）へ転送されます。
ここで重要なのは、RouteTable-Workload に VPC-B への伝播を設定していなければ、VPC-A から VPC-B への経路は物理的に存在しないため、パケットは容赦なくドロップされるということです。セキュリティグループの制御以前に、ネットワーク層で完全に遮断できるのがTGWの強みです。
—
3. 実践：AWS CLIによる高度なTGWルートテーブル設計
GUI（マネジメントコンソール）でポチポチ設定するのも悪くありませんが、インフラストラクチャ・アズ・コード（IaC）や緊急時の迅速なリカバリを考慮すると、CLIの操作コマンドを体に叩き込んでおく必要があります。
ここでは、「ワークロード用ルートテーブル」と「共有サービス用ルートテーブル」を分離し、意図した伝播制御を行う一連のステップをコードとして紹介します。
ステップ1: TGWルートテーブルの作成
まずは、用途ごとに2つのTGWルートテーブルを作成します。
# 1. ワークロードVPC群用のルートテーブルを作成（相互通信禁止用）
aws ec2 create-transit-gateway-route-table \
--transit-gateway-id tgw-0123456789abcdef0 \
--tag-specifications 'ResourceType=transit-gateway-route-table,Tags=[{Key=Name,Value=TGW-RT-Workloads}]'
# 2. 共有サービスVPC用のルートテーブルを作成（全VPCからアクセス可能）
aws ec2 create-transit-gateway-route-table \
--transit-gateway-id tgw-0123456789abcdef0 \
--tag-specifications 'ResourceType=transit-gateway-route-table,Tags=[{Key=Name,Value=TGW-RT-SharedServices}]'ステップ2: アタッチメントの関連付け（Association）の制御
次に、各VPCのアタッチメントを、どのTGWルートテーブルに所属させるかを紐づけます。
# VPC-Aのアタッチメントを 「ワークロード用RT」 に関連付け
aws ec2 associate-transit-gateway-route-table \
--transit-gateway-route-table-id tgw-rt-workload-xxxxxxxxx \
--transit-gateway-attachment-id tgw-attach-vpc-a-yyyyyyyy
# VPC-Sharedのアタッチメントを 「共有サービス用RT」 に関連付け
aws ec2 associate-transit-gateway-route-table \
--transit-gateway-route-table-id tgw-rt-shared-zzzzzzzzz \
--transit-gateway-attachment-id tgw-attach-vpc-shared-wwwwwwwステップ3: 伝播（Propagation）の制御
ここが肝です。デフォルトでは「自動伝播（Default route table propagation）」が有効になっていることが多いですが、セキュアな設計ではこれを無効化し、明示的に必要な経路だけを伝播させます。
# ワークロード用RTには、共有サービスVPCの経路だけを伝播させ、他のワークロードは伝播させない
aws ec2 enable-transit-gateway-route-table-propagation \
--transit-gateway-route-table-id tgw-rt-workload-xxxxxxxxx \
--transit-gateway-attachment-id tgw-attach-vpc-shared-wwwwwww
# 逆に、共有サービス用RTには、すべてのVPC（VPC-A, VPC-Bなど）の経路を伝播させ、管理通信を受け付けられるようにする
aws ec2 enable-transit-gateway-route-table-propagation \
--transit-gateway-route-table-id tgw-rt-shared-zzzzzzzzz \
--transit-gateway-attachment-id tgw-attach-vpc-a-yyyyyyyy—
4. 現場でハマる！陥りがちな罠とデバッグTips
設計図が完璧でも、実際の現場では「なぜか通信できない」という壁にぶつかります。シニアとして後輩によく指導する、代表的なトラブルシューティングのポイントを共有します。
トラブル1：ルートはあるのにパケットが返ってこない（非対称ルーティングの呪い）
- 症状:
VPC-AからVPC-Sharedへの往きパケットは届いているのに、レスポンスが返ってこない。 - 原因: TGWのルートテーブルだけでなく、各VPC側のサブネットルートテーブルの設定漏れが原因の9割です。
VPC-Shared側のルートテーブルで、VPC-AのCIDRへの宛先ターゲットが、正しくTGWアタッチメントを向いているか確認してください。往きと戻りで経路が食い違っていると、AWSのステートフルなファイアウォール（セキュリティグループやNACL）に捨てられます。
トラブル2：静的ルートと伝播ルートの優先順位
- 症状: 明示的に静的ルートを書いたのに、意図しない伝播ルートが優先されてパケットの向き先が狂う。
- 原因: TGWのルートテーブルにおけるルーティング評価の優先順位は、基本的に最長一致（Longest Prefix Match）です。
/32や/24などのプレフィックス長が同じ場合、静的ルートと伝播ルートで競合が発生することがあります。原則として、特殊なルーティング（ブラックホール設定や特定のファイアウォールへの強制転送など）以外は、伝播（Propagation）に任せる設計にするのがクリーンです。
デバッグの強力な味方：AWS Network Reachability Analyzer
パケットキャプチャができないクラウド環境において、IAM権限とルートの迷宮を解き明かす最強のツールが AWS Network Reachability Analyzer です。
TGWを挟んだクロスVPC通信のテストを作成し、「ソース: VPC-A のインスタンス」「ターゲット: VPC-Shared のインスタンス」を指定して実行すれば、どのルートテーブルのどのエントリでパケットが許可され、どこでブロックされたのかがグラフィカルに可視化されます。設計レビューの段階や、構築直後の結合テストでは必ずこれを回すようにしましょう。
—
5. まとめ
AWS Transit Gatewayのルートテーブル分離設計は、一見すると複雑で面倒くさいボイラープレート作業に見えます。しかし、ここを妥協して「とりあえず全部繋ぐ」設計にしてしまうと、後からスケールアウトさせた際にマルチテナント間のセキュリティ担保が不可能になり、インフラ全体の作り直しという悪夢を見るハブになります。
「Associationでどのテーブルの土俵に上げるかを決め、Propagationでどの宛先を知るかを限定する」
このコンセプトをしっかりと頭に焼き付け、クリーンで堅牢なクラウドネットワークを構築してください。あなたのSREライフ、そしてプロダクトの成長を、背後からしっかり支える強固な基盤になるはずです。
コメント