実践！AWSネットワーク構築・運用30日チャレンジ: Day 11

Posted at 2025-07-25

Day 11: Transit Gateway：複雑なネットワークをシンプルに管理

皆さん、こんにちは！「実践！AWSネットワーク構築・運用30日チャレンジ」のDay 11へようこそ！

昨日は、2つのVPC間をプライベートに接続するVPCピアリングについて学び、そのシンプルさとメリットを実感しました。しかし、VPCピアリングには「推移的ルーティングをサポートしない」という大きな制約があることをお伝えしました。これは、VPCの数が多くなると、ピアリング接続が複雑な「メッシュ型」になり、管理が非常に困難になることを意味します。

例えば、5つのVPC（A, B, C, D, E）がすべて互いに通信したい場合、各VPCは他の4つのVPCとピアリング接続を結ぶ必要があり、合計で $(5 \times 4) / 2 = 10$ のピアリング接続が必要になります。VPCの数が増えれば増えるほど、この接続数は指数関数的に増大し、管理不能に陥ります。

VPC-A <--> VPC-B
VPC-A <--> VPC-C
VPC-A <--> VPC-D
VPC-A <--> VPC-E
VPC-B <--> VPC-C
VPC-B <--> VPC-D
VPC-B <--> VPC-E
VPC-C <--> VPC-D
VPC-C <--> VPC-E
VPC-D <--> VPC-E

↑こんな複雑なメッシュ構成は管理が大変！

そこで今日登場するのが、この課題を解決し、大規模で複雑なネットワークをシンプルに管理するためのサービス「AWS Transit Gateway (TGW)」です！

1. Transit Gatewayとは？その革新性

AWS Transit Gateway は、複数のVPC、オンプレミスネットワーク（VPNやAWS Direct Connect経由）、さらには別のAWSアカウントのVPCなどを、単一の集中型ハブとして接続できるネットワーク転送サービスです。

簡単に言えば、VPCピアリングでは実現できなかった「推移的ルーティング」を可能にし、ネットワーク構成を劇的に簡素化します。

Transit Gatewayのメリット

推移的ルーティングの実現: これがTGWの最大の特長です。TGWを介することで、VPC-AはTGWに接続されているVPC-BやVPC-Cとも直接通信できます。これにより、VPC間に直接ピアリング接続を設定する必要がなくなり、ネットワーク構成が「スター型（ハブ＆スポーク型）」になります。
```
VPC-A -- TGW -- VPC-B
  |      |      |
  +------TGW-----+
         |
       VPC-C
```
↑この図のように、各VPCはTGWに接続するだけで、TGW経由で他のVPCと通信できる。
ネットワークの簡素化: 多数のVPCやオンプレミス接続を一元的に管理できるようになり、VPCの数が増えてもネットワーク設計が複雑になりません。これにより、運用の手間とコストが大幅に削減されます。
スケーラビリティ: TGWはAWSがフルマネージドで提供するサービスであり、高いスケーラビリティと可用性を備えています。大量のネットワークトラフィックにも自動的に対応します。
セキュリティ強化: 特定のVPCからのトラフィックのみを許可したり、ネットワーク分離を強化したりするなど、きめ細やかなルーティング制御が可能です。
ハイブリッドクラウド接続の集中化: オンプレミス環境とのVPNやDirect Connect接続もTGWに集約できるため、VPCとオンプレミス間のルーティングも一元的に管理できます。
ルーティングドメインの分離: 同じTGW内で複数のルーティングテーブルを持つことができ、異なるネットワークセグメント（例: 本番、開発、共有サービス）の通信を論理的に分離できます。

Transit Gatewayが向いているシナリオ

5つ以上のVPCが存在し、それらが相互に通信する必要がある場合
オンプレミスネットワークと多数のVPCを接続する必要があるハイブリッドクラウド環境
共通サービスVPC（AD、ログサーバーなど）を複数のVPCから利用させたい場合
組織内の異なる部署やプロジェクトがそれぞれ独自のVPCを持っており、相互接続が必要な場合

2. Transit Gatewayの主要コンポーネントと仕組み

Transit Gatewayの動作を理解するために、いくつかの重要な概念を把握しましょう。

Transit Gateway (TGW): ネットワークの中心となるハブ。これ自体がトラフィックを転送する機能を持つ。
アタッチメント (Attachment): VPC、VPN、Direct Connectなど、TGWに接続される各ネットワークリソースのこと。TGWとVPCを接続するには「VPCアタッチメント」を作成します。
トランジットゲートウェイルートテーブル (Transit Gateway Route Table): TGW自体が持つルーティングテーブル。アタッチメントから受信したトラフィックを、どのアタッチメントに転送するかを決定します。
- 伝播 (Propagation): アタッチメントがTGWルートテーブルにそのCIDRブロックを自動的に登録する機能。
- 関連付け (Association): 各アタッチメントは、特定のTGWルートテーブルに関連付けられ、そのルートテーブルに送信されるトラフィックの転送先を決定します。

3. Transit Gatewayの構築と設定の実践

それでは、実際にTransit Gatewayを構築し、複数のVPCを接続してみましょう。今回は、昨日作成した2つのVPC（my-vpc と my-second-vpc）をTGW経由で通信させ、VPCピアリングとの違いを実感します。

事前準備：EC2インスタンスの確認とピアリング接続の削除（任意）

my-vpc と my-second-vpc にそれぞれEC2インスタンスが起動していることを確認してください（Day 10で起動したインスタンスでOKです）。プライベートIPアドレスを控えておきましょう。
任意: もしDay 10で設定したVPCピアリングが不要であれば、ピアリング接続の承諾を解除（拒否）し、各VPCのルートテーブルからピアリング接続へのルートを削除しておきましょう。これにより、TGWの動作がより明確になります。

3.1. Transit Gatewayの作成

AWSマネジメントコンソールで「VPC」サービスを開きます。
左側ナビゲーションペインから「Transit Gateways」をクリックします。
「Transit Gateway の作成」ボタンをクリックします。
以下の情報を入力します。
- 名前タグ: my-transit-gateway
- 説明: My central network hub
- その他のオプション（Amazon側で提供されるルートテーブルや、自動承認など）は、今回はデフォルトのままで構いません。
「Transit Gateway の作成」をクリックします。

作成には数分かかります。ステータスが「Available」になるまで待ちましょう。

3.2. VPCアタッチメントの作成

作成したTGWに、各VPCを接続するためのアタッチメントを作成します。

3.2.1. メインVPCのアタッチメントを作成

TGWの詳細画面で、「Transit Gateway アタッチメント」タブをクリックし、「アタッチメントを作成」をクリックします。
以下の情報を入力します。
- 名前タグ: my-vpc-attachment
- Transit Gateway ID: 先ほど作成した my-transit-gateway を選択します。
- アタッチメントタイプ: VPC を選択します。
- VPC ID: あなたのメインVPC (my-vpc など) を選択します。
- サブネット: あなたのVPC内の、各アベイラビリティゾーンに存在するサブネットを1つずつ選択します。 TGWは各AZでIPアドレスを持つため、選択されたサブネットからIPアドレスが割り当てられます。（例: my-vpc-public-subnet-a, my-vpc-public-subnet-c, my-vpc-private-subnet-a, my-vpc-private-subnet-c など、各AZから少なくとも1つずつ選ぶと良いでしょう。今回はプライベートサブネットを選ぶのが一般的です。）
  - ポイント: TGWが各AZでIPアドレスを持つことで、そのAZ内のVPCリソースとの通信が最適化されます。
「アタッチメントを作成」をクリックします。

3.2.2. セカンドVPCのアタッチメントを作成

同様に、my-second-vpc のアタッチメントも作成します。

「アタッチメントを作成」をクリックします。
以下の情報を入力します。
- 名前タグ: my-second-vpc-attachment
- Transit Gateway ID: my-transit-gateway を選択します。
- アタッチメントタイプ: VPC を選択します。
- VPC ID: my-second-vpc を選択します。
- サブネット: my-second-vpc 内のサブネットを選択します。（例: my-second-vpc-subnet-a）
「アタッチメントを作成」をクリックします。

両方のアタッチメントのステータスが「Available」になるまで待ちましょう。

3.3. Transit Gatewayルートテーブルの設定

デフォルトでは、TGWは自動的にTGWルートテーブルを作成し、そこにVPCアタッチメントのCIDRブロックを伝播させます。これを確認しましょう。

左側ナビゲーションペインから「Transit Gateway ルートテーブル」をクリックします。
作成されたTGWのデフォルトルートテーブル（名前は通常自動生成）を選択します。
「ルート」タブをクリックします。
- ここで、my-vpc のCIDR (10.0.0.0/16) と my-second-vpc のCIDR (10.1.0.0/16) が、それぞれ対応するアタッチメントにルーティングされていることを確認できます。これらが自動的に「伝播済み (propagated)」として表示されていればOKです。
「関連付け」タブをクリックします。
- my-vpc-attachment と my-second-vpc-attachment の両方が、このルートテーブルに「関連付け済み (associated)」になっていることを確認します。

3.4. 各VPCのルートテーブルの更新（最重要！）

最後に、各VPC内のサブネットのルートテーブルを更新し、相手のVPCへのトラフィックをTransit Gatewayにルーティングするように設定します。

3.4.1. メインVPCのルートテーブルを更新

メインVPC (例: my-vpc) に関連付けられているすべてのサブネットのルートテーブル（my-vpc-public-rtb, my-private-rtb-a など）を更新します。

VPCサービスの左側ナビゲーションペインから「ルートテーブル」をクリックします。
my-vpc の各ルートテーブルを選択し、「ルート」タブをクリックし、「ルートを編集」ボタンをクリックします。
「ルートを追加」をクリックします。
- 宛先: 10.1.0.0/16 (相手の my-second-vpc のCIDRブロック)
- ターゲット: 「Transit Gateway」を選択し、プルダウンから作成したTGW (tgw-xxxxxxxx) を選択します。
「変更を保存」をクリックします。

