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からインターネット通信をさせることが可能です。本記事の後半では、実際に同じ構成を作っていきます。公式のハンズオンもあるので、こちらも是非お試しください。
Transit Gatewayの用語
Transit Gatewayを理解するには、Transit Gatewayの用語を理解しておくことが重要です。
アタッチメント
VPCやVPN、Direct ConnectをTransit Gatewayに関連付けるアクションです。対象をTransit Gatewayで管理するための最初のアクションです。ただし、アタッチメントをしただけで通信はできません。
ルートテーブル
いわゆるルートテーブルです。通信経路を制御します。なお、デフォルトの状態では、1つのTransit Gatewayあたりに作成可能なルートテーブルは20までです。
アソシエーション
アタッチメントとルートテーブルを関連付けする作業です。これによりアタッチメント間で通信を行うことができます。1つのアタッチメント（1つのVPC）が、複数のルートテーブルにアソシエーションすることはできません。
プロパゲーション
アタッチメントしたVPCをルートテーブルに伝播する機能です。これにより、スタティックルートを定義せずに自動でルートテーブルを更新することができます。
Transit Gateway peeringは、プロパゲーションができないので注意が必要です。
デフォルト動作
デフォルトの設定では、「デフォルトルートテーブルの関連付け」、「デフォルトルートテーブル伝播」が有効になっています。
この設定が有効になっていると、アタッチメントしたVPCがデフォルトで作成されるルートテーブルに、自動でアソシエーションとプロパゲーションされます。
Transit Gatewayで気を付けるポイント
Transit Gatewayで気を付けるポイントをまとめていきます。公式から設計のベストプラクティスもでていますので、こちらもご確認ください。
VPC側のルートテーブル編集
Transit Gatewayに接続されたVPC側でも、ルートテーブルの編集が必要です。
ルートテーブルでは、アタッチメントをターゲットとして設定します。
アソシエーションの付け替え
アソシエーションを異なるルートテーブルに付け替える場合、既存のアソシエーションを削除して、新しいルートテーブルでのアソシエーションが必要です。その際、ダウンタイムが発生するので注意が必要です。
Transit Gateway越しのセキュリティグループ参照
Transit Gateway越しのVPC間では、セキュリティグループの参照はサポートされません。そのため、通信させたい宛先のCIDRを指定する必要があります。
Transit Gateway専用サブネットの作成
Transit Gateway用の専用サブネットを作成することがベストプラクティスです。アタッチメント作成時に、サブネットの指定が必要になり、指定したサブネットにENIが作成されます。
なお、AZごとに一つのサブネットを指定することができ、当然マルチAZ構成で冗長化することが推奨です。
やってみる
冒頭で触れたように、次の構成を作成していきます。目標は、右下のEC2の通信をNetwork Firewallで監査し、最終的に10.1.0.0/16のVPCにあるNat Gatewayからインターネット通信をさせることです。
前提環境
本記事では、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を作成します。今回は、「デフォルトルートテーブルの関連付け」、「デフォルトルートテーブル伝播」を無効にし、その他はデフォルトで作成していきます。
アタッチメントの作成
アタッチメントを作成します。次の設定を行い、3つのVPCすべてにアタッチメントを作成します。指定していない設定についてはデフォルトのままとします。
- 名前：任意の名前（わかりやすい名前にしましょう）
- Transit Gateway ID：上記で作成したTransit GatewayのIDを選択
- VPC ID：各VPCのID
- サブネット ID：Transit Gateway用サブネットのID
ルートテーブルの作成
ルートテーブルを作成します。今回はFirewallVPCと、それ以外のVPCで分けるため、2つのルートテーブルが必要になります。名前は任意ですが、私は「DefaultRouteTable」、「FirewallRouteTable」という名前をつけました。
アソシエーションの設定
アソシエーションを設定します。各ルートテーブルに、アタッチメントをアソシエーションします。
- DefaultRouteTable：BoundaryVPC、PrivateVPC
- FirewallRouteTable：FirewallVPC
ルートテーブルの編集
まず、「DefaultRouteTable」のルートテーブルを編集します。今回は、EC2からの通信をNetwork Firewallで監査するように構成します。そのため、FirewallVPC以外のVPCからの通信をすべてFirewallVPCに向けてあげる必要があります。BoundaryVPCの通信もFirewallVPCに向けるのは、帰りの通信もNetwork Firewallを経由するためです。
▼行きの通信
▼帰りの通信
設定としては、全通信をFirewallVPCのアタッチメントに向けるようにします。
| CIDR | アタッチメント |
|---|---|
| 0.0.0.0/0 | FirewallVPC |
続いて、「FirewallRouteTable」の編集です。Firewallからは、各CIDRの通信を適切な宛先に返せるようするため、次のように設定します。
| CIDR | アタッチメント |
|---|---|
| 0.0.0.0/0 | BoundaryVPC |
| 10.1.0.0/16 | BoundaryVPC ※今回の通信上は不要 |
| 10.3.0.0/16 | PrivateVPC |
VPCルートテーブルの編集
前半で触れたように、VPC側のルートテーブル編集も必要になります。各サブネットで図の通りのルートテーブルになるよう設定します。（赤字部分追加だけになるはず）
接続してみる
PrivateVPCにEC2を起動し、実際の動きを確認してみます。今回はWindows Serverでウェブサイトにアクセスしてみます。
試しにAWSの公式ページにアクセスしてみます。問題なく通信できることがわかります。（そもそもSSMで繋いでいるので、インターネット通信できるのはわかってましたが）
次に接続元IPアドレスを確認してみます。確認すると、Nat GatewayにアタッチされたElastic IPアドレスであることを確認できました。
最後に、Network Firewallで「aws.amazon.com」へ通信ができないように設定し、再度AWSの公式ページにアクセスします。
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/