AWS Transit Gateway を用いて NAT Gateway を集約し、コストを最適化するための経路設計

マネージドサービス部佐竹です。
以前 NAT Gateway 集約のためのネットワーク設計においてトラブルを発生させてしまったことがあり、その再発防止のためのブログを記載します。

はじめに
NAT Gateway 集約と経路設計
ハマり（躓き）ポイント
- View reverse path について
まとめ

はじめに

各 VPC ごとに NAT Gateway を構築した場合

上図のような構成があるとします。VPC が3つあり、それぞれに NAT Gateway が存在する構成です。

このように、VPC ごとに NAT Gateway を用いる構成では NAT Gateway の費用が嵩みます。特に AWS Organizations を用いたマルチアカウント構成でこの実装を行うと、AWS アカウントごとに NAT Gateway が増えてしまい、将来的には意図せずコスト増につながってしまう危険が高いでしょう。

NAT Gateway の利用料

aws.amazon.com

念のため、ここで NAT Gateway の利用料をみてみましょう。

上記公式ドキュメントより引用すると、東京リージョンにおいては「NAT ゲートウェイあたりの料金 (USD/時)」として「0.062USD」が毎時間発生します。他にも通信料が発生するのですが、今回は「保持しているだけで発生してしまう」利用料にフォーカスします。

そしてこの利用料は NAT Gateway 1つあたりの利用料のため、これを複数の Availability Zone (AZ) で作成する場合、AZ の数だけ利用料が増えていきます。2つの AZ を利用すると仮定した場合、2倍の費用が発生します。

2つの AZ で利用する場合、NAT Gateway は単純計算で年間「$0.062 * 2 AZ * 24 * 365 = $1,086.24」の保持費用がかかります*1。

さらに、AWS アカウントが仮に100アカウントあり、各アカウントで NAT Gateway を2つずつ作成してしまうと、この費用が100倍になってしまいます。現在の為替レート（150円換算）であれば年間1,630万円程度です*2。

大規模なユーザ様では AWS アカウントが100以上に増えることは珍しくありません。ということで、特にマルチアカウントを運用するにあたっては NAT Gateway を予め集約しておくことでコストが最適化される場合があります。

AWS Transit Gateway を用いて集約する

AWS Transit Gateway (TGW) を利用すれば、AWS アカウントを跨いで VPC 間を接続可能です。これにより、NAT Gateway を集約することができます。

今回は社内検証アカウント内で検証作業を完結させたいため、都合1つの AWS アカウント内に構築した3つの VPC を利用し NAT Gateway への経路を集約していきます。

というわけで、ここから本題です。

NAT Gateway 集約と経路設計

AWS Transit Gateway を用いて NAT Gateway を集約するために必要な経路設計について記載していきます。

経路の設計（及び設定）でどのように躓いていったのかも、構成図と合わせて記載します。

Transit Gateway を構築する

まずは Transit Gateway を構築します。基本的には VPC 間をフルメッシュで相互通信を「可」とするため、以下の設定を有効にして作成しておきます。

Default association route table : Enable
Default propagation route table : Enable

この設定をしておけば、新規に作成された VPC に TGW アタッチメントを作成するだけで経路情報が自動的に交換（Propagation）されてお互いのフルメッシュ接続が可能となります。

構成図にすると上図の通りです。また VPC Subnet のルートテーブルにおいても設定変更が必要であるため、表形式で合わせて記載しました。今現在はまだ、各 VPC においてそれぞれの NAT Gateway を向いた経路になっています。

なお、先に記載した通り今回は1つの AWS アカウントで検証を行っていますが、マルチアカウントの場合においてはネットワーク専用の AWS アカウントに構築することが一般的です。今回は図の中央にある「VPC B」の NAT Gateway を残してここに NAT への経路を集約するため、「VPC B」をマルチアカウントにおけるネットワークアカウントに見立ててください。

Transit Gateway Attachment (Type VPC) を各 VPC で作成する

各 VPC 用の TGW Attachment を作成します。

TGW Attachment を作成すると、自動的に経路情報が TGW のデフォルトルートテーブルに Propagation されるため、上図のように各 VPC 同士が繋がります。デフォルトの TGW ルートテーブルは No.1 として①の形で図に記載している通りで、各 TGW Attachment に紐付けされています。

なお、構成図の通り VPC 用の TGW Attachment 作成時に指定する必要がある「各 VPC の Subnet」はベストプラクティスに則り「TGW Attachment 専用に用意した Subnet」を利用してください。

構成図に記載した TGW のルートテーブルは短縮して記載しています。実際は上画像の通りの経路が設定されます。

「VPC A」と「VPC C」の Subnet の経路を修正し、 NAT Gateway を削除する

ということで、VPC Subnet の経路を集約するために修正していきます。

まずは TGW Attachment 用の Subnet のルートテーブルですが、ここは「local」のみあれば良いとなりますので、左側「VPC A」と右側「VPC C」の NAT Gateway への経路を消します。

左側「VPC A」と右側「VPC C」の Public Subnet の「0.0.0.0/0」を TGW へ向けます。また、Private Subnet も同様に「0.0.0.0/0」を TGW へ向けます。その後「VPC A」と「VPC C」の NAT Gateway を削除します*3。

一度ここで経路確認を行ってみる

さて、ここまでの作業の段階で左側「VPC A」から中央「VPC B」の NAT Gateway を通じて IGW に抜けられるでしょうか？