3.4.2. セカンドVPCのルートテーブルを更新

my-second-vpc のルートテーブルを更新します。

VPCサービスの左側ナビゲーションペインから「ルートテーブル」をクリックします。
my-second-vpc に関連付けられているルートテーブルを選択し、「ルート」タブをクリックし、「ルートを編集」ボタンをクリックします。
「ルートを追加」をクリックします。
- 宛先: 10.0.0.0/16 (相手の my-vpc のCIDRブロック)
- ターゲット: 「Transit Gateway」を選択し、プルダウンから作成したTGW (tgw-xxxxxxxx) を選択します。
「変更を保存」をクリックします。

これで、両方のVPC内のサブネットから、TGWを経由して相手のVPCへ通信がルーティングされるようになります。

5. Transit Gatewayの動作確認

Day 10と同じように、EC2インスタンスをデプロイし、TGW経由でVPC間の通信が機能しているか確認しましょう。

5.1. セキュリティグループの確認（相互通信の許可）

各EC2インスタンスのセキュリティグループが、相手のEC2インスタンスからのSSH（またはPingなどテストしたいプロトコル）を許可するように設定されていることを確認します。（Day 10で設定済みであればそのままでOKです）

5.2. Bastion Host経由で通信テスト

Day 9で作成したBastion Hostを経由して、EC2-in-MainVPC (メインVPC内のEC2) にSSH接続します。
その後、EC2-in-MainVPC から EC2-in-SecondVPC (セカンドVPC内のEC2) のプライベートIPアドレスに対してSSH接続またはPingを試行します。

# Bastion HostからEC2-in-MainVPCへ接続後、EC2-in-MainVPCのターミナルで実行
ping <EC2-in-SecondVPC_Private_IP_Address>

# もしSSH接続を試す場合（秘密鍵が必要）
ssh -i /path/to/keypair.pem ec2-user@<EC2-in-SecondVPC_Private_IP_Address>

Pingが通る、またはSSH接続が成功すれば、Transit Gatewayが正しく機能し、VPC間でプライベートな通信が可能になったことになります！おめでとうございます！

6. AI時代におけるTransit Gatewayの活用シナリオ

AI/MLワークロードは、多くの場合、複数のVPCや共有サービスを必要とします。TGWは、このような複雑な環境で、効率的かつセキュアなネットワーク基盤を提供します。

データレイクVPC、学習VPC、推論VPCの統合: 大規模なAIプラットフォームでは、データ保存用のVPC、モデル学習用のVPC、本番推論用のVPCなど、役割ごとにVPCを分離することがよくあります。これらのVPCをTGWを介して接続することで、効率的なデータフローとセキュリティ分離を両立できます。
共有サービスVPCの利用: Active Directory、ログ収集サーバー、監視ツールなどが配置された共有サービスVPCをTGWに接続し、複数の開発VPCや本番VPCから共通で利用できるようにします。
オンプレミスからの学習データアクセス: オンプレミスのデータセンターにある大量の学習データをAWSに転送する場合、Direct Connect接続をTGWに集約し、TGW経由で複数の学習VPCにデータを提供できます。
MLOpsパイプラインのネットワーク: CI/CDパイプラインを構築するVPCと、学習・推論を行うVPCの間でセキュアな通信経路をTGWで確立し、モデルのデプロイや監視を自動化します。
ネットワーク監視の一元化: TGWのフローログを有効にすることで、TGWを通過するすべてのVPC間トラフィックを集中して監視・分析できるようになり、AI/MLワークロードのネットワークパフォーマンス問題やセキュリティ異常を特定しやすくなります。

本日のまとめと次へのステップ

今日は、AWSにおける複雑なネットワークをシンプルに管理するための画期的なサービス「Transit Gateway (TGW)」について学び、実践しました。

TGWは、VPCピアリングの課題（推移的ルーティング非サポート、メッシュ型接続）を解決し、スター型（ハブ＆スポーク型）の集中型ネットワークハブを提供します。
複数のVPCやオンプレミスネットワークを効率的かつスケーラブルに接続できます。
設定は、TGWの作成、VPCアタッチメントの作成、TGWルートテーブルの確認、各VPCのルートテーブル更新というステップで行います。

Transit Gatewayは、エンタープライズレベルのクラウドネットワーク設計において、非常に重要なサービスです。この知識があれば、より大規模で複雑なシステムにも対応できるようになります。

明日のDay 12では、「AWS Direct Connect と VPN：ハイブリッドクラウドネットワーキングの実現」と題して、オンプレミス環境とAWS VPCを安全かつ高速に接続するための「AWS Direct Connect」と「AWS Site-to-Site VPN」について学びます。TGWと組み合わせることで、真のハイブリッドクラウド環境を構築できるようになります。

今日のTransit Gatewayのハンズオン、いかがでしたか？複雑なネットワークがシンプルになる感覚を掴めましたか？ぜひ「いいね」👍で教えてください！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up