AWS Transit Gatewayの「ルートテーブル分離」を完全攻略！郵便局の仕分けシステムで理解するネットワーク設計
こんにちは！クラウドの世界へようこそ。インフラエンジニアとして日々AWSの設計図を引いていると、必ずと言っていいほどぶつかる壁があります。それが「VPCが増えすぎて、ネットワークがスパゲッティ状態になる問題」です。
今日は、そんな悩みを一発で解決する救世主、AWS Transit Gateway (TGW) を使った「ルートテーブルの分離」について、郵便局の仕組みを例に、誰でもわかるように解説していきます。
—
1. なぜTransit Gatewayが必要なの？
VPCが2〜3個のうちは、VPC同士を直接つなぐ「VPCピアリング」で十分です。でも、VPCが10個、20個と増えていくとどうなるでしょう？
すべてのVPCを1対1でつなぐと、回線数はネズミ算式に増えて、管理はまさに地獄絵図になります。「AとBはつなぐけど、CとDは隔離したい」なんて要件が出てきた日には、もうお手上げですよね。
そこで登場するのが、Transit Gateway (TGW) です。TGWは、ネットワークの「中央ハブ（郵便局）」のような存在。すべてのVPCを一度この郵便局に接続することで、複雑なルート管理を中央で一元管理できるようになるんです。
—
2. 「関連付け」と「伝播」—郵便局の仕分けルール
TGWの核心は、「ルートテーブル」にあります。TGWには複数のルートテーブルを作ることができ、それぞれのテーブルで「どこに届けるか」というルールを書き込めます。
ここで重要なのが、以下の2つの概念です。
- 関連付け (Association): 「このVPCは、どのルートテーブルを使って郵便物を配送するか」を決めるもの。
- 伝播 (Propagation): 「このVPCの住所（ネットワーク範囲）を、どのルートテーブルのリストに自動で載せるか」を決めるもの。
これを郵便局に例えてみましょう。
- 関連付け = 「あなたの家の集荷担当は、A地区のルート便ですよ」と指定すること。
- 伝播 = 「A地区の配送リストに、あなたの家の住所を載せておきますね」と登録すること。
これらを使い分けることで、「本番環境のVPC同士は話せるけど、開発環境とは遮断する」といった高度な交通整理が可能になります。
—
3. 実践！ルートテーブルを分けて隔離してみよう
例えば、「本番用(Prod)」と「開発用(Dev)」を完全に分けたい場合、以下のような設計が一般的です。
1. Prod用ルートテーブル: Prod VPCを「関連付け」し、Prod VPCの住所を「伝播」させる。
2. Dev用ルートテーブル: Dev VPCを「関連付け」し、Dev VPCの住所を「伝播」させる。
こうすれば、ProdのルートテーブルにはDevの住所が載っていないため、物理的にパケットが届くことはありません。まさに魔法のような分離ですね！
AWS CLIでの設定イメージ
実際に、TGWでルートテーブルを作成し、関連付けを行うコマンドは以下のようになります。
# 1. 新しいルートテーブルを作成（本番用）
aws ec2 create-transit-gateway-route-table \
--transit-gateway-id tgw-0123456789abcdef0 \
--tag-specifications 'ResourceType=transit-gateway-route-table,Tags=[{Key=Name,Value=Prod-Route-Table}]'
# 2. VPCアタッチメントをルートテーブルに関連付ける
aws ec2 associate-transit-gateway-route-table \
--transit-gateway-route-table-id tgw-rtb-0a1b2c3d4e5f6g7h8 \
--transit-gateway-attachment-id tgw-attach-99887766554433221
# 3. 特定のVPCの住所を自動的に伝播させる設定
aws ec2 enable-transit-gateway-route-table-propagation \
--transit-gateway-route-table-id tgw-rtb-0a1b2c3d4e5f6g7h8 \
--transit-gateway-attachment-id tgw-attach-99887766554433221—
4. 現場で役立つ「お作法」
最後に、現場で設計する際に気をつけている「コツ」を共有します。
- デフォルトルートテーブルを過信しない: AWSはデフォルトでTGWルートテーブルを1つ作りますが、実務では「用途別（Prod/Dev/Sharedなど）」に必ず専用のテーブルを作りましょう。
- 共通サービスは全伝播: ログサーバーや踏み台サーバーなど、「どこからでもアクセスさせたい」というVPCがある場合は、それらの住所をすべてのルートテーブルに伝播させると効率的です。
- トラブルシューティングはフローログ: 「なぜか繋がらない！」という時は、TGWのフローログを確認しましょう。パケットがどこでドロップされたのか、宛先不明（ルートなし）なのか、一目瞭然です。
まとめ
TGWのルートテーブル設計は、最初は難しく感じるかもしれません。でも、「郵便物の宛先リスト（ルートテーブル）を、誰に見せるか（関連付け/伝播）」をコントロールしているだけだと考えると、少し親近感が湧きませんか？
この仕掛けをマスターすれば、どんなに大規模なクラウドネットワークでも、安全かつスッキリと管理できるようになります。一歩ずつ、パケットの旅路を想像しながら設計を楽しんでいきましょう！
何か不明な点や、「こんな構成は作れるの？」といった疑問があれば、ぜひコメントで教えてくださいね。応援しています！
コメント