こんにちは！毎日クラウドやコンテナのネットワークと格闘しているSREの技術ライターです。
インフラの世界に一歩足を踏み入れると、VPC、サブネット、ルートテーブル、そして今回の主役であるNATゲートウェイなど、アルファベットだらけの専門用語が一気に押し寄せてきますよね。「なんだか難しそう…」と身構えてしまうかもしれませんが、安心してください。
ネットワークの仕組みは、私たちが日常的に使っている「郵便」や「マンションの宅配システム」と驚くほどそっくりなんです。
この記事では、難しいパケットのビット数や英語のヘッダー仕様などは一旦脇に置いて、「プライベートサブネットのサーバーが、どうやって安全にインターネットと通信しているのか」という裏側のドラマを、優しい言葉で一歩ずつ紐解いていきましょう！
—
1. なぜ「プライベートサブネット」はそのまま外に出られないの？
まずは基本となる「パブリック」と「プライベート」の違いから整理していきましょう。
クラウドの世界では、セキュリティを守るためにネットワークを以下のように2つのエリアに分けるのが鉄則です。
- パブリックサブネット：インターネットから直接アクセスできる、いわば「大通りに面したお店」のような場所。
- プライベートサブネット：インターネットからは直接見えない、セキュリティでガッチリ守られた「マンションの奥の個室」のような場所。
ここで登場するのが、ネットワークの住所にあたるIPアドレスです。
- プライベートIPアドレス（例:
10.0.1.5）：マンションの「101号室」という内輪の部屋番号。 - パブリックIPアドレス（例:
54.240.196.1）：世界に一つしかない「〇〇市〇〇町1-2-3 マンション名」という正式な住所。
もし、101号室（プライベートIP）の住人が、そのまま「101号室より」とだけ書いた手紙を街のポスト（インターネット）に投函したらどうなるでしょうか？
郵便屋さん（ルーター）は「どこのマンションの101号室かわからないよ！」と困ってしまい、手紙を届けることも、返事を書くこともできませんよね。
これが、「プライベートIPアドレスのままではインターネットと通信できない」最大の理由です。
—
2. 救世主「NATゲートウェイ」と「SNAT」の魔法
そこで登場するのが、マンションの頼れるコンシェルジュ（管理人さん）であるNAT（ナット）ゲートウェイです。
プライベートサブネットにいるサーバーが「インターネット上のWebサイトを見に行きたいな（アウトバウンド通信）」と思ったとき、このNATゲートウェイが間に入って、素晴らしい魔法をかけてくれます。
その魔法の名前をSNAT（Source Network Address Translation：送信元ネットワークアドレス変換）と呼びます。
難しそうな名前ですが、仕組みはとてもシンプルです。
[プライベートのサーバー] 10.0.1.5 (部屋番号101)
│
│ 「Yahoo!のページを見たいな」
▼
[NATゲートウェイ] 54.240.196.1 (マンション全体の代表住所)
│
│ ★送信元を「101号室」から「マンションの代表住所」に書き換える！(SNAT)
▼
[インターネット上のサーバー]郵便の例えに戻りましょう。
1. あなたが「101号室の佐藤」として手紙を書き、マンションのコンシェルジュ（NATゲートウェイ）に渡します。
2. コンシェルジュは、手紙の差出人欄を「マンションの代表住所（パブリックIPアドレス）」に書き換えて、代わりにポストに投函してくれます。
3. 外の世界からは、この手紙はすべて「マンションの代表住所から届いたもの」に見えます。
このように、「送信元（Source）の住所を書き換える」から、SNATと呼ばれるのです。
—
3. 「誰宛ての返事だっけ？」を防ぐ「ポート番号」の仕組み
ここで、鋭い方は一つの疑問に気づいたかもしれません。
> 「もし、101号室の佐藤さんと、202号室の鈴木さんが、同時に同じWebサイトに手紙を出したら、返ってきた手紙をコンシェルジュはどうやって2人に振り分けるの？」
全員の差出人が「マンションの代表住所」に書き換わっているため、返事が届いたとき、そのままでは誰宛てなのか区別がつきませんよね。
この問題を解決するのが、ポート番号という「引き換えタグ（整理番号）」の仕組みです。
ネットワークの世界では、この仕組みをNAPTやIPマスカレードと呼びますが、ここではシンプルに「引き換えタグ付きの郵便転送」と覚えましょう！
NATゲートウェイは、手紙を預かると、以下のような「お預かりマッピング表」にこっそりメモを書き残します。
NATゲートウェイの「お預かりマッピング表」のイメージ
| 元の送信元 (部屋番号) | 割り当てたタグ (ポート番号) | 宛先 (送り先) |
| :— | :— | :— |
| 10.0.1.5 (101号室の佐藤さん) | 10001 | Yahoo.com |
| 10.0.1.9 (202号室の鈴木さん) | 10002 | Google.com |
そして、外の世界へ手紙を出すときに、差出人の名前にこのタグを貼り付けます。
- 佐藤さんの手紙：
54.240.196.1のポート10001から発送 - 鈴木さんの手紙：
54.240.196.1のポート10002から発送
インターネットの向こう側から返事が届くときは、必ずこのタグが宛先に書いてあります。
「54.240.196.1 の ポート10001 宛て」の返事が届いたら、コンシェルジュはマッピング表を見て、「よし、これは101号室の佐藤さん（10.0.1.5）への返事だな！」と判断し、無事にお部屋まで届けてくれるのです。
実に見事なチームワークですよね！
—
4. パケットの旅をステップ・バイ・ステップで見てみよう
それでは、実際のパケット（データのお手紙）がどのようにネットワークを駆け巡るのか、流れを4つのステップで追いかけてみましょう。
+-----------------------------------------------------------------------------------+
| [VPC] |
| +-----------------------------------+ +-----------------------------------+ |
| | [プライベートサブネット] | | [パブリックサブネット] | |
| | +-----------------------------+ | | +-----------------------------+ | |
| | | EC2インスタンス | | | | NATゲートウェイ | | |
| | | IP: 10.0.1.5 | | | | IP: 54.240.196.1 | | |
| | +--------------+--------------+ | | +--------------+--------------+ | |
| +-----------------|-----------------+ +-----------------|-----------------+ |
+--------------------|-----------------------------------------|--------------------+
| [1] 送信 (Src: 10.0.1.5) | [2] 変換後 (Src: 54.240.196.1)
v v
[ルートテーブル] ------------------------------> [インターネット]【Step 1】出発：インスタンスから手紙を発送
プライベートサブネットにあるサーバー（10.0.1.5）が、インターネット上のサーバー（93.184.216.34）に向けてデータを送ります。
- 送信元（From）:
10.0.1.5 - 宛先（To）:
93.184.216.34
【Step 2】中継：NATゲートウェイでの変換 (SNAT)
ルートテーブル（道案内板）に従って、データはパブリックサブネットにあるNATゲートウェイに届きます。ここでコンシェルジュが魔法を使います。
- 送信元（From）:
54.240.196.1（NATゲートウェイのパブリックIPに書き換え！） - 同時に、お返事を受け取るための「引き換えタグ（ポート番号）」をマッピング表に記録します。
【Step 3】相手に到着＆お返事の発送
インターネット上のサーバーは、届いたデータに対してお返事を書きます。このとき、宛先はNATゲートウェイになっています。
- 送信元（From）:
93.184.216.34 - 宛先（To）:
54.240.196.1（引き換えタグ付き）
【Step 4】帰還：元のサーバーへお届け
お返事を受け取ったNATゲートウェイは、マッピング表を素早く確認します。
「このタグは、10.0.1.5のサーバー宛てだな！」と判別し、宛先を書き換えてプライベートサブネットのサーバーへとデータを届けます。
これで、無事に往復の通信が完了しました！
—
5. 実務で使える！AWSでの「NATゲートウェイ」構築コード例
概念が理解できたら、実際のクラウド構築でどのように設定するのかを見てみましょう。
今回は、インフラのコード化（IaC）で最も人気のあるTerraformを使って、パブリックサブネット、プライベートサブネット、そしてNATゲートウェイを繋ぐ設定例をご紹介します。
じっくりコメントを読みながら、設定の流れをイメージしてみてくださいね。
# ------------------------------------------------------------------------------
# 1. VPC (仮想のネットワーク空間) の作成
# ------------------------------------------------------------------------------
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
enable_dns_hostnames = true
tags = {
Name = "my-friendly-vpc"
}
}
# ------------------------------------------------------------------------------
# 2. サブネットの作成 (パブリックとプライベート)
# ------------------------------------------------------------------------------
# 外と直接繋がるパブリックサブネット
resource "aws_subnet" "public" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
availability_zone = "ap-northeast-1a"
tags = {
Name = "public-subnet"
}
}
# 奥まった安全なプライベートサブネット
resource "aws_subnet" "private" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.2.0/24"
availability_zone = "ap-northeast-1a"
tags = {
Name = "private-subnet"
}
}
# ------------------------------------------------------------------------------
# 3. NATゲートウェイと、そのための固定IP（Elastic IP）の作成
# ------------------------------------------------------------------------------
# NATゲートウェイが外と通信するための「固定のパブリックIPアドレス」を確保します
resource "aws_eip" "nat" {
domain = "vpc"
tags = {
Name = "nat-eip"
}
}
# NATゲートウェイ本体を「パブリックサブネット」に配置します
resource "aws_nat_gateway" "nat" {
allocation_id = aws_eip.nat.id
subnet_id = aws_subnet.public.id # 必ずパブリック側に置くのがポイントです！
tags = {
Name = "my-nat-gateway"
}
}
# ------------------------------------------------------------------------------
# 4. ルートテーブル (道案内板) の設定
# ------------------------------------------------------------------------------
# プライベートサブネット専用の道案内板を作ります
resource "aws_route_table" "private" {
vpc_id = aws_vpc.main.id
# 「外の世界（0.0.0.0/0）に行く通信は、すべてNATゲートウェイに預けなさい」というルール
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_nat_gateway.nat.id
}
tags = {
Name = "private-route-table"
}
}
# この道案内板を、プライベートサブネットに紐付けます
resource "aws_route_table_association" "private" {
subnet_id = aws_subnet.private.id
route_table_id = aws_route_table.private.id
}—
6. 先輩SREからのワンポイントアドバイス：現実のトラブル「ポート枯渇」
最後に、少しだけ実務で役立つ「現場の知恵」をお話しします。
コンシェルジュであるNATゲートウェイは非常に優秀ですが、「引き換えタグ（ポート番号）」の数には限界があります。
一般的に、1つのIPアドレスで使えるタグの数は約64,000個です。
もし、プライベートサブネットにあるたくさんのサーバーが一斉に、数万回もの通信をインターネットに対して行うと、「貸し出せる引き換えタグが足りなくなる」という事件が発生します。これを専門用語で「ポート枯渇（SNAT Port Exhaustion）」と呼びます。
現場でこのトラブルを防ぐための対策
1. NATゲートウェイに複数のIPアドレスを割り当てる：
引き換えタグが足りないなら、看板となるIPアドレスを2つ、3つと増やして、タグの総数を増やしてあげます。
2. 不要な通信を減らす（コネクションの再利用）：
毎回手紙を送り直すのではなく、一度繋いだパイプ（コネクション）を使い回すようにアプリケーションを設計します（Keep-Aliveの有効化など）。
ネットワークの設計をするときは、「もしコンシェルジュの仕事が忙しくなりすぎたらどうしよう？」という視点を持っておくと、トラブルに強い美しいインフラが作れるようになりますよ！
—
まとめ：一歩ずつ、ネットワークを楽しもう！
一見すると難解に思えるクラウドネットワークですが、その本質は「お互いの住所を正しく書き換えて、迷子にならないように届けること」です。
SNATは、プライベートIPを代表のパブリックIPに書き換えること。ポート番号は、返事の宛先を間違えないための引き換えタグ。NATゲートウェイは、そのすべてを支える優秀なコンシェルジュ。
この基本さえ頭に入っていれば、これから先、もっと複雑なコンテナネットワークやハイブリッドクラウドに出会っても、きっとスムーズに理解できるはずです。
インフラの世界は、知れば知るほどパズルのように面白いピースが繋がっていきます。焦らず、一歩ずつ一緒に楽しんで学んでいきましょう！
コメント