導入・背景
ちょうど担当している案件でTransit Gateway(以下、TGW)を中心にしたネットワーク設計についてお客様向けに提案する機会がありました。
TGWの概要自体はドキュメントを読めばわかるのですが、実際に案件などで提案・設計しようとすると「TGWはいくつ立てるのが正解なのか」、「VPNの冗長構成はどうする」、「PrivateLinkやVPC Peeringとの使い分けは？」といった判断をすることになると思います。
本記事では自分が実際に設計を担当した内容をベースに、TGWを使ったネットワーク設計の判断基準を整理しておこうと思います。本記事は私の備忘録兼同じような構成を検討している方の参考になることを目的としています。
なお、本記事の内容は案件の内容を参考にしているため一部内容をぼかしております。ご容赦いただけますと幸いです。
想定読者
本記事は以下の読者を想定しています。
- AWSのネットワーク基礎知識(VPC・サブネット・ルーティング)があるインフラエンジニア
- TGWを使った設計にこれから取り組む、または既存設計を見直したい方
※基本的な用語・概念はある程度既知のものとして扱います。
想定シナリオ
以下の構成を前提に話を進めます。
| 項目 | 内容 |
|---|---|
| 想定シチュエーション | 複数支店(10〜数十拠点)とAWSとを接続するにあたってTGWを使ったネットワーク構成を検討する |
| 接続構成 | 各支店 → 集約端末(NAT/FW) → Site-to-Site VPN → Transit Gateway → VPC |
| 環境分離 | 本番・開発でTGWを分離 |
| VPN本数 | 本番2本(Active/Standby)、開発1本 |
| AWSアカウント | 単一アカウント運用(Network Account分離なし) |
| リージョン | 単一リージョン(ap-northeast-1) |
上記構成を構成図に落とし込むと以下のような構成図になります。本番のみ記載しておりますが、同様の構成が開発分もあるイメージになります。
上記構成の場合、NATの部分がSPOFになり得るのでここも冗長化しておく必要があります。
実際の案件だと「最初からマルチアカウント＋Direct Connect構成でガッツリやりましょう」となるケースよりも、「まずはSite-to-Site VPNでやってみて、必要に応じて拡張していく」ケースのほうが多い印象です。今回はこの現実的な出発点をベースに話を進めます。
1. TGWをいくつ立てるか
そもそもTGWを分ける必要はあるのか
大体の場合、最初に悩むのはこの部分になるのではないかと思っています。TGWはサービスの仕様上、ルートテーブルを複数持てるので1つのTGWの中でルートテーブルを分けるだけでも環境ごとの経路分離は実現できます。
ではどういうケースでTGW自体を分けるのかというと、主に以下の4つの軸で判断することになるかなと思います。
| 軸 | 内容 |
|---|---|
| セキュリティ境界 | 本番・開発を完全分離したい、テナント間の経路漏洩を防ぎたい |
| ルーティング複雑化の回避 | アタッチメント数が増えすぎてルートテーブル管理が破綻しそう |
| コスト最適化 | データ転送料の削減が優先課題 |
| 組織境界 | 事業部・会社単位でネットワーク管理責任を分けている |
今回のシナリオでTGWを2つにした理由
前述の通りルートテーブル分離だけでも本番・開発の経路分離は実現できますが、今回は以下の理由でTGWを本番・開発で分けています。
- 障害影響の完全分離：TGW自体の設定ミスや障害が本番に波及するリスクをゼロにしたい
- 権限管理の明確化：本番TGWへのアクセス権限を厳格に絞りたい
- 将来の拡張性：本番側のみDirect Connectを追加するといった個別拡張がしやすい
正直なところ、大半のケースではTGW1つ＋ルートテーブル分離で十分な気はしています。ただ、今回のお客様は本番環境の障害分離に対する要求が強かったためTGWごと分ける判断をしています。
本番障害の影響範囲を最小化したい場合はTGW分割が有効ですが、TGWを分けるとその分アタッチメント料金やVPN接続が増えるので、コストとのトレードオフになります。この辺りはお客様と合意を取っておくのが大事ですね。
2. Site-to-Site VPN設計
なぜ支店ごとにVPNを引かないのか
直感的には「支店・拠点ごとにVPNを張ればいいのでは？」と思うかもしれませんが、以下の理由から現実的ではありません。
- 支店数に比例してVPN接続コストが増加する($0.05/時間/接続 × 支店数)
- 支店ごとの機器調達・設定管理・障害対応コストが増加する
- 支店側のネットワーク設計を統制できないケースでは、CIDRの重複リスクがある
特に3つ目は意外と厄介で、支店が独自にネットワーク構成を組んでいると「192.168.1.0/24がAWSで定めていたCIDRと被っている」みたいなことが普通に起きます。
そういった場合には企業側に集約端末(NATやFW)を置き、そこからVPNを引く構成が現実的な落とし所なのかなと思います。集約端末でNATをかけることでCIDR重複の問題もある程度吸収できます。
大体の場合、AWSに移行してきて初めて直面する問題だと思うので、支店側のCIDRを変更するなんてことは現実的ではありません。
Site-to-Site VPNを本番で2本(Active/Standby)引く際の設計
本番環境では冗長性を確保するためVPNを2本構成にしています。
Active/Standby構成を選ぶ理由
VPNの冗長構成としてはECMPによる並列利用も選択肢にはなりますが、今回はActive/Standbyを採用しています。
| 観点 | Active/Standby | ECMP |
|---|---|---|
| 経路制御 | BGPのAS-PATH Prependingで明示的にActive/Standbyを制御 | 複数経路に均等分散 |
| 通信の対称性 | 常に1本の経路を通るため対称性が保たれる | 行きと帰りで異なる経路を通る可能性がある |
| ユースケース | 帯域が十分なケース | VPN1本の帯域(最大1.25Gbps)では足りないケース |
多くの案件ではActive/Standbyが採用される印象です。ECMPは帯域増強が明確に必要なケースでない限り、あえて選ぶ理由は薄いかなと思います。
それ以上に帯域が欲しい場合であれば、Direct Connectを利用した専用線を引くことを検討すべきかなと考えています。
VPN接続とトンネルの関係
ここは少しややこしいのですが、AWS側では1つのVPN接続に対して2つのトンネルエンドポイント(Tunnel 1/Tunnel 2)が払い出されます。これはVPN接続単位の冗長性であり、今回の「VPN接続を2本立てる」という話とは別のレイヤーです。
VPN接続①(Active) ─┬─ Tunnel 1 (Active) ← BGP AS-PATHを短くしてActiveに
└─ Tunnel 2 (Standby)
VPN接続②(Standby) ─┬─ Tunnel 1 (Standby) ← BGP AS-PATHを長くしてStandbyに
└─ Tunnel 2 (Standby)
Active/Standby構成の場合、VPN接続①のTunnel 1をActiveとしてBGPのAS-PATH Prependingで優先度を設定するのが一般的です。VPN接続②は普段はトラフィックが流れず、VPN接続①に障害が発生した場合にフェイルオーバーします。
こういったところは実際にSite-to-Site VPNを使ってみないとわからないところだったりするので、案件に携われる機会があるのであれば積極的に学ぶことをお勧めいたします。
コスト概算
VPN接続料金：$0.05 × 2本 × 730時間/月 ≒ $73/月
TGWアタッチメント料金(VPN)：$0.07 × 2本 × 730時間/月 ≒ $102.20/月
データ転送料：$0.02/GB(TGW経由のデータ処理料金)
VPN接続自体の費用はそこまで大きくないですが、TGWのアタッチメント料金も加わる点は忘れがちなので注意です。
実際に環境単位でTGWを分けた際にどれくらい費用感が変わるのかを試算してみました。これはあくまでも参考値のため実際の案件の使い方によって料金は変動します。
前提条件
- TGWアタッチメント料金：$0.07/時間
- VPN接続料金：$0.05/時間
- TGWデータ処理料金：$0.02/GB
- データ転送量：各環境100GB/月と仮定
- 1か月 = 730時間
| 項目 | 本番環境 | 開発環境 |
|---|---|---|
| TGWアタッチメント数 | 3個(VPN×2 + VPC×1) | 2個(VPN×1 + VPC×1) |
| TGWアタッチメント料金 | $0.07 × 3 × 730h = 153.30 | $0.07 × 2 × 730h = 102.20 |
| VPN接続料金 | $0.05 × 2本 × 730h = 73.00 | $0.05 × 1本 × 730h = 36.50 |
| データ処理料金 | $0.02 × 100GB = 2.00 | $0.02 × 100GB = 2.00 |
| 小計 | $228.30/月 | $140.70/月 |
合計：$369.00/月（約55,000円/月）
TGWを1つにまとめた場合はアタッチメント数が減る分コストを抑えられますが、今回は障害分離の要求を優先してTGWを分離しています。このあたりのコスト差をお客様に提示した上で判断を仰ぐのが重要になるかなと思います。
今回の場合はお客様の方でNATを用いて通信を集約することでTGWアタッチメントの数を減らすことができていました。しかし、各拠点から個別にSite-to-Site VPNを引く場合、TGWアタッチメントの数が増加するため費用にもかなり跳ねてきます。
開発1本の設計
開発環境はコスト優先・障害時の影響が限定的という判断から1本構成にしています。
- 開発環境が数時間落ちても業務影響は限定的
- VPN接続1本分＋TGWアタッチメント1本分のコスト削減になる
本番と開発で冗長レベルに差をつけるのはよくある話ですが、この判断もお客様と合意を取っておくべきポイントです。
3. TGWルートテーブル設計
基本構成
今回は本番・開発でTGWを分離しているので、各TGWがそれぞれ独立したルートテーブルを持つシンプルな構成です。
本番TGWのルートテーブル例
| 宛先CIDR | ネクストホップ | 用途 |
|---|---|---|
| 10.0.0.0/8 | VPNアタッチメント | 支店側ネットワークへの経路 |
| 172.16.0.0/16 | VPCアタッチメント | 本番VPCへの経路 |
開発TGWのルートテーブル例
| 宛先CIDR | ネクストホップ | 用途 |
|---|---|---|
| 10.0.0.0/8 | VPNアタッチメント | 支店側ネットワークへの経路 |
| 172.17.0.0/16 | VPCアタッチメント | 開発VPCへの経路 |
ルートテーブル設計のポイント
今回のシナリオではVPN接続とVPCアタッチメントを同一ルートテーブルに紐付けるシンプルな構成で十分です。
AWS上でのベストプラクティスではTGWのルートテーブルではVPC単位で粗めの制御を行い、詳細な設計については各サブネットのルートテーブル、NACLやSecurity Groupsで制御することを推奨しています。
制約値の確認
設計前に確認しておくべき上限値です。今回のシナリオ規模だと引っかかることはまずないですが、大規模環境では意識しておく必要があります。
| 項目 | デフォルト上限 | 備考 |
|---|---|---|
| TGWあたりのアタッチメント数 | 5,000 | VPC・VPN・Direct Connect Gateway等の合計 |
| TGWルートテーブルあたりのルート数 | 10,000 | スタティックルート＋伝播ルートの合計 |
| VPNあたりのBGP広報プレフィックス数 | 1,000 | オンプレ側からAWSへ広報できる経路数 |
| TGWあたりのルートテーブル数 | 20 | 上限緩和申請が可能 |
TGWを扱う案件をいくつかみてきていますが、流石に上記のクォータに達した案件は見たことはないですね...(念のためにルートテーブル数を引き上げたことはありますが、、、)
4. 補完技術の使い分け
TGWだけで全ての接続要件を満たせるわけではないので、PrivateLinkやVPC Peeringとの使い分けも整理しておきます。
PrivateLink
使う場面
- マルチテナントSaaS構成で、テナント間のルートを見せたくない
- サービス提供側のVPCネットワーク情報を接続元に開示したくない
TGWベースの接続はルートテーブルに経路が乗るため、接続元からサービス側のCIDRが見えてしまいます。これはセキュリティ的に問題になるケースがあって、例えばマルチテナント構成で「テナントAからテナントBのVPCのCIDRが見える」というのはなかなか許容されません。
PrivateLinkではこの問題を解消できて、エンドポイント経由のアクセスのみに制限されるため経路情報が漏れることがありません。
「最小限だけ穴あけを行いたい」という要望に対してはPrivateLinkが使えないかを検討すると良いかもしれません。PrivateLinkはあくまでサービス単位のアクセス提供に向いている仕組みであり、VPC間で広範囲に通信したい場合はTGWのほうが適しています。
VPC Peering
使う場面
- 同リージョン内・少数VPC間の接続でコストを最小化したい
- TGWを経由させる必要がないシンプルな1:1接続
VPC Peeringの最大のメリットはデータ転送料金がTGWより安い(同リージョンなら$0.01/GB)ことと、アタッチメント料金が不要なことです。VPC2つの間を繋ぐだけならTGWを立てるよりPeeringのほうがシンプルでコストも安いです。
使わないほうがいい場面
VPC数が増えるとフルメッシュ構成になり管理が破綻します。接続数はVPC数の二乗に比例して増えるので、VPC数が5〜6を超えてきたらTGWへの移行を検討したほうがいいです。
ちなみにVPC Peeringには推移的なルーティングができない(AとBがPeering、BとCがPeeringしていても、AからCへは通信できない)という制約もあるので、3つ以上のVPCが相互に通信する要件がある時点でTGWを検討するのが無難です。
5. アンチパターン
ここまでの内容を踏まえて「これはやらないほうがいい」と感じたパターンも整理しておきます。
① 全VPCをTGWに集約してルートテーブルが管理不能になる
TGWはアタッチメント数の上限が5,000もあるのでとりあえず全部繋いでしまいたくなるのですが、設計なしに全VPCを接続すると以下の問題が起きます。
- ルートテーブルが肥大化し、意図しない経路がアドバタイズされる
- 本番・開発・ステージング環境が同一ルートテーブルで混在して、環境間の経路が通ってしまう
「とりあえず全部デフォルトルートテーブルに関連付けておこう」は後から修正が大変になるので、最初から環境ごと・用途ごとにルートテーブルを分割しておくべきです。
特に意図しない経路がアドバタイズされる現象については注意が必要です。AWSのベストプラクティスでも不要な経路に対してはBlackholeを設定しなさいと記載があります。
② VPC Peeringを乱用してフルメッシュ地獄になる
4章でも触れましたが、VPCが増えるにつれてPeering接続数が二乗で増加します。
VPC数 5 → 最大10接続
VPC数 10 → 最大45接続
VPC数 20 → 最大190接続
最初は「VPC2つだしPeeringでいいか」から始まって、気づいたらVPCが増えてフルメッシュ地獄に陥る...というのは割とある話です。VPC数が増える見込みがある場合は最初からTGWを採用しておいたほうが後々楽です。
③ 支店ごとに個別VPNを張る
先ほど触れた通りですが、支店数が増えると管理コスト・金銭コストの両面で維持が困難になります。
特にお客様側で「各支店から直接AWSに繋ぎたい」という要望が出ることがありますが、コストとCIDR管理の面から難しい点についてはきちんと説明しておくのが大事です。
まとめ
本記事で扱った判断基準を表にまとめます。
| 判断軸 | 今回の判断 | 補足 |
|---|---|---|
| TGWの数 | 本番・開発で2つ | 原則1つで十分。障害分離の要求が強い場合に分割を検討 |
| VPN本数 | 本番2本(Act/Stby)、開発1本 | 開発の冗長レベルはお客様と合意を取っておく |
| Act/Stby vs ECMP | Active/Standby | 帯域増強が明確に必要なケースでなければAct/Stbyが無難 |
| PrivateLink | 今回は不採用 | テナント間の経路隠蔽やサービスVPCのCIDR非公開が必要な場合に採用 |
| VPC Peering | 今回は不採用 | 同リージョン・少数VPC・コスト優先の1:1接続のみ |
TGWは柔軟なサービスですが、その分だけ設計なしに使うと複雑になりがちです。
今回の記事で書いた内容はあくまでも1つの案件での判断であり、要件が変われば構成も変わります。ただ、「なぜその構成にしたのか」という判断基準の部分は他の案件でも使い回せるところが多いかなと思っているので、参考にしていただければ幸いです。
構成や判断について「こういうケースではどうするか？」といったご意見があればコメントいただけると嬉しいです。