AWS Transit Gatewayを図解しながら理解する

# Transit Gatewayとは
Transit GatewayはVPCとオンプレネットワークの通信を管理する**リージョンのコアルーター**です。VPCをつなげるサービスとしてVPC peeringがありますが、VPCの数が増えるとVPC peeringも膨大になり管理が複雑になります。それに対し、Transit Gatewayを利用すると、1箇所で通信を管理し、ネットワークを簡素化することができます。

例えば次のような構成を作ることが可能です。ルートテーブルの設定によって、右下のEC2の通信をNetwork Firewallで監査し、最終的に10.1.0.0/16のVPCにあるNat Gatewayからインターネット通信をさせることが可能です。本記事の後半では、実際に同じ構成を作っていきます。[公式のハンズオン](https://catalog.us-east-1.prod.workshops.aws/workshops/e0d1c19d-c80b-4695-a3fc-5c4a25132f47/ja-JP/2-hands-on/2-5-lab5)もあるので、こちらも是非お試しください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/f10a7926-bfd6-99ad-0d59-4f36a6043365.png)

# Transit Gatewayの用語
Transit Gatewayを理解するには、Transit Gatewayの用語を理解しておくことが重要です。
## アタッチメント
VPCやVPN、Direct ConnectをTransit Gatewayに関連付けるアクションです。対象をTransit Gatewayで管理するための最初のアクションです。ただし、アタッチメントをしただけで通信はできません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/a2d84557-db46-1c84-ee61-c6523ef0c489.png)

## ルートテーブル
いわゆるルートテーブルです。通信経路を制御します。なお、デフォルトの状態では、[1つのTransit Gatewayあたりに作成可能なルートテーブル](https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/transit-gateway-quotas.html#routing-quotas)は20までです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/e816c1b7-794a-d0d2-3c22-cd81972d67b3.png)

## アソシエーション
アタッチメントとルートテーブルを関連付けする作業です。これによりアタッチメント間で通信を行うことができます。1つのアタッチメント（1つのVPC）が、複数のルートテーブルにアソシエーションすることはできません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/aff8327d-3130-29dd-fa05-af76e81165dd.png)

## プロパゲーション
アタッチメントしたVPCをルートテーブルに伝播する機能です。これにより、スタティックルートを定義せずに自動でルートテーブルを更新することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/f97c8dff-1d87-036a-6fd7-840fe1f7e822.png)

:::note warn
Transit Gateway peeringは、プロパゲーションができないので注意が必要です。
:::

# デフォルト動作
デフォルトの設定では、「デフォルトルートテーブルの関連付け」、「デフォルトルートテーブル伝播」が有効になっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/75c12fa5-d3fe-d853-05a6-b3ff87b91c1c.png)

この設定が有効になっていると、アタッチメントしたVPCがデフォルトで作成されるルートテーブルに、自動でアソシエーションとプロパゲーションされます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/fb1e1ae4-e826-d6f1-8d7e-adbbfb0f2096.png)

# Transit Gatewayで気を付けるポイント
Transit Gatewayで気を付けるポイントをまとめていきます。公式から[設計のベストプラクティス](https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-best-design-practices.html)もでていますので、こちらもご確認ください。

## VPC側のルートテーブル編集
Transit Gatewayに接続されたVPC側でも、ルートテーブルの編集が必要です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/f8ad2d43-e0fd-caaa-3691-606a1a3fa17a.png)

ルートテーブルでは、アタッチメントをターゲットとして設定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/377cd93f-4cd3-1841-ef19-a4f9d1edb0b3.png)

## アソシエーションの付け替え
アソシエーションを異なるルートテーブルに付け替える場合、既存のアソシエーションを削除して、新しいルートテーブルでのアソシエーションが必要です。その際、ダウンタイムが発生するので注意が必要です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/0d5962f4-d8cd-e542-cce0-bd5595c39829.png)

## Transit Gateway越しのセキュリティグループ参照
Transit Gateway越しのVPC間では、セキュリティグループの参照はサポートされません。そのため、通信させたい宛先のCIDRを指定する必要があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/8c7f18b3-005a-2545-fe68-2f374c35b9df.png)

:::note warn
2024/9/5より、セキュリティグループを参照するインバウンドセキュリティルールを作成できるようになりました。
https://aws.amazon.com/jp/blogs/news/introducing-security-group-referencing-for-aws-transit-gateway/
:::

## Transit Gateway専用サブネットの作成
Transit Gateway用の専用サブネットを作成することが[ベストプラクティス](https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-best-design-practices.html)です。アタッチメント作成時に、サブネットの指定が必要になり、指定したサブネットにENIが作成されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/d8c1e311-5556-d240-6687-ae868c6c8d3c.png)

なお、AZごとに一つのサブネットを指定することができ、当然マルチAZ構成で冗長化することが推奨です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/9a13b735-f32f-6f98-889b-e36511dab16a.png)

# やってみる
冒頭で触れたように、次の構成を作成していきます。目標は、右下のEC2の通信をNetwork Firewallで監査し、最終的に10.1.0.0/16のVPCにあるNat Gatewayからインターネット通信をさせることです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/8022707a-d78b-2918-8b66-ad8adb4a6a1b.png)

## 前提環境
本記事では、VPC、Nat Gatewayへのルーティング設定、Network Firewallは作成されている前提で、作業を行っていきます。本記事では便宜上、各VPCを下記のように名付けます。

* 10.1.0.0/16のVPC：BoundaryVPC
* 10.2.0.0/16のVPC：FirewallVPC
* 10.3.0.0/16のVPC：PrivateVPC

## Transit Gatewayの作成
まずTransit Gatewayを作成します。今回は、「デフォルトルートテーブルの関連付け」、「デフォルトルートテーブル伝播」を無効にし、その他はデフォルトで作成していきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/dc8f9e53-ec2c-4f75-1ce8-a88cea5ca467.png)

## アタッチメントの作成
アタッチメントを作成します。次の設定を行い、3つのVPCすべてにアタッチメントを作成します。指定していない設定についてはデフォルトのままとします。
* 名前：任意の名前（わかりやすい名前にしましょう）
* Transit Gateway ID：上記で作成したTransit GatewayのIDを選択
* VPC ID：各VPCのID
* サブネット ID：Transit Gateway用サブネットのID
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/32392115-4e2e-62ab-062f-2a70d49a25a0.png)

## ルートテーブルの作成
ルートテーブルを作成します。今回はFirewallVPCと、それ以外のVPCで分けるため、2つのルートテーブルが必要になります。名前は任意ですが、私は「DefaultRouteTable」、「FirewallRouteTable」という名前をつけました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/3d4a98db-5bf1-5a71-f07c-ce657cd45c7f.png)

## アソシエーションの設定
アソシエーションを設定します。各ルートテーブルに、アタッチメントをアソシエーションします。
* DefaultRouteTable：BoundaryVPC、PrivateVPC
* FirewallRouteTable：FirewallVPC
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/abe5a4e1-fda7-e63b-7e3b-4e1a4ddcc289.png)

## ルートテーブルの編集
まず、「DefaultRouteTable」のルートテーブルを編集します。今回は、EC2からの通信をNetwork Firewallで監査するように構成します。そのため、FirewallVPC以外のVPCからの通信をすべてFirewallVPCに向けてあげる必要があります。BoundaryVPCの通信もFirewallVPCに向けるのは、帰りの通信もNetwork Firewallを経由するためです。

▼行きの通信
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/3caa730e-9b28-5747-f7fc-fba1ec381aa6.png)

▼帰りの通信
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/4392e7f0-a4a5-a5ae-abcf-b5ba44a71d38.png)

設定としては、全通信をFirewallVPCのアタッチメントに向けるようにします。
| CIDR | アタッチメント |
|:-:|:-:|
| 0.0.0.0/0  | FirewallVPC |

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/23ae6081-a6a4-40b4-819d-f11bbac7be37.png)


続いて、「FirewallRouteTable」の編集です。Firewallからは、各CIDRの通信を適切な宛先に返せるようするため、次のように設定します。
| CIDR | アタッチメント |
|:-:|:-:|
| 0.0.0.0/0  | BoundaryVPC |
| 10.1.0.0/16  | BoundaryVPC ※今回の通信上は不要　|　
| 10.3.0.0/16  | PrivateVPC |

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/f2aaa8e3-1799-4395-815f-ada54e451afe.png)


## VPCルートテーブルの編集
前半で触れたように、VPC側のルートテーブル編集も必要になります。各サブネットで図の通りのルートテーブルになるよう設定します。（赤字部分追加だけになるはず）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/a36e88fd-7ba2-c690-cfd0-088ebf953593.png)

## 接続してみる
PrivateVPCにEC2を起動し、実際の動きを確認してみます。今回はWindows Serverでウェブサイトにアクセスしてみます。

試しにAWSの公式ページにアクセスしてみます。問題なく通信できることがわかります。（そもそもSSMで繋いでいるので、インターネット通信できるのはわかってましたが）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/554d099d-344a-c809-431a-1f2b1d594f44.png)

次に接続元IPアドレスを確認してみます。確認すると、Nat GatewayにアタッチされたElastic IPアドレスであることを確認できました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/1be1db32-cddb-2fc4-e83c-a5e4fca2b66b.png)

最後に、Network Firewallで「aws.amazon.com」へ通信ができないように設定し、再度AWSの公式ページにアクセスします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3075801/741d1e44-502b-881b-fa8c-691a9cd508d4.png)

Network Firewallで通信を監査していることが確認できました。

# 参考
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/what-is-transit-gateway.html
https://catalog.us-east-1.prod.workshops.aws/