Transit Gateway ハンズオン手順書

📋 概要

AWS Transit Gateway（TGW）は、複数の VPC やオンプレミスネットワークを 1 つのハブに集約して相互接続するマネージドサービスです。VPC ピアリングでは接続が増えるほどフルメッシュ構成が複雑化しますが、TGW を使えば各 VPC を「ハブ」に 1 本ずつ繋ぐだけで相互通信を実現できます。このハンズオンでは 3 つの VPC を作成し、TGW でルーティングを集約・制御する一連の流れを体験します。

項目	内容
対象サービス	Transit Gateway、VPC、EC2、ルートテーブル、Session Manager
主な学習内容	TGW 作成・VPC アタッチメント・ルート伝播・TGW ルートテーブルによる通信制御
所要時間	75〜90 分
難易度	★★★☆☆（中級者向け）
前提知識	VPC・サブネット・ルートテーブル・セキュリティグループの基礎知識
費用目安	約 1〜3 USD（TGW アタッチメント時間課金 + EC2。数時間で完了しクリーンアップ前提）

ℹ️ VPC ピアリングとの違い

観点	VPC ピアリング	Transit Gateway
接続形態	1 対 1（フルメッシュ）	ハブ & スポーク
接続数（N VPC）	N×(N-1)/2 本	N 本
推移的ルーティング	不可	可能
ルート制御	各 VPC ルートテーブル	TGW ルートテーブルで集中管理
課金	データ転送のみ	アタッチメント時間 + データ処理

ℹ️ Transit Gateway の主なユースケース

多数の VPC を持つ大規模環境のネットワーク集約
共有サービス VPC（DNS・監視・認証）への一元アクセス
オンプレミスとの Site-to-Site VPN / Direct Connect の集約
マルチアカウント環境（AWS RAM で TGW を共有）
セグメント分離（本番 / 開発 VPC を TGW ルートテーブルで論理分離）

🏗️ アーキテクチャ

このハンズオンで構築する構成です。3 つの VPC を Transit Gateway に接続し、VPC-A と VPC-B は相互通信可能、VPC-C は最終ステップで分離制御を試します。

🟧 VPC-A 10.0.0.0/16
プライベートサブネット + EC2-A

↕ TGW アタッチメント

🔶 Transit Gateway（ハブ）
TGW ルートテーブルでルート伝播・制御

↕ TGW アタッチメント

🟦 VPC-B 10.1.0.0/16
プライベートサブネット + EC2-B

↕ TGW アタッチメント（Step5 で制御）

🟩 VPC-C 10.2.0.0/16
プライベートサブネット + EC2-C

CIDR 設計

TGW で接続する VPC は CIDR が重複してはいけません。重複するとルーティングが成立しません。

VPC 名	VPC CIDR	サブネット CIDR	EC2
VPC-A	10.0.0.0/16	10.0.1.0/24	EC2-A（10.0.1.x）
VPC-B	10.1.0.0/16	10.1.1.0/24	EC2-B（10.1.1.x）
VPC-C	10.2.0.0/16	10.2.1.0/24	EC2-C（10.2.1.x）

ℹ️ TGW の 2 つのルートテーブル

TGW のルーティングには「アソシエーション」と「プロパゲーション（伝播）」の 2 概念があります。

アソシエーション：アタッチメントが「どの TGW ルートテーブルを参照してパケットを転送するか」を決める
プロパゲーション：アタッチメント（VPC）の CIDR を TGW ルートテーブルに自動的にルートとして登録する

デフォルト TGW ルートテーブルでは全アタッチメントが自動アソシエート・自動プロパゲートされ、全 VPC が相互通信できます。Step5 ではこれを手動制御して VPC を分離します。

✅ 前提条件

AWS アカウントにログイン済みであること
VPC・EC2・Transit Gateway・IAM の作成権限を持つユーザーであること
EC2 に Session Manager で接続するための IAM ロール（AmazonSSMManagedInstanceCore）を用意できること
同一リージョン内で作業すること

⚠️ リージョン確認

すべてのリソースを同一リージョンに作成します。このハンズオンでは ap-northeast-1（東京） を使用します。コンソール右上のリージョンを固定してください。

ℹ️ Session Manager を使う理由

各 EC2 はプライベートサブネットに配置し、SSH キーやパブリック IP を使わずに Session Manager で接続します。これにより踏み台不要で安全に検証できます。Session Manager を使うには EC2 に SSM 用 IAM ロールをアタッチし、SSM エンドポイントへの到達性（NAT または VPC エンドポイント）が必要です。本ハンズオンでは簡易化のため各 VPC に NAT ゲートウェイ、もしくはパブリックサブネット + パブリック IP の EC2 を使う構成でも代替可能です。

