Transit Gateway に複数の VPC を接続するとき、VPC 間で自由に通信させたくない場合があります。
例えば、Transit Gateway にそれぞれアタッチメントで接続している共有リソース VPC とアカウント A の VPC、アカウント B の VPC があり、共有リソース VPC と他の VPC は相互に通信させたいが、アカウント A の VPC とアカウント B の VPC の間は通信させたくない、といったケースです。
この時、一つの Transit Gateway ルートテーブルに全てのアタッチメントを関連付けてしまうと、VPC ルートテーブルの設定次第では全ての VPC 間で通信ができてしまいます。
そこで、Transit Gateway アタッチメントごとに Transit Gateway ルートテーブルを分離し、適切に設定することで、通信させたくない VPC 同士が誤って通信することを防ぐようにします。
Transit Gateway ルートテーブル分離の概要図
アカウント A に二つの VPC（共有リソース VPC、アカウント A VPC）があり、アカウント B にも VPC（アカウント B VPC）があり、それぞれの VPC のサブネットから Transit Gateway にアタッチメントで接続します。
また、共有リソース VPC にある VPN Instance 経由でオンプレミスとも接続されています。
オンプレミスと共有リソース VPC からはアカウント A VPC とアカウント B VPC の両方へ通信ができるが、アカウント A VPC とアカウント B VPC の間は通信できないようにします。
共有リソース VPC に接続されたアタッチメントを関連付けた Transit Gateway ルートテーブルには共有リソース VPC、アカウント A VPC、アカウント B VPC、オンプレミスへのルートを設定します。
一方、アカウント A VPC とアカウント B VPC の Transit Gateway ルートテーブルにはそれぞれ共有リソース VPC とオンプレミスへのルートのみを設定しています。
図では省略していますが、各 VPC ルートテーブルにも通信させたいルートを追加する必要があります。それでは実際に検証していきます。
Transit Gateway の設定
Transit Gateway の作成
アカウント A で、デフォルトルートテーブルの関連付けと伝搬は、アタッチメント作成時に自分で設定したいので、これらのチェックをオフにして Transit Gateway を作成します。
Transit Gateway アタッチメントの作成
接続先の VPC とサブネットを選んで Transit Gateway アタッチメントを作成します（本当は AZ ごとに Transit Gateway 用サブネットを作成してアタッチメントを接続するのがベストですが、検証のためテスト用のサブネットのみに直接アタッチメントを接続しています）。
Transit Gateway ルートテーブルを作成
アタッチメントの数だけ Transit Gateway ルートテーブルを作成します。関連付けや伝搬、静的ルートの追加は後で行います。
Transit Gateway を別アカウントへ共有する
Resource Access Manager で相手アカウントへ Transit Gateway をリソース共有
Resource Access Manager でアカウント A の Transit Gateway をアカウント B へ共有します。
Transit Gateway 用のマネージド型アクセス許可があるのでそのまま使用します。
共有したいアカウント B の AWS アカウント ID を設定します。
Resouce Access Manager でリソース共有の承認
アカウント B の Resource Access Manager でアカウント A からの Transit Gateway のリソース共有を承認します。
共有された Transit Gateway へアタッチメントを作成
アカウント B からアカウント A の Transit Gateway にアタッチメントが作成できるようになったので作成します。アカウント A に承諾されるまでアタッチメントは有効になりません。
作成された別アカウントからの Transit Gateway アタッチメントの承認
アカウント B が作成した Transit Gateway アタッチメントを承諾します。
VPC 間で通信させないための Transit Gateway ルートテーブルの設定
各 VPC とオンプレミスのサブネットの状況
各 VPC とオンプレミスのサブネットと、接続する Transit Gateway アタッチメント、アタッチメントが関連付けられるルートテーブルの状況は次のとおりとします（分かりやすくするためサブネットごとではなく VPC 全体の CIDR ブロックにルートを設定することにします）。
| 場所 | サブネット | TGW アタッチメント | 参照する TGW ルートテーブル |
|---|---|---|---|
| オンプレミス | 10.1.0.0/16 | Attachment 1 | Route Table 1 |
| 共有リソース VPC | 10.128.0.0/16 | Attachment 1 | Route Table 1 |
| アカウント B VPC | 10.129.0.0/16 | Attachment 2 | Route Table 2 |
| アカウント A VPC | 10.130.0.0/16 | Attachment 3 | Route Table 3 |
共有リソース VPC へ接続するアタッチメントに関連付ける Transit Gateway ルートテーブル
アタッチメントの Transit Gateway ルートテーブルへの関連付け（共有リソース VPC）
共有リソース VPC へ接続するアタッチメント（Attachment 1）を、Transit Gateway ルートテーブル（Route Table 1）に関連付けます。
アタッチメントから Transit Gateway ルートテーブルへの伝搬（共有リソース VPC）
アタッチメントが直接接続しているルートを Transit Gateway ルートテーブルへ伝搬させるようにします。
Transit Gateway ルートテーブルへ静的ルートを追加（共有リソース VPC）
共有リソース VPC には全ての VPC とオンプレミスと通信したいため、共有リソース VPC が参照する Transit Gateway ルートテーブルには全てのサブネットへの静的ルートを設定します。
| 宛先サブネット | 向かう TGW アタッチメント | ルートタイプ | 備考 |
|---|---|---|---|
| 10.128.0.0/16 | Attachment 1 | 伝搬 | 共有リソース VPC |
| 10.1.0.0/16 | Attachment 1 | 静的 | オンプレミス |
| 10.129.0.0/16 | Attachment2 | 静的 | アカウント B VPC |
| 10.130.0.0/16 | Attachment3 | 静的 | アカウント A VPC |
VPC ルートテーブルへ Transit Gateway への静的ルートを追加（共有リソース VPC）
Transit Gateway ルートテーブルへルートを追加しただけでは、肝心の VPC から宛先サブネットへのネクストホップが分からない状態のため、Transit Gateway を介して通信させたいサブネットへのネクストホップは Transit Gateway であるという静的ルートを共有リソース VPC ルートテーブルに追加します。
| 宛先サブネット | ネクストホップ | 備考 |
|---|---|---|
| 10.128.0.0/16 | local | 共有リソース VPC |
| 10.1.0.0/16 | VPN インスタンスの ENI | オンプレミス |
| 10.129.0.0/16 | TGW | アカウント B VPC |
| 10.130.0.0/16 | TGW | アカウント A VPC |
アカウント B VPC へ接続するアタッチメントに関連付ける Transit Gateway ルートテーブル
アタッチメントの Transit Gateway ルートテーブルへの関連付け・伝搬（アカウント B VPC）
同様にアカウント B VPC へ接続するアタッチメント（Attachment 2）を、Transit Gateway ルートテーブル（Route Table 2）に関連付け、伝搬の設定をします。
Transit Gateway ルートテーブルへ静的ルートを追加（アカウント B VPC）
アカウント B VPC は共有リソース VPC とオンプレミスとのみ通信したいため、アカウント B VPC が参照する Transit Gateway ルートテーブルにはこれらのサブネットへのみの静的ルートを設定します。
通信させたくないアカウント A VPC へのルートを追加しないことで、アカウント A VPC への通信をできないようになるわけです。
| 宛先サブネット | 向かう TGW アタッチメント | ルートタイプ | 備考 |
|---|---|---|---|
| 10.129.0.0/16 | Attachment2 | 伝搬 | アカウント B VPC |
| 10.128.0.0/16 | Attachment 1 | 静的 | 共有リソース VPC |
| 10.1.0.0/16 | Attachment 1 | 静的 | オンプレミス |
VPC ルートテーブルへ Transit Gateway への静的ルートを追加（アカウント B VPC）
アカウント B VPC の VPC ルートテーブルにも Transit Gateway への静的ルートを設定します。
なお、ここでもし誤って（または悪意を持って）アカウント A VPC への静的ルートを追加したとしても、上記 Transit Gateway ルートテーブルにルートがないため、通信はできないようになります。
| 宛先サブネット | ネクストホップ | 備考 |
|---|---|---|
| 10.129.0.0/16 | local | アカウント B VPC |
| 10.128.0.0/16 | TGW | 共有リソース VPC |
| 10.1.0.0/16 | TGW | オンプレミス |
アカウント A VPC へ接続するアタッチメントに関連付ける Transit Gateway ルートテーブル
アカウント B VPC への設定と同じです。適切に Transit Gateway ルートテーブルを設定することで、アカウント B VPC への通信をできないようになります。
Transit Gateway ルートテーブルは適切に分離しよう
以上のとおり、Transit Gateway に接続する複数の VPC 間の通信を制御したい場合は、アタッチメントごとにルートテーブルを分けるようにしましょう。最初は全ての VPC 間の通信ができて良くても、後で制御したくなる場合はあると思うので、最初からこのように設計すると良いと思います。
識者にとっては「何を当たり前のことを……」と思われるかもしれませんが、自分はどこの設定が通信の制御に関わっているかうまく説明できなかったので、今回検証してみることで理解でき、勉強になりました。