はじめに
Transit Gateway（以降、TGW）がGAされてAWSのネットワーク構成がよりシンプルにできるようになりました。
さらにTGWのルートテーブルで集中管理ができるため、運用保守がより容易になったかと思います。
今回、私がTGWを導入・移行する上で構成比較と検討観点をまとめてみました。
前提
- TransitGatewayの導入を検討していて、構成比較や導入観点を参考にしたい方向けとなっています。
- こちらの記事はAWSネットワークサービスについて、ある程度わかっていることが前提となっております。
TransitGatewayとは
AWS Transit Gateway は、中央ハブを介して VPC とオンプレミスネットワークを接続します。これにより、ネットワークが簡素化され、複雑なピア接続関係がなくなります。
TGW導入の構成の違い
TGWの導入を検討する上でVPC PeeringとDirectConnectの構成が大きな要素となってきます。
そこでTGW導入における構成の比較を以下に記載しました。
①VPC Peering構成とTGW構成の違い
◆VPC Peering構成イメージ
構成図上からも分かる通り、基本的には各VPCのルートテーブルでルーティング管理をします。
Peering数が多いほどルート数も増え、また特定のVPCのみ通信するという場合は、各VPCのルートテーブル上で制御する必要があります。
VPC Peeringの数が多いほどルーティング管理が複雑化します。
◆VPC間通信におけるTGW構成イメージ
TGW構成では構成が簡素化され、TGWのルートテーブルを定義することでルート情報を一括管理することができます。
またTGWで複数ルートテーブルを用意することで、VRF（Virtual Routing and Forwarding）1 のように環境毎にルーティング情報を分離することができます。
なお、VPCルートテーブルでは通信したいVPC CIDRに対してTGWをネクストホップとするルートを登録する必要があります。
②個別DirectConnect接続構成とTGW集約構成
◆個別DirectConnect（以降、DX）構成イメージ
各VPCに対してDXを接続しており、各VPC毎に帯域幅を確保できます。
VPCのルートテーブルにはオンプレミス宛てのルートがルート伝搬有効化で自動登録されます。
またオンプレミスの特定NWのみ通信させる場合は、各VPC毎にBGPで広報するプレフィックスを制御することができます。
ただし、オンプレミス側のNW機器側の設定が複雑になり、ルーティング管理が大変となります。
◆TGWによるDX集約構成イメージ
DXをTGWに接続することで複数VPCでDXを共有化することができます。
またTGWのルートテーブルを定義することでルート情報を一括管理することができます。
なお、VPCルートテーブルでは通信したいオンプレミスNWに対してTGWをネクストホップとするルートを登録する必要があります。
個別DX接続と異なり共有化するため、BGPで広報するルートはまとめて広報する必要があります。
詳細比較
①VPC Peering構成とTGW構成の違い
VPC PeeringとTGWの構成における比較を表にしてみました。
| VPC Peering | TGW | |
|---|---|---|
| コスト | 〇：コストなし | △：TGWのAttachmentに月額コストがかかる |
| 管理運用 | △：各VPCでピアルートを管理 | 〇：TGWルートテーブルでルート情報を集中管理 |
| 構成 | △：フルメッシュの場合は構成が複雑となる | 〇：ハブ＆スポーク構成の簡素化が見込める |
| パフォーマンス | 〇：ルートテーブルに登録できる数がデフォルト50であり、最大 1,000 まで引き上げ可能である。帯域幅のボトルネックはなし。 | 〇：ルートテーブルあたりに登録できるルート数は10,000である。最大帯域幅は50Gbps。 |
※データ転送量は考慮しておりません
- コスト：VPC Peeringは無料であるのに対し、TGWはAttachmentの数だけ課金されます。
例えば、10個のVPCをTGW構成で接続する場合、月額504USD (0.07USD/時 * 24時間 * 30日 * 10VPC)となります。
コストだけ考えるとVPC Peeringで接続した方が明らかに良いです。 - 管理運用：VPC Peeringの数が20以上ある場合、各VPCにあるルートテーブルには20以上のルート情報を管理することになります。TGW構成でVPC側のルートテーブルにはルート集約してTGWに向けてしまい、TGW側で制御して管理するやり方ができればメリットありそうです。
- パフォーマンス：基本的にはどちらもボトルネックとなりそうな箇所はなさそうです。
注意点
①TGW専用サブネットの必要性：TGW Attachmentのアタッチで指定する際にTGW専用サブネットを作成することが推奨されております。以下のQ＆Aにも記載がありますが、インライン監査用途等のEC2のENIをルートテーブルでルート定義していると影響があるみたいです。導入前に既存VPCにTGW専用サブネットを用意できるか確認することをおすすめします。
Q. VPC をアタッチするときに指定するサブネットをアタッチ専用のサブネットとする必要性について、もう少し具体例を挙げて説明していただきたいです。そのサブネットの内部のEC2 インスタンスのルーティングに影響あるとのことでしたが、どのような影響があるのか？などを教えていただきたいです。
A. Transit Gateway (TGW) のアタッチメントがついているサブネットと同一のサブネットに EC2 インスタンスが存在する場合に、その EC2 インスタンスはTGWと同じルーティングテーブルを参照します。
例えば インライン監査用の VPC の TGW の ENI がある Subnet 上に EC2 インスタンスを設置してしまうと、その EC2 インスタンスは必ずインライン監査のミドルボックス ENI に吸い込まれてしまい、EC2 インスタンスの意図するルーティングテーブルを作れなくなってしまいます。こういったことを防ぐために、TGW 専用のサブネットを作ることをお薦めしています。
②TGW専用サブネットの考慮：AZ冗長でEC2を構築しており他VPCとのAZ間通信が必要な場合は、TGW Attachmentで指定するサブネットはAZ冗長としてください。以下のスライド（p.19）にも記載があるのですが、AZ間の通信フローでは同一AZのTGW ENIを使用して通信が行われます。
②個別DirectConnect接続構成とTGW集約構成
各VPCにDX接続している構成とTGW構成としてDXを集約する構成の比較を表にしてみました。
| 個別DX構成 | TGW集約構成 | |
|---|---|---|
| コスト | -：DX帯域幅の指定次第ではあるが各DXのコスト発生 | -：DXを集約してDX（最小帯域幅は1Gbps）のコスト発生 |
| 管理運用 | -：BGP伝搬によるルート自動登録 | -：TGWルートテーブルへのBGP伝搬によるルート登録 |
| 構成 | △：DXの数が多い場合、複雑性は増す | 〇：DX集約できるのでシンプルな構成となる |
| パフォーマンス | 〇：VPC個別にDX帯域幅を確保できる | △ or 〇：DXを共用することになるので、事前に調査しないと干渉する恐れあり |
-
コスト：集約するDXの数と帯域幅次第であるので、一概にどちらが安いかは言い難いです。以下は参考例です。
例1）50MbpsのDXを10VPC（冗長として20本）の場合、月額417.6USD + α(DXパートナの料金)
1GbpsのDX集約（冗長として2本）の場合、月額452.16USD + α(DXパートナの料金)
例2）50MbpsのDXを20VPC（冗長として40本）の場合、月額835.2USD + α(DXパートナの料金)
1GbpsのDX集約（冗長として2本）の場合、月額452.16USD + α(DXパートナの料金) -
管理運用：オンプレミスとAWS間のルーティング設計次第であるので、一概にどちらが運用管理として良いかは言い難いです。基本的にはルート伝搬でルート情報の登録がなされます。仮にNW機器も運用管理する方は、個別DXにおけるBGP設定やルート制御が複雑になるので運用負荷は高くなります。
注意点
①Transit VIFの帯域幅：最低帯域幅は1Gbpsであるため、その分の物理線等の帯域幅確保の検討が必要です。
②BGP広報ルートの制限：AWSからオンプレミスへのルート広報上限は 20 です。上限緩和はできません。
各比較の結論
①VPC PeeringとTGWの構成
TGW構成のコスト増の懸念があり、10～20のVPC Peeringで運用がまかなえる場合はTGW構成でなくても良いと感じました。
ルーティングに関するトラブルシュート回避や管理運用を簡素化したい場合は、TGWの導入を検討しても良いかもしれません。
またTGWを導入することでVPC Peeringの制限であるVPCまたぎの通信不可がなくなるので、セキュリティ専用VPC（IPS/IDS）や外向け通信用VPC（インターネット出口）といったVPCにルーティングさせることが可能となります。
②個別DirectConnect接続構成とTGW集約構成
20個以上のDXをTGWで集約する場合はコスト減がかなり見込めると思います。ただし、制約として最低帯域幅やBGP広報ルートには注意しないといけません。
運用管理としてはDXのみ集約化してTGWを導入しても大きな差はないように感じます。オンプレミスNWのみTGWへ通信させるためにルート管理をVPC側で行う必要があると思うので、TGW側で一括管理はできないと思います。
Virtual Private Gateway + DX Gatewayの構成も可能なので、無理にTGWを利用する必要性はないと思います。
※IPアドレス設計やルーティング設計次第では一括管理はできる場合もあると思います。
①と②の単体比較すると重きを置く観点次第で移行・導入の箇所が変わるかと思います。
ただし、①と②を組み合わせて利用すると大きなメリットを得られるので、どちらも検討可能であるならば以下の「導入事例」を参考にしてみてください。
導入事例
私の場合は①、②のを組み合わせて以下のような構成でコストと運用管理の複雑性を解消させました。
結論から言うと、①と②の課題部分を各構成が補うような形になります。
- コスト：コスト減となりました。「TGW Attachmentにかかるコスト増」より「DX集約化によるコスト減」の方が大きかったので、結果的にはコスト減となっております。（DX数20以上を集約）
- 管理運用：TGWのルートテーブルで一括管理できるようになりました。クラスA,B,Cのプライベートアドレスを一律TGWに通信するようにVPCルートテーブルを設計し、各VPCとオンプレミスへの通信はTGWルートテーブルで制御します。
- 構成：かなり簡素化されました。
最後に
TGW導入における私なりの検討観点と導入メリットをお伝えしました。
各会社の設計思想やセキュリティ要件等があると思うので、必ずしも私の検討観点が当てはまるものではありません。
そのため、参考程度に読んでいただけますと幸いです。
TGW移行方法の詳細は別途、記事にしていきたいと思います。
またTGWの自動化も導入したので、こちらも記事にしていきたいと思います。
-
1つのルータ上で独立した複数のルーティングテーブルを保持できる技術です。（https://www.infraexpert.com/study/mpls5.html） ↩