【AWS】 NAT Gateway｜初学者向けにまとめてみた

はじめに

AWSでVPCを設計しはじめると、ほぼ必ず登場するのが NAT Gateway です。
ところがチュートリアル通りに作ってみたものの、

• そもそも「何のために」配置しているのかピンと来ない
• Internet Gatewayと何が違うのかわからない
• なぜパブリックサブネットに置くのに、プライベートサブネット用なの？
• 気づいたら毎月のコストを圧迫していた¹

…という疑問を抱える人が後を絶ちません。

この記事ではAWS初学者向けに、NAT Gatewayが「何を解決するための仕組みなのか」を図解中心でゼロから解説します。さらに、2025年11月にリリースされた新機能 リージョナルNAT Gateway にも触れていきます。

対象読者

• AWSの基礎を学習中の方（VPC・サブネット・EC2の名前は知っているレベル）
• ハンズオンで「とりあえず動いた」が、仕組みを言語化できない方
• AWS認定資格（CLF・SAA）の学習中で、用語の意味を腹落ちさせたい方

前提知識

用語	一言で
VPC	AWS内に作る仮想ネットワーク
サブネット	VPCを分割した区画
EC2	AWSの仮想サーバー
ルートテーブル	サブネット内の通信先を決めるルール表

参考リンク

まず結論：NAT Gatewayとは何なのか？

ひとことで言うとこうです。

プライベートサブネット内のリソースが、インターネットに「出る」ことだけを許可するための仕組み

ポイントは「片道切符」だということです。

• ✅ プライベートサブネット → インターネット（OK）
• ❌ インターネット → プライベートサブネット（NG）

つまり、EC2から yum update や外部API呼び出しはできるけど、外からそのEC2に直接アクセスはできない、という状態を作ってくれるサービスですね。

「なぜそんな機能が必要なのか？」を理解するには、まずVPCのサブネット設計の話から押さえるのが近道です。

前提知識：パブリックサブネットとプライベートサブネット

VPCの中にはサブネットを複数作ることができ、外との通信のしやすさで2種類に分類されます。

種類	インターネットとの直接通信	用途の例
パブリックサブネット	✅ できる	ALB、踏み台サーバー、Web公開リソース
プライベートサブネット	❌ できない	DB、アプリケーションサーバー、バッチ処理

実は、AWSの仕組み上で「パブリック」「プライベート」というスイッチがあるわけではありません。ルートテーブルにInternet Gatewayへのルートが設定されているか否か だけが両者の違いです。

Internet Gatewayの役割

Internet Gateway は、VPCをインターネットに接続する「出入口」です。

ルートテーブルに 0.0.0.0/0 → IGW のルートを追加することで、サブネット内のリソースが外部と双方向に通信できるようになります。

じゃあなぜ「プライベートサブネット」が必要なの？

「全部パブリックでよくない？」と思うかもしれませんが、本番運用では推奨されません。

理由は セキュリティ です。

• DBサーバーがインターネットから直接見える状態は危険
• アプリケーションサーバーに不要な攻撃面を作りたくない
• 本来外から見える必要のないリソースは隠したい

そのため、本番のAWS設計では「外向きが必要なリソースだけパブリック、それ以外はプライベート」とするのが鉄則になっています。

ここで詰まる：プライベートサブネットの矛盾

ここで一つ問題が起こります。

プライベートサブネットに置いたEC2は、外と通信できません。
しかし現実には、こんなことをやりたい場面が頻繁にあります。

• yum update や apt-get install でパッケージを取得したい
• アプリから外部APIを叩きたい（例: Stripe、SendGrid）
• pipやnpmでライブラリをインストールしたい

つまり「外から守られたいけど、内側からは外に出たい」という需要があるわけですね。

ここで登場するのが NAT Gateway です。

NATが解決するこの「内→外はOK、外→内はNG」のパターンは、家庭のブロードバンドルーターと全く同じ仕組みです。インターネット側からあなたの自宅PCに直接アクセスはできませんが、PCからWebサイトの閲覧はできるのと同じ理屈ですね。

NAT Gatewayが解決すること（NATの基本）

NAT = Network Address Translationとは

NATは Network Address Translation の略で、日本語でいうと「ネットワークアドレス変換」です。

ざっくり言うと、IPアドレスを書き換えて通信を中継する仕組み です。

EC2のプライベートIPアドレス（例: 10.0.1.5）はインターネットでは使えないため、NAT Gatewayが自分のグローバルIPアドレスに書き換えて中継します。
返ってきたパケットも、NAT Gatewayが「この通信は誰が始めたものか」を覚えていて、元のEC2に正しく戻してくれます。

「片道切符」のイメージで理解する

NAT Gatewayの最大の特徴は、発信元になれるのは内側だけ という点です。

通信方向	可否	理由
プライベートEC2 → 外部サーバー	✅ OK	NATが翻訳して中継する
外部サーバー → プライベートEC2	❌ NG	NATは「自分から始まった通信の応答」しか戻さない

これにより、外向きの通信は許可しつつ、外から内へのアクセスは遮断するという構成が実現できるわけです。

NAT Gatewayの全体像（図解）

登場人物

NAT Gatewayを成立させるためには、以下のリソースが連携して動いています。

リソース	役割
VPC	ネットワーク全体の入れ物
Internet Gateway	VPCとインターネットの出入口
パブリックサブネット	NAT Gatewayを置く場所
プライベートサブネット	EC2など守りたいリソースを置く場所
NAT Gateway	プライベート→外への中継役
Elastic IP	NAT Gatewayが使う固定パブリックIP
ルートテーブル	サブネットからの通信先ルール

通信の流れをステップで追う

実際のフローを追ってみましょう。

ポイントは、NAT Gateway自身はパブリックサブネットに配置する という点です。
NAT Gatewayはインターネットと通信する必要があるため、Internet Gatewayへ抜けられる場所、つまりパブリックサブネットに置く必要があります。

「NAT Gatewayはプライベートサブネット用なのに、なぜパブリックサブネットに置くの？」というのは初学者が必ず詰まる点です。
「サービス対象はプライベートサブネット、配置場所はパブリックサブネット」 と覚えておきましょう。

似て非なるもの：Internet GatewayとNAT Gatewayの違い

両者は名前が似ていて混乱しがちですが、役割は明確に違います。

項目	Internet Gateway	NAT Gateway
役割	VPCとインターネットの出入口	プライベートサブネット用の片道出口
通信方向	双方向	内→外のみ
配置場所	VPCにアタッチ（サブネットには置かない）	パブリックサブネット内
料金	無料	時間課金＋データ処理課金
個数	VPCあたり1つ	サブネットごとに必要（ゾーナルモードの場合）

注意したいのは、Internet GatewayがあるからといってNAT Gatewayが不要になるわけではない ということ。
むしろ、NAT GatewayはInternet Gatewayがある前提で動作します。両者は競合ではなく、組み合わせて使うものですね。

NAT Gateway vs NATインスタンス（昔の選択肢）

NATの仕組みを実現する手段は、もう一つあります。それが NATインスタンス です。

NATインスタンスは、NAT機能を持つAMIをEC2として自分で起動する方式で、NAT Gatewayが登場する前の選択肢でした。

項目	NAT Gateway	NATインスタンス
管理	フルマネージド	自分で運用
可用性	AZ内で自動冗長化	自前でAuto Scalingなどを組む必要
帯域	5 Gbpsから100 Gbpsまで自動拡張	EC2インスタンスタイプに依存
コスト	高め（時間+データ処理）	安め（EC2料金のみ）
用途	本番環境向け	検証・小規模・コスト最優先用途

個人検証や開発環境ではNATインスタンスが選ばれることもありますが、本番ではほぼNAT Gatewayが選ばれるのが一般的です。自前でフェイルオーバーを設計するコストの方が、NAT Gatewayの利用料より高くつくケースが多いためですね。

注意ポイント：NAT Gatewayは"知らぬ間に高い"

NAT GatewayはAWSコスト最適化の話題で常連のサービスです。
理由は料金構造にあります。

料金構造

NAT Gatewayの料金は、大きく2つの要素で構成されます。

料金要素	課金単位
NAT Gatewayの起動時間	1時間ごと（プロビジョニングされている限り発生）
データ処理料金	1GBごと（送信・受信両方向）

つまり、何もしていなくても起動時間で課金され、通信が発生すればさらにデータ処理料金が乗る という構造ですね。

具体的な単価はリージョンによって異なるため、必ず公式の料金ページを確認してください（執筆時点では東京リージョンで時間あたりとデータ処理あたりとも、同程度の単価が設定されています）。

よくあるコストの落とし穴

NAT Gatewayでコストが膨らむ典型パターンは以下の通りです。

1. S3との通信をNAT Gateway経由で行ってしまう
   • S3はAWS内部のサービスなので、本来はNAT Gateway経由にする必要がない
   • ところが何も設定しないと、S3向けの通信もNAT Gatewayを通ってしまう
2. マルチAZでNAT Gatewayを必要以上に立てている
   • 開発環境なのに3AZ構成にしていて、NAT Gatewayが3つ常時起動しっぱなし
3. コンテナがインターネット越しにイメージをpullしている
   • ECR（プライベート）への通信もVPCエンドポイントが無いとNAT Gateway経由になる

NAT Gatewayの料金は 「EC2 - Other」 という分類で請求されることが多く、Cost Explorerで気づきにくいのが厄介な点です。
NAT Gatewayの利用状況は、CloudWatchメトリクスの BytesOutToDestination や BytesInFromDestination で確認する習慣をつけておきましょう。

コスト削減の基本：VPCエンドポイントを使う

NAT Gatewayのコストを抑える最大の打ち手が VPCエンドポイント です。

VPCエンドポイントは、AWS内部のサービス（S3、DynamoDB、ECR、CloudWatchなど）への通信を、インターネットを経由せずVPC内で完結させる仕組みです。

エンドポイントタイプ	対象サービス	料金
Gatewayタイプ	S3、DynamoDB	無料
Interfaceタイプ	ECR、SSM、その他多数	時間課金あり（NAT Gatewayより安いことが多い）

特にS3とのやり取りが多いシステムでは、Gateway型VPCエンドポイントを設定するだけでNAT Gatewayの処理量を大幅に減らすことができます。

まとめ

ここまでの内容を振り返ります。

• NAT Gatewayは プライベートサブネットからインターネットへの片道通信 を実現する仕組み
• 内→外はOK、外→内はNGという「片道切符」の挙動が本質
• パブリックサブネットに配置するが、サービス対象はプライベートサブネット
• Internet Gatewayとは役割が違う（IGWありきで動く）
• 2025年11月のリージョナルNAT Gatewayにより、マルチAZ運用が大幅にシンプル化された
• 料金は 時間課金＋データ処理課金 で、放置するとコスト増の常連になる
• VPCエンドポイントの活用がコスト削減の基本

1. 「気づいたらNAT Gatewayが請求の大半を占めていた」というコスト最適化事例は、各社のテックブログで定番のテーマになっています。 ↩