仕事でAWS Transit Gateway（以下、TGW）に触れる機会があったので、個人のAWSアカウントでも実際に試してみました。
TGWは、複数のVPCやオンプレミス環境を接続する際に利用できるサービスです。
今回は、2つのVPCをTGWで接続し、EC2インスタンス間でpingが通ることを確認します。
また、ルートテーブルやプロパゲーションの設定を変更し、通信にどのような影響が出るのかも検証してみました。
AWSのネットワーク構成を理解したい方や、TGWを実際に触ってみたい方の参考になれば幸いです。
用語
まず今回の検証で使用する用語を整理します。
Transit Gatewayとは
Transit Gatewayは、複数のネットワークを接続するためのAWSのサービスです。
イメージとしては、AWS上に設置する仮想ルーターのようなものです。
例えば、VPCが2つある場合、それぞれのVPCをTGWに接続することで、VPC間の通信を中継できます。
VPCが増えた場合でも、各VPCをTGWに接続する構成にすれば、ネットワークをまとめて管理しやすくなります。
TGWでは、主に次のようなネットワークを接続できます。
- VPC同士の接続
- オンプレミス環境とVPCの接続
- Transit Gateway同士の接続
このように、TGWは複数のネットワークを集約する「ハブ」の役割を担います。
ルートテーブルとは
ルートテーブルとは、宛先のネットワークに対して、どこへ通信を転送するかを定義するものです。
TGWでは、複数のルートテーブルを作成できます。
さらに、それぞれのルートテーブルは論理的に分離されています。
この仕組みは、ネットワークを分離するVRF（Virtual Routing and Forwarding）に似ています。
例えば、部署ごとにネットワークを分けたい場合や、開発環境と本番環境の通信を制御したい場合などに活用できます。
ただし、ルートテーブルを分けるだけで自動的にすべての通信が遮断されるわけではありません。
それぞれのルートテーブルにどのような経路を設定するかによって、通信できる範囲が変わります。
アタッチメントとは
アタッチメントとは、TGWとVPCなどのネットワークを接続するための仕組みです。
ケーブルのようなものをイメージすると、理解しやすいと思います。
VPCをTGWに接続する場合は、VPCアタッチメントを作成します。
今回の検証では、VPC-AとVPC-BをTGWに接続するため、2つのアタッチメントを作成します。
アソシエーションとは
アソシエーション（関連付け）とは、アタッチメントとTGWルートテーブルを関連付ける仕組みです。
TGWのルートテーブルは、通信を受信したアタッチメントに対して、どのルートテーブルを使用するかを決定するために利用されます。
例えば、VPC-Aのアタッチメントをルートテーブル1に関連付けると、VPC-AからTGWに入ってきた通信は、ルートテーブル1を使って転送先を判断します。
1つのアタッチメントに関連付けられるTGWルートテーブルは、同時に1つです。
プロパゲーションとは
プロパゲーション（伝播）とは、アタッチメントに関連するネットワークの経路情報を、TGWのルートテーブルに反映する仕組みです。
例えば、VPC-Aのアタッチメントから経路を伝播させると、VPC-AのCIDRに対応する経路をTGWルートテーブルに登録できます。
これにより、VPC-A向けの経路をTGWルートテーブルに手動で1つずつ登録する手間を減らせます。
ただし、プロパゲーションによって経路が登録されても、VPC側のルートテーブルに必要な経路がなければ通信できません。
また、プロパゲーション先のTGWルートテーブルが、アタッチメントのアソシエーション先と同じである必要はありません。
このように、アソシエーションとプロパゲーションは別の役割を持っています。
CloudFormationとは
CloudFormationは、AWSリソースの作成や管理を自動化するサービスです。
YAMLやJSON形式のテンプレートを用意することで、VPCやEC2などのリソースをまとめて作成できます。
CloudFormationでは、テンプレートから作成・管理するリソースのまとまりを「スタック」と呼びます。
今回は、VPC-AとVPC-B、およびそれぞれのVPCに配置するEC2インスタンスの作成を自動化します。
一方、Transit Gatewayやアタッチメントなどは、仕組みを理解するために手動で作成します。
今回の検証構成
今回の検証では、2つのVPCをTransit Gatewayで接続します。
構成は次のとおりです。
各VPCにEC2インスタンスを1台ずつ配置します。
今回は、EC2-AからEC2-Bに向けてpingを実行し、VPC間の通信ができることを確認します。
検証環境の情報
| 項目 | VPC-A | VPC-B |
|---|---|---|
| VPC CIDR | 10.1.0.0/16 | 10.2.0.0/16 |
| サブネットCIDR | 10.1.1.0/24 | 10.2.1.0/24 |
| EC2インスタンス | EC2-A | EC2-B |
| EC2のプライベートIP | 10.1.1.235 | 10.2.1.202 |
※EC2のIPアドレスは、今回の検証で確認した値です。実際に作成すると異なる場合があります。
CloudFormationでVPCとEC2を作成する
まず、CloudFormationを使用してVPCとEC2を作成します。
今回は、Transit Gatewayを作成するテンプレートではなく、VPCとEC2のみを作成するテンプレートを使用します。
YAMLファイルを準備する
以下のYAMLファイルを使用します。
ファイル名：transit-gateway-vpc-ec2-only.yaml
VPC-A、VPC-B、EC2-A、EC2-Bなどのリソースを作成するテンプレートです。
このテンプレートでは、主に次のリソースを作成します。
- VPC-AとVPC-B
- 各VPCのサブネット
- EC2インスタンス
- セキュリティグループ
- インターネットゲートウェイ
- ルートテーブル
- EC2接続用のIAM関連リソース
今回はTGWを手動で作成するため、テンプレートにはTGWやアタッチメントを含めていません。
CloudFormationでスタックを作成する
AWSマネジメントコンソールにログインし、CloudFormationを開きます。
以下の手順でスタックを作成します。
- 「スタックの作成」を選択します。
- 「既存のテンプレートを選択」を選択します。
- 「テンプレートファイルのアップロード」を選択します。
- 「ファイルの選択」を押します。
transit-gateway-vpc-ec2-only.yamlを選択します。- 「次へ」を押します。
- 任意のスタック名を入力し「次へ」を押します。
- “AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。“にチェックを入れて「次へ」を押します。
- 「送信」を押します。
スタックの作成が始まります。
スタックのステータスがCREATE_COMPLETEになれば、作成成功です。
VPC IDを控える
スタックの作成が完了したら、「出力」タブを確認してください。
ここに表示されるVPC-AとVPC-BのVPC IDを控えておきます。
後ほど、Transit Gatewayのアタッチメントを作成する際に使用します。
Transit Gatewayを作成する
次に、Transit Gatewayを作成します。
今回はCloudFormationではなく、AWSマネジメントコンソールから手動で作成します。
Transit Gatewayの作成手順
- VPCコンソールを開きます。
- 左メニューから「Transit Gateway」を選択します。
- 「Transit Gatewayを作成」を押します。
- 任意の名前タグを入力し「Transit Gatewayを作成」を押します。
今回の検証では、デフォルトの設定でTransit Gatewayを作成します。
作成後、Transit Gatewayの状態がAvailableになることを確認します。
Transit Gateway IDを控えておきましょう。後ほど、Transit Gatewayのアタッチメントを作成する際に使用します。
VPCアタッチメントを作成する
Transit Gatewayを作成しただけでは、VPCとは接続されていません。
VPC-AとVPC-Bを接続するため、それぞれのVPCに対してアタッチメントを作成します。
アタッチメントの作成手順
- VPCコンソールを開きます。
- 左メニューから「Transit Gatewayアタッチメント」を選択します。
- 「Transit Gatewayアタッチメントを作成」を押します。
- 名前タグに任意の名前を入力します。（VPC-AとVPC-Bの区別がつきやすいよう名前にするといい）
- Transit Gateway IDに接続先のTransit Gateway IDを選択します。
- アタッチメントタイプで「VPC」を選択します。
- VPC IDでVPC-Aを選択します。
- 同じ手順でVPC-Bのアタッチメントも作成します。
これで、2つのVPCをTGWに接続するためのアタッチメントが作成されます。
アタッチメントの状態がAvailableになることを確認しましょう。
Transit Gatewayのルートテーブルを確認する
次に、Transit Gatewayのルートテーブルを確認します。
VPC-AとVPC-Bのアタッチメントが、どのルートテーブルに関連付けられているかを確認してください。
また、ルートテーブルの経路情報に、VPC-AとVPC-BのCIDRが登録されていることを確認します。
今回は、2つのVPCを同じTGWルートテーブルで通信させる構成にします。
今回のTransit Gatewayの設定ではデフォルトルートテーブルのプロパゲーションが有効なため、各VPCのCIDRに対応する経路が登録されます。
VPCのルートテーブルに経路を追加する
TGWのルートテーブルを設定しただけでは、VPC側からTGWに通信を送れません。
VPCのルートテーブルにも、相手のVPCへ向かう経路を追加する必要があります。
VPC-Aに経路を追加する
VPC-Aのルートテーブルを開き、次の経路を追加します。
| 項目 | 設定値 |
|---|---|
| 宛先 | 10.2.0.0/16 |
| ターゲット | Transit Gateway |
この設定により、VPC-Aから10.2.0.0/16宛ての通信はTGWに転送されます。
VPC-Bに経路を追加する
続いて、VPC-Bのルートテーブルに次の経路を追加します。
| 項目 | 設定値 |
|---|---|
| 宛先 | 10.1.0.0/16 |
| ターゲット | Transit Gateway |
これで、VPC-BからVPC-Aへの通信もTGWに転送されます。
VPC間の通信では、行きの経路だけでなく戻りの経路も必要です。
そのため、両方のVPCに相手のネットワーク宛ての経路を設定します。
また、ルートテーブルに経路があっても、セキュリティグループやネットワークACLで通信が拒否されていれば疎通できません。
EC2インスタンス間の疎通を確認する
ネットワークの設定ができたので、EC2インスタンス間の通信を確認します。
EC2のプライベートIPを確認する
EC2コンソールを開き、各インスタンスのプライベートIPアドレスを確認します。
今回の検証では、次のIPアドレスでした。
- EC2-A：
10.1.1.235 - EC2-B：
10.2.1.202
EC2-Aに接続する
EC2-AにSession Managerで接続します。
今回は、接続したEC2-AからEC2-BのプライベートIPアドレスに対してpingを実行します。
ping -c 4 10.2.1.202-c 4は、pingを4回送信して終了するためのオプションです。
応答が返ってくれば、EC2-AからEC2-Bへの疎通ができています。
今回の検証では、pingの疎通を確認できました。
これで、Transit Gatewayを経由したVPC間通信ができることを確認できました。
設定を変更して通信への影響を確認する
ここからは、設定を変更して通信がどのように変化するかを確認します。
VPC-Aのルートテーブルから経路を削除する
まず、VPC-Aのルートテーブルから、次の経路を削除します。
- 宛先：
10.2.0.0/16 - ターゲット：Transit Gateway
その後、EC2-Aから再度pingを実行します。
ping -c 4 10.2.1.202今回は疎通できません。
これは、VPC-AのルートテーブルからEC2-B宛ての経路を削除したためです。
EC2-AからEC2-Bに向かう通信をTGWに転送できなくなったことが原因です。
この検証から、TGW側のルーティングだけでなく、VPC側のルートテーブルも重要であることが分かります。
Transit Gatewayのプロパゲーションを削除する
次に、TGWのプロパゲーションを変更します。
TGWのルートテーブルを開き、伝播の設定からVPC-Aのアタッチメントを削除します。
その後、EC2-AからEC2-Bにpingを実行します。
ping -c 4 10.2.1.202今回は疎通できませんでした。
プロパゲーションを削除すると、対象のTGWルートテーブルに伝播されていたVPC-Aの経路が削除されます。
そのため、TGWがVPC-Aへの戻りの経路を認識できなくなり、通信が成立しなくなります。
なお、この検証では、VPC-AのルートテーブルにあるEC2-B宛ての経路は残しておく必要があります。
VPC側の経路も削除してしまうと、プロパゲーションの変更による影響だけを切り分けられなくなるためです。
このように、プロパゲーションはTGWのルートテーブルに経路を登録するうえで重要な機能です。
Transit Gatewayのルートテーブルを分ける
最後に、TGWのルートテーブルを分けてみます。
これまでは、VPC-AとVPC-Bの両方を同じTGWルートテーブルに関連付けていました。
今回は、次のように変更します。
Transit Gateway
├─ ルートテーブル1
│ └─ アタッチメントA
│
└─ ルートテーブル2
└─ アタッチメントBルートテーブル1をVPC-Aのアタッチメントに関連付けます。
ルートテーブル2をVPC-Bのアタッチメントに関連付けます。
この状態で、EC2-AからEC2-Bにpingを実行します。
ping -c 4 10.2.1.202今回の検証では、疎通できませんでした。
これは、ルートテーブルを分けたこと自体が直接の原因というよりも、通信に必要な経路がそれぞれのルートテーブルに存在しないことが原因です。
例えば、ルートテーブル1にVPC-B宛ての経路がなければ、VPC-Aから届いた通信をVPC-Bへ転送できません。
同様に、ルートテーブル2にVPC-A宛ての経路がなければ、戻りの通信をVPC-Aへ転送できません。
つまり、ルートテーブルを分けた場合は、それぞれのルートテーブルに必要な経路があるかを確認する必要があります。
逆に、別々のルートテーブルを使用していても、適切な経路を登録すれば通信させることは可能です。
ルートテーブルを分離することで、ネットワークごとに通信可能な範囲を制御できます。
これは、TGWを利用してネットワークを分離する際に重要なポイントです。
検証が終わったらリソースを削除する
今回の検証では、CloudFormationで作成したリソースと、手動で作成したTGW関連のリソースがあります。
検証が終わったら、不要なリソースを削除しましょう。
特に、TGWやVPCアタッチメントは、存在している時間に応じて料金が発生する場合があります。
Transit Gatewayの関連リソースを削除する
手動で作成しているTGWが不要であれば、次の順番で削除します。
- VPCアタッチメントを削除する
- アタッチメントの削除完了を確認する
- Transit Gatewayを削除する
なお、VPCアタッチメントの削除が完了する前に、TGW本体を削除することはできません。
CloudFormationのスタックを削除する
CloudFormationで作成したスタックを削除します。
- CloudFormationコンソールを開きます。
- 対象のスタックを選択します。
- 「削除」を押します。
- 削除が完了したことを確認します。
削除に失敗した場合は、スタックの「イベント」タブでエラー内容を確認します。
サブネットなどは依存しているリソースが残っている場合、削除できない場合があります。
まとめ
今回は、AWS Transit Gatewayを使って2つのVPCを接続し、EC2インスタンス間の疎通を検証しました。
実際に設定を変更することで、TGWのルーティングの仕組みを確認できました。
今回の検証で押さえておきたいポイントは、次の4つです。
Transit Gatewayは複数のネットワークを接続するハブとして利用できる
VPC同士だけでなく、オンプレミス環境やほかのTransit Gatewayとの接続にも利用できます。
プロパゲーションによって、TGWのルートテーブルに経路を反映できる
アタッチメントに関連するネットワークの経路を伝播させることで、経路を手動で登録する手間を減らせます。
ただし、プロパゲーションだけですべてのルーティング設定が完了するわけではありません。
VPC側にも適切なルート設定が必要
TGWに経路が登録されていても、VPC側のルートテーブルに相手のネットワーク宛ての経路がなければ通信できません。
また、セキュリティグループなどの設定も疎通に影響します。
TGWのルートテーブルを分けると、通信経路を制御できる
異なるルートテーブルにアタッチメントを関連付けると、利用するルートテーブルが分かれます。
ただし、ルートテーブルを分けただけで必ず通信できなくなるわけではありません。
必要な経路が登録されているかどうかが重要です。
今回の検証を通して、TGWの基本的な仕組みや、VPC間通信に必要なルーティング設定を確認できました。
AWSのネットワークを学ぶ際は、実際にリソースを作成し、設定を変更しながら動作を確認してみると理解が深まると思います。
