NAT Gateway の仕組みとコスト最適化
akinori概要
AWS で VPC を設計すると、ほぼ必ず登場するのが NAT Gateway です。プライベートサブネットに置いたリソース（EC2、Lambda、ECS タスクなど）から外部インターネットへ「出ていく」通信を可能にするマネージドサービスですが、仕組みを理解せずに使うと請求書で驚くことになりがちな要注意コンポーネントでもあります。本記事では入門者向けに、NAT Gateway の役割・通信の流れを整理したうえで、実務で効くコスト最適化の勘所を公開情報ベースでまとめます。
パブリックとプライベート
VPC の中のサブネットは、ルートテーブルの構成によってパブリックかプライベートかが決まります。
- パブリックサブネット: ルートテーブルに Internet Gateway（IGW）へのデフォルトルート（
0.0.0.0/0）を持つ - プライベートサブネット: IGW への直接ルートを持たない
セキュリティ上、DB やアプリケーションサーバーはプライベートサブネットに置くのが定石です。しかしプライベートサブネットのリソースも、OS のパッケージ更新・外部 API の呼び出し・コンテナイメージの取得など、外向きの通信が必要になります。ここで NAT Gateway が登場します。
NAT Gateway とは何をするものか
NAT（Network Address Translation）は、送信元のプライベート IP アドレスを、NAT Gateway が持つパブリック IP（Elastic IP）に付け替えて外部と通信させる仕組みです。重要なのは通信の「向き」です。
- プライベート → インターネット（アウトバウンド起点）: 可能
- インターネット → プライベート（インバウンド起点）: 不可能
つまり NAT Gateway は「中から外への通信」と「その戻り」だけを通します。外部から勝手に接続されることはないため、プライベートサブネットのセキュリティを保ったまま外向き通信だけを許可できます。外部からの接続を受けたい場合は、ロードバランサーや別途 IGW を使うことになります。
通信の流れ
プライベートサブネットの EC2 から外部 API を叩くケースを追ってみます。
[Private Subnet] [Public Subnet] [Internet]
EC2 (10.0.2.10)
│ ①外部へリクエスト
▼
Route Table
0.0.0.0/0 → NAT Gateway
│ ②NAT Gateway へ
▼
NAT Gateway (EIP: 203.0.113.5)
│ ③送信元IPを付け替え
▼
Internet Gateway ──────▶ 外部API
│
◀──────────────────────────────────────────────── ④戻り
- プライベートサブネットの EC2 が外部宛にパケットを送出
- プライベートサブネットのルートテーブルが
0.0.0.0/0を NAT Gateway に向けているため NAT Gateway へ転送 - NAT Gateway が送信元 IP を自身の Elastic IP に変換し、パブリックサブネット経由で IGW から外へ
- 戻りのパケットは NAT Gateway が変換テーブルを見て元の EC2 に返す
ポイントは NAT Gateway 自体はパブリックサブネットに配置し、そこから IGW へ抜ける構成です。プライベートサブネットのルートは NAT Gateway を、NAT Gateway のあるパブリックサブネットのルートは IGW を向きます。
コスト構造を理解する
NAT Gateway の課金は大きく2つに分かれます（最新の正確な数値は必ず公式の料金ページを確認してください）。
- 時間課金: NAT Gateway が存在している限り、1時間あたりの固定料金が発生する
- データ処理課金: NAT Gateway を通過したデータ量（GB 単位）に対して課金される
さらに見落としがちなのが、このデータ処理料金とは別に、通常のデータ転送料金も上乗せされる点です。大量のデータをプライベートサブネット経由で外に流すと、二重の従量課金が効いてきます。「使っていなくても立っているだけで課金」「通せば通すほど課金」という二段構えなので、放置された検証環境の NAT Gateway が地味にコストを積み上げているケースは珍しくありません。
コスト最適化のポイント
1. VPC エンドポイントで NAT を経由させない（最も効く）
S3・DynamoDB・ECR・CloudWatch Logs など多くの AWS サービスへの通信は、VPC エンドポイントを使えば NAT Gateway を経由せず AWS 内部ネットワークで完結できます。
- Gateway 型エンドポイント（S3 / DynamoDB）: 追加料金なしで使える。ルートテーブルに追加するだけ
- Interface 型エンドポイント（ECR / CloudWatch など）: ENI とわずかな課金があるが、NAT のデータ処理料金より安くなるケースが多い
コンテナ環境で ECR からイメージを頻繁に pull する、大量のログを CloudWatch に送る、といった構成では NAT を通さないだけで大きな削減になります。
# S3 Gateway エンドポイント作成の例（AWS CLI） aws ec2 create-vpc-endpoint \ --vpc-id vpc-xxxxxxxx \ --service-name com.amazonaws.ap-northeast-1.s3 \ --route-table-ids rtb-xxxxxxxx \ --vpc-endpoint-type Gateway
2. AZ 冗長度を環境に応じて調整する
NAT Gateway は AZ 単位のリソースです。可用性を重視するなら AZ ごとに配置するのが定石ですが、時間課金もその数だけ増えます。
- 本番の可用性重視環境 → 各 AZ に配置（片方の AZ 障害時も外向き通信を維持）
- 検証・開発環境 → 1つに集約してコスト削減
単一 AZ 集約は、その AZ が落ちると全プライベートサブネットの外向き通信が止まるトレードオフがあります。
3. 不要な外向き通信そのものを減らす
- 外部通信をバッチ化し、常時ダラダラ流さない
- 検証環境は使わない時間帯に NAT Gateway を削除する運用（再作成は数分）
4. 本当に NAT Gateway が必要か問い直す
外向き通信がほぼ発生しないワークロードなら、そもそも NAT Gateway は不要です。逆に「外部から接続を受けたいだけ」なら NAT ではなくロードバランサーを検討します。
確認方法
- Cost Explorer の「使用タイプ（Usage Type）」で
NatGateway-Hours（時間課金）とNatGateway-Bytes（データ処理課金）を分離して確認する - CloudWatch の NAT Gateway メトリクス（
BytesOutToDestinationなど）で、どれだけデータが流れているかを把握する
注意点
- NAT Gateway はアウトバウンド専用。インバウンドの入口には使えない
- 単一 AZ 集約はコストと引き換えに可用性を落とす。本番では慎重に
- VPC エンドポイントは万能ではなく、対応サービスと型（Gateway/Interface）を確認する必要がある
- 料金の具体的な数値は変動するため、判断時には必ず公式の最新料金を参照する
まとめ
NAT Gateway は「プライベートサブネットから外へ出るための、アウトバウンド専用のマネージド NAT」です。仕組みはシンプルですが、立っているだけの時間課金と通した分のデータ処理課金という二段の従量課金を持つため、コスト最適化の観点が欠かせません。効果が大きい順に、①VPC エンドポイントで AWS サービス通信を NAT から逃がす、②環境に応じて AZ 冗長度を調整する、③外向き通信量そのものを減らす、の順で見直すのが実務的です。まずは Cost Explorer で「NAT がいくら食っているか」を可視化するところから始めてみてください。
＼ 最新情報をチェック ／
