【入門編】 マスカレードIPアドレス（Elastic IP）の動的割り当てとフロー制御 – クラウド＆コンテナネットワーク実践ガイド

こんにちは！SREとして日夜クラウドとコンテナの海を泳いでいるライターの私です。

クラウドインフラの構築に少し慣れてくると、必ずと言っていいほど直面するのが「外の世界（インターネット）とどうやって安全に通信するか」という壁ですよね。特に、プライベートな空間（プライベートサブネット）にいるサーバーたちから、どうやって安全に外へお使いに出かけるかという問題です。

今回は、そんなインフラの要である「NATゲートウェイ」と、そこに紐づく「マスカレードIPアドレス（Elastic IP）」の秘密に迫ります。
「なんだか専門用語が多くて難しそう……」と思った方も安心してください！一歩ずつ、身近な例えを交えながら優しく紐解いていきましょう！

—

1. そもそも「NATゲートウェイ」と「マスカレードIP」ってなに？

いきなりカタカナが並んでお腹いっぱいになりそうですが、まずは身近な世界に置き換えて考えてみましょう。

🏢 社内から外へ荷物を送る「総務部（NAT）」の仕組み

想像してみてください。あなたが秘密主義の巨大なオフィスビル（プライベートサブネット）の奥深くで働いているとします。あなたの部屋には外線電話（グローバルIPアドレス）が直接つながっていません。セキュリティ上の理由で、外の怪しい業者から直接あなたに電話がかかってこないようにするためです。

「でも、どうしても外のウェブサービスからデータをダウンロードしたい！」
そんなとき、どうしますか？

ここで登場するのが、総務部の窓口（NATゲートウェイ）です。
あなたは「このデータを取ってきて」と内線で総務部に頼みます。総務部の担当者は、あなたの代わりに会社の代表電話（Elastic IP）を使って外の相手とやり取りし、届いた荷物をあなたにこっそり届けます。

このとき、外の相手から見ると、通信しているのはあなたではなく「会社の代表電話」に見えていますよね。この「内側のプライベートなIPアドレスを、外向けの代表IPアドレスにこっそり書き換える（変装させる）技術」を、ネットワークの世界ではマスカレード（Masquerade：仮面舞踏会のような変装）と呼んでいます。

そして、クラウドの世界（AWSなど）でこの「会社の固定の代表電話番号」として割り当てられるのが、Elastic IP（EIP）というわけです。

—

2. なぜ複数IP（マルチEIP）が必要になるの？

「じゃあ、代表電話（Elastic IP）は1つあれば十分じゃないの？」と思いますよね。実はその通り、小規模なシステムなら1つで事足ります。

しかし、あなたの会社（システム）が大人気になって、世界中からものすごい数の注文（リクエスト）が押し寄せたとしましょう。たった1つの代表電話（1つのEIP）だけでは、電話回線がパンクしてしまいます。

TCP/IPの通信では、1つのIPアドレスから同じ宛先に同時につなげるコネクションの数に、物理的・論理的な限界（ポート枯渇問題）があります。
そこで必要になるのが、「複数のElastic IPをNATゲートウェイに束ねて使う（マルチEIP構成）」というアプローチです！

📦 複数の配送トラックを使い分けるイメージ

複数のElastic IPを用意するということは、会社ニーの配送トラックを1台から3台、5台へと増やすようなものです。
外のインターネットへ出ていくときに、ランダムあるいは一定のルールに従って「今日の出荷はトラックAを使おう」「次の荷物はトラックBで行こう」と負荷を分散させることができます。

—

3. 実践！Terraformで構築するマルチEIPなNATゲートウェイ

「理屈はわかったけれど、実際のインフラ設定ではどう書くの？」
ここからは、現場でそのまま使える実践的なコードを見ていきましょう。今回は多くの現場で採用されているTerraformを使って、複数のElastic IPを持つ堅牢なNATゲートウェイを構築する例をご紹介します。

# ==========================================
# 1. 複数のElastic IP（マスカレード用IP）の確保
# ==========================================
# 負荷分散と冗長化のために、2つのElastic IPをAWS上に確保します
resource "aws_eip" "nat_eip_1" {
  domain = "vpc"
  tags = {
    Name = "prod-nat-eip-01"
    Role = "MasqueradeAddress"
  }
}

resource "aws_eip" "nat_eip_2" {
  domain = "vpc"
  tags = {
    Name = "prod-nat-eip-02"
    Role = "MasqueradeAddress"
  }
}

# ==========================================
# 2. パブリックサブネットとNATゲートウェイの作成
# ==========================================
# ※前提として、VPCやパブリックサブネットの定義が既にあるものとします。

# 1つ目のNATゲートウェイ（EIP-1を使用）
resource "aws_nat_gateway" "nat_gw_1" {
  allocation_id = aws_eip.nat_eip_1.id
  subnet_id     = aws_subnet.public_subnet_1.id # パブリックサブネットのIDを指定

  tags = {
    Name = "prod-nat-gw-az1"
  }

  # 依存関係の明示：インターネットゲートウェイの作成が完了した後にNATを作成する
  depends_on = [aws_internet_gateway.igw]
}

# 2つ目のNATゲートウェイ（EIP-2を使用：マルチAZでの冗長化）
resource "aws_nat_gateway" "nat_gw_2" {
  allocation_id = aws_eip.nat_eip_2.id
  subnet_id     = aws_subnet.public_subnet_2.id

  tags = {
    Name = "prod-nat-gw-az2"
  }

  depends_on = [aws_internet_gateway.igw]
}

💡 設定のポイント解説

上記のコードでは、単にIPを2つ用意しただけでなく、異なるアベイラビリティゾーン（AZ）のパブリックサブネットにそれぞれNATゲートウェイを配置しています。
これにより、万が一片方のデータセンターで障害が発生しても、もう片方のNATゲートウェイ（およびElastic IP）を経由して通信を継続できる、非常に可用性の高い構成（マルチAZ構成）が完成します。

—

4. フロー制御とルーティングの最適化：現場の知見

さて、複数のElastic IPとNATゲートウェイを配置したところで、パケットの「通り道（ルーティング）」を正しく整理してあげる必要があります。ここがSREの腕の見せ所です。

🧭 プライベートサブネットからの道案内

プライベートサブネットにあるKubernetesのワーカーノードやEC2インスタンスは、「外の世界へ行くときは、近くにあるNATゲートウェイを頼りなさい」というルールをルートテーブルに教え込む必要があります。

# ==========================================
# 3. プライベートサブネット用ルートテーブルの設定
# ==========================================
resource "aws_route_table" "private_rt_az1" {
  vpc_id = aws_vpc.main.id

  # 「外のインターネット(0.0.0.0/0)へ行くパケットは、AZ1のNATゲートウェイへ投げろ！」
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat_gw_1.id
  }

  tags = {
    Name = "prod-private-rt-az1"
  }
}

resource "aws_route_table" "private_rt_az2" {
  vpc_id = aws_vpc.main.id

  # 「AZ2のプライベートリソースからの外行きパケットは、AZ2のNATゲートウェイへ！」
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat_gw_2.id
  }

  tags = {
    Name = "prod-private-rt-az2"
  }
}

⚠️ トラブルシューティングの現場から：非対称ルーティングの罠

マルチAZで複数のNATゲートウェイを運用する際によくあるハマりどころが、「クロスAZルーティングによる非対称ルーティング（Asymmetric Routing）」です。

  • 行きのパケット: AZ1にあるコンテナから出たパケットが、なぜか遠くのAZ2にあるNATゲートウェイを通過して外に出る。
  • 帰りのパケット: 外から見ると「AZ2のElastic IP」に返事を返すため、AZ2のNATゲートウェイに戻ってくるが、元のコンテナがいるのはAZ1。ステートフルファイアウォールが「あれ、行きと入り口が違うぞ？」とパケットを破棄（ドロップ）してしまう。

これを防ぐための鉄則は、「自分の所属するAZと同じAZ内にあるNATゲートウェイへパケットをルーティングする（ゾーンローカリティを意識する）」ことです！上のTerraformコードのように、AZ1のプライベートサブネットはAZ1のNATへ、AZ2はAZ2へ向けるという「地道で正しい経路設計」が、安定稼働の最大の秘訣となります。

—

まとめ

今回は、クラウドネットワークの裏側を支える「マスカレードIPアドレス（Elastic IP）」と「NATゲートウェイ」の役割、そして複数IPを使った負荷分散とルーティングの最適化について解説しました。

  • NATゲートウェイは、プライベートな仲間たちが外の世界へお使いに行くときの「総務部の窓口」。
  • Elastic IP（マスカレードIP）は、外の相手から見える「会社の代表電話番号」。
  • 大規模なシステムでは複数のEIPとマルチAZなNAT配置を行い、ゾーンを意識した正しいルーティングを組むことで、安全で枯渇知らずのネットワークが手に入る。

最初は難しく感じるクラウドのネットワークも、パケットの気持ちになって「荷物の配達」に例えてみると、ぐっと身近に感じられるようになったのではないでしょうか？
ぜひ実際のインフラ構築や設計の現場で、この知識を役立ててみてくださいね。それでは、また次回の技術解説でお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました