はじめに
本記事は「AWS Transit Gateway ハンズオン」を実施した際のメモです。
AWS Transit Gateway（以降、TGW と呼ぶ）は今まで設定や管理が複雑になりがちなVPCやオンプレ間の接続を簡略化するネットワークの中継ハブです。
本ハンズオンを実施することで、さまざまなユースケースに応じたTGWの設定方法を体験しながら学ぶことができます。
自分の理解のため、皆さんが理解しやすくするため、構成図を書きました。
このハンズオンを実施する方への副読本のようなものとなればうれしいです。
ハンズオンの主なアジェンダ
- Lab1: TGWによるVPC間接続
- Lab2: 別のアカウントのVPCからTGWを経由して接続する
- Lab3: TGWルートテーブルを使用し、トラフィックの分離する
- Lab4: TGW Peeringで別リージョンのTGW同士を接続する
- Lab5(option): セキュリティ VPC で全ての VPC 間トラフィックを監査する（今回は未実施）
メモ
ゴール
- 同一アカウント、同一リージョンにある複数のVPC間を通信するTGWの設定を理解する
- 別アカウントにあるVPC間を通信するTGWの設定を理解する
- TGWルートテーブルでハブアンドスポークアーキテクチャを実現する方法を理解する
- 同一アカウント、別リージョンにあるTGW同士をピアリングする設定を理解する
- TGWを通過する通信をAWS Network Firewallで監視する設定を理解する（今回は未実施）
用語
TGW関連の用語である以下の用語についてはリンクを参照ください。
- ルートテーブル
- アタッチメント
- アソシエーション
- プロパゲーション
Lab1
TGWを作成した段階での通信状態は以下の通りであり、PrivateVPC1からInternetへのアクセスができません（図中①）。
| Src\Dst | 192.168.1.100 | 10.0.1.100 | Internet(amazon.co.jp) |
|---|---|---|---|
| BoundaryVPC(192.168.1.100) | (ok) | OK | OK |
| PrivateVPC1(10.0.1.100) | OK | (ok) | NG |
これはTGWルートテーブルに「インターネット向きの経路（デフォルトルート）」が存在しないからです。
BoundaryVPCのTGWアタッチメントへのデフォルトルートを追加することでインターネットへ通信させることができます(図中②)。
最終的にNG部分はOKになります。
| Src\Dst | 192.168.1.100 | 10.0.1.100 | Internet(amazon.co.jp) |
|---|---|---|---|
| BoundaryVPC(192.168.1.100) | (ok) | OK | OK |
| PrivateVPC1(10.0.1.100) | OK | (ok) | OK |
Lab2
別アカウント(今回はAccount2)にTGWを使用してもらうにはResource Access Manager(RAM)を使用します。
まず、TGW所有アカウント側(今回はAccount1)でRAMを使用し、TGWをAccount2に共有する設定を行います。
次に、Account2側でTGWの共有を許可します(図中①)。
以上で、TGWを別アカウントに使用させることができます。
その後はAccount2側でTGWアタッチメントを作成し、Account1のTGWと関連付けをしたり(図中②)、
Account2のVPCルートテーブルに経路を追加することで（図中③）、Account1、Account2間の通信をTGW経由で行うことができます。
| Src\Dst | 192.168.1.100 | 10.0.1.100 | 10.1.1.100 | Internet(amazon.co.jp) |
|---|---|---|---|---|
| BoundaryVPC(192.168.1.100) | (ok) | OK | OK | OK |
| PrivateVPC1(10.0.1.100) | OK | (ok) | OK | OK |
| PrivateVPC2(10.1.1.100) | OK | OK | (ok) | OK |
Lab3
Lab2の段階ではBoundaryVPC、PrivateVPC1、PrivateVPC2がそれぞれ相互に接続できる状態です。
TGWルートテーブルを変更することでPrivateVPC1、PrivateVPC2間の直接通信を禁止することができます。
既存のTGWルートテーブル(TGWRoute1)はPrivateVPC1、PrivateVPC2とTGWアタッチメントとの関連付けを持っています。
これにより、PrivateVPC1、PrivateVPC2からTGWの通信はTGWRoute1によって制御されています。
PrivateVPC1、PrivateVPC2間の通信を禁止するためTGWRoute1からこれら関連付けを削除します(図中①)。
次に、PrivateVPC1、PrivateVPC2からのTGWへの通信制御をするため、新しいTGWルートテーブル(TGWRoute2)を作成します。
そして、TGWRoute1の方で削除していた、PrivateVPC1、PrivateVPC2のTGWアタッチメントの関連付けを追加します。
最後に経路を追加します。PrivateVPC1、PrivateVPC2からデフォルトルートへのアクセスをBoundaryVPCへ転送する経路を追加します。
また、PrivateVPC1、PrivateVPC2間で通信させないようBlackholeルート(今回は10.0.0.0/15)を追加します(図中②)。
以上により、PrivateVPC1、PrivateVPC2間の通信を禁止することできました。
| Src\Dst | 192.168.1.100 | 10.0.1.100 | 10.1.1.100 | Internet(amazon.co.jp) |
|---|---|---|---|---|
| BoundaryVPC(192.168.1.100) | (ok) | OK | OK | OK |
| PrivateVPC1(10.0.1.100) | OK | (ok) | NG | OK |
| PrivateVPC2(10.1.1.100) | OK | NG | (ok) | OK |
Lab4
別リージョン(今回はus-east-1)と現在リージョン(今回はap-northeast-1)のTGWを相互通信するためには、Transit Gateway inter-Region Peeringを使用し、別リージョンのTGWと現在リージョンのTGWの関連付けを行います。
まず、ap-northeast-1のTGWとus-east-1のTGWを関連付けするため、Peering Connection型のTGWアタッチメント(以降、Peeringアタッチメント)をap-northeast-1で作成します(図中①)。
次に、上記関連付けリクエストをus-east-1側で承認します。
そして、ap-northeast-1からPeeringアタッチメント経由して、us-east-1のVPC(PrivateVPC3)と通信するため、TGWRoute1にPeeringアタッチメントへの静的ルートを追加する(図中②)。
最後に、us-east-1のPrivateVPC3からap-northeast-1へアクセスするため、us-east-1のTGWルートテーブルにPeeringアタッチメントへのデフォルトルートを追加する(図中③)。
| Src\Dst | 192.168.1.100 | 10.0.1.100 | 10.1.1.100 | 10.2.1.100 | Internet(amazon.co.jp) |
|---|---|---|---|---|---|
| BoundaryVPC(192.168.1.100) | (ok) | OK | OK | OK | OK |
| PrivateVPC1(10.0.1.100) | OK | (ok) | NG | OK | OK |
| PrivateVPC2(10.1.1.100) | OK | NG | (ok) | OK | OK |
| PrivateVPC3(10.2.1.100) | OK | OK | OK | (ok) | OK |
ハンズオンの感想
TGWの設定は最初理解に苦しみましたが、図解してみると容易になりました。
VPCピアリングを実行した方ならわかると思いますが、TGWを使用するよりも手順がだいぶ面倒です。
使いこなせば、構築や運用管理の負荷が大幅に軽減されるサービスだと感じました。