AWS Transit Gateway の基本概念

Transit Gateway (以降、TGW と表記) について、個人的に押さえておきたいところを書きました。

TGW で良くなること

• VPC 間の接続が多数必要な場合に VPC Peering と比較して管理が楽になる
  • VPC Peering の場合は通信したい VPC 同士をすべて Peering する必要があるので、VPC が増えるにつれて構成が非常に複雑になる
  • TGW なら、通信させたい VPC をすべて TGW に繋げばよい
• 設定次第では、TGW に接続したすべての VPC/VPN 間で通信させることができ、この構成の場合は非常に簡単に設定することができる

例えば 4 つの VPC を相互に通信させたい場合、VPC Peering だと下記のように、非常に複雑な構成になります。

これが TGW なら、Default route table association と Default route table propagation を有効な状態で構築してあげれば下記のように各 VPC を TGW に接続すれば OK です。

覚える必要がある要素

• アタッチメント
  • VPC と TGW を接続すること。LAN ケーブルを繋ぐような概念であり、これだけでは通信はできない
• ルートテーブル
  • TGW にデフォルトで 1 つ存在していて、複数作成可能
    • すべての接続された VPC/VPN で通信するならデフォルトのルートテーブルを使う
    • 個別に通信を制御したい場合は、別途ルートテーブルを作る
• ルートテーブルのアソシエーション
  • アタッチメントした VPC を特定のルートテーブルに紐づける
• ルートテーブルのプロパゲーション
  • アタッチメントした VPC からルートテーブルに経路を伝播する
  • 設定先のルートテーブルは指定できる
• ルートテーブルのスタティックルート
  • 個別のルート定義
  • アソシエートされていない VPC/VPN への経路も記述できる

図の簡略化のためスタティックルートを省いていますが、こんなイメージです。

補足事項

• TGW 作成時のみ、Default route table association や Default route table propagation の有効・無効が設定可能
• VPN や Direct Connect を繋ぎこむことも可能

おまけ：Azure の場合は Virtual WAN