はじめに
今回はTransit Gatewayの**リージョン間接続（TGW ピアリング）**を取り上げます。
前回の記事では、同一リージョン内での VPC 間接続と基本的なルート設計について整理しました。
↓前回の記事
https://qiita.com/pommny_dev/items/58f3fdd7cb8b97af6a61
今回はそれを一歩進めて、東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-3）を TGW ピアリングで接続し、本番環境 VPC 同士のみ疎通させる構成を検証します。
マルチリージョン冗長や災害対策環境の設計を行う上で必須となる知識であり、エンタープライズ環境でもよく登場するユースケースです。
今回の構成
- リージョン間：東京 ↔ 大阪
- 接続対象：本番環境 VPC - DR環境VPC間のみ（東京リージョンのテスト環境/ステージング環境は非接続）
- 接続方式：Transit Gateway Peering
構築ステップ（概観）
以下に構築のステップを示します。
-
各リージョンで Transit Gateway を作成・VPCと紐づけ
- 東京 / 大阪それぞれに TGW と関連リソース（RTB・アタッチメント）を用意
- 各VPCをそれぞれのリージョンのTransit Gatewayに接続
-
Transit Gateway Peering 作成
- 東京側 TGW から Peering Attachment を作成し、大阪側で承認
-
Peering・VPCアタッチメントルートテーブルの作成・紐づけ・更新
- 東京・大阪の両リージョンでルートテーブルを作成し、Peeringアタッチメントに関連付ける
- PeeringアタッチメントにVPCアタッチメント向けのルートを追加
- 東京・大阪の両リージョンのVPCアタッチメントにPeering向けのルートを登録
-
各 VPC のサブネットルートテーブルを更新
- 相手リージョンの CIDR 宛を TGW に向ける
-
疎通確認
- 本番⇔DR のみ通信可
① 各リージョンで Transit Gateway を作成・VPCと紐づけ
前回までで東京リージョン側のリソースは作成済みのため、今回は大阪リージョンに構築を進めます。
基本構成は東京リージョンと同様であるため詳細は割愛しますが、以下を対応します。
- VPC・サブネット・VPCルートテーブル・エンドポイント・疎通確認用サーバ作成
- TGW作成
- TGWアタッチメント・ルートテーブル作成、紐づけ
- TGW・VPCそれぞれのルート追加
↓Transit Gateway作成
↓TGWアタッチメント・ルートテーブル作成・関連付け
② Transit Gateway Peeringアタッチメントの作成・承認
Transit Gateway ピアリングアタッチメントとは？
Transit Gateway ピアリングアタッチメントは、別リージョンや別アカウントにある Transit Gateway 同士を接続するための仕組みです。
これを作成することで、東京リージョンの TGW と大阪リージョンの TGW を直結し、両リージョンに所属する VPC 間通信が可能になります。
東京リージョン側で Peering Attachment を作成
-
[Transit Gateway Attachments] から [Transit Gateway アタッチメントを作成] をクリック
アタッチメントタイプに Peering アタッチメント を選択します。
この Peering アタッチメントがリージョン跨ぎで通信する際の HUB となります。
- 接続先のリージョンとして ap-northeast-3（大阪） を指定
- 接続先の Transit Gateway ID を選択（大阪リージョンに作成したTGWのIDを入力）
- 必要に応じてタグを設定し、[アタッチメントを作成] を実行
これで東京リージョン側に Peering Attachment（ステータス: Pending Acceptance） が作成されます。
ただし、この時点では大阪側でピアリング接続を承認していないため、両リージョンのTGWはまだ接続されていません。
大阪リージョン側で Peering リクエストを承認
-
大阪リージョンのマネジメントコンソールに切り替え
-
[Transit Gateway Attachments] に進むと、ステータスが Pending Acceptance の Peering Attachment が表示されます
-
対象を選択し、[アクション] → [Transit Gateway アタッチメントを承認] をクリック
承認が完了すると、両リージョンの Peering Attachment が Available 状態になります。
-
大阪側（Available 状態）
-
東京側（Available 状態）
これで両リージョンの TGW が接続完了しました。
ただし、この時点ではまだルーティング設定を行っていないため、VPC 間の疎通はできません。
③ Peering・VPCアタッチメントルートテーブルの作成・紐づけ・更新
- Transit Gateway Peeringを通じてリージョン間のVPCのルーティングを行うために、
②で作成したPeeringアタッチメントにルートテーブルを紐づける必要があります。 - VPCアタッチメント用ルートテーブルと同様の方法にて、Peeringアタッチメント用ルートテーブルを作成し、Peeringアタッチメントに関連付けます。
続いて、各リージョンのVPC間が通信出来るように、TGWのルート設計を行います。
Peeringアタッチメント・VPCアタッチメントそれぞれで、以下の考え方でルートを追加します。
🔹 Peeringルートテーブルの考え方
- 役割：リージョンを超えてきたトラフィックを「どのローカルVPCへ届けるか」を決める
- 流れで言うと：
VPC ⇒ TGW ⇒ ピアリング ⇒ TGW ⇒ VPC
のうち、**「ピアリング ⇒ TGW 」**のルーティングを担当 - 具体的には：
- 東京側のPeering RTには「送信先：本番VPCのCIDR ターゲット：各VPCアタッチメント」
- 大阪側のPeering RTには「送信先：DR VPCのCIDR ターゲット：各VPCアタッチメント」
🔹 VPCアタッチメントルートテーブルの考え方
- 役割：ローカルVPCから出て行く通信をピアリングに向ける
- 流れで言うと：
VPC ⇒ TGW ⇒ ピアリング ⇒ TGW ⇒ VPC
のうち、「TGW ⇒ ピアリング」を担当 - 具体的には：
- 東京のVPC RTには「大阪DRのCIDR → Peeringアタッチメント」
- 大阪のVPC RTには「東京本番のCIDR → Peeringアタッチメント」
今回の要件
- 東京本番VPC ⇔ 大阪DR VPC のみ疎通させる
- 評価環境・ステージング環境のVPCは接続対象外とする
- リージョン間の通信はすべて TGW Peering 経由
- 不要な経路は Propagation を外すことで明示的に遮断
上記を踏まえて、以下の通りルート設計を行います。
Peeringアタッチメント
東京側のRTB
| 送信先(CIDR) | ターゲット（VPCアタッチメント） |
|---|---|
| 10.10.10.0/26 | 本番VPC① の TGWアタッチメント |
| 10.10.10.64/26 | 本番VPC② の TGWアタッチメント |
- 大阪リージョンから東京リージョンへの通信を、東京のどのVPCアタッチメントにルーティングするかを定義
- 評価(10.10.10.128/26)・ステージング(10.10.10.192/26)はルート未登録
大阪側のRTB
| 送信先(CIDR) | ターゲット（VPCアタッチメント） |
|---|---|
| 10.10.11.0/26 | DR VPC① の TGWアタッチメント |
| 10.10.11.64/26 | DR VPC② の TGWアタッチメント |
- 東京リージョンから大阪リージョンへの通信を、大阪のどのVPCアタッチメントにルーティングするかを定義
VPCアタッチメント
東京側 VPCアタッチメント RT（本番VPC①②用）
以下ルートを本番VPC①②それぞれのVPCアタッチメントRTにて追加する
| 送信先(CIDR) | ターゲット（Peering Attachment） |
|---|---|
| 10.10.11.0/26 | 東京のピアリングアタッチメント |
| 10.10.11.64/26 | 東京のピアリングアタッチメント |
- 大阪のVPCへの通信をピアリングアタッチメントにルーティング
- 評価/ステージング（10.10.10.128/26、10.10.10.192/26）向けルートは作成しない
大阪側 VPC RT（DR VPC①②用）
同様に以下ルートをDR VPC①②それぞれのVPCアタッチメントRTにて追加する。
| 送信先(CIDR) | ターゲット（Peering Attachment） |
|---|---|
| 10.10.10.0/26 | 大阪のピアリングアタッチメント |
| 10.10.10.64/26 | 大阪のピアリングアタッチメント |
- 東京のVPCへの通信をピアリングアタッチメントにルーティング
これで、各VPCのアタッチメントからピアリングを経由して、別リージョンのVPCアタッチメントへのルーティングが定義できました。
④ サブネットのルートテーブルの更新
- 最後に、VPC内からTGW向けのルーティングを定義するため、サブネットに紐づけているルートテーブルに疎通先のVPC向けのルートを追加していきます。
- ここでの考え方は、リージョン内のVPC間通信と同じ考え方でOKです。
- 疎通したい相手CIDRを送信先に、ターゲット＝自リージョンの Transit Gateway を指定します。
東京側（本番VPC①/② の各サブネットRT）
以下ルートを本番環境VPCのApp層のサブネットのルートテーブルにそれぞれ追加します。
| 送信先 (CIDR) | ターゲット |
|---|---|
| 10.10.11.0/26 | Transit Gateway（東京側 TGW） |
| 10.10.11.64/26 | Transit Gateway（東京側 TGW） |
- 対象は通信させたいサブネットのRT（今回だとApp層）
- 評価/ステージングVPCのサブネットRTには追加しない（非接続要件のため）
↓本番環境VPC App層サブネットのRT
大阪側（DR VPC①/② の各サブネットRT）
同様に、以下ルートをDR環境VPCのApp層のサブネットのルートテーブルにそれぞれ追加します。
| 送信先 (CIDR) | ターゲット |
|---|---|
| 10.10.10.0/26 | Transit Gateway（大阪側 TGW） |
| 10.10.10.64/26 | Transit Gateway（大阪側 TGW） |
↓DR環境VPC App層サブネットのRT
これで、エンドtoエンドでのルーティングが完了しました。
⑤ 疎通確認
実際にリージョン間で通信が通るのか疎通確認を実施します。
-
今回は 東京リージョンの本番環境VPC（10.10.10.0/26） 内に作成した疎通確認用のサーバから、
大阪リージョンのDR環境VPC（10.10.11.0/26・10.10.11.64/26） 内にそれぞれ作成したサーバに対して疎通出来るのか確認しました。 -
Fleet ManagerからサーバにRDP接続し、
test-netconnectionを実行。
疎通出来ていることが確認出来ました。
おわりに
今回は、Transit Gateway Peering を用いたリージョン間接続を構築し、
東京リージョンの本番VPCと大阪リージョンのDR VPC間のみを疎通させる構成を検証しました。
ポイントは以下。
- Peeringアタッチメントを作成し、双方のTGWで承認することでリージョン間接続を実現
- ルートテーブルの役割分担（VPC RT＝行きのルート、Peering RT＝戻りのルート）を明確化
- 評価・ステージング環境はルート未登録とすることで、本番⇔DRのみに通信を制御
- 各VPCサブネットのRTに相手リージョンのCIDRを追加し、エンドtoエンドの通信を確立
これにより、マルチリージョンを前提とした環境の設計・実装方法を整理できました。
次回予告
次回は、Transit Gatewayのクロスアカウント接続方法についてまとめます。
マルチアカウント環境における設計のポイントや運用上の考慮事項を整理します。