概要
NAT ゲートウェイは、パブリック IP を持たないプライベートサブネットのリソースが、インターネットへ「出ていく」ための出口。インスタンスの代わりに自分の Elastic IP（EIP）で外と通信し、応答を返す。内 → 外はできるが、外 → 内の接続開始はできない一方通行の部品である。
もう 1 つの重要な役割が送信元 IP の固定。背後のインスタンスが何台あっても、外から見える送信元は EIP 1 つに揃う。月数十ドルかかるわりに働きが見えにくく、リソース整理で真っ先に疑われがちだが、「出口」と「身元」の 2 つを担っている。
詳細
マネージドであることとコスト
NAT インスタンス（EC2 1 台）でも同じ機能は作れるが、NAT ゲートウェイは OS パッチや監視が不要で、AZ 内で冗長化され帯域も自動スケールする。代わりに時間課金＋データ処理量課金がかかる（東京リージョンでおおむね $0.062/時間 ≒ 月 $45 前後＋処理量 1GB あたり $0.062、別に EIP のパブリック IPv4 料金が月 $3.6 ほど。最新は公式で確認）。
| 構成 | 月額の目安 | 主な課題 |
|---|---|---|
| NAT ゲートウェイ 1 本 | 約 $49 ＋ 処理量 | 費用 |
| インスタンスごとに EIP | 約 $3.6 × 台数 | 下記の利点をすべて失う |
| NAT インスタンス | 数ドル〜 | パッチ・監視・冗長化を自前で |
AZ 単位のリソースなので、可用性重視なら AZ ごとに 1 本、コスト重視なら 1 本（その AZ 障害時は外に出られない）。
典型構成と「外に出たい」用途
入口は ALB（＋CDN / WAF）、アプリサーバーはプライベートサブネット、外向き通信は NAT が出口という 3 層構成が定番。アプリが外へ出る用途は多い — 外部 SaaS / API、SES などの AWS API（VPC エンドポイントがなければインターネット経由）、S3、reCAPTCHA、OS パッケージ更新や git pull。
送信元 IP が 1 つに揃うので、外部 SaaS の接続元 IP 制限、IAM ポリシーの aws:SourceIp 条件、SPF レコードなどの IP アローリストに EIP を登録して使われる。
Auto Scaling 配下の Web アプリでの利点
- アプリサーバーを晒さない — パブリック IP が不要で、入口を ALB に絞れる。セキュリティグループが緩くても直接到達する経路がない（多層防御）
- インスタンスが入れ替わっても送信元 IP が変わらない — インスタンスに EIP を直接付けると、起動のたびの付け直しや、スケールアウト時の 2 つ目の EIP が要る
- アローリストの管理が 1 か所 — 台数分の IP を登録する構成では、登録漏れが平常時には見えず「ピーク時だけメールが送れない」ような見つけにくい障害になる
- 運用の手間が少ない
事例：唯一の出口を消して本番が止まった
リソース整理で、本番の唯一の出口だった NAT ゲートウェイと EIP が削除された。使われていない VPC の NAT と並んでいた、EIP が「インスタンスに割り当てられていない」ように見えた、処理量課金がわずかだった、という理由で「消してよさそう」に見えた。
- 削除直後: 外向き通信が全停止 → 外部 API 待ちでタイムアウト → ALB が 504
- 応答待ちで PHP-FPM の枠が埋まりヘルスチェックが失敗 → Auto Scaling がインスタンスを作り直し続けた（ローカルログも消える）
- 再構築後: 出口は戻ったが EIP が新しい IP に変わり、CRM のログイン拒否、S3 画像の 500、メール送信失敗（いずれも IP 制限・
aws:SourceIp）が順に表面化した
教訓
- NAT の EIP は「誰にも割り当てられていない」ように見えるが使われている。割り当て先が NAT かを必ず確認する
- 削除前にルートテーブルを見る。
0.0.0.0/0が NAT を指し稼働中のインスタンスがあれば使われている。処理量の少なさは未使用の根拠にならない - 解放した EIP が戻る保証はない（
aws ec2 allocate-address --addressで取り戻せる場合もあるが確実ではない）。削除前にアローリストを洗い出す - IP 依存はドキュメントに書く。IAM の
aws:SourceIp条件はaws iam get-account-authorization-detailsを jq で総当たりして探せる（バケットポリシーなどリソース側のポリシーは別途確認） - 外向き通信の詰まりがヘルスチェックの失敗に連鎖しないよう、ヘルスチェックは静的ファイルにし、外部通信のタイムアウトを短くする
NAT への依存を減らす
| 施策 | 効果 | 注意点 |
|---|---|---|
| S3 のゲートウェイ型 VPC エンドポイント（無料） | S3 通信が NAT を通らない | aws:SourceIp が含まれなくなるので、条件を aws:SourceVpce / aws:SourceVpc などに変える作業とセット |
| IAM ユーザーをやめてインスタンスロールに | 長期キーがなくなり IP 縛りの必要性が下がる | アプリの認証情報の読み方を変える |
| SES などのインターフェース型 VPC エンドポイント | AWS API を NAT 経由にしない | エンドポイントごとに時間課金。IP 条件の見直しが要る |
| 共通基盤の出口プロキシ | 外向き通信を組織で一元管理 | 接続先ごとの申請、送信元 IP の扱いを確認 |
AWS API への依存を外していくと、最後まで固定 IP が要るのは IP 制限をかけている外部 SaaS だけになり、そこを NAT の EIP 1 つで受けるのが最も単純で壊れにくい。
関連ページ
- AWS Compute Optimizer — ルートテーブルに紐づかない NAT Gateway をアイドルリソースとして検出する
- CloudFront → ALB → Django の HTTPS 判定 — 同じ CDN＋ALB の入口構成
- Terraform IaC ベストプラクティス — ネットワーク構成をコードで管理する
- インシデント対応の5フェーズ — 障害時の対応の進め方
ソース記事
- AWS の NAT ゲートウェイとは何か — 「唯一の出口」を消して本番が止まった話から考える — 2026-10-01