AWS Transit Gateway入門｜マルチVPC・オンプレ接続をハブ&スポーク設計で統制する実践ガイド

VPC数が増えてきたとき、VPC間の接続設計で悩んだことはないだろうか。
オンプレ時代はルーター1台でネットワーク全体を束ねていたのに、クラウドに移行するとVPCごとにピアリングを張る「フルメッシュ」構成になりがちで、VPCが5個を超えたあたりから設定の複雑さが一気に増す。VPCが10個あれば、ピアリング数は最大45本。これを全部手で管理するのは現実的ではない。

さらにオンプレとのVPN接続が絡むと、各VPCに仮想プライベートゲートウェイ（VGW）を立てる必要があり、管理コストが爆発する。

そこで登場するのが AWS Transit Gateway（TGW）だ。複数のVPCとオンプレミス環境をハブ&スポーク型で束ね、ルーティングを一元管理できるAWSのマネージドサービスである。

この記事では、Transit Gatewayの仕組みと設計パターンを、オンプレ経験者にもわかりやすく解説する。ルートテーブルの設計方法・料金の実態・よくある落とし穴までカバーするので、マルチVPC環境の構築を検討しているインフラエンジニアはぜひ参考にしてほしい。

なぜTransit Gatewayなのか？VPCピアリングとの根本的な違い

Transit Gatewayを理解するには、まず「VPCピアリングで何が辛いのか」を整理するところから始めたほうがわかりやすい。

1. VPCピアリングの限界

VPCピアリングは2つのVPCを1対1で繋ぐ仕組みだ。シンプルで分かりやすいが、VPC数が増えると問題が顕在化する。

・フルメッシュの爆発: N個のVPCを全結合するには N×(N-1)/2 本のピアリングが必要。VPC数が10なら45本。
・推移的ルーティング禁止: VPC-A → VPC-B → VPC-C という経路は通れない。A-C間に別途ピアリングが必要。
・オンプレ接続の増大: 各VPCにVGWが必要で、Direct ConnectのVIF数が上限に達しやすい。
・メンテナンスコスト: ピアリング接続ごとに両側のルートテーブルを更新する必要があり、変更管理が煩雑。

オンプレのルーター設計では「スター型（ハブ&スポーク）」が常識だ。Transit Gatewayはまさにそのハブにあたる。

2. Transit Gatewayが解決すること

Transit Gatewayを導入すると、すべてのVPCとオンプレはTGWに対してのみ接続すればよい。追加のVPCが増えてもTGWにアタッチするだけで既存ネットワークに接続できる。

・接続の簡素化: VPC数がN個あっても、ピアリング数は常にN本（TGWへの接続のみ）
・推移的ルーティングの実現: VPC-A → TGW → VPC-C が可能
・オンプレ接続の集約: VPNやDirect ConnectはTGWに一元化、各VPCのVGWが不要
・ルーティング制御: TGWルートテーブルで「どのVPCとどのVPCが通信できるか」を細かく制御

Transit Gatewayの基本構成を理解する

TGWを使った接続は、大きく3つのコンポーネントで成り立っている。アタッチメント・ルートテーブル・オンプレ接続の3点をしっかり理解することで、設計ミスを防げる。

1. アタッチメント（接続単位）

Transit Gatewayに「何を繋ぐか」の単位が アタッチメント だ。接続できる対象は以下の通り。

・VPCアタッチメント: AWSアカウント内のVPCを接続する最も基本的な形。VPCの各アベイラビリティゾーン（AZ）に1サブネットずつ指定する。
・VPNアタッチメント: Site-to-Site VPN経由でオンプレを接続。ECMP（等コストマルチパス）でActive-Active構成も可能。
・Direct Connectゲートウェイアタッチメント: AWS Direct Connect Gatewayを介して専用線接続。帯域保証・低レイテンシが必要な本番環境に向いている。
・TGWピアリングアタッチメント: 別リージョンまたは別アカウントのTGWとピアリング。グローバル展開時に使用。

VPCアタッチメントを作成するときのポイントを押さえておこう。

# AWS CLI: VPCアタッチメントの作成
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-0abc1234567890def \
  --vpc-id vpc-0abc1234567890001 \
  --subnet-ids subnet-0111111111111aaaa subnet-0222222222222bbbb \
  --options "ApplianceModeSupport=enable,DnsSupport=enable"

【注意】ApplianceModeSupport=enable は、ネットワーク仮想アプライアンス（ファイアウォール等）を経由させる構成で必須だ。有効にしないと戻りパケットが別のENIを経由してしまい、ステートフル検査が崩れる。ファイアウォールVPCを挟む設計では必ず有効化すること。

2. ルートテーブル設計

TGWの心臓部が Transit Gatewayルートテーブル だ。「どのアタッチメントからの通信が、どこに向かえるか」を定義する。

Transit Gatewayルートテーブルには2種類の操作がある。

・アソシエーション（association）: アタッチメントをルートテーブルに紐付ける。アタッチメントは1つのルートテーブルにのみアソシエートできる。
・プロパゲーション（propagation）: アタッチメントのCIDRをルートテーブルに自動伝播させる。複数のルートテーブルへ同時にプロパゲート可能。

シンプルな構成では、デフォルトルートテーブル1枚で全VPCが相互通信できる状態になる。しかし、本番環境ではセグメント分離が必要なことが多い。代表的な設計パターンを見ていこう。

パターン①: フラット構成（シンプル）
すべてのアタッチメントを1つのルートテーブルに集約。全VPCが相互通信できる。検証環境や小規模構成に向いている。

パターン②: セグメント分離（本番推奨）
「本番VPC用ルートテーブル」「開発VPC用ルートテーブル」を分けて、本番と開発の通信を遮断する。オンプレ接続用のルートテーブルをさらに独立させることで、必要なVPCだけオンプレに通信を許可できる。

パターン③: ファイアウォール経由（セキュリティ強化）
スポークVPCのデフォルトルートをTGWに向け、TGWからファイアウォールVPCに誘導してからインターネットや他VPCへ転送する。全通信をAWS Network Firewallで検査できる。

# AWS CLI: ルートテーブルの作成と操作（本番用）
# 本番用ルートテーブル作成
aws ec2 create-transit-gateway-route-table \
  --transit-gateway-id tgw-0abc1234567890def \
  --tag-specifications 'ResourceType=transit-gateway-route-table,Tags=[{Key=Name,Value=prod-rtb}]'

# 本番VPCアタッチメントをアソシエート
aws ec2 associate-transit-gateway-route-table \
  --transit-gateway-route-table-id tgw-rtb-0111111111111111 \
  --transit-gateway-attachment-id tgw-attach-0aaaaaaaaaaaaaa01

# 本番VPCのCIDRをプロパゲート
aws ec2 enable-transit-gateway-route-table-propagation \
  --transit-gateway-route-table-id tgw-rtb-0111111111111111 \
  --transit-gateway-attachment-id tgw-attach-0aaaaaaaaaaaaaa01

重要なのは、VPC側のルートテーブルにもTGWへのルートを追加することだ。TGW側にルートを書いても、VPC側のルートテーブルが更新されていなければパケットはTGWに向かわない。これを忘れる初心者が非常に多い。

# VPCルートテーブルにTGWへのルートを追加（必須）
aws ec2 create-route \
  --route-table-id rtb-0abc1234567890aaa \
  --destination-cidr-block 10.0.0.0/8 \
  --transit-gateway-id tgw-0abc1234567890def

3. オンプレミス接続（Site-to-Site VPN・Direct Connect）

オンプレからTGWに接続する方法は2つある。

・Site-to-Site VPN: インターネット経由の暗号化トンネル。設定が比較的簡単で、冗長化（2本のIPsecトンネル）が標準で提供される。帯域は1接続あたり1.25Gbpsが上限。TGWのECMPを有効にすることで複数のVPN接続を並列化できる。
・AWS Direct Connect + Direct Connect Gateway: 専用線接続。帯域保証・低レイテンシが必要な本番環境向け。Direct Connect GatewayをTGWにアタッチすることで、複数のVPCにアクセスできる。

オンプレのルーター担当者には「TGWはAWS側の中央ルーター」と説明すると伝わりやすい。BGPでルート交換を行う点もオンプレのルーティング設計と同じ感覚で扱える。

料金の仕組みとコスト試算

Transit Gatewayの料金は2種類の課金から構成される（2026年5月時点、東京リージョン・ap-northeast-1）。

・アタッチメント時間料金: $0.07/時間 × アタッチメント数。VPC1個につき1アタッチメント。常時接続なら1VPCあたり約$50/月。
・データ処理料金: $0.02/GB（TGWを通過するデータ量に対して課金）。

試算例: VPC5個 + オンプレVPN1本の構成（月間データ転送500GB）

VPCピアリングはデータ転送量のみの課金だが、TGWはアタッチメント時間料金が加わる。VPCが2～3個程度の小規模構成では、TGWのほうが割高になることもある。VPC数が増えるにつれて管理コストのメリットが料金差を上回るケースが多い。

また、同じAZ内での通信はデータ転送料が安い。AZをまたぐとAWSのクロスAZ転送料（$0.01/GB）も加わるため、アタッチメントのサブネットはAZ分散配置しつつ、重要なデータは同AZ内で完結させる設計が望ましい。

【コスト削減のヒント】 開発・検証VPCを夜間や週末に不使用にしてアタッチメントを外せば、その時間帯の料金をゼロにできる。自動化スクリプトを組み合わせてコスト最適化するチームも多い。

応用・実務Tips

【Tip 1】AWSマルチアカウント環境でのRAM共有

複数のAWSアカウントを運用しているなら、TGWを AWS Resource Access Manager（RAM） で共有することでアカウントをまたいだ接続が可能になる。共有されたTGWに対して、各アカウントがVPCアタッチメントを作成できる。

エンタープライズ環境でよくある設計は「ネットワーキング専用アカウントでTGWを管理し、各事業部のアカウントのVPCをアタッチする」パターンだ。ネットワーク管理者が一元的にルーティングを統制できる。AWS Organizationsと組み合わせれば、RAM共有の受諾を自動化できる。

【Tip 2】ECMPでVPN帯域を拡張する

Site-to-Site VPNの帯域上限は1接続あたり1.25Gbps。これを超えたい場合、TGWのECMP（Equal Cost Multi-Path）を有効にして複数のVPN接続を並列で使用できる。

# ECMP有効化（TGW作成時オプション）
aws ec2 create-transit-gateway \
  --options "VpnEcmpSupport=enable,DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable"

DefaultRouteTableAssociation=disable と DefaultRouteTablePropagation=disable を設定することで、デフォルトルートテーブルへの自動追加を抑制し、意図しないルーティングを防げる。本番環境でのTGW作成時はこの設定を強く推奨する。

【Tip 3】AWS Network FirewallをTGWと組み合わせる

全VPCの通信をAWS Network Firewallで検査したい場合、「ファイアウォールVPC」を独立させてすべての通信をそこに向けるアーキテクチャが定番だ。

・スポークVPCのデフォルトルート（0.0.0.0/0）をTGWに向ける
・TGWのルートテーブルでトラフィックをファイアウォールVPCに向ける
・ファイアウォールで検査後、インターネットまたは宛先VPCへ転送

このパターンでは ApplianceModeSupport=enable が必須。有効化を忘れると戻りパケットの非対称ルーティングが発生し、ファイアウォールの接続が頻繁に切断される。

【Tip 4】マルチリージョン展開でのTGWピアリング

東京リージョンのTGWと大阪リージョンのTGWをピアリングアタッチメントで接続することで、リージョン間のプライベート通信路を確立できる。AWSのバックボーンネットワークを経由するため、インターネットより安定した帯域が得られる。

ただし、TGWピアリングの静的ルートはBGPで自動伝播されない点に注意が必要だ。リージョン間のルートは手動で静的エントリを追加する必要がある。

よくあるトラブルと対処法

【トラブル1】VPC側のルートテーブルを更新し忘れた

症状: TGWを作成してアタッチメントも作ったのに、VPC間の疎通が取れない。
原因: VPCのルートテーブルに「宛先CIDR → TGW」のエントリが追加されていない。TGWはルーティングを引き受けるだけで、VPC側は自分でTGWへのルートを書く必要がある。
対処: 各VPCのルートテーブルに宛先CIDRとTGW IDを追加する。複数のサブネットを持つVPCでは、すべてのサブネットのルートテーブルを確認すること。

【トラブル2】アタッチメントが「pending」のまま進まない

症状: VPCアタッチメントを作成したが、ステータスが「pending」のまま「available」にならない。
原因: 指定したサブネットのAZでTGWがサポートされていないか、IAM権限が不足している。
対処: TGWの作成リージョンとサブネットのAZを確認する。また、アタッチメント作成に必要なIAM権限（ec2:CreateTransitGatewayVpcAttachment）が付与されているか確認する。

【トラブル3】VPNのBGPセッションが確立しない

症状: TGWにVPNアタッチメントを作成したが、オンプレとのBGPが上がらない。
原因: オンプレのルーター設定（BGP ASN・BGP認証キー・BGPピアIPアドレス）がAWSのカスタマーゲートウェイ設定と不一致。
対処: AWSコンソールからVPN接続の設定ファイルをダウンロードし、オンプレのルーターメーカー別の設定サンプルに従って設定する。Cisco IOS・Juniper JunOS・FortigateなどのルーターはAWSコンソールから設定ファイルをダウンロードできる。

【トラブル4】クロスアカウントのアタッチメントが作れない

症状: RAMでTGWを共有したが、別アカウントからアタッチメントが作れない。
原因: RAMの共有設定後、受信アカウント側でリソース共有の受諾が完了していない。AWSアカウントがAWS Organizationsに参加していない場合は手動受諾が必要。
対処: 受信アカウントのRAMコンソールで「リソース共有への招待」を受諾する。AWS Organizations経由の共有なら自動承認される。

【トラブル5】クロスAZ通信でコストが予想より増えた

症状: TGW導入後、月次のデータ転送コストが想定より高くなった。
原因: TGWのアタッチメントサブネットとEC2インスタンスが異なるAZにあり、クロスAZのデータ転送料が加算されている。
対処: アタッチメントのサブネットをEC2インスタンスと同じAZに配置する。AZ-a・AZ-cの両方にアタッチメントを作っておき、EC2インスタンスが近いAZのサブネットを使うよう設計する。

本記事のまとめ

AWS Transit Gatewayは、VPC数が増えてきたマルチVPC環境の接続設計を根本から変えるサービスだ。オンプレ時代の「ハブ&スポーク型ルーティング」をそのままクラウドに持ち込めるため、ネットワーク設計の考え方はそのままにスケールできる。

クラウド上のLinuxサーバー構築や運用の基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説している。EC2インスタンスのサーバー設定と合わせて学ぶことで、ネットワーク設計の全体像がより具体的につかめるはずだ。