はじめに
社内のプロジェクトで AWS Transit Gateway を利用したVPC間接続を設計・構築する機会がありました。
検証から本番適用に至る過程で、設計の勘所やハマりどころを整理する良いきっかけとなったため、シリーズ記事としてまとめていきたいと思います。
本シリーズでは、私が経験した基本のVPC間接続から始めて、TGW活用法としてリージョン間接続やマルチアカウント対応、運用監視までをハンズオンで検証してみます！
AWSネットワーク設計に携わる方の参考になれば幸いです。
第一章：VPC間接続のキホン
Transit Gatewayのキホン
■ Transit Gatewayとは
AWS Transit Gateway（TGW）は、複数のVPCやオンプレミス環境を ハブ＆スポーク型 で接続できるサービスです。
従来のVPC Peeringと異なり、VPCが増えてもフルメッシュ接続を作る必要がなく、接続の一元管理が可能となります。
■ Transit Gatewayのメリット
-
フルメッシュからの解放
VPC Peeringでは接続するVPCごとにピアリングを作成する必要がありました。
TGWではハブを介するため、各VPCはTransit Gatewayにアタッチするだけで相互通信が可能です。 -
ルート制御の一元化
TGW Route Tableにルーティングを集約できるため、通信制御がわかりやすく、セキュリティ設計もしやすくなります。 -
オンプレミスとの統合が容易
Direct Connect GatewayやSite-to-Site VPNと組み合わせることで、VPCとオンプレミスのハブとしても利用できます。
■ Transit Gatewayの構成要素
-
Transit Gateway
中心となるハブ。すべてのVPCやオンプレ接続の接点となる。 -
アタッチメント
各VPCやVPNをTGWに接続するための仕組み。VPCアタッチメント、VPNアタッチメントなどがある。 -
Transit Gateway Route Table (TGW RTB)
アタッチメント間の通信経路を制御するルートテーブル。
今回の構成
本記事では、まずシンプルに 「1つのアカウント、1つのリージョン内で複数VPCを相互接続」 する構成を検証します。
接続対象となるVPCは以下の通りです。
- tgw-handson-prod-vpc-01：本番環境①を想定
- tgw-handson-prod-vpc-02：本番環境②を想定
- tgw-handson-test-vpc-01：テスト環境を想定
- tgw-handson-staging-vpc-01：ステージング環境を想定
設計方針
- 本番用VPC同士は相互に通信可能
- ステージング用VPCは本番・テストの双方と通信可能
- 本番用VPCとテスト用VPCは分離（通信不可）
👉 このシンプルなポリシーをTransit Gatewayのルートテーブルで実装していきます。
Transit Gateway構築ステップ（概観）
以下ステップにて構築～疎通確認を進めます。実際の手順や抑えておくべきポイントは後述します。
- 事前準備（VPC・エンドポイント・疎通確認用サーバの作成）
- Transit Gatewayの作成
- Transit Gatewayアタッチメントの作成・関連付け
- ルートテーブル設定（TGW RTB・VPC RTB）
- 疎通確認
① 事前準備
VPC・サブネット
-
CIDR構成
各VPCごとに/26を割り当て、内部でサブネットを分割。 -
片AZ構成（検証用）
今回は簡易検証のため 1AZ のみ で作成。 -
本番運用を意識する場合
複数AZにサブネットを分散し、冗長性・可用性を確保するのがベストプラクティス。 -
役割ごとの分割
疎通確認用サーバを配置する「アプリケーション層」と、TGWアタッチメント専用の「TGW層」にサブネットを分割。（責務分離のベストプラクティス）
VPC一覧
| VPC名 | CIDR | 用途 |
|---|---|---|
| tgw-handson-prod-vpc-01 | 10.10.10.0/26 | 本番環境① |
| tgw-handson-prod-vpc-02 | 10.10.10.64/26 | 本番環境② |
| tgw-handson-test-vpc-01 | 10.10.10.128/26 | 検証環境 |
| tgw-handson-staging-vpc-01 | 10.10.10.192/26 | ステージング環境 |
サブネット一覧
| サブネット名 | VPC名 | CIDR | 用途 |
|---|---|---|---|
| tgw-handson-prod-subnet-tgw-01 | tgw-handson-prod-vpc-01 | 10.10.10.0/28 | TGW接続用 |
| tgw-handson-prod-subnet-app-01 | tgw-handson-prod-vpc-01 | 10.10.10.32/27 | アプリ用 |
| tgw-handson-prod-subnet-tgw-02 | tgw-handson-prod-vpc-02 | 10.10.10.64/28 | TGW接続用 |
| tgw-handson-prod-subnet-app-02 | tgw-handson-prod-vpc-02 | 10.10.10.96/27 | アプリ用 |
| tgw-handson-test-subnet-tgw-01 | tgw-handson-test-vpc-01 | 10.10.10.128/28 | TGW接続用 |
| tgw-handson-test-subnet-app-01 | tgw-handson-test-vpc-01 | 10.10.10.160/27 | アプリ用 |
| tgw-handson-staging-subnet-tgw-01 | tgw-handson-staging-vpc-01 | 10.10.10.192/28 | TGW接続用 |
| tgw-handson-staging-subnet-app-01 | tgw-handson-staging-vpc-01 | 10.10.10.224/27 | アプリ用 |
ルートテーブル（RTB）
-
TGW用とApp用の2種類を作成
VPC間のきめ細かいルーティングを行うため、各サブネットに関連付けて運用 -
ルート設計
ここでは詳細割愛。後ほどTGW接続の流れで説明予定。
エンドポイント
-
作成したVPCエンドポイント
- SSM
- EC2 Messages
- SSM Messages
-
目的
今回の疎通確認サーバ管理に Fleet Manager を使用するため必須。
（エンドポイント未作成だと Fleet Manager からの操作ができない）
② Transit Gatewayの作成
- AWS マネジメントコンソールにて VPCサービス を選択。
- 左メニューから Transit Gateway を選択。
- 「Transit Gateway なし」と表示されるので、右上の [Transit Gateway を作成] をクリック。
設定項目
以下の通りに設定を行う。
| 項目 | 設定値 | 説明 | 設定理由 |
|---|---|---|---|
| Amazon 側の自律システム番号 (ASN) | 64512 | BGP（ルーティングプロトコル）で使う番号。オンプレや他のVPCと経路交換する際に必要。 | デフォルトの64512を利用。今回のハンズオンでは他システムとの重複を気にしなくて良いため。 |
| DNS サポート | 有効化 | Transit Gateway経由の通信でもVPC内のDNS解決が可能。 | 名前解決できないとアプリやサービスで不具合が出るため有効化。 |
| セキュリティグループ参照サポート | 有効化 | 他VPCのインスタンスをSGルールで指定可能。 | マルチVPC環境で柔軟にルールを設定できるため有効化。 |
| VPN ECMP サポート | 有効化 | 複数のVPN接続を並列利用し、トラフィックを負荷分散可能。 | 今回は特に意識しないためデフォルトのまま利用。 |
| デフォルトルートテーブルの関連付け | 無効化 | 新規アタッチメントが自動で共通ルートテーブルに入らないようにする。 | 接続ごとに明示的にルート制御したいため無効化。 |
| デフォルトルートテーブル伝播 | 無効化 | 各VPCのルートが勝手に広がらないようにする。 | 意図しないルート伝播を避けるために無効化。 |
| マルチキャストサポート | 無効化 | マルチキャスト通信を有効にするか。 | 今回のユースケースには不要なので無効化。 |
クロスアカウント共有オプションの設定
クロスアカウントで作成されたアタッチメントを Transit Gateway に自動で関連付けるかどうかを設定する。
今回はシングルアカウント構成のため 無効化。
（後続の章でマルチアカウント構成を扱う際に有効化予定）
設定完了後の操作
-
設定画面右下の [Transit Gateway を作成] をクリック。
-
Transit Gateway の状態が Available になっていればOK。
③ Transit Gatewayアタッチメントの作成
アタッチメントは Transit Gateway と接続先リソースを結ぶ“ケーブル”のような存在 です。
今回は VPC 間接続が目的のため、アタッチメントタイプとして VPC を選択します。
これを設定しないと、Transit Gateway はどの VPC と通信して良いのか分からず、実際のルーティングが成立しません。
- VPCコンソールで 「Transit Gatewayアタッチメント」 を選択し、
「Transit Gatewayアタッチメントを作成」 をクリックします。
- 作成済みの TGW を選択します。
（ここではtgw-hands-on-prod-tgw-01を使用） - VPC間を接続するためのアタッチメントとなるため、「VPC」 を選択します。
- 他にも以下の種類がありますが、ここでは割愛します。
- VPN と接続する際の「VPN」
- DXGW と接続するための「DXGW」
（後程 DXGW については少し触れます）
-
接続対象の VPC ID を指定
-
サブネットは アベイラビリティゾーン単位で 1つ以上選択
👉 今回は各VPCに作成したTGW用のサブネットである
tgw-handson-[env]-subnet-tgw-xxを選択します -
DNSサポート・セキュリティグループ参照サポート は基本的に有効化（名前解決のため推奨）
⚠️ TGW側で有効化していても、アタッチメント側でも有効化していないと機能しないので注意！
ここまで設定できたら 「作成」ボタン をクリック。
これで VPC と TGW が論理的に接続されます。
④ ルートテーブル設定（TGW RTB・VPC RTB）
ルーティングの考え方
Transit Gateway を使った VPC 間通信では、
「どの宛先ネットワークへ行くトラフィックを、どの経路に流すか」
をルートテーブルで定義する必要があります。
構成上は以下の 2 つのルートテーブルを意識します。
-
Transit Gateway ルートテーブル（TGW RTB）
- 宛先 CIDR ごとに、対応するアタッチメントを指定する
-
各 VPC のルートテーブル
- 宛先が「自分の VPC 以外」だった場合、そのトラフィックを Transit Gateway に向ける
👉 双方向のルート設定 が揃って初めて VPC 間の通信が成立します。
Transit Gateway ルートテーブルの設定
TGWルートテーブル作成
-
VPCコンソールから 「Transit Gatewayルートテーブル」 を選択し、
「Transit Gatewayルートテーブルを作成」 をクリック
-
Transit Gateway IDには作成済みの TGW（例：tgw-hands-on-prod-at-01）を指定。 -
今回は VPC（アタッチメント）単位 でルートテーブルを作成する
(本番VPC×2、テスト×1、ステージング×1で4つのルートテーブルを作成）
アタッチメントを関連付け
- 各VPCごとに細かいルーティング制御を行うため、アタッチメント単位で関連付け を行います。
- 作成したルートテーブルのページから「関連付け」→「関連付けを作成」を選択
- 紐づけたい VPC（アタッチメント）を指定
👉 今回は4VPCを接続するため、VPCごとに 4つのルートテーブル を作成・関連付け。
ルートの追加
- 作成したルートテーブルの「ルート」→「ルートを作成」を選択
疎通する場合
- CIDR：疎通するVPCのCIDR
- タイプ：アクティブ
-
アタッチメント：対象のVPCに紐づくアタッチメントを選択
疎通しない場合
- CIDR：疎通させないVPCのCIDR
-
タイプ：ブラックホール
👉 これにより指定したCIDRへの通信は明示的にドロップされます。
今回の要件に沿ったTGW RTB設計
- 本番用VPC同士は相互に通信可能
- ステージング用VPCは本番・検証の双方と通信可能
- 本番用VPCと検証用VPCは分離（通信不可）
TGWルートテーブル設計（VPCごと）
TGWアタッチメントのルートテーブル設計まとめ
本番環境VPC①（TGWアタッチメント）
| 送信先 (CIDR) | ターゲット (VPCのTGWアタッチメント) | 備考 |
|---|---|---|
| 10.10.10.64/26 | 本番VPC② の TGWアタッチメント | 本番同士の相互疎通 |
| 10.10.10.192/26 | ステージングVPC の TGWアタッチメント | STG→PRDの戻り経路を許可 |
| 10.10.10.128/26 | Blackhole（ルート未登録） | 本番⇄検証は分離 |
本番環境VPC②（TGWアタッチメント）
| 送信先 (CIDR) | ターゲット (VPCのTGWアタッチメント) | 備考 |
|---|---|---|
| 10.10.10.0/26 | 本番VPC① の TGWアタッチメント | 本番同士の相互疎通 |
| 10.10.10.192/26 | ステージングVPC の TGWアタッチメント | 本番-STGの相互疎通 |
| 10.10.10.128/26 | Blackhole（ルート未登録） | 本番⇄検証は分離 |
ステージングVPC（TGWアタッチメント）
| 送信先 (CIDR) | ターゲット (VPCのTGWアタッチメント) | 備考 |
|---|---|---|
| 10.10.10.0/26 | 本番VPC① の TGWアタッチメント | 本番-STGの相互疎通 |
| 10.10.10.64/26 | 本番VPC② の TGWアタッチメント | 本番-STGの相互疎通 |
| 10.10.10.128/26 | テストVPC の TGWアタッチメント | 検証-STGの相互疎通 |
テスト環境VPC（TGWアタッチメント）
| 送信先 (CIDR) | ターゲット (VPCのTGWアタッチメント) | 備考 |
|---|---|---|
| 10.10.10.192/26 | ステージングVPC の TGWアタッチメント | 検証-STGの相互疎通 |
| 10.10.10.0/26 | Blackhole（ルート未登録） | 本番環境と分離 |
| 10.10.10.64/26 | Blackhole（ルート未登録） | 本番環境と分離 |
👉 これで アタッチメント－TGW－アタッチメントの通信経路 が定義されました。
VPCルートテーブルの設定
TGWのルートテーブルを設定しただけでは、各VPC間の通信は成立しません。
続いて、VPCのルートテーブル に別VPCへのルートを追加する必要があります。
ルート設計の考え方（VPC側）
-
送信元サブネットのRTBがすべて
通信経路はそのパケットを出すサブネットのルートテーブルで決まる。
👉 インスタンスが存在する App層サブネットのRTB に宛先→TGW を追加。 -
対称ルーティングが必須
TGW RTB と 各VPC RTB の双方に対応ルートが必要。
（片側だけでは疎通できない） -
開始可否はSGで制御
VPC RTBにブラックホール設定はできない。
👉 通信遮断はTGW RTBの Blackhole で表現。
各VPCのルート（App層 RTB）
本番環境VPC①（tgw-handson-prod-vpc-01 / 10.10.10.0/26）
Appサブネット：10.10.10.32/27 → RTB: tgw-handson-prod-rtb-app-01
| 送信先 | ターゲット |
|---|---|
| 10.10.10.0/26（自VPC） | local |
| 10.10.10.64/26（本番環境VPC②） | Transit Gateway |
| 10.10.10.192/26（ステージングVPC） | Transit Gateway |
メモ：ステージングVPC宛のルートは戻り用に必須。開始可否は SG の egress で規制。
本番環境VPC②（tgw-handson-prod-vpc-02 / 10.10.10.64/26）
Appサブネット：10.10.10.96/27 → RTB: tgw-handson-prod-rtb-app-02
| 送信先 | ターゲット |
|---|---|
| 10.10.10.64/26（自VPC） | local |
| 10.10.10.0/26（本番環境VPC②） | Transit Gateway |
| 10.10.10.192/26（ステージングVPC） | Transit Gateway |
テスト環境VPC（tgw-handson-test-vpc-01 / 10.10.10.128/26）
Appサブネット：10.10.10.160/27 → RTB: tgw-handson-test-rtb-app-01
| 送信先 | ターゲット |
|---|---|
| 10.10.10.128/26（自VPC） | local |
| 10.10.10.192/26（ステージングVPC） | Transit Gateway |
メモ：本番環境VPC宛ルートは置かない（分離方針）。ステージングVPCへの応答・検証用のみ。
ステージングVPC（tgw-handson-staging-vpc-01 / 10.10.10.192/26）
Appサブネット：10.10.10.224/27 → RTB: tgw-handson-staging-rtb-app-01
| 送信先 | ターゲット |
|---|---|
| 10.10.10.192/26（自VPC） | local |
| 10.10.10.0/26（本番環境VPC①） | Transit Gateway |
| 10.10.10.64/26（本番環境VPC②） | Transit Gateway |
| 10.10.10.128/26（テスト環境VPC） | Transit Gateway |
メモ：ステージングVPCは運用ハブ想定なので 本番/検証 宛を明示許可。
TGW層用のルートテーブルはデフォルトで問題無し
👉 これで、Transit Gateway を利用した複数VPCの接続・VPC間のルーティング制御が可能となります。
⑤ 疎通確認
TGWとルート設定が完了したので、いよいよFleet Managerから実際に疎通確認用のサーバにRDPし、疎通確認を実施してみます。
（Fleet Managerを使うための設定は割愛。今回はTGWの疎通確認が目的なので、サーバのSGもフルオープンとしています）
本番環境VPC① → 本番環境VPC②
Prd-01のVPCに立てたサーバから Prd-02 のサーバに test-netconnection を実行。
疎通できることが確認できます。
本番環境VPC① → テスト環境VPC
疎通出来ない
ステージングVPC → 本番環境VPC①
疎通出来る
おまけ：DXGWを使ったオンプレ接続とインターネットアクセス設計
今回のハンズオンでは VPC 間疎通のみを扱いましたが、
実際のエンタープライズ環境ではオンプレミス環境と Direct Connect Gateway（DXGW） で接続してオンプレ側サーバと疎通し、
インターネットアクセスはオンプレの プロキシ経由 にさせることが一般的です。
ここでは、その場合のルート設計の考え方を整理します。
各レイヤのルート設計
VPC 側ルート（Appサブネット RTB）
例：本番環境VPC
| 送信先 | ターゲット |
|---|---|
| 10.10.10.0/26（自VPC） | Local |
| Xx.xx.xx.xx/xx（疎通先VPC） | Transit Gateway |
| 0.0.0.0/0（インターネット・オンプレ宛） | Transit Gateway |
👉 ポイント
- 経路は「VPC ⇒ TGW ⇒ DXGW ⇒ 社内プロキシ ⇒ インターネット」となるため、
0.0.0.0/0をTGW向けに設定 - VPCにIGWはアタッチせず、直接のインターネット出口は作らない
TGW 側ルート（RTB）
| 送信先 | アタッチメント |
|---|---|
| Xx.xx.xx.xx/xx（疎通先VPC） | 各VPC アタッチメント |
| 0.0.0.0/0（インターネット・オンプレ宛） | DXGW アタッチメント |
👉 ポイント
- デフォルトルート（0.0.0.0/0）をDXGWに流す設計
- オンプレ側で戻りルートが正しく設定されていることが大前提
DXGW 側ルート（RTB）
| 送信先 | アタッチメント |
|---|---|
| Xx.xx.xx.xx/xx（VPC・オンプレからDXGW側にルーティングするVPC） | AWS 側 TGW |
👉 ポイント
- オンプレから疎通するVPC、またはオンプレからインターネット通信を行うVPCへのルートを設定
通信フロー例（VPC → インターネット）
- EC2 から外部サイト（例：8.8.8.8）にアクセス
- App RTB のデフォルトルートで TGW に転送
- TGW から DXGW Attach へ
- オンプレルータがProxy に転送
- Proxy 経由でインターネットへ
メリット
- セキュリティガバナンスを オンプレで一元化 できる（FW/Proxy）（各VPCでNetwork Firewallをデプロイする必要無し）
- AWS 側に IGW を作らないため、インターネット経路が単純化
まとめ
今回の記事では、Transit Gateway を用いた VPC 間接続の基本構築手順を一通り解説しました。
- 事前準備として VPC・サブネット・エンドポイント・疎通確認用の環境を作成
- Transit Gateway の作成とアタッチメントの関連付け
- TGW RTB と VPC RTB のルート設計と疎通確認
- 発展編として、オンプレ環境（DXGW）と組み合わせたインターネットアクセス経路設計の例
これらを通じて、Transit Gateway を利用したネットワークの基本的な接続イメージと設計の考え方を整理できたかと思います。
次回の告知
次回は、Transit Gateway を活用した応用編として以下のテーマを予定しています。
- 複数リージョンをまたいだ TGW 接続パターン