---
title: "AWS NAT Gateway（NATゲートウェイ）とは？インターネットゲートウェイとの違い・料金・作成手順"
url: "https://www.issoh.co.jp/column/details/3105/"
published: 2024-07-19
updated: 2026-10-26
categories: ["ネットワーク"]
publisher: "株式会社一創"
---

# AWS NAT Gateway（NATゲートウェイ）とは？インターネットゲートウェイとの違い・料金・作成手順

AWSのNAT Gateway（NATゲートウェイ）は、プライベートサブネットにあるEC2やコンテナが、インターネットや他のネットワークへ**自分から接続を始めるときだけ**通す出口です。外から内側への接続は受け付けません。OSの更新パッケージや外部APIには届く必要があるが、サーバーそのものは公開したくない。この構成を作るための部品です。

本記事では、インターネットゲートウェイ（IGW）との違い、リージョナルとゾーナルの選び分け、コンソールとAWS CLIでの作成・削除の手順、東京リージョンの料金、帯域や同時接続の上限、置かなくてよい構成までを、AWS公式ドキュメントと価格表の数値で整理します（2026年10月時点）。

## まとめ：NATゲートウェイの役割・料金・作り方の要点

- **役割**：プライベートサブネットから外への通信だけを通し、外からの新規接続は通しません。インターネットへ出るパブリックNATゲートウェイは、IGWと組み合わせて初めて機能します。
- **IGWとの違い**：IGWはパブリックIPを持つリソースの双方向通信を担い、料金は無料です。NATゲートウェイは片方向の出口で、東京では1時間0.062ドルと1GBあたり0.062ドルがかかります。
- **作り方**：新規構築ではリージョナルNATゲートウェイ（2025年11月提供開始）が第一候補です。VPCを選ぶだけで作れ、パブリックサブネットもAZごとの作成も要りません。作成後はプライベートサブネットのルートテーブルに `0.0.0.0/0` を向けます。
- **止め方**：停止の操作は無く、課金を止めるには削除します。削除してもElastic IPは残り、1時間0.005ドルがかかり続けるので解放まで行います。
- **置かない判断**：通信先がS3・DynamoDBだけならゲートウェイ型VPCエンドポイント（無料）で足ります。IPv6の外向き通信ならEgress-Only IGWで代替できます。

## NATゲートウェイの役割と通信の向き：外へ出るだけの出口

### NATの意味とアドレス変換の2段構え

NATはNetwork Address Translation（ネットワークアドレス変換）の略です。プライベートIPアドレスしか持たないインスタンスの通信を、NATゲートウェイが自分のアドレスに置き換えて外へ送り、戻ってきた応答を元のインスタンスへ返します。NATそのものの仕組みやNAPT（IPマスカレード）との違いは[NATの仕組みとNAPTとの違いの解説](/tech/details/13552/)にまとめています。

AWSのパブリックNATゲートウェイでは、変換が2段階で起きます。[AWSのNATゲートウェイのドキュメント](https://docs.aws.amazon.com/ja%5Fjp/vpc/latest/userguide/vpc-nat-gateway.html)の説明では、まずNATゲートウェイがインスタンスの送信元プライベートIPを**NATゲートウェイ自身のプライベートIP**に変換し、次にIGWがそのプライベートIPを**NATゲートウェイに関連付けたElastic IP**に変換します。NATゲートウェイ単体ではインターネットに出られず、同じVPCのIGWへのルートが必須になるのはこのためです。

NATゲートウェイは応答の戻り通信だけを通すステートフルな装置です。インターネット側から内部のサーバーへ新規に接続させる用途（公開Webサーバーやポートフォワーディング）には使えません。

### パブリックNATとプライベートNATの接続先の違い

作成時に接続タイプを2つから選びます。既定はパブリックです。

| 項目                 | パブリックNATゲートウェイ          | プライベートNATゲートウェイ         |
| ------------------ | ----------------------- | ----------------------- |
| 主な接続先              | インターネット（他VPC・オンプレも可）    | 他VPC・オンプレミス             |
| Elastic IP         | ゾーナルは作成時に関連付けが必須        | 関連付け不可                  |
| 置き場所（ゾーナル）         | パブリックサブネット              | プライベートサブネット             |
| 経由する装置             | IGW／Transit Gateway／VGW | Transit Gateway／VGW     |
| VPC内に単独作成するリージョナル版 | あり                      | なし（TGW組み込みの1対1 NATは別機能） |

プライベートNATゲートウェイからIGWへトラフィックを流しても、IGWが破棄します。一般的な「プライベートサブネットから外へ出したい」という要件なら、パブリックNATゲートウェイを選びます。

プライベートNATの代表的な用途は、社内ネットワークや買収先のVPCとCIDRが重なっていて直接つなげない場合です。この用途には2026年10月23日、[Transit GatewayとCloud WANのアタッチメントで設定する1対1のNAT](https://aws.amazon.com/about-aws/whats-new/2026/10/aws-transit-gateway-cloud-wan-1-1-nat/)という選択肢が加わりました。Transit Gatewayに組み込まれたリージョナルのプライベートNATゲートウェイとして動き、NATゲートウェイのリソースを別に作りません。CIDR同士を同じプレフィックス長で対応付ける（例：10.10.100.0/24を100.64.100.0/24へ）ステートレスな変換で、IPv4のみが対象です。ポートは変換しないため、多数のインスタンスを1つのアドレスにまとめる用途には使えません。Transit Gatewayの基本と料金は[Transit GatewayとVPC Peeringの違いの解説](/tech/details/4263/)で扱っています。

## インターネットゲートウェイとNATゲートウェイの違い：向き・IP・料金の比較

インターネットゲートウェイとNATゲートウェイは、どちらか一方を選ぶ部品ではありません。役割が違い、プライベートサブネットからインターネットへ出る構成では両方が必要です。

| 比較項目     | インターネットゲートウェイ   | NATゲートウェイ（パブリック）           |
| -------- | --------------- | -------------------------- |
| 通信の向き    | 双方向（外からの接続も可）   | 内から外のみ                     |
| 使うリソース   | パブリックIPを持つリソース  | プライベートIPだけのリソース            |
| アタッチ・配置  | VPCにアタッチ（同時に1つ） | ゾーナルはサブネット、リージョナルはVPCに作成   |
| IPv6     | 対応（双方向）         | NAT64でIPv4宛てに変換            |
| 可用性      | 水平スケール・冗長構成     | ゾーナルはAZ内で冗長・AZ障害の影響あり      |
| 料金（東京）   | 無料（データ転送料は別）    | 0.062ドル/時＋0.062ドル/GB       |
| 作成数の既定上限 | リージョンあたり5       | ゾーナル：AZあたり5／リージョナル：VPCあたり5 |

### IGWが担う1対1のNATと双方向通信

IGWもIPv4ではアドレス変換をしています。ただしインスタンスごとの**1対1のNAT**です。IGWは外に出る通信の送信元をそのインスタンスのパブリックIPv4（またはElastic IP）へ、入ってくる通信の宛先をプライベートIPへ置き換えます。パブリックIPを持つリソースは外から接続を受けられるので、Webサーバーやロードバランサーの置き場所になります。

サブネットの「パブリック」「プライベート」を決めるのは、このIGWへのルートの有無です。関連付けたルートテーブルに `0.0.0.0/0` などIGW宛てのルートがあればパブリックサブネット、無ければプライベートサブネットと呼ばれます。プライベートサブネットのインスタンスにパブリックIPを付けても、IGWへのルートが無い限り外とは通信できません。

### IPv6の外向き通信はEgress-Only IGWで足りる理由

Amazonが提供するIPv6アドレスはグローバルに一意で、インターネットに広告されます（AWSにはプライベートIPv6アドレスもありますが、こちらはEgress-Only IGWを置いても直接インターネットへは出られません）。パブリックIPv6ではNATでアドレスを隠す必要がないため、IPv6で「外へは出したいが外からは接続させたくない」場合は、NATゲートウェイではなく**Egress-Only インターネットゲートウェイ**を使います。ルートテーブルに `::/0` をその宛てで追加すれば使え、料金は無料です（EC2のデータ転送料は別途）。

NATゲートウェイがIPv6で出番になるのは、IPv6だけのサブネットからIPv4しか持たない相手へつなぐときです。Route 53 ResolverのDNS64と組み合わせると、NATゲートウェイがNAT64としてIPv6からIPv4へ変換します。

## NATゲートウェイの配置：リージョナルとゾーナルの選び分け

NATゲートウェイには、AZをまたいで自動で広がる**リージョナル**と、1つのAZで動く従来型の**ゾーナル**があります。APIの既定はゾーナルですが、[AWSのリージョナルNATゲートウェイのドキュメント](https://docs.aws.amazon.com/ja%5Fjp/vpc/latest/userguide/nat-gateways-regional.html)は、プライベートNATが必要な場合を除き、すべての用途でリージョナルの利用を検討するよう案内しています。新規のVPCではリージョナルを第一候補とし、プライベートNATが必要ならゾーナルを選びます。制約付きAZにはゾーナルも作れないため、公式のトラブルシューティングが示すとおり、別のAZに置いたNATゲートウェイへ制約付きAZのプライベートサブネットからルートを向けます。

### ゾーナル構成のルートテーブルとAZ障害の影響範囲

ゾーナルのパブリックNATゲートウェイは、特定のAZのパブリックサブネットに作ります。ルートテーブルは2枚を意識します。

| ルートテーブル      | 送信先       | ターゲット                 |
| ------------ | --------- | --------------------- |
| パブリックサブネット用  | 0.0.0.0/0 | igw-xxxxxxxx          |
| プライベートサブネット用 | 0.0.0.0/0 | nat-xxxxxxxx（同じAZのもの） |

ゾーナルのNATゲートウェイはAZ内では冗長化されていますが、AZをまたいだ自動フェイルオーバーはしません。[NATゲートウェイの基本のドキュメント](https://docs.aws.amazon.com/ja%5Fjp/vpc/latest/userguide/nat-gateway-basics.html)は、複数AZのリソースが1つのNATゲートウェイを共用していて、そのAZが停止すると**他のAZのリソースもインターネットへのアクセスを失う**と明記しています。本番環境ではAZごとにNATゲートウェイを置き、各AZのプライベートサブネットは同じAZのNATゲートウェイへ向けます。AZをまたぐ通信にはAZ間のデータ転送料もかかるため、同一AZへ寄せる設計は可用性と料金の両方に効きます。止まっても困らない検証環境なら、1台に集約して時間料金を抑える判断もあります。

### リージョナルNATゲートウェイで不要になる作業と制約

リージョナルNATゲートウェイは2025年11月19日に提供が始まりました（GovCloud（US）と中国リージョンを除く全商用リージョン）。VPCを指定して作ると、ENIがあるAZへ自動で広がり、ワークロードが無くなったAZからは縮みます（推奨の自動モードの場合。手動モードではAZごとのIPと拡張・縮小を自分で管理します）。

- ホスト用のパブリックサブネットが要りません。専用のルートテーブルが自動で作られ、IGWへのルートも入っています。
- 全AZのプライベートサブネットから、同じNATゲートウェイIDへルートを向けられます。
- IPアドレスはAZあたり最大32個で、ゾーナルの8個より同時接続の余力があります。

制約もあります。プライベートNATには対応せず、制約付きAZ（constrained Availability Zones）でも使えません。新しいAZにリソースを起動してから、そのAZへ広がるまで最大60分かかり、その間は既存AZのNATゲートウェイがAZをまたいで処理します。料金はAZごとの時間課金なので、3AZに広がれば3台分です。リージョナルにしても安くはならず、得られるのは設定と運用の手間の削減です。ゾーナルからの切り替えは既存の接続がリセットされるため、AWSはメンテナンス時間帯での実施を勧めています。

## NATゲートウェイの作成手順：コンソールとAWS CLI

作成前に、VPCにIGWがアタッチされていることを確認します。コンソールの「VPCのみ」で作ったVPCにはIGWが無く、リージョナルでもゾーナルでも、パブリックNATゲートウェイはIGWを通って外へ出ます。

### リージョナルNATゲートウェイのコンソール作成手順

[公式の作成手順](https://docs.aws.amazon.com/ja%5Fjp/vpc/latest/userguide/nat-gateways-regional.html)に沿うと、操作は次の4ステップです。

1. VPCコンソールの左メニューで「NATゲートウェイ」を開き、「NATゲートウェイを作成」を選びます。
2. 「アベイラビリティモード」で「リージョナル」を選びます。サブネットの指定は不要です。
3. 対象のVPCを選び、名前タグなど残りの設定を入れて作成します。
4. 状態が `Pending` から `Available` に変わったら、プライベートサブネットのルートテーブルを開き、送信先 `0.0.0.0/0`・ターゲットに作成したNATゲートウェイを追加します。

ゾーナルで作る場合は、2の代わりに作成先のパブリックサブネットを選び、接続タイプ「パブリック」のままElastic IPを割り当てます（「Elastic IPを割り当て」で新規に確保できます）。ルートはAZごとに、同じAZのNATゲートウェイへ向けます。

### AWS CLIによるNATゲートウェイ作成とルート追加

リージョナルは `--availability-mode regional` と `--vpc-id` を渡すだけで、Elastic IPもサブネットも指定しません（自動モード）。`--availability-mode` を省くとゾーナルになります（各リソースIDは実環境の値に置き換えます）。以下はリージョナルとゾーナルの代替例なので、どちらか一方だけを実行してください。対象ルートテーブルに同じ宛先のルートが既にある場合は、追加ではなく既存ルートの変更が必要です。

```
# リージョナル（自動モード）
NAT_ID=$(aws ec2 create-nat-gateway --vpc-id vpc-0abc1234 --availability-mode regional --query NatGateway.NatGatewayId --output text)
aws ec2 wait nat-gateway-available --nat-gateway-ids "$NAT_ID"
aws ec2 create-route --route-table-id rtb-0ddd4444 --destination-cidr-block 0.0.0.0/0 --nat-gateway-id "$NAT_ID"

# ゾーナル（パブリックサブネットとElastic IPを指定）
ALLOC_ID=$(aws ec2 allocate-address --domain vpc --query AllocationId --output text)
NAT_ID=$(aws ec2 create-nat-gateway --subnet-id subnet-0aaa1111 --allocation-id "$ALLOC_ID" --query NatGateway.NatGatewayId --output text)
aws ec2 wait nat-gateway-available --nat-gateway-ids "$NAT_ID"
aws ec2 create-route --route-table-id rtb-0ddd4444 --destination-cidr-block 0.0.0.0/0 --nat-gateway-id "$NAT_ID"
```

ゾーナルの `--subnet-id` にはパブリックサブネットを指定します。プライベートサブネットに作ったパブリックNATゲートウェイは、IGWへのルートが無いため外へ出られません。`aws ec2 wait nat-gateway-available` は状態が `available` になるまで15秒間隔で最大40回確認し、`failed` になった時点でエラーで終わります。Terraformでの構築やポート枯渇への対処は、[NAT Gatewayの構築手順とリージョナル移行の実装解説](/tech/details/17747/)で扱っています。

### プライベートサブネットからの疎通と送信元IPの確認

curlはプライベートサブネットのインスタンス側で実行します（Systems Manager Session Managerなどで接続）。describe-nat-gatewaysは、作成時のNAT\_IDを保持し、同じリージョンの情報を参照できるAWS CLI環境で実行します。AWSが提供する `checkip.amazonaws.com` は、アクセス元に見えているパブリックIPv4を1行で返します。

```
curl -s https://checkip.amazonaws.com
aws ec2 describe-nat-gateways --nat-gateway-ids "$NAT_ID" --query "NatGateways[].NatGatewayAddresses[].PublicIp"
```

1行目の結果が2行目に並ぶNATゲートウェイのパブリックIPのどれかと一致すれば、通信はNATゲートウェイ経由で出ています。応答が返らないときは、後述の「外へ出られないときの確認順」を上から当たります。

### NATゲートウェイの削除とElastic IPの解放

NATゲートウェイには停止の操作がなく、課金を止めるには削除します。ゾーナルで自分で確保したElastic IPは、削除後もアカウントに残ります。[Amazon VPCの料金ページ](https://aws.amazon.com/jp/vpc/pricing/)では、パブリックIPv4アドレスはリソースに関連付いていない状態でも1時間0.005ドルがかかります。

```
aws ec2 delete-nat-gateway --nat-gateway-id "$NAT_ID"
aws ec2 wait nat-gateway-deleted --nat-gateway-ids "$NAT_ID"
# この手順のゾーナル作成例で確保したElastic IPがある場合のみ実行
if [ -n "${ALLOC_ID:-}" ]; then
  aws ec2 release-address --allocation-id "$ALLOC_ID"
fi
aws ec2 delete-route --route-table-id rtb-0ddd4444 --destination-cidr-block 0.0.0.0/0
```

Elastic IPの解放は、NATゲートウェイの状態が `deleted` になってから行います（2行目の `wait` がそれを待ちます）。削除したNATゲートウェイを向いていたルートは `blackhole` 状態で残るため、最後に消すか、再作成したNATゲートウェイへ張り直します。夜間だけ止めたい検証環境では、この削除と再作成をスクリプト化する運用になります。再作成するとNATゲートウェイIDが変わり、新しくElastic IPを確保すれば外から見える送信元IPも変わる点に注意します。

## NATゲートウェイの料金：東京リージョンの時間課金とデータ処理の試算

AWSの価格データ（東京リージョン ap-northeast-1、2026年10月26日取得）の単価は次のとおりです。

| 課金項目           | 単価（東京）       | 課金の単位             |
| -------------- | ------------ | ----------------- |
| NATゲートウェイの時間料金 | 0.062ドル      | 1時間（1時間未満は切り上げ）   |
| データ処理料金        | 0.062ドル      | 1GB（送信元・宛先を問わない）  |
| リージョナルNATの時間料金 | 0.062ドル      | 1時間×広がっているAZ数     |
| パブリックIPv4アドレス  | 0.005ドル      | 1時間・1アドレス（未使用も同額） |
| データ転送料         | EC2の転送料金表に従う | インターネットやAZ間への転送量  |

### 3AZ・月500GBの構成で見る月額の目安

1か月を730時間とすると、NATゲートウェイ1つの時間料金は0.062×730＝**45.26ドル**です。本番向けに3AZへ1つずつ置けば135.78ドル、Elastic IP 3つ分のパブリックIPv4料金が0.005×730×3＝10.95ドル、NATゲートウェイを通る通信が月500GBならデータ処理料金が31.00ドルで、合計は約177.73ドルになります。インターネットへのデータ転送料はこれとは別に加わります。リージョナルで3AZに広がった場合も、時間料金は同じ3台分です。

時間料金は通信量ゼロでも発生し、放置した検証環境でも1つあたり毎月約45ドルが積み上がります。データ処理料金は、S3へのバックアップやコンテナイメージの取得など大量のAWS向け通信がNATゲートウェイを通ると膨らみます。NATインスタンスとの比較や削減策は[NAT ゲートウェイと NAT インスタンスの違い・料金の解説](/tech/details/3868/)、VPCエンドポイントとの損益分岐は[VPCエンドポイントの料金とNATゲートウェイとの損益分岐の解説](/tech/details/2326/)で試算しています。

## NATゲートウェイの上限と制約：帯域・同時接続・タイムアウトの数値

AWS公式ドキュメント（NATゲートウェイの基本・[Amazon VPCのクォータ](https://docs.aws.amazon.com/ja%5Fjp/vpc/latest/userguide/amazon-vpc-limits.html)・トラブルシューティング）に基づき、以下の表にはゾーナルNATゲートウェイの数値をまとめます。リージョナルではIPアドレス数がAZあたり最大32個となるなど、適用される上限が異なります。

| 項目         | 値                    | 超えたとき・補足              |
| ---------- | -------------------- | --------------------- |
| 帯域         | 5Gbpsから100Gbpsまで自動拡張 | それ以上はサブネットを分けて複数作成    |
| パケット処理     | 毎秒100万から1,000万まで自動拡張 | 超過分は破棄                |
| 同時接続       | 同一宛先に1IPあたり55,000    | IPを最大8個（1＋セカンダリ7）まで追加 |
| Elastic IP | パブリックNATあたり既定2個      | 申請で最大8個               |
| 作成数        | AZあたり既定5個            | 作成中・利用可能・削除中が対象       |
| アイドルタイムアウト | 350秒                 | 以降の通信にRSTを返す          |
| 対応プロトコル    | TCP・UDP・ICMP         | それ以外は通らない             |
| MTU        | 8500バイト              | インターネット向けは1500以下を推奨   |

### 同一宛先55,000接続と350秒タイムアウトの実害

「同一宛先」は、宛先IP・宛先ポート・プロトコルの組み合わせで数えます。多数のコンテナが同じ外部APIのHTTPS（443番）へ同時接続すると、この55,000に先に達し、新しい接続が失敗します。対処の第一はIPアドレスの追加で、8個にすれば上限は440,000になります（パブリックNATはElastic IPの既定上限2個を引き上げ申請したうえで。リージョナルならAZあたり32個まで）。CloudWatchメトリクスの `ErrorPortAllocation` が増えていれば、この上限に当たっています。

350秒のアイドルタイムアウトは、長時間無通信になるDB接続やSSHで表面化します。NATゲートウェイはタイムアウト後にFINではなくRSTを返すので、アプリ側には突然の切断として見えます。350秒未満の間隔でTCPキープアライブを送る設定が公式の対処です。

### セキュリティグループは付けられずNACLで絞る範囲

NATゲートウェイにはセキュリティグループを関連付けられません。通信を絞るのは、背後のインスタンスに付けたセキュリティグループのアウトバウンドルールと、インスタンスのサブネットのネットワークACLです。ゾーナルでは、NATゲートウェイを置いたパブリックサブネットのネットワークACLも経路に入ります。NATゲートウェイが使うポートは1024〜65535なので、NACLで絞るときは戻り通信のためにこの範囲を許可しておかないと応答が落ちます。ドメイン単位で外向き通信を制限したい（特定のSaaSだけ許可したい）要件は、NATゲートウェイでは満たせず、AWS Network Firewallなどを経路に挟みます。

### VPCピアリングとVGW経由では共用できない経路

他のVPCからVPCピアリング経由でNATゲートウェイへ通信を流し、共用することはできません。Site-to-Site VPNやDirect Connectからも、仮想プライベートゲートウェイ（VGW）経由ではNATゲートウェイへルーティングできず、Transit Gatewayを経由すれば可能です。複数VPCや拠点で1つの出口を共有したい場合は、Transit Gatewayを使った集約構成にします。接続方式の選び分けは[AWSのネットワーク接続方式まとめ](/column/details/2805/)で比較しています。

## NATゲートウェイを置かない判断：VPCエンドポイント・NATインスタンスで足りる構成

「プライベートサブネットにはNATゲートウェイ」と決め打ちする前に、通信先を洗い出します。必要なAWSサービスへの通信をすべてVPCエンドポイントなどのプライベート経路で処理でき、インターネットへの接続も不要なら、NATゲートウェイは要りません。

**S3とDynamoDBだけなら、ゲートウェイ型VPCエンドポイントを使います。**時間料金もデータ処理料金もかからず、NATゲートウェイのデータ処理料金（1GB0.062ドル）がそのまま消えます。ECRのプライベートイメージ取得には、ECRのインターフェイス型エンドポイントに加えて、イメージレイヤーを置くS3へのゲートウェイ型エンドポイントも必要です。プルスルーキャッシュの初回取得ではインターネットへの経路が必要になる場合があります。Systems ManagerやCloudWatch Logsなどの対応サービスは、インターフェイス型VPCエンドポイント（AWS PrivateLink）で閉域化できます。インターフェイス型は時間料金がかかるので、使うサービス数×AZ数が増えるとNATゲートウェイより高くなる場合があります。仕組みと料金は[AWS PrivateLinkとVPCエンドポイントの違いの解説](/tech/details/15473/)を参照してください。

**外へ出る必要があるのがIPv6だけなら、Egress-Only IGW**で足ります。前述のとおり無料です。

**開発・検証環境で、止まっても業務に影響しないなら、NATインスタンス**も選べます。t4g.nanoなど小さなEC2で済み、データ処理料金もかかりませんが、OSの更新や障害時の切り替えは自分で担います。本番で選ぶのは、ポートフォワーディングや踏み台サーバーとの兼用など、NATゲートウェイにできない機能が必要なときに限るべきです。

VPCの出口は、通信先、必要な可用性、月額料金を比較して決めます。外部APIの追加やAZ構成の変更があった場合は、経路と費用を再確認します。設計から構築・運用までまとめて任せたい場合は、[AWSのインフラ構築支援](/service/system/aws/)でもご相談を受けています。

## プライベートサブネットから外へ出られないときの確認順

[AWSのトラブルシューティングガイド](https://docs.aws.amazon.com/ja%5Fjp/vpc/latest/userguide/nat-gateway-troubleshooting.html)が挙げる原因を、通信経路をたどる順に並べると次のようになります。

1. NATゲートウェイの状態が `Available` か。`Failed` は作成時のエラーで、約1時間後に自動で消えます。サブネットの空きIPアドレス不足や、VPCにIGWがアタッチされていない場合も失敗します。
2. プライベートサブネットのルートテーブルに、`0.0.0.0/0` がNATゲートウェイ宛てで入っているか。より細かい宛先のルートが別の装置を向いていないか。
3. ゾーナルの場合、NATゲートウェイがあるサブネットのルートテーブルにIGWへのルートがあるか。ここが漏れていると、NATゲートウェイまでは届いても外へ出られません。
4. インスタンスのセキュリティグループが、アウトバウンドの該当通信を許可しているか。
5. インスタンス側サブネットのネットワークACLが戻り通信を許可しているか。ゾーナルの場合はNAT配置先サブネットのネットワークACLも確認し、NATが使う1024〜65535のポート範囲を考慮しているか。
6. TCP・UDP・ICMP以外のプロトコルを使っていないか。IPsecはそのままでは通らないため、NAT-T（UDPカプセル化）を使います。

NATゲートウェイのElastic IPやプライベートIPにpingを打っても応答は無く、故障の証拠にはなりません。疎通は前述のcurlのようにインスタンス側から試し、原因が絞れなければVPCフローログで破棄（REJECT）を確認します。

## よくある質問

### NATゲートウェイは必要ですか？

プライベートサブネットのリソースがインターネット上のIPv4サービスへ接続する場合、NATゲートウェイは代表的な選択肢です。ただし、NATインスタンスやプロキシなど別の出口を用意する構成では必須ではありません。通信先がS3・DynamoDBなどAWSサービスだけならVPCエンドポイントで代替でき、IPv6だけならEgress-Only IGWで足ります。外へ出る通信が一切ないサブネットには不要で、置くと通信量がゼロでも時間料金が発生し、パブリックNATでは使用するパブリックIPv4アドレスの料金も加わります。

### NATゲートウェイのNATとは何の略ですか？

Network Address Translation（ネットワークアドレス変換）の略です。プライベートIPアドレスを別のアドレスに置き換えて通信させる技術で、家庭用ルーターも同じ仕組みを使っています。AWSのパブリックNATゲートウェイは、インスタンスのプライベートIPを自身のプライベートIPへ変換し、IGWがそれをElastic IPへ変換する2段階で外へ出します。

### NATゲートウェイはどこに置くべきですか？

新規構築では、パブリックサブネットが不要でAZへ自動で広がるリージョナルNATゲートウェイが第一候補で、置き場所はVPCそのものになります。ゾーナルを使う場合は、各AZのパブリックサブネットに1つずつ置き、同じAZのプライベートサブネットからルートを向けます。1つを複数AZで共用すると、そのAZの障害時に他のAZのリソースも外へ出られなくなります。

### NAT Gatewayの料金は1か月いくらですか？

東京リージョンでは、1つあたり時間料金だけで月約45.26ドル（0.062ドル×730時間）です。これに通過したデータ1GBあたり0.062ドルのデータ処理料金と、Elastic IPのパブリックIPv4料金（1時間0.005ドル）、インターネットへのデータ転送料が加わります。3AZ構成なら時間料金は3倍です。

### NATゲートウェイで外部からの接続を受けられますか？

受けられません。NATゲートウェイは内側から始めた接続の応答だけを通し、ポートフォワーディングにも踏み台サーバーとしての利用にも対応していません。外部から接続させたいサーバーは、パブリックサブネットに置いてIGW経由で公開するか、プライベートサブネットに置いたままロードバランサーを前段に置きます。

## 関連記事

- [NAT Gatewayの構築手順とリージョナル移行：AZ設計とポート枯渇の実装対処](/tech/details/17747/)
- [NAT ゲートウェイと NAT インスタンスの違い・料金｜AWSのNATコストを抑える方法](/tech/details/3868/)
- [VPCエンドポイントの料金と違い：ゲートウェイ型・インターフェース型の選び方とNATゲートウェイとの損益分岐【2026年10月】](/tech/details/2326/)
- [AWSのネットワーク接続方式まとめ｜VPC内・VPC間・オンプレ・インターネットの選び分け](/column/details/2805/)
- [NATとは？仕組み・NAPT（IPマスカレード）との違い・静的/動的NATからクラウド実装まで実装者向けに解説](/tech/details/13552/)

---

出典: [AWS NAT Gateway（NATゲートウェイ）とは？インターネットゲートウェイとの違い・料金・作成手順](<https://www.issoh.co.jp/column/details/3105/>)（株式会社一創）