Transit Gatewayのマルチリージョン設計とEdge-to-Edge制限の理解

概要

Transit Gatewayはリージョン単位のリソースであり、ピアリングでリージョン間のVPC通信は可能ですが、VPN/Direct ConnectのトラフィックはピアリングをまたげないEdge-to-Edge制限があります。本記事では、この制限の仕組みと適切なマルチリージョン設計について解説します。

目次

1. Transit Gatewayの基本概念とスコープ
2. リージョン間接続：Transit Gatewayピアリング
3. Edge-to-Edge制限とは何か
4. マルチリージョン設計のベストプラクティス
5. 料金体系の理解
6. 終わりに

1. Transit Gatewayの基本概念とスコープ

Transit Gatewayとは

AWS Transit Gateway（TGW）は、複数のVPCやオンプレミス環境を相互接続するネットワークハブとして機能するサービスです。従来のVPCピアリングで複雑になっていたメッシュ構成を、中央ハブを経由するシンプルな構成に変えることができます。

リソースのスコープを理解する

AWSネットワークリソースの地理的スコープを理解することは、適切なアーキテクチャ設計の基礎となります。

リソース	スコープ	説明
VPC	リージョン単位	単一リージョン内で複数のAZにまたがる
サブネット	AZ単位	単一のAZ内に存在
Transit Gateway	リージョン単位	同一リージョン内のリソースのみアタッチ可能
Transit Gatewayアタッチメント	AZ単位	各AZに1つのENI（Elastic Network Interface）を配置
Direct Connect Gateway	グローバル	複数リージョンのTGW/VPCと関連付け可能（最大10個）
Site-to-Site VPN	リージョン単位	特定リージョンのTGWまたはVGWに終端

Transit Gatewayはリージョン単位のリソースであり、同一リージョン内のVPCのみをアタッチできます。つまり、東京リージョン（ap-northeast-1）のTGWに大阪リージョン（ap-northeast-3）のVPCを直接アタッチすることはできません。

アタッチメントの種類

Transit Gatewayには複数のアタッチメントタイプがあります。

アタッチメントタイプ	接続先	用途
VPC Attachment	VPC	VPCとTGWを接続
VPN Attachment	Site-to-Site VPN	オンプレミスとIPsec VPN接続
Direct Connect Attachment	Direct Connect Gateway	専用線でオンプレミス接続
Transit Gateway Connect	SD-WAN/仮想アプライアンス	BGP over GREで接続
Peering Attachment	別のTransit Gateway	リージョン内/リージョン間のTGW接続

各アタッチメントは、AZごとに1つのENIをサブネットに配置します。これにより、AZ単位での高可用性が実現されます。

2. リージョン間接続：Transit Gatewayピアリング

ピアリングの仕組み

異なるリージョンにある Transit Gateway を接続するには、Transit Gateway ピアリングを使用します。これは、VPCピアリングと似た概念で、2つのTGW間にピアリング接続を確立します。

ピアリングの特徴は以下のとおりです。

• リージョン内ピアリング（Intra-region peering）：同一リージョン内の異なるTGW間の接続
• リージョン間ピアリング（Inter-region peering）：異なるリージョンのTGW間の接続
• IPv4/IPv6の両方をサポート：最新のIPプロトコルに対応
• 静的ルートのみ：BGPによる動的ルート伝播は非対応
• 暗号化通信：リージョン間トラフィックはAES-256で暗号化

ピアリング設定の手順

ピアリング接続を確立するには、以下の手順が必要です。

1. ピアリングアタッチメントの作成（リクエスト側）

   • リクエスタTGWで、接続先リージョンと接続先TGW IDを指定
   • 同一アカウント内でも承認が必要

2. ピアリングリクエストの承認（アクセプタ側）

   • アクセプタTGW側で、保留中のリクエストを承認
   • ステータスがavailableになるまで待機

3. ルートテーブルの設定（両側）

   • 各TGWのルートテーブルに静的ルートを追加
   • 宛先CIDR: 相手リージョンのVPC CIDR
   • ターゲット: ピアリングアタッチメント

4. VPCルートテーブルの設定（両側）

   • 各VPCのルートテーブルに静的ルートを追加
   • 宛先CIDR: 相手リージョンのVPC CIDR
   • ターゲット: 自リージョンのTransit Gateway

AWS CLI v2での設定例（東京リージョンから大阪リージョンへのピアリング作成）：

# 東京リージョンでピアリングアタッチメントを作成
aws ec2 create-transit-gateway-peering-attachment \
  --transit-gateway-id tgw-tokyo123456789 \
  --peer-transit-gateway-id tgw-osaka987654321 \
  --peer-region ap-northeast-3 \
  --region ap-northeast-1

# 大阪リージョンで承認
aws ec2 accept-transit-gateway-peering-attachment \
  --transit-gateway-attachment-id tgw-attach-abcdef123456 \
  --region ap-northeast-3

重要な注意点として、ピアリング接続では動的ルート伝播（BGP）が使えません。すべてのルートは静的に設定する必要があります。

3. Edge-to-Edge制限とは何か

制限の内容

Transit Gateway ピアリングには重要な制限があります。それがEdge-to-Edge routing制限です。AWS公式ドキュメント ( https://aws.amazon.com/transit-gateway/faqs/ ) では、この制限について次のように説明されています。

ピアリングアタッチメント経由では、以下のエッジ接続を通過するトラフィックをルーティングできません：

• Site-to-Site VPN接続
• Direct Connect接続
• Internet Gateway
• NAT Gateway

これは何を意味するのでしょうか。具体例で見てみましょう。

不可能な構成例

次のような構成は実現できません。

オンプレミス → VPN → TGW-A（東京） → ピアリング → TGW-B（大阪） → VPC-B

この場合、VPNからのトラフィックはTGW-Aで終端され、ピアリング越しにTGW-Bへ転送することはできません。同様に、以下の構成も不可能です。

オンプレミス → Direct Connect → TGW-A（東京） → ピアリング → TGW-B（大阪） → VPC-B

可能な構成例

一方で、VPC間の通信はピアリング経由で可能です。

VPC-A（東京） → TGW-A（東京） → ピアリング → TGW-B（大阪） → VPC-B（大阪）

この構成は正常に動作します。ピアリングアタッチメントは、VPC Attachmentから送信されたトラフィックの転送をサポートしています。

なぜこの制限があるのか

この制限は、AWS Transit Gatewayのアーキテクチャ設計に基づいています。ピアリングアタッチメントは、シンプルな静的ルーティングのみをサポートし、複雑な動的ルーティングやエッジサービスの連鎖的な利用を意図的に制限しています。

これにより、予測可能なルーティング動作と、セキュリティ境界の明確化を実現しています。

4. マルチリージョン設計のベストプラクティス

Edge-to-Edge制限を理解した上で、適切なマルチリージョン設計を行う必要があります。

パターン1：VPC間通信のみ必要な場合

複数リージョンのVPC同士だけを接続したい場合は、Transit Gatewayピアリングがシンプルな解決策です。

構成：

1. 各リージョンにTransit Gatewayを作成
2. VPCをそれぞれのTGWにアタッチ
3. TGW同士をピアリング接続
4. 各TGWのルートテーブルに相手VPCのCIDRを静的ルートで追加

適用シナリオ：

• マルチリージョンのマイクロサービス間通信
• 災害対策（DR）環境でのデータ同期
• リージョン間の開発/ステージング環境の接続

パターン2：オンプレミスから複数リージョンへVPN接続

オンプレミスから複数リージョンのVPCへアクセスしたい場合、各リージョンに個別のVPN接続が必要です。

構成：

1. 各リージョンのTGWに対して、個別にSite-to-Site VPNを作成
2. VPC間通信が必要なら、TGW間をピアリング接続（オンプレトラフィックは流さない）
3. オンプレミス側のカスタマーゲートウェイで、リージョンごとにVPNトンネルを管理

重要な注意点：

• VPNトラフィックはピアリングをまたげないため、東京リージョンへのVPNで大阪リージョンのVPCへは直接到達できません
• 各リージョンへの到達性を確保するには、それぞれのリージョンに専用のVPN接続を確立する必要があります

AWS CLI v2での設定例（東京リージョンへのVPN接続作成）：

# Customer Gatewayの作成
aws ec2 create-customer-gateway \
  --type ipsec.1 \
  --bgp-asn 65000 \
  --public-ip 203.0.113.1 \
  --region ap-northeast-1

# Site-to-Site VPN接続の作成
aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-abc123 \
  --transit-gateway-id tgw-tokyo123456789 \
  --region ap-northeast-1

パターン3：Direct Connectで複数リージョンへ接続

Direct Connectを使用する場合、**Direct Connect Gateway（DXGW）**を活用することで、1本の物理回線から複数リージョンへ分配できます。

構成：

1. Direct Connect Gatewayを作成（グローバルリソース）
2. 物理回線からTransit Virtual Interface（VIF）を作成し、DXGWに関連付け
3. DXGWを各リージョンのTransit Gatewayに関連付け（最大10個まで）
4. VPC間通信が必要なら、TGW間をピアリング接続

制限事項：

• DXGWから各リージョンのTGWまでしかトラフィックを転送できません
• TGWピアリング越しにDirect Connectのトラフィックは流せません
• つまり、東京TGWに到達したDXトラフィックを、ピアリング経由で大阪TGWへ転送することは不可能です

AWS公式ドキュメント ( https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-dcg-attachments.html ) では、Direct Connect GatewayとTransit Gatewayの統合について詳しく説明されています。

パターン4：ハイブリッド構成（VPN + Direct Connect）

本番環境ではDirect Connect、バックアップとしてVPNを使用するハイブリッド構成も一般的です。

構成：

1. 各リージョンにDirect Connect Gateway経由でDXを接続
2. 各リージョンに個別のSite-to-Site VPNをバックアップとして接続
3. BGPを使用して、Direct Connect側の経路を優先（AS Path PrepenまたはMED値で制御）

ルート優先順位：
AWS Transit Gatewayでは、同じCIDRの経路が複数存在する場合、以下の優先順位でルートを評価します。

1. 最長プレフィックスマッチ（より具体的なCIDR）
2. 静的ルート
3. Direct Connect Gateway（BGP AS_PATH、MED値で評価）
4. VPN接続（BGP AS_PATH、MED値で評価）

AWS公式ドキュメント ( https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/how-transit-gateways-work.html ) では、ルート評価順序について『一部のアタッチメントは、BGP 経由でルートアドバタイズをサポートしています。同じ CIDR を持つルートと、同じアタッチメントタイプのルートの場合、ルートの優先度は BGP 属性によって制御されます』と説明されています。

5. 料金体系の理解

Transit Gatewayの料金は、主にアタッチメント時間課金とデータ処理課金の2つで構成されます。

基本料金（2025年12月時点、東京リージョン）

項目	料金
アタッチメント時間課金	0.07 USD/時間/アタッチメント
データ処理料金	0.02 USD/GB

※料金は変動する可能性があります。最新情報はAWS公式料金ページ ( https://aws.amazon.com/transit-gateway/pricing/ ) をご確認ください。

アタッチメント時間課金

VPC、VPN、Direct Connect、ピアリングなど、すべてのアタッチメントタイプに対して時間単位で課金されます。

計算例：

• VPC Attachment: 3個
• VPN Attachment: 1個
• Peering Attachment: 1個

月額料金 = 5アタッチメント × 0.07 USD/時間 × 730時間（1ヶ月） = 255.5 USD

データ処理料金

Transit Gatewayを経由するデータ1GBあたり0.02 USDが課金されます。

重要な注意点：

• VPC、VPN、Direct ConnectからTGWへ送信されたデータに課金
• ピアリングアタッチメントからTGWへ送信されたデータには課金されない
• つまり、リージョン間のピアリング越しにデータを受信する側のTGWでは、データ処理料金は発生しません

リージョン間ピアリングの料金例

AWS公式料金ページ ( https://aws.amazon.com/transit-gateway/pricing/ ) の例では、以下のように説明されています。

シナリオ：
バージニア北部リージョンのVPCからEC2インスタンスが1GBのデータを送信し、TGW-1（バージニア北部）を経由してピアリング接続でTGW-2（オレゴン）へ、そしてオレゴンリージョンのVPCへ到達する場合

課金内訳：

1. TGW-1でのデータ処理料金: 0.02 USD（送信元VPCからTGW-1への送信）
2. リージョン間データ転送料金: 0.02 USD（バージニア→オレゴンへのアウトバウンド転送）
3. TGW-2でのデータ処理料金: 0 USD（ピアリングアタッチメントからの受信のため課金なし）
4. リージョン間インバウンド転送: 0 USD（AWSリージョン間のインバウンドは無料）

合計: 0.04 USD

東京リージョン（ap-northeast-1）の料金も基本的に同様の構造ですが、リージョン間データ転送料金は送信元・送信先リージョンの組み合わせによって異なります。

コスト最適化のヒント

1. アタッチメント数の最小化：不要なアタッチメントは削除する
2. データ転送量の監視：CloudWatch Metricsでバイト数を追跡
3. VPC Peeringとの比較検討：接続数が少ない場合はVPC Peeringも選択肢
4. コスト配分タグの活用：アタッチメントにタグを付与して部門別のコスト配分を実現

注意点として、Transit Gatewayにコスト配分タグを付与しても、VPCごとのデータ処理料金を分離することはできません。タグで追跡できるのは、アタッチメント時間課金とTransit Gateway全体のデータ処理総量のみです。

6. 終わりに

Transit Gatewayは、AWSにおける大規模ネットワーク管理を大幅に簡素化する強力なサービスです。しかし、マルチリージョン環境で利用する際には、以下の重要なポイントを理解しておく必要があります。

重要なポイントの再確認：

1. Transit Gatewayはリージョン単位のリソースであり、同一リージョン内のVPCのみアタッチ可能
2. リージョン間はピアリング接続で、VPC↔VPC通信は可能
3. Edge-to-Edge制限により、VPN/Direct Connectのトラフィックはピアリングをまたげない
4. マルチリージョンでオンプレミスと接続する場合は、各リージョンに個別のVPN/DX接続が必要
5. Direct Connect Gatewayを活用することで、1本の回線から複数リージョンへ分配可能（ただし各TGWまでが終端）

次のステップ：

• 実際の環境でTransit Gatewayピアリングを試してみる
• Network ManagerのRoute Analyzerで経路を可視化・デバッグする
• CloudWatch Metricsでデータ転送量とコストを監視する
• 災害対策（DR）環境の構築にマルチリージョンTGWを活用する

マルチリージョン設計では、Edge-to-Edge制限を正しく理解することが、適切なアーキテクチャ選択の鍵となります。本記事で紹介したパターンを参考に、要件に最適な構成を検討してください。

参考文献・参考サイト

AWS公式ドキュメント

• 「AWS Transit Gateway の Transit Gateway ピアリングアタッチメント」AWS Documentation, https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-peering.html
• 「AWS Transit Gateway の仕組み」AWS Documentation, https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/how-transit-gateways-work.html
• 「Amazon VPC Transit Gateway クォータ」AWS Documentation, https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/transit-gateway-quotas.html
• 「AWS Transit Gateway pricing」AWS, https://aws.amazon.com/transit-gateway/pricing/
• 「AWS Transit Gateway FAQs」AWS, https://aws.amazon.com/transit-gateway/faqs/
• 「AWS Direct Connect | FAQ」AWS, https://aws.amazon.com/directconnect/faqs/

技術ブログ・記事

• たかくに「Transit GatewayとVPC Peeringを比較してみた」DevelopersIO, https://dev.classmethod.jp/articles/different-from-vpc-peering-and-transit-gateway-japanese/
• 片方「Transit Gateway (ピアリング) を利用して、東京リージョンの EC2 インスタンスからバージニア北部リージョンの IAM VPC エンドポイントへ AWS CLI コマンド実行してみた」DevelopersIO, 2025年7月1日, https://dev.classmethod.jp/articles/transit-gateway-peer-ec2-tokyo-to-iam-vpc-endpoint-virginia/
• 佐竹陽一「Direct Connect と VPN をフェイルオーバーのために併用する場合の Transit Gateway ルート設定」サーバーワークスエンジニアブログ, 2021年10月5日, https://blog.serverworks.co.jp/transit-gateway-route-tables-for-dx-and-vpn-failover
• shikoan「AWS Transit Gatewayでのマルチリージョン接続とRoute Analyzer活用」Shikoan's ML Blog, 2025年3月8日, https://blog.shikoan.com/transit_gateway_peering_route_analyzer/
• 「AWS Black Belt Online Seminar AWS Transit Gateway」AWS, 2025年1月, https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2025_AWS-Transit-Gateway-deepdive_0122_v1.pdf