【入門編】可用性ゾーン(AZ)障害耐性を考慮したマルチAZ NATゲートウェイ配置設計 – クラウド＆コンテナネットワーク実践ガイド

こんにちは！クラウドの世界へようこそ。第一線でSRE（サイト信頼性エンジニア）をしている私です。

日々のインフラ運用の中で、「なぜクラウドの設計書には、あんなにもたくさんの細かいルールや冗長化の仕組みが書かれているんだろう？」と疑問に思ったことはありませんか？
特に、インターネットとの出入り口である「NATゲートウェイ」や「サブネット」の話になると、途端に図面が複雑になって頭がクラクラしてしまいますよね。

でも、安心してください。難解に見えるクラウドのネットワークも、私たちの身の回りにある「現実世界の仕組み」に置き換えてみると、驚くほどすんなり理解できるようになります。

今回は、インフラやネットワークに初めて触れる方に向けて、「可用性ゾーン（AZ）障害耐性を考慮したマルチAZ NATゲートウェイ配置設計」という、ちょっと噛みごたえのあるテーマを、郵便配達のストーリーになぞらえて優しく紐解いていきたいと思います。一歩ずつ、一緒に理解していきましょう！

—

1. そもそも「NATゲートウェイ」ってどんな存在？（身近な例え話）

まずは、NATゲートウェイの役割からおさらいしましょう。

クラウドの世界では、セキュリティをしっかり守るために、私たちが普段動かしているサーバー（プライベートサブネットにあるサーバー）には、直接インターネット側の住所（グローバルIPアドレス）を持たせないのが鉄則です。

でも、「サーバーだってOSのアップデートのために外部のパッケージを取りに行きたい」「外部のAPIと通信したい」という時がありますよね。そんなとき、「社内の代表者」として外の世界へお使いに行ってくれる頼れる代理人が「NATゲートウェイ」です。

郵便局の本局をイメージしてみよう

これを身近な例えで考えてみましょう。
あなたの会社（プライベートサブネット）が、外の取引先（インターネット）に手紙を出したいとします。しかし、会社のメンバーは外部の住所を直接持ってはいけないルールになっています。

そこで、会社の門のところに「専用の郵便ポスト兼、差出人スタンプを押してくれる受付窓口」を置きます。これが NATゲートウェイ です。

社内のメンバーは、とりあえずその窓口に手紙を投函する。
窓口の係員（NATゲートウェイ）は、手紙の差出人名を自分の名前に書き換えて、外の世界へ送り出してくれる。
返事が返ってきたら、係員が宛先を確認して、社内の正しいメンバーに手紙をそっと渡してくれる。

この仕組みのおかげで、サーバーの安全性を保ったまま、安全に外の世界と通信できるようになるわけです。素晴らしい仕組みですよね！

—

2. 「すべてを1箇所にまとめる」危険性と、その結末

さて、ここで一つ大きな疑問が湧いてきます。
「この便利な窓口（NATゲートウェイ）、わざわざあちこちに置くのは面倒だし、お金もかかるから、真ん中にドンと1つだけ置けばいいんじゃないの？」

実はこれ、インフラ初心者が一番やりがちな「うっかりポイント」なんです。

クラウドサービス（AWSやGCPなど）は、自然災害や予期せぬハードウェアの故障に備えて、物理的に離れた複数の建物（これを可用性ゾーン（AZ）と呼びます）を用意してシステムを分散配置します。

もし、この大切なNATゲートウェイを、Aという建物の中に「1つだけ」ポツンと置いていたとしましょう。普段はすこぶる順調に動きます。
しかし、ある日突然、Aの建物がある地域で電源トラブルや大きな障害が起きてしまいました。

単一障害点（SPOF）の恐怖

Aの建物が機能停止した瞬間、何が起きるでしょうか？

Aの建物にあるサーバーはもちろん動かなくなります。
さらに恐ろしいことに、別の無事な建物（Bの建物）で動いているサーバーまで、外の世界と通信ができなくなってしまいます。 なぜなら、みんなで共有していたたった一つの「お使い窓口（NATゲートウェイ）」がAの建物と一緒に倒れてしまったからです。

これは、会社全体の連絡網や郵便局の本局が、たった1つのフロアの停電で完全に麻痺してしまうようなものです。ビジネスにおいては大惨事ですよね。

—

3. ベストプラクティス：マルチAZ NATゲートウェイ配置設計

このリスクを回避するために、クラウドのプロたちが実践しているのが 「マルチAZ NATゲートウェイ配置設計」 です。

考え方はとてもシンプル。
「主要な建物（AZ）ごとにお使い窓口（NATゲートウェイ）をそれぞれ独立して1つずつ置く」 というものです。

AZ-a（Aの建物）： AZ-a専用のNATゲートウェイを置く
AZ-c（Cの建物）： AZ-c専用のNATゲートウェイを置く

こうしておけば、万が一AZ-aで大障害が発生してその建物が機能しなくなっても、AZ-cにあるサーバーと「AZ-c専用のNATゲートウェイ」はびくともせず動き続けます。インターネットとの通信も、自動的に生き残っているルートに切り替わり、システム全体が全滅するのを防ぐことができるのです。

まさに、会社の本社機能や郵便窓口を複数の拠点に分散させておく、究極のリスクヘッジですね。

—

4. 実務で使える！インフラ構成のコード例（Terraform）

「なるほど、考え方はわかったけれど、実際の現場ではどうやって設定するの？」
そんな声にお応えして、大手クラウド（AWSを想定）でこのマルチAZ NATゲートウェイを構築するための設定コードのイメージを見てみましょう。

インフラをコードで管理するツール「Terraform」を使うと、次のように美しく定義することができます。

# =================================================================
# 可用性ゾーン(AZ)ごとのパブリックサブネットとNATゲートウェイの配置設計
# =================================================================

# 1つ目の可用性ゾーン（AZ-a）用のパブリックサブネット
resource "aws_subnet" "public_aza" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a" # 東京リージョン aゾーン

  tags = {
    Name = "pub-subnet-az-a"
  }
}

# 2つ目の可用性ゾーン（AZ-c）用のパブリックサブネット
resource "aws_subnet" "public_azc" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = "ap-northeast-1c" # 東京リージョン cゾーン

  tags = {
    Name = "pub-subnet-az-c"
  }
}

# --- AZ-a 用のElastic IP（固定のグローバルIP）の確保 ---
resource "aws_eip" "nat_aza" {
  domain     = "vpc"
  depends_on = [aws_internet_gateway.igw]

  tags = {
    Name = "eip-nat-az-a"
  }
}

# --- AZ-c 用のElastic IP（固定のグローバルIP）の確保 ---
resource "aws_eip" "nat_azc" {
  domain     = "vpc"
  depends_on = [aws_internet_gateway.igw]

  tags = {
    Name = "eip-nat-az-c"
  }
}

# --- AZ-a に配置する NATゲートウェイ ---
resource "aws_nat_gateway" "nat_aza" {
  allocation_id = aws_eip.nat_aza.id
  subnet_id     = aws_subnet.public_aza.id # AZ-aのパブリックサブネットに配置

  tags = {
    Name = "nat-gw-az-a"
  }
}

# --- AZ-c に配置する NATゲートウェイ ---
resource "aws_nat_gateway" "nat_azc" {
  allocation_id = aws_eip.nat_azc.id
  subnet_id     = aws_subnet.public_azc.id # AZ-cのパブリックサブネットに配置

  tags = {
    Name = "nat-gw-az-c"
  }
}

コードのポイント解説

それぞれのAZ（ap-northeast-1a と ap-northeast-1c）に、独立したパブリックサブネットを作っています。
外の世界と通信するための「看板（グローバルIPアドレス）」である aws_eip も、AZごとに別々のものを割り当てています。
結果として、nat_gw-az-a と nat_gw-az-c という2つの独立したNATゲートウェイが誕生し、片方が倒れてももう片方が生き残る強靭なネットワーク基盤が完成します。

—

5. コスト面でのトレードオフ、そしてSREとしての判断

ここまで読んで、「なるほど、完璧な設計だ！じゃあ3つのAZがあるなら、NATゲートウェイも3つ置こう！」と思ったそこのあなた。素晴らしい学習意欲です！

しかし、現場のSREとしては、ここで一つだけ現実的なお話をしなければなりません。
それは「コスト（費用）とのバランス」です。

NATゲートウェイというサービスは、残念ながら「置いておくだけ（時間単位）」で一定の固定費がかかります。さらに、そこを通過するデータ量（パケットの重さ）に応じた従量課金も発生します。
そのため、AZを3つ使っているからといって必ず3つすべてのAZにNATゲートウェイを配置しなければならないかというと、システム予算や求められるSLA（サービス品質保証）との相談になります。

実務での現実解

ミッションクリティカルな本番環境（金融、EC、大規模Webサービスなど）： 多少コストがかかっても、主要なAZすべて（最低2つ以上）にNATゲートウェイを配置し、障害耐性を最優先する。
検証環境や小規模な社内システム： コストを抑えるために、NATゲートウェイはあえて1つに絞り、万が一の障害時は「手動で作り直すか、復旧を待つ許容範囲」と割り切る。

このように、技術のベストプラクティスを理解した上で、「自分たちのシステムにとって、どこまでのお守りが必要か」をコストと天秤にかけて判断する。これこそが、一流のクラウドアーキテクトやSREの腕の見せ所なのです。

—

まとめ

今回は、マルチAZ NATゲートウェイ配置設計について、郵便配達の例えや実際のコードを交えて解説しました。

単一のNATゲートウェイへの依存は、システム全体の単一障害点（SPOF）になる。
複数のAZごとにNATゲートウェイを分散配置することで、片方が倒れても通信を継続できる高可用性を手に入れられる。
ただし、可用性とコストのトレードオフを意識して、システムの重要度に応じた適切な設計を選ぶことが大切。

難しく感じられたネットワークの仕組みも、裏側にあるストーリーを知ることで、ぐっと身近に感じられるようになったのではないでしょうか？
今回の知識が、あなたのこれからのクラウド設計やインフラ構築の現場で、少しでもお役に立てれば幸いです。

それでは、また次の技術でお会いしましょう！よきクラウドライフを！