🧱 ステップ 1 ― 検証用 VPC と EC2 を準備する

CIDR の重ならない 3 つの VPC を作成し、各 VPC に EC2 を 1 台ずつ起動します。ここでは VPC-A・VPC-B を中心に進め、VPC-C は Step5 用に用意します。

1-1. VPC を作成する（VPC and more で一括作成）

VPC コンソール → 「VPC を作成」 →「VPC など」を選択すると、サブネット・ルートテーブルまで一括作成できます。VPC-A を以下で作成します。

名前タグtgw-vpc-a

IPv4 CIDR10.0.0.0/16

アベイラビリティーゾーン1

パブリックサブネット1

プライベートサブネット1

NAT ゲートウェイなし（コスト削減・任意）

同様に tgw-vpc-b（10.1.0.0/16）、tgw-vpc-c（10.2.0.0/16）を作成します。

1-2. SSM 用 IAM ロールを準備する

EC2 に Session Manager で接続するため、AmazonSSMManagedInstanceCore ポリシーをアタッチした EC2 用ロール（インスタンスプロファイル）を用意します。IAM → ロール → 「ロールを作成」→ 信頼されたエンティティ「EC2」→ AmazonSSMManagedInstanceCore を選択 → ロール名 ec2-ssm-role で作成します。

1-3. EC2 を各 VPC に起動する

EC2 コンソール →「インスタンスを起動」で 3 台起動します。各台の設定例（EC2-A）：

名前tgw-ec2-a

AMIAmazon Linux 2023

インスタンスタイプt3.micro

VPCtgw-vpc-a

サブネットtgw-vpc-a のサブネット

IAM インスタンスプロファイルec2-ssm-role

キーペアなし（Session Manager 接続のため）

EC2-B（tgw-vpc-b）、EC2-C（tgw-vpc-c）も同様に起動します。

1-4. セキュリティグループで ICMP を許可する

VPC 間で ping 疎通を確認するため、各 EC2 のセキュリティグループのインバウンドに以下を追加します。

タイプ	プロトコル	ソース
すべての ICMP - IPv4	ICMP	10.0.0.0/8（検証用に広めに許可）

⚠️ 検証用の設定です

本番環境では必要な CIDR・ポートのみに絞ってください。ここでは 10.0.0.0/8 で 3 VPC をまとめて許可しています。

✅ 確認ポイント

3 つの VPC とそれぞれに 1 台ずつ EC2（計 3 台）が「実行中」になり、Session Manager の「接続」ボタンが有効（緑）になっていれば準備完了です。各 EC2 のプライベート IP をメモしておきます。

🔶 ステップ 2 ― Transit Gateway を作成しVPC をアタッチする

ハブとなる Transit Gateway を作成し、VPC-A と VPC-B をアタッチします。

2-1. Transit Gateway を作成する

VPC コンソール左メニュー → 「Transit Gateway」→「Transit Gateway を作成」 をクリックします。

設定項目	設定値
名前タグ	handson-tgw
説明	Hands-on Transit Gateway
Amazon 側 ASN	デフォルト（64512）のまま
デフォルトルートテーブルの関連付け	有効（チェック）
デフォルトルートテーブルの伝播	有効（チェック）
DNS サポート	有効

「Transit Gateway を作成」をクリックします。状態が available になるまで数分待ちます。

ℹ️ デフォルト関連付け / 伝播を有効にする意味

両方を有効にすると、後でアタッチする VPC が自動的にデフォルト TGW ルートテーブルに関連付けられ、CIDR が伝播されます。つまり アタッチするだけで全 VPC が相互通信できる状態になります。Step5 ではこの自動動作を理解した上で手動制御を行います。

2-2. VPC-A をアタッチする

「Transit Gateway アタッチメント」→「Transit Gateway アタッチメントを作成」 をクリックします。

設定項目	設定値
名前タグ	attach-vpc-a
Transit Gateway ID	handson-tgw
アタッチメントタイプ	VPC
VPC ID	tgw-vpc-a
サブネット	tgw-vpc-a のサブネット（AZ ごとに 1 つ選択）

「Transit Gateway アタッチメントを作成」をクリックします。

2-3. VPC-B をアタッチする

同じ手順で VPC-B をアタッチします。名前タグ attach-vpc-b、VPC ID tgw-vpc-b を指定します。

ℹ️ VPC-C はまだアタッチしません

VPC-C は Step5 のルート制御の検証で使用するため、この時点ではアタッチしないでおきます。

✅ 確認ポイント

アタッチメント一覧で attach-vpc-a と attach-vpc-b の状態が available になれば成功です（数分かかります）。

🧭 ステップ 3 ― VPC ルートテーブルに TGW 向けルートを追加する

TGW にアタッチしただけでは VPC 内のサブネットは相手 VPC への経路を知りません。各 VPC のサブネットルートテーブルに「相手の CIDR → TGW」のルートを追加する必要があります。

ℹ️ 2 種類のルートテーブルを混同しないこと

VPC（サブネット）ルートテーブル：VPC 内のサブネットがどこへパケットを送るかを決める ← このステップで編集
TGW ルートテーブル：TGW 内でアタッチメント間をどう転送するかを決める ← Step2 で自動伝播済み

3-1. VPC-A のルートテーブルを編集する

VPC コンソール → 「ルートテーブル」→ VPC-A の EC2-A が属するサブネットに関連付いたルートテーブルを選択 → 「ルート」タブ →「ルートを編集」 をクリックします。以下を追加します。

送信先（Destination）	ターゲット（Target）
10.1.0.0/16（VPC-B の CIDR）	Transit Gateway → handson-tgw

「変更を保存」をクリックします。

3-2. VPC-B のルートテーブルを編集する

同様に VPC-B のサブネットルートテーブルに、VPC-A への戻りルートを追加します。

送信先（Destination）	ターゲット（Target）
10.0.0.0/16（VPC-A の CIDR）	Transit Gateway → handson-tgw

⚠️ 往復のルートが両方必要

ping は「行き」と「帰り」の両方の経路が必要です。VPC-A 側だけにルートを追加しても、VPC-B から VPC-A への戻り経路がないと疎通しません。必ず両 VPC にルートを追加してください。

✅ 確認ポイント

VPC-A と VPC-B のルートテーブルに、それぞれ相手の CIDR 宛て TGW ルートが「アクティブ」状態で表示されていれば成功です。

🔬 ステップ 4 ― VPC 間の疎通を確認する

EC2-A から EC2-B へ ping を打ち、TGW 経由で VPC をまたいだ通信が成立することを確認します。

4-1. EC2-A に Session Manager で接続する

EC2 コンソール → tgw-ec2-a を選択 → 「接続」→「セッションマネージャー」タブ →「接続」をクリックします。ブラウザ上でターミナルが開きます。

4-2. EC2-B へ ping を実行する

EC2-B のプライベート IP（例：10.1.1.x）に対して ping を実行します。

# EC2-A のセッションで実行（EC2-B のプライベート IP を指定） ping -c 4 10.1.1.100

応答が返れば TGW 経由で VPC-A → VPC-B の通信が成立しています。

64 bytes from 10.1.1.100: icmp_seq=1 ttl=126 time=1.20 ms
64 bytes from 10.1.1.100: icmp_seq=2 ttl=126 time=0.98 ms
--- 10.1.1.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss

4-3. 逆方向も確認する（任意）

EC2-B のセッションを開き、EC2-A（10.0.1.x）へ ping して双方向の疎通を確認します。

# EC2-B のセッションで実行 ping -c 4 10.0.1.100

⚠️ 疎通しない場合のチェックリスト

セキュリティグループのインバウンドで ICMP が許可されているか
両 VPC のサブネットルートテーブルに TGW ルートがあるか（往復分）
TGW アタッチメントが available か
TGW ルートテーブルに両 VPC の CIDR が伝播（propagated）されているか
ping 先がサブネットルートテーブルに紐づくサブネット内の EC2 か

✅ 確認ポイント

EC2-A ⇔ EC2-B 間で ping 応答が返れば、Transit Gateway によるハブ & スポーク接続が成功です 🎉

🚦 ステップ 5 ― TGW ルートテーブルでセグメント分離を制御する

応用として VPC-C をアタッチし、TGW ルートテーブルの「関連付け」と「伝播」を手動制御することで、VPC-C を VPC-A とは通信させ、VPC-B とは遮断するといったセグメント分離を実現します。

5-1. VPC-C を TGW にアタッチする

Step2 と同じ手順で VPC-C をアタッチします（名前タグ attach-vpc-c、VPC tgw-vpc-c）。デフォルト伝播が有効なため、この時点では VPC-C も全 VPC と通信可能な状態です。

5-2. カスタム TGW ルートテーブルを 2 つ作成する

「Transit Gateway ルートテーブル」→「Transit Gateway ルートテーブルを作成」 で 2 つ作成します。

名前タグ	用途
rt-prod	VPC-A・VPC-B 用（相互通信グループ）
rt-isolated	VPC-C 用（VPC-A とのみ通信、VPC-B とは遮断）

5-3. アソシエーション（関連付け）を設定する

各ルートテーブルの「関連付け」タブ →「関連付けを作成」で、アタッチメントを割り当てます。

TGW ルートテーブル	関連付けるアタッチメント
rt-prod	attach-vpc-a, attach-vpc-b
rt-isolated	attach-vpc-c

ℹ️ アソシエーションとは

アタッチメントから「入ってくる」パケットが、どの TGW ルートテーブルを見て転送先を決めるかの設定です。VPC-C から出たパケットは rt-isolated を参照します。

5-4. プロパゲーション（伝播）を設定する

各 TGW ルートテーブルの「伝播」タブ →「伝播を作成」で、どのアタッチメントの CIDR をそのルートテーブルに登録するかを決めます。

TGW ルートテーブル	伝播させるアタッチメント	結果（このRTが知る経路）
rt-prod	attach-vpc-a, attach-vpc-b, attach-vpc-c	VPC-A・B・C すべてへ到達可
rt-isolated	attach-vpc-a のみ	VPC-A へのみ到達可（VPC-B は知らない）

ℹ️ この設定で起きること

VPC-C → VPC-A：rt-isolated に VPC-A の経路があるので通信可能
VPC-C → VPC-B：rt-isolated に VPC-B の経路がないので遮断
VPC-A → VPC-C：rt-prod に VPC-C の経路があるので通信可能

これにより「VPC-A は共有サービス VPC、VPC-B と VPC-C は互いに分離されたテナント」のような設計が表現できます。

5-5. VPC-C のサブネットルートに TGW ルートを追加する

VPC-C のサブネットルートテーブルに、VPC-A 宛てのルートを追加します（Step3 と同じ要領）。

送信先	ターゲット
10.0.0.0/16（VPC-A）	Transit Gateway → handson-tgw

VPC-A のルートテーブルにも VPC-C 宛て（10.2.0.0/16）の TGW ルートを追加します。

5-6. 分離を検証する

EC2-C に Session Manager で接続し、ping を実行して期待通りの分離になっているか確認します。

# EC2-C のセッションで実行 ping -c 3 10.0.1.100 # VPC-A 宛て → 成功するはず ping -c 3 10.1.1.100 # VPC-B 宛て → タイムアウトするはず（遮断）

✅ 確認ポイント

VPC-C → VPC-A は ping 成功、VPC-C → VPC-B はタイムアウトすれば、TGW ルートテーブルによるセグメント分離が成功しています。TGW のルートテーブルを使えば VPC ごとに「誰と通信できるか」を中央集権的に制御できることが体験できました。

🧹 クリーンアップ

⚠️ 課金防止のためクリーンアップを必ず実施してください

Transit Gateway はアタッチメントごとに時間課金が発生します（1 アタッチメントあたり約 $0.07/時 + データ処理）。EC2・NAT ゲートウェイ（作成した場合）も課金対象です。

削除手順（依存関係の逆順で実施）

EC2 インスタンスを終了
EC2 → tgw-ec2-a / tgw-ec2-b / tgw-ec2-c を選択 →「インスタンスを終了」
VPC ルートテーブルの TGW ルートを削除（VPC 削除前に自動で消えるが念のため）
各 VPC のルートテーブルから TGW 宛てルートを削除
TGW アタッチメントを削除
Transit Gateway アタッチメント → attach-vpc-a / -b / -c を選択 →「削除」。状態が deleted になるまで待つ
カスタム TGW ルートテーブルを削除
Transit Gateway ルートテーブル → rt-prod / rt-isolated を削除
Transit Gateway を削除
Transit Gateway → handson-tgw を選択 →「削除」（アタッチメントがすべて消えてから実行可能）
VPC を削除
VPC → tgw-vpc-a / -b / -c を削除（NAT ゲートウェイを作った場合は先に削除）
IAM ロールを削除（再利用しない場合）
IAM → ec2-ssm-role を削除

✅ クリーンアップ完了の確認

Transit Gateway 一覧が空になった
TGW アタッチメント一覧が空になった
EC2 インスタンスがすべて「終了済み」
VPC が削除された

学習のまとめ

習得したスキル	実践内容
Transit Gateway の作成	ハブとなる TGW を作成し VPC をアタッチ
VPC アタッチメント	複数 VPC を 1 つのハブに集約接続
ルーティング設計	VPC サブネットルートと TGW ルートの 2 階層を理解
VPC 間疎通確認	Session Manager + ping で TGW 経由通信を検証
セグメント分離制御	TGW ルートテーブルのアソシエーション/プロパゲーションで通信を制御