AWS Transit Gateway

AWS Transit Gateway は、多数の VPC とオンプレミスネットワークをハブ&スポーク構成で相互接続する、リージョン単位のマネージド中継ルータです。各ネットワークを Transit Gateway という一点に接続するだけで相互到達性を確立でき、接続数の増加に伴って配線が爆発的に複雑化する問題を解消します。

解決する課題

VPC を VPC ピアリングだけで相互接続すると、接続関係はフルメッシュとなり、VPC が N 個あれば必要なピアリング数は N かける N から 1 を引いた数を 2 で割った数に達します。VPC が増えるほど設定・管理・ルートテーブルの維持が指数的に煩雑になり、しかも VPC ピアリングは推移的ルーティングに対応しないため、A と B、B と C をつないでも A から C へは通信できません。

オンプレミスとの接続も同様で、各 VPC に個別の Virtual Private Gateway を立てて VPN や Direct Connect を張ると、拠点側の管理対象が VPC の数だけ増えていきます。

Transit Gateway はこれらをハブに集約することで、各ネットワークを 1 本だけハブへ接続すればよい構成に変え、推移的なルーティングと一元的なルート管理を実現します。

主要概念と用語

• アタッチメント: Transit Gateway に接続する対象を表す単位。VPC、VPN、Direct Connect ゲートウェイ、別の Transit Gateway とのピアリング、Connect などの種類がある。
• Transit Gateway ルートテーブル: アタッチメントごとに関連付けるルーティングテーブル。複数持てるため、アタッチメントを別々のルートテーブルに割り当てることでネットワークをセグメント分離できる。
• アソシエーション: アタッチメントを 1 つのルートテーブルに関連付ける設定。あるアタッチメントからの通信がどのルートテーブルを参照するかを決める。
• ルートプロパゲーション: アタッチメント側のルート情報を Transit Gateway ルートテーブルへ自動的に伝播させる仕組み。VPN や Direct Connect では動的ルーティングと組み合わせて使う。
• アプライアンスモード: ステートフルなインスペクション用アプライアンスを経由させる際に、同一フローを同じアベイラビリティーゾーンへ固定し、非対称ルーティングによる通信断を防ぐオプション。
• Transit Gateway ピアリング: 異なるリージョンやアカウントの Transit Gateway 同士を接続し、グローバルなネットワークを構成する機能。
• Transit Gateway Connect: GRE と動的ルーティングプロトコルを用いて、SD-WAN 機器などのサードパーティ仮想アプライアンスを高帯域で接続するアタッチメント種別。

仕様・制限・クォータ

Transit Gateway はリージョン単位のリソースで、同一リージョン内の VPC を高い帯域で接続します。VPC アタッチメントは VPC のサブネット内に配置され、アタッチメントが存在するアベイラビリティーゾーン内のリソースへルーティングされるため、可用性を確保するには複数のアベイラビリティーゾーンにアタッチメントのサブネットを用意することが推奨されます。

1 つの Transit Gateway に接続できるアタッチメント数や、ルートテーブルあたりのルート数、ピアリング数などにはアカウント単位のクォータが定められています。多くは Service Quotas から緩和申請が可能なものと、ハードリミットとして固定されているものがあるため、大規模設計時には最新のドキュメントで上限を確認してください。帯域はアタッチメント単位で上限があり、より高い帯域が必要な場合は等コストマルチパスを利用して複数経路に分散します。

なお、VPC アタッチメント経由のフレームではジャンボフレームに関する上限があり、想定するパケットサイズが対応範囲に収まるかを設計段階で確認することが重要です。

内部の仕組み

Transit Gateway は AWS が運用するスケーラブルな分散ルータとして実装され、利用者はルーティングの論理構成だけを管理します。VPC アタッチメントを作成すると、指定したサブネット内に Transit Gateway 用のネットワークインターフェースが配置され、そのアベイラビリティーゾーンのトラフィックがここを通って Transit Gateway へ入ります。

各アタッチメントは 1 つのルートテーブルにアソシエートされ、通信が発生すると送信元アタッチメントに関連付いたルートテーブルを参照して次の転送先アタッチメントが決定されます。ルートは静的に登録するか、VPN や Direct Connect、ピアリングからプロパゲーションによって動的に学習します。

ルートテーブルを複数に分けてアソシエーションとプロパゲーションを設計することで、たとえば本番系と検証系を相互に到達不可にしたり、共有サービス用 VPC だけは全セグメントから到達可能にする、といったセグメンテーションを表現できます。これがフラットな単一ルートテーブルとの大きな違いです。

設計パターン / ベストプラクティス

代表的な構成は、すべての VPC を 1 つの Transit Gateway に接続し、共有サービス VPC やインスペクション用 VPC を中央に置くハブ&スポークです。トラフィックを集中点で検査したい場合は、中央 VPC にファイアウォールや NAT を配置し、Transit Gateway ルートテーブルで通信を強制的にそこへ通します。

マルチアカウント環境では、AWS Resource Access Manager を使って Transit Gateway を組織内の他アカウントへ共有し、各アカウントの VPC を同一ハブへアタッチします。ネットワークの所有と運用を一元化しつつ、アカウント境界を保てます。

セグメント分離が必要なら、用途ごとにルートテーブルを分け、アソシエーションとプロパゲーションを明示的に設計します。ステートフルなインスペクションアプライアンスを経由させる構成では、アプライアンスモードを有効化して同一フローを同一アベイラビリティーゾーンに固定し、非対称ルーティングを防ぎます。

運用・監視

Transit Gateway はアタッチメントやルートテーブルの状態、データ転送量などのメトリクスを Amazon CloudWatch に発行します。アタッチメント単位の受信・送信バイト数やパケットドロップを監視し、帯域上限への到達やルーティング不一致によるドロップを早期に検知することが運用上重要です。

通信フローの可視化やトラブルシューティングには Transit Gateway のフローログを利用し、どのアタッチメント間でどれだけの通信が行われているかを把握します。ルーティングの問題切り分けには Reachability Analyzer や、Transit Gateway ルートテーブルの経路検索機能が役立ちます。

ルート構成は Infrastructure as Code で管理し、アソシエーションとプロパゲーションの変更を履歴として残すと、セグメント間の到達性が意図せず変わる事故を防げます。

コスト

Transit Gateway の課金は大きく分けて、アタッチメントが接続されている時間に対する時間課金と、処理したデータ量に対するデータ処理課金の 2 種類で構成されます。VPC ピアリングがピアリング自体に時間課金を持たないのに対し、Transit Gateway はアタッチメントごとに継続的な時間課金が発生する点が設計上の判断材料になります。

そのため、ごく少数の VPC を恒常的に接続するだけなら VPC ピアリングの方が安価になることがあり、接続数が増えて管理性や推移的ルーティングの価値が上回る規模で Transit Gateway が有利になります。リージョン間ピアリングではリージョンをまたぐデータ転送料も加わるため、トラフィック量を見積もって比較してください。具体的な単価は変動するため、最新の料金ページで確認することが前提です。

セキュリティ

Transit Gateway 自体はセキュリティグループを持たないため、アクセス制御は接続される各 VPC のセキュリティグループ、ネットワーク ACL、そして Transit Gateway ルートテーブルによる経路制御の組み合わせで実現します。あるセグメントから別セグメントへの到達を遮断したい場合は、ルートを登録しないか、ルートテーブルを分離して相互にプロパゲーションしないことで論理的に分離します。

中央でのトラフィック検査が要件であれば、インスペクション VPC を経由させてファイアウォールでフィルタリングします。複数アカウントへ共有する際は、RAM の共有範囲を組織や組織単位に限定し、不要なアカウントからアタッチメントが作られないよう IAM ポリシーで権限を絞ります。すべてのアタッチメントとルート変更は CloudTrail で記録し、監査可能にしておきます。

Well-Architected の観点

信頼性の観点では、アタッチメントを複数のアベイラビリティーゾーンに分散させ、VPN や Direct Connect を冗長化することで単一障害点を排除します。Transit Gateway 自体はリージョン内で可用性が確保されたマネージドサービスであり、利用者は接続側の冗長化に注力します。

運用上の優秀性の観点では、ハブに集約することでルーティングと接続の管理点が 1 か所にまとまり、変更とトラブルシューティングが容易になります。ルート構成をコード化し、メトリクスとフローログで継続的に状態を可視化することが、運用負荷を下げる鍵になります。

試験で問われるポイント

関連サービス・比較

最も比較されるのは VPC ピアリングです。少数の VPC を 1 対 1 で恒久接続するなら VPC ピアリングが簡潔かつ低コストですが、接続数が増えて推移的ルーティングや一元管理が必要になると Transit Gateway が適します。

ハンズオン / CLI例

以下は Transit Gateway を作成し、VPC をアタッチして、別ネットワークへの静的ルートを 1 本登録する最小の流れの例です。リソース ID は実際の値に置き換えてください。

# Transit Gateway を作成
aws ec2 create-transit-gateway \
  --description "hub-tgw" \
  --options DefaultRouteTableAssociation=enable,DefaultRouteTablePropagation=enable

# VPC をアタッチ（複数 AZ のサブネットを指定して冗長化）
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-0123456789abcdef0 \
  --vpc-id vpc-0123456789abcdef0 \
  --subnet-ids subnet-0aaa subnet-0bbb

# Transit Gateway ルートテーブルへ静的ルートを 1 本追加
aws ec2 create-transit-gateway-route \
  --transit-gateway-route-table-id tgw-rtb-0123456789abcdef0 \
  --destination-cidr-block 10.20.0.0/16 \
  --transit-gateway-attachment-id tgw-attach-0123456789abcdef0