上図の通りですが、抜けられません。TGW Attachment を通じて TGW にまでは到達しますが、TGW が「0.0.0.0/0」の経路を理解できていないためです。

Transit Gateway のルートテーブルに「0.0.0.0/0」を追加する

対応として、TGW のデフォルトルートテーブルに経路を手動で追加する必要があります。

向き先は中央「VPC B」の TGW Attachment の先となるため、「VPC B」の TGW Attachment を指定して Static ルートを TGW ルートテーブルへ追加します。

Reachability Analyzer での動作確認

さて、ここまでの設定を完了したところで、Reachability Analyzer を用いて「VPC A」に構築した EC2 インスタンスから「VPC B」の IGW への経路が疎通可能か、判定してみましょう。

結果としては「Reachable」となりました。となると「論理的には繋がる」ということです。

ただし、この状態では実際「疎通は不可能」です。何故でしょうか？

それは「戻りのルートがない」ためです。具体的には、中央「VPC B」の NAT Gateway の配置された Public Subnet のルートに「戻り」が記載されていないために疎通ができない状態になります。

Reachability Analyzer の結果については、「行き」の経路は「論理的に繋がる」と判定してくれますが、「戻り」の経路は判定してくれていない点に注意が必要です。

「VPC B」の Public Subnet のルートテーブルに「戻り」の経路を追加する

上図の通り、中央「VPC B」の Public Subnet のルートテーブルに「戻り」の経路を追加します。「VPC A」と「VPC C」の CIDR を記載し、それぞれの「戻り」を明示的に記載します。

この戻りの宛先は「TGW の向こう側にある」ことになるため、Target は TGW を指定することになります。

この通り記載すれば無事に「戻り」も疎通が可能となります。

ハマり（躓き）ポイント

ハマったポイントとしては、私が実装したときは先の通り「Reachability Analyzer」の結果だけを見て"良し"としてしまい、この「戻り」の経路を書き忘れてしまいました。このために、一時的に「VPC A」と「VPC C」がインターネットに抜けられないという事態に陥った期間が出てしまいました。

合わせて、本来であれば「VPC A」の Private Subnet に EC2 インスタンスを構築し、実際にインターネットに抜けられるのか動作確認をすべきだったのですが、少額ではあるもののコストの発生を鑑みて「実施しなかった」ことも反省点です。

View reverse path について

Reachability Analyzer の Analysis explorer には、Path details のすぐ下に「View reverse path」というボタンがあります。

これは「戻りのルート」を確認することが可能な機能なのですが今回はこれが利用できません。

An unidirectional path will be shown if analysis involves Transit Gateway. と記載があり、ボタンがグレーアウトしています。説明の通り、TGW が経路上に含まれている場合にはこの機能が利用できません。

では戻りのルートを Reachability Analyzer で新規に別の Path として「Create and analyze path」すれば良いかというと、これもまた厳しいです。IGW から EC2 インスタンスへの経路は、From が IGW になってしまいます。この場合は、EC2 インスタンスの Security Group で Inbound を別途解放する必要があるなど、本来の利用用途からズレた経路になってしまいます。

ですため、やはり動作確認時には実際に EC2 インスタンスを構築しての疎通確認がベストでしょう。

まとめ

本ブログでは、AWS Transit Gateway を用いて NAT Gateway を集約し、コストを最適化するための経路設計についてステップバイステップで解説を行いました。

また複数の AWS 環境構成図を用いてその設定の変遷を図示しました。Reachability Analyzer での動作確認の注意点や「戻り」を書き忘れるという躓きポイントも合わせて記載しています。

最後にまとめとして、「経路設計のまとめ」と「構築順」について記載しておきます。

経路設計のまとめ「行き」

左側「VPC A」から中央「VPC B」の NAT Gateway へ疎通させるための「行き」の経路設計は、以下の4つの経路設計が必要です。

「VPC A」の Subnet ルートテーブルで「0.0.0.0/0」を TGW へ向ける
TGW のルートテーブルに「0.0.0.0/0」を追加し「VPC B」の TGW Attachment へ向ける
「VPC B」の TGW Attachment 用の Subnet ルートテーブルで「0.0.0.0/0」を追加し NAT Gateway へ向ける
「VPC B」の NAT Gateway 用の Subnet ルートテーブルで「0.0.0.0/0」を IGW へ向ける

③と④については、既に実装されている場合が多いでしょう。①と②を忘れずに実装してください。

経路設計のまとめ「戻り」

「VPC B」の NAT Gateway 用の Subnet ルートテーブルに「VPC A」及び「VPC C」への経路を追加し TGW へ向ける
TGW のルートテーブルで各 VPC への経路を記載する*4
「VPC A」及び「VPC C」の TGW Attachment 用の Subnet ルートテーブルでは「local」によって「戻り」が完了する

戻りでは特に「①」を忘れないように実装ください。

設定作業の順序について

今回は理解の都合、先に NAT Gateway を消してしまっているのですが、正しいと思われる設定作業の順序を記載しておきます。

Transit Gateway を構築する
Transit Gateway Attachment (Type VPC) を各 VPC で作成する
Transit Gateway のルートテーブルに「0.0.0.0/0」を追加する
「VPC B」の Public Subnet のルートテーブルに「戻り」の経路を追加する
「VPC A」と「VPC C」の Subnet の経路を修正し、 NAT Gateway を削除する

以上になります。