NAT Gateway の料金が高い本当の理由 - データ処理料金の仕組みと回避策
NAT Gateway の時間料金とデータ処理料金が高額になるメカニズムを分解し、VPC エンドポイント、NAT インスタンス、IPv6 への移行など、コストを削減する実践的な回避策を解説します。
NAT Gateway の二重課金構造
NAT Gateway の料金は 2 つの要素で構成されます。時間料金は、NAT Gateway が存在する時間に対して課金されます。ap-northeast-1 では 1 時間あたり 0.062 USD で、月額に換算すると約 45 USD です (2026 年 8 月時点)。使用していなくても、存在しているだけで課金されます。データ処理料金は、NAT Gateway を通過するデータ量に対して課金されます。1GB あたり 0.062 USD です。この料金は、通常のデータ転送料金に加算されます。つまり、プライベートサブネットの EC2 インスタンスがインターネット上の API を呼び出すと、NAT Gateway のデータ処理料金 (0.062 USD/GB) + インターネットへのデータ転送料金 (0.114 USD/GB) の合計 0.176 USD/GB が課金されます。マルチ AZ 構成で各 AZ に NAT Gateway を配置すると、時間料金だけで月額 135 USD (3 AZ) になります。NAT Gateway は何もしなくても月額 135 USD かかるため、小規模な環境ではコストに占める割合が大きくなることがあります。
データ処理料金が膨らむパターン
NAT Gateway のデータ処理料金が想定外に高額になるパターンがあります。代表的なのは、プライベートサブネットから AWS サービスの API を呼び出すケースです。S3 へのファイルアップロード、CloudWatch Logs へのログ送信、SQS へのメッセージ送信など、AWS サービスへの通信がすべて NAT Gateway を経由すると、データ処理料金が発生します。たとえば、Lambda 関数が VPC 内に配置されており、S3 に 1 日 100GB のデータをアップロードする場合、NAT Gateway のデータ処理料金だけで月額約 186 USD (100GB × 30 日 × 0.062 USD) になります。もう一つのパターンは、AZ をまたぐ NAT Gateway の利用です。AZ-a のインスタンスが AZ-c の NAT Gateway を使うと、インスタンスと NAT Gateway の間に AZ 間のデータ転送料金もかかります。各 AZ に NAT Gateway を配置し、ルートテーブルで同じ AZ の NAT Gateway を使用するよう設定することで、AZ 間転送料金を回避できます。
VPC エンドポイントによるコスト削減
NAT Gateway のコストを下げる方法の一つは、AWS サービスへの通信を VPC エンドポイント経由に切り替えることです。S3 と DynamoDB にはゲートウェイエンドポイントが利用でき、追加料金なしで NAT Gateway を迂回できます。ゲートウェイエンドポイントは、ルートテーブルにエントリを追加するだけで機能し、データ処理料金もかかりません。S3 への大量のデータ転送がある環境では、ゲートウェイエンドポイントを入れると、NAT Gateway のデータ処理料金を減らせます。その他の AWS サービス (CloudWatch、SQS、SNS、KMS、ECR など) にはインターフェースエンドポイント (PrivateLink) を使用します。インターフェースエンドポイントにも時間料金とデータ処理料金がかかるため、通信量に応じて NAT Gateway の料金と比べて選びます。データ量が多いサービスから順にインターフェースエンドポイントを導入する進め方があります。CloudWatch Logs、ECR (コンテナイメージのプル)、Systems Manager は、通信量が多くなりやすいサービスの例です。
NAT インスタンスという選択肢
NAT Gateway の代わりに、EC2 インスタンスで NAT 機能を実現する NAT インスタンスという選択肢があります。t4g.nano のような小さなインスタンスに NAT を設定すると、NAT Gateway の時間料金 (月額 45 USD) を下げられます。NAT インスタンスにはデータ処理料金がかかりません。通常の EC2 のデータ転送料金のみです。ただし、NAT インスタンスにはデメリットがあります。可用性の管理が自分の責任になります。NAT Gateway はマネージドサービスで自動的に冗長化されますが、NAT インスタンスは単一の EC2 インスタンスであり、障害時の自動復旧を自分で設計する必要があります。スループットも EC2 インスタンスのネットワーク帯域に制限されます。NAT Gateway は最大 100Gbps まで帯域が伸びますが、NAT インスタンスの帯域は選んだインスタンスタイプのネットワーク性能で決まります。開発環境やトラフィックの少ない環境では NAT インスタンスが合理的ですが、本番環境では NAT Gateway のマネージドな冗長性を選ぶ考え方があります。fck-nat という OSS の AMI を使えば、NAT インスタンスのセットアップを簡素化できます。
IPv6 への移行 - NAT Gateway が不要になる未来
IPv6 を使うと、NAT Gateway を通す通信を減らせる可能性があります。IPv6 アドレスはグローバルにユニークであるため、NAT (Network Address Translation) が不要です。プライベートサブネットの EC2 インスタンスに IPv6 アドレスを割り当て、Egress-Only Internet Gateway を使用すれば、インスタンスからインターネットへのアウトバウンド通信が可能になります。Egress-Only Internet Gateway 自体に料金はかかりませんが、インスタンスのデータ転送料金はかかります。ただし、IPv6 への完全移行にはハードルがあります。すべての AWS サービスが IPv6 をサポートしているわけではありません。また、通信先のサーバーが IPv6 をサポートしていない場合、IPv4 での通信が必要です。現実的なアプローチは、デュアルスタック (IPv4 + IPv6) 構成で段階的に IPv6 に移行することです。AWS サービスへの通信は VPC エンドポイント経由、IPv6 対応の外部サービスへの通信は Egress-Only Internet Gateway 経由、IPv4 のみの外部サービスへの通信だけ NAT Gateway 経由、という構成にすれば、NAT Gateway を通過するトラフィックを減らせます。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトと公式ドキュメントです。最新の仕様と料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。