【入門編】マルチAZ構成におけるNATゲートウェイの冗長化とゾーン障害時のフェイルオーバー – クラウド＆コンテナネットワーク実践ガイド

壊れないネットワークの作り方：NATゲートウェイと「郵便局」の意外な共通点

こんにちは！SREの現場で日々ネットワークのトラブルと格闘しているエンジニアです。

皆さんは、AWSやGCPでインフラを組むとき、「マルチAZ（可用性ゾーン）」という言葉を聞いたことはありますか？「なぜわざわざお金をかけて、複数のゾーンに分ける必要があるの？」と思う方も多いはずです。

今日は、そんなインフラ構築の登竜門であり、本番環境の生命線でもある「NATゲートウェイの冗長化」について、難しい専門用語はなるべく置いておいて、身近な「郵便局」に例えて解説していきます。

—

NATゲートウェイは「外の世界へつながる唯一の郵便局」

まず、NATゲートウェイ（NAT GW）の役割をイメージしてみましょう。

プライベートサブネットにあるサーバーたちは、セキュリティのために「引きこもり」状態です。外から直接アクセスできない代わりに、自分たちからも外の世界（インターネット）へ直接出ていくことはできません。でも、アップデートのパッチをダウンロードしたり、APIを叩いたりしたい時はありますよね。

そこで登場するのが、NATゲートウェイです。これは、プライベートなエリアにあるサーバーが、外へ手紙（パケット）を出すための「郵便局」です。

プライベートサブネット： 住民しかいない住宅街
NATゲートウェイ： 外の世界へ手紙を届けてくれる郵便局
インターネットゲートウェイ： 郵便局から外の世界へ続く、唯一の幹線道路

この郵便局がないと、住宅街の住人は外の世界から隔離されてしまいます。だからこそ、この「郵便局」が止まってしまうと一大事なのです。

—

なぜ「1つ」ではダメなのか？：ゾーン障害の恐怖

もし、郵便局が1つしかなかったらどうでしょう？
その郵便局がある場所で地震（＝AZ障害）が起きたら、もうその住宅街からは手紙が出せなくなります。サービス全体がストップしてしまう、これが「単一障害点」の怖さです。

これを防ぐために、各AZに個別のNATゲートウェイを配置するという設計が、プロの現場では「当たり前」の選択になります。

AZ-aの郵便局は、AZ-aの住人の手紙を運ぶ
AZ-bの郵便局は、AZ-bの住人の手紙を運ぶ

こうすれば、仮にAZ-aで災害が起きても、AZ-bの郵便局は元気に稼働しているので、サービス全体の停止を防げるのです。これが「冗長化」の基本戦略です。

—

現場で使う構成：ルートテーブルによる「交通整理」

さて、実際にどうやって「各AZの郵便局」を使わせるのか、その仕組みを見てみましょう。ここで主役になるのが「ルートテーブル」です。

ルートテーブルは、いわば住民に配られる「地図」です。「外へ行くなら、この郵便局を通ってね」と書かれた案内図ですね。

# AZ-aのサブネット向けルートテーブル（例）
宛先: 0.0.0.0/0 (インターネット全般)
ターゲット: nat-0123456789abcdef (AZ-aにあるNATゲートウェイ)

# AZ-bのサブネット向けルートテーブル（例）
宛先: 0.0.0.0/0 (インターネット全般)
ターゲット: nat-9876543210fedcba (AZ-bにあるNATゲートウェイ)

もしAZ-aが全滅したとしても、AZ-bのルートテーブルは「AZ-bの郵便局」を指し示しているため、通信は影響を受けずに走り続けます。これが、マルチAZ構成の真骨頂です。

—

実践：TerraformでNATゲートウェイを構築するヒント

実際にインフラをコードで書く（IaC）場合、以下のようにAZごとにNATゲートウェイを定義します。

# AZ-a用のNATゲートウェイ
resource "aws_nat_gateway" "nat_a" {
  allocation_id = aws_eip.nat_a.id
  subnet_id     = aws_subnet.public_a.id # AZ-aのパブリックサブネットに配置
  
  tags = { Name = "nat-gateway-az-a" }
}

# AZ-b用のNATゲートウェイ
resource "aws_nat_gateway" "nat_b" {
  allocation_id = aws_eip.nat_b.id
  subnet_id     = aws_subnet.public_b.id # AZ-bのパブリックサブネットに配置
  
  tags = { Name = "nat-gateway-az-b" }
}

このように、「サブネット」と「NATゲートウェイ」を同じAZで揃えることが、ネットワーク設計の鉄則です。これを怠ると、ゾーンをまたぐ通信が発生して「AZ間転送コスト」がかさんだり、通信が遅延したりする原因になります。

—

最後に：完璧なシステムなんてない、だから備える

「NATゲートウェイを全AZに置くのはコストがかかる」という意見もあります。確かに、NATゲートウェイは維持費がかかるサービスです。

しかし、障害が起きた時に「通信が全滅して、深夜に叩き起こされる」というリスクと、コストを天秤にかけてみてください。ビジネスを止めないための「保険」として、この設計は非常にコスパが良い投資だと私は考えています。

ネットワークは目に見えませんが、郵便局の例えのように、パケットたちは今日もどこかで、誰かが作った地図（ルートテーブル）に従って、せっせと手紙を届けています。

もし今度、クラウドの管理画面を開いたら、「この郵便局はどこに立っているのかな？」と想像してみてください。きっと、より頼もしいアーキテクチャが描けるはずですよ！

それでは、また次回のブログでお会いしましょう。ハッピーなクラウドライフを！