AWSの「NATゲートウェイ」を攻略せよ！冗長化の仕組みと「見えないコスト」の正体
こんにちは！クラウドの深淵を覗き込み、インフラの泥臭いトラブルを愛してやまないSREエンジニアです。
皆さんはAWS VPCを設計する際、プライベートサブネットにあるサーバーが「どうやってインターネットと通信しているか」を意識したことはありますか？そこで登場するのがNATゲートウェイです。
今回は、「NATゲートウェイを複数並べるとなぜ安心なのか？」「そこに隠れたコストの罠とは？」という、現場で必ず直面するけれど意外と曖昧にされがちなテーマを、身近な例えを交えて紐解いていきましょう。
—
1. NATゲートウェイは「郵便局の集荷係」
まず、NATゲートウェイの役割をイメージしてみましょう。
プライベートサブネットにあるEC2インスタンスは、外部（インターネット）から直接話しかけられることはありません。セキュリティ上の理由で「外の世界と直接繋がっていない」からです。でも、アップデートの取得などで外に出たいときはありますよね。
そんな時、NATゲートウェイは「外の世界へ荷物を出しに行く集荷係」として働いてくれます。
- プライベートサブネットのサーバー： 宛先を書いた荷物を集荷係（NATゲートウェイ）に預ける。
- NATゲートウェイ： 「差出人は私（NAT）にしておきますね！」と荷物を書き換え、インターネットへ運び出す。
この仕組みがあるからこそ、私たちは安全にインターネットへ通信できるのです。
—
2. なぜNATゲートウェイを「複数」置くのか？（冗長化の魔法）
もし、集荷係がたった一人（1つのAZ）しかいなかったらどうなるでしょう？もしその人が病気（AZの障害）で倒れてしまったら、そのエリアのすべての通信がストップしてしまいます。
これを防ぐのがマルチAZ構成です。
各アベイラビリティゾーン（AZ）に一つずつNATゲートウェイを配置します。すると、もし「AZ-a」の集荷係がトラブルで動かなくなっても、「AZ-c」の集荷係が代わりに荷物を運んでくれる……といった冗長化が可能になります。
注意点：フェイルオーバーは自動ではない！
ここが一番の落とし穴です。「NATゲートウェイを2つ置けば、自動で切り替わってくれるんでしょ？」と期待してはいけません。
AWSのNATゲートウェイは、「どのサブネットのルートテーブルが、どのNATゲートウェイを指しているか」という設定に依存します。
AZ-aのルートテーブル：0.0.0.0/0->nat-gw-aAZ-cのルートテーブル：0.0.0.0/0->nat-gw-c
もし nat-gw-a がダウンしても、AZ-a のサブネットは「壊れた nat-gw-a」を指し続けます。これを救うには、自動スクリプト等でルートテーブルを書き換える仕組み（またはRoute 53 Resolverの活用など）が必要になるんです。
—
3. 「クロスAZコスト」という見えない請求書
さて、ここからがSREとしての腕の見せ所です。
「じゃあコストを抑えるために、NATゲートウェイは1つだけにして、全AZからそこにアクセスさせよう！」と考える方がいます。
これは絶対にやってはいけません。
なぜか？
NATゲートウェイを置いたAZ以外から通信を送ると、「クロスAZデータ転送コスト」という、いわゆる「通行料」が発生するからです。
- 同AZ通信： 荷物を近所の郵便局へ持っていく（無料）
- 別AZ通信： 荷物をわざわざ隣の県まで運んでから出す（有料）
塵も積もれば山となります。特に通信量が多いプロダクション環境では、この「通行料」だけで月額数万円〜数十万円の差がつくこともあります。NATゲートウェイは「AZごとに配置する」のが、コストと可用性のバランスを取る黄金律なのです。
—
4. 実践：Terraformで構成する際のポイント
最後に、インフラ構築時の設定サンプルを見てみましょう。Terraformで各AZにNATをデプロイするイメージです。
# AZ-a用のNATゲートウェイ定義
resource "aws_nat_gateway" "nat_a" {
allocation_id = aws_eip.nat_a.id # 固定IPを割り当て
subnet_id = aws_subnet.public_a.id
tags = { Name = "nat-gw-az-a" }
}
# AZ-a用のルートテーブル（プライベートサブネットからNATへ）
resource "aws_route" "private_to_nat_a" {
route_table_id = aws_route_table.private_a.id
destination_cidr_block = "0.0.0.0/0"
nat_gateway_id = aws_nat_gateway.nat_a.id # ここでAZ-aのNATを指定！
}このように、「サブネットが存在するAZと、NATゲートウェイが存在するAZを一致させる」ことが、パフォーマンスとコスト効率の基本になります。
—
まとめ：一歩ずつ理解を深めよう
今回お伝えしたかったポイントは以下の3つです。
1. NATゲートウェイは「外の世界へ荷物を運ぶ集荷係」と捉える。
2. 冗長化は大切だが、自動フェイルオーバーにはルートテーブルの更新戦略が必要。
3. 「クロスAZ通信」はインフラの隠れたコスト要因。 基本はAZごとに配置しよう。
ネットワークは目に見えない分、最初は難しく感じるかもしれません。でも、パケットの流れを郵便配達のルートのように想像してみると、途端に愛着が湧いてくるはずです。
皆さんの設計が、今日も安全で、かつコスト効率の良いものになりますように！また次の記事でお会いしましょう。
コメント