はじめに
AWS認定ソリューションアーキテクト – アソシエイト（SAA）の勉強を進めていくとVPCの範囲では、NAT Gateway というサービスが出てきます。
「プライベートサブネットからインターネットへアクセスするために使う」と説明されるのですが、これまで業務で使っていたのはS3やDynamoDBなどが中心で、NAT Gatewayを意識することはありませんでした。
なぜこんな仕組みが必要なのかという部分も含めて、順を追って整理した内容をまとめます。
パブリックサブネットとプライベートサブネット
VPCはAWS上に作る自分専用の仮想ネットワークで、サブネットはそれを用途ごとに区切った小さなネットワークです。EC2やRDSは、必ずどれか1つのサブネットに配置されます。
サブネットは役割によって2つに分けて使います。
パブリックサブネット：インターネットと通信するサブネット
Webサーバーや、社内から接続するための踏み台サーバーなど、外部と通信するリソースを置きます。
プライベートサブネット：インターネットと通信しないサブネット
データベースサーバーなど、セキュリティ上インターネットに接続させたくないリソースを置きます。
この2つを分けているのは、ルートテーブルという通信の行き先を決める設定です。サブネットごとに1つ紐づいており、インターネットへの経路が、VPCの出入口である IGW（インターネットゲートウェイ）に向いていればパブリック、経路そのものが無ければプライベートになります。
課題：プライベートサブネットからも外部通信が必要になる
プライベートサブネットは外部から守られていますが、運用上こちらから外へ出たい場面があります。
- OSのセキュリティパッチを取得する
- 外部のAPIを呼び出す
- コンテナイメージを取得する
必要なのは「外から内側への通信（インバウンド）は受け付けないが、内側から外への通信（アウトバウンド）は許可する」という状態です。
プライベートサブネットの経路をIGWに向ければ解決しそうですが、これでは通信できません。
IGWは、EC2が持っているパブリックIPアドレスを使って外部と通信する仕組みです。プライベートサブネットのEC2はパブリックIPを持っていないので、IGWへの経路があっても外に出ていくことができません。
そこで、プライベートサブネットのEC2が外部と通信するには、代わりに通信してくれる存在が要ります。
NAT Gatewayとは
NAT Gatewayは、プライベートサブネットのリソースに代わってインターネットと通信するサービスです。パブリックサブネットに配置し、プライベートサブネットからの通信をここに集めて外部に中継します。
[プライベートサブネット] [パブリックサブネット]
EC2 ----------------> NAT Gateway ----> IGW ----> インターネット
<---------------- <---- <----
仕組み
NATは Network Address Translation（ネットワークアドレス変換）の略で、送信元のIPアドレスを書き換えるのが役割です。
プライベートサブネットのEC2が持っているのはプライベートIPアドレスです。これは自分のネットワーク内部でのみ通用するアドレスで、インターネット上では使えません。世界中で重複しているので、そのまま外部に送っても応答を返しようがないのです。
そこでNAT Gatewayが、送信元を自身のパブリックIPアドレスに書き換えて外部に送り出します。このとき「この通信はどのEC2からのものか」を記録しておき、応答が返ってきたらその記録をもとに元のEC2へ転送します。
これにより、プライベートIPアドレスしか持たないEC2でも外部と通信できるようになります。
外部から接続できない理由
インターネット側から突然通信が届いた場合、NAT Gatewayにはその通信に対応する記録がありません。転送先を判断できず、通信は破棄されます。
つまり「アウトバウンドは可、インバウンドは不可」というのは、意図的に設けられた制限ではなく、アドレス変換の仕組み上そうなるということです。
作成に必要なもの
NAT Gatewayを作成するときに指定するのは、主に次の2つです。
- 配置するサブネット（パブリックサブネットを指定）
- Elastic IP（AWSから払い出される固定のパブリックIPアドレス。NAT Gatewayが外部と通信する際に使います）
作成後、プライベートサブネットのルートテーブルでインターネット宛ての経路をNAT Gatewayに向けることで利用できるようになります。
注意点やつまずきポイント
NAT Gatewayは構成を誤ると動かない・気づかず課金され続けるといった注意点があるサービスです。
パブリックサブネットに配置する
NAT Gateway自身が外部と通信するので、プライベートサブネットに置くと機能しません。プライベートサブネットのためのサービスですが、NAT Gateway自身はパブリックサブネットに配置します。
作成しただけでは通信できない
NAT Gatewayを作っただけでは何も起きません。プライベートサブネットのルートテーブルで、インターネット宛ての通信をNAT Gatewayに向ける設定を別途行います。
アウトバウンド専用
NAT Gatewayでは、プライベートサブネットのサーバーを外部に公開することはできません。Webサーバーを公開したい場合は、NAT Gatewayではなくロードバランサー（ALBなど）をパブリックサブネットに配置します。
AZ単位のサービスである
NAT Gatewayは、1つのAZの中に存在します。そのAZで障害が発生すると、そのNAT Gatewayを参照している別のAZのサブネットも外部通信できなくなります。
サブネットやEC2は複数のAZに分散させたのにNAT Gatewayは1つだけ、という構成では冗長化できていないことになります。
可用性が必要ならAZごとに作成し、それぞれのルートテーブルを分けて設定します。
補足
AZ間の通信自体にもデータ転送料がかかります。AZごとにNAT Gatewayを分けるのは、可用性だけでなくこの点でも意味があります。
セキュリティグループを設定できない
セキュリティグループはリソース単位で通信を制御するファイアウォールですが、NAT Gatewayには設定できません。通信を制御したい場合は、サブネット単位で制御するネットワークACLか、通信元のEC2側のセキュリティグループで行います。
存在するだけで課金される
NAT Gatewayは通信量に関わらず、存在しているだけで時間単位の料金が発生します。加えて、処理したデータ量に応じた料金もかかります。東京リージョンでは次のとおりです。
| 料金の種類 | 単価 | 月額換算 |
|---|---|---|
| 時間料金 | $0.062/時間 | 約 $45（730時間） |
| データ処理料金 | $0.062/GB | 100GBなら $6.2 |
2026年8月時点・東京リージョン
通信が一切なくても月$45かかる計算です。検証で作成した場合は、削除を忘れないようにしましょう。
また、NAT Gatewayを削除しても割り当てていたElastic IPは残ります。使っていないElastic IPも課金対象になるので、不要であれば併せて解放します。
AWSサービス宛ての通信はインターネットに出ていない
これまで業務でS3を使うときは、アップロードしたファイルにURLでアクセスする、という使い方をしていました。そのため、S3はインターネット上にあるサービスで、EC2から使う場合もインターネットを経由するものだと思っていました。
調べてみると、同じリージョン内のEC2とS3の通信は、AWSのネットワーク内で完結しており、インターネットには出ておらずデータ転送料も無料です。
インターネットに出ないのであれば、プライベートサブネットのEC2からS3への通信に、NAT Gatewayは要らないように思えますが、標準の構成では、この通信もNAT Gatewayを経由します。
理由はルートテーブルにあります。S3はVPCの外にあります。そのため宛先としては「VPC内のどれにも当てはまらないアドレス」、つまりインターネット宛ての経路に該当します。ルートテーブルはそこに書かれた行き先を見ているだけなので、実際の通信がどこを通るかとは無関係にNAT Gatewayへ送られます。
結果として、インターネットに出ていない通信のために、NAT Gatewayの利用料だけを払っている状態になります。プライベートサブネットのEC2からS3にファイルを置くだけの構成でも、NAT Gatewayを用意することになります。
VPCエンドポイントで解決できる
この状態を解消するのが VPCエンドポイント です。VPCからAWSサービスへ、IGWやNAT Gatewayを経由せずに直接接続するための入口です。
[プライベートサブネット]
EC2 ----------------> VPCエンドポイント ----> S3
<---------------- <----
※ NAT Gateway・IGWを経由しない
メリットは2つあります。
コスト削減
ゲートウェイ型のVPCエンドポイント（S3・DynamoDB向け）は無料で利用できます。NAT Gatewayを経由しなくなるので、その分の利用料がかかりません。
たとえば、プライベートサブネットのEC2から月100GBをS3に送るだけの構成なら、次の差になります。
| 構成 | 月額 |
|---|---|
| NAT Gateway経由 | 約 \$51（時間料金 \$45 + データ処理 \$6.2） |
| ゲートウェイ型VPCエンドポイント | $0 |
外部との通信がS3だけであれば、NAT Gateway自体が不要になります。
セキュリティ強化
VPCエンドポイントを使えば、そのサブネットはインターネットへの経路を一切持たないままS3を利用できます。外部とつながる経路自体を構成から無くせるので、より安全になります。
補足
VPCエンドポイントには2種類あり、無料で使えるのはS3とDynamoDB専用のゲートウェイ型です。他のサービス向けはインターフェース型という有料のものになります。S3でもインターフェース型を選べば課金されるため、コスト目的であればゲートウェイ型を選びます。
まとめ
- パブリックサブネットはWebサーバーや踏み台など外部と通信するもの、プライベートサブネットはDBなど公開したくないものを置く
- パブリックIPを持たないEC2は、IGWへの経路があっても外部と通信できない
- NAT Gateway は、プライベートサブネットのリソースに代わって外部と通信するサービス
- 送信元のIPアドレスを書き換えて中継し、その記録をもとに応答を返す
- 外部から接続できないのは制限ではなく、変換の記録がないため転送先を判断できないから
- 注意点は、パブリックサブネットに配置する・ルートテーブルの設定が別途必要・アウトバウンド専用・AZ単位・セキュリティグループ設定不可・存在するだけで課金される
- S3などへの通信はインターネットに出ていないが、標準ではNAT Gatewayを経由してしまう
- VPCエンドポイント（ゲートウェイ型）を使えば無料になり、コスト削減とセキュリティ強化の両方につながる
S3などのフルマネージドのサービスでは意識しない部分が、EC2をVPCに置くと必要な設計事項になってくることを学びました。
NAT GatewayとVPCエンドポイントの使い分けなどSAA試験対策としても理解しておきたいところです。
参考
※本記事の内容および料金は2026年8月時点・東京リージョンのものです。最新の仕様と価格は必ず公式ドキュメントでご確認ください。