NAT Gatewayとは？private subnet が外へ出られない理由を整理

先に結論

NAT Gateway は、VPC の private subnet に置いたEC2などが、外向きにだけ通信できるようにするためのAWSマネージドサービスです。
ポイントは、private subnet はそのままではインターネットに出られない という前提にあります。

なぜかというと、private subnet のインスタンスは外から直接見えないプライベートIPだけを使い、インターネット向けの出口経路も持たない設計にすることが多いからです。
ただし、実務では完全に閉じたままだと困る場面があります。

OSやミドルウェアのアップデートを取りたい
外部APIを呼びたい
パッケージを取得したい
セキュリティ定義ファイルや時刻情報を更新したい

このときに使う代表的な出口が NAT Gateway です。

この記事は、2026年4月23日時点で AWS 公式の NAT gateways NAT gateway basics Connect to the internet or other networks using NAT devices Pricing for NAT gateways をもとに整理しています。

NAT Gatewayとは何か

AWS公式では、NAT Gateway は private subnet 内のインスタンスが VPC 外のサービスへ接続できるようにするが、外部から未承諾の接続は開始できない サービスと説明されています。
要するに、外には出たいが、外から直接入らせたくない ときの出口です。

ここで大事なのは、NAT Gateway 自体を private subnet に置くのではなく、通常は public subnet に作ることです。
そして private subnet 側のデフォルトルートを NAT Gateway に向けます。

流れをざっくり書くとこうなります。

private subnet のEC2が外部へ通信したい
private subnet の経路設定で、その通信を NAT Gateway へ送る
NAT Gateway が送信元アドレスを変換して外へ出す
応答は NAT Gateway に戻る
NAT Gateway が元の private subnet のEC2へ返す

このため、EC2自身を public にせずに外向き通信だけ確保できます。

private subnet がそのままでは外へ出られない理由

ここがいちばん誤解されやすいところです。
private subnet にいる = 何となくインターネットにつながらない ではなく、ちゃんと理由があります。

主な理由は次の3つです。

1. プライベートIPはそのままではインターネットで通用しない

private subnet のインスタンスは、通常はプライベートIPだけを持ちます。
このIPはVPC内や社内ネットワーク向けのアドレスであり、そのままインターネット上の相手とやり取りする前提ではありません。

そのため、外へ出るには どこかで送信元を変換する仕組み が要ります。
それを担うのが NAT Gateway です。

2. private subnet には外向きの公開経路を持たせない

AWSでは、public subnet はインターネット向けの経路を持ち、private subnet は持たない、という分け方が基本です。
この分離によって、公開が必要なものと、内部に置きたいものを分けます。

つまり private subnet のEC2は、経路設定の時点でインターネットへ直接出る道を持っていない ことが多いです。
NAT Gateway は、この出口を安全寄りの形で足すための部品です。

3. 外からの到達を防ぎたい

インターネットへ直接出られるようにすると、逆に外からも見えやすくなります。
private subnet を使う理由は、アプリ本体、バッチ、内部API、DB近くの処理基盤などを、むやみに公開しないためです。

そのため設計としては、外向き通信は必要だが、受け口は作りたくない になりやすく、NAT Gateway がちょうどそこにはまります。

NAT Gateway は何をしていて、何をしていないのか

NAT Gateway をひとことで言うなら、送信用の出口 です。
ただし、できることとできないことを分けて理解したほうが事故が減ります。

できること

private subnet のリソースを外向きに通信させる
応答パケットを元のインスタンスへ返す
AWS管理サービスとして高可用な出口を使う

できないこと

インターネットから private subnet のEC2へ新規接続を受ける
SSH や RDP の入口になる
WAF のようにアプリ防御を行う
ALB のように受信トラフィックを振り分ける

ここを混同すると、踏み台の代わりになると思っていた 受信もできると思っていた という勘違いが起きます。
管理接続をしたいなら、Session Manager や踏み台構成を別で考える必要があります。

どんな場面で使うのか

NAT Gateway は、外へ少しだけ出たい内部サーバーでよく使われます。

たとえば次のような場面です。

private subnet のEC2がOSアップデートを取りに行く
バックエンドサーバーが決済APIや通知APIを呼ぶ
ECS やEC2上のアプリが外部パッケージやライセンス確認へ出る
内部処理基盤が更新元や外部連携先へ接続する

逆に、すべての通信を何でもかんでも NAT Gateway に通すと、あとで費用が重く見えてきます。
特にAWS内サービス向け通信は、別の選択肢があるかを先に見たほうがよいです。

コストで注意する点

AWS公式では、NAT Gateway は 稼働時間 と 処理したデータ量 の両方で課金されます。
つまり、置いてあるだけでも費用がかかり、通過データが増えるほどさらに増えます。

ここで見落としやすい点は次の3つです。

1. 小さい構成でも固定費が出やすい

アプリ自体が小さくても、NAT Gateway を1台常設するとネットワーク費用が目立つことがあります。
検証環境や小規模サービスでは、EC2本体より NAT Gateway が気になる、ということもあります。

2. AZをまたぐと余計な転送料金が増えやすい

NAT Gateway は通常、特定の Availability Zone に作ります。
AWS公式でも、リソースと NAT Gateway を同じAZに寄せる、またはAZごとに NAT Gateway を置くことが勧められています。

理由は2つあります。

AZ障害時に、別AZのNAT Gatewayへ依存すると外向き通信がまとめて影響を受ける
クロスAZ通信が増えると、費用面でも不利になりやすい

とりあえず1個だけ作る は簡単ですが、本番では可用性と費用の両方で見直し候補になります。

3. AWSサービス向け通信は別経路のほうが安いことがある

AWS公式の料金ドキュメントでも、S3 や DynamoDB など、VPC Endpoint を使えるサービスなら NAT Gateway を通さない設計がコスト削減につながると案内されています。
つまり NAT Gateway は万能な出口ではありますが、全部通す前提 にすると無駄が出やすいです。

よくある誤解

1. private subnet に NAT Gateway を置くと思っている

通常のインターネット向け出口として使う public NAT Gateway は、public subnet に置きます。
private subnet 側は、そこへ向けて経路を張る側です。

2. NAT Gateway があれば受信もできると思っている

できません。
外から始まる接続を受けたいなら、ALB、CloudFront、API Gateway など別の入口が要ります。

3. NAT Gateway は踏み台サーバーの代わりだと思っている

これも違います。
NAT Gateway は管理者が入る入口ではなく、サーバーが外へ出るための出口です。

まとめ

NAT Gateway は、private subnet のリソースに 外向き通信だけ を持たせるための出口です。
private subnet がそのままでは外へ出られないのは、プライベートIPのままでインターネットへ出る設計ではなく、公開経路も持たせないことが多いからです。

そのうえで NAT Gateway を使うと、

EC2や内部アプリを public にしなくてよい
外部APIや更新元には出られる
ただし受信入口にはならない
費用とAZ設計は軽く見ないほうがよい

という整理になります。

最初に覚えるなら、NAT Gateway = private subnet 用の送信用出口 と置くとかなり分かりやすいです。

この記事と一緒に読む

参考リンク

AWS Docs: NAT gateways
AWS Docs: Connect to the internet or other networks using NAT devices
AWS Docs: NAT gateway basics
AWS Docs: Pricing for NAT gateways

NAT Gatewayとは？private subnet がそのままでは外へ出られない理由をAWSで整理