NAT ゲートウェイ

NAT ゲートウェイとは

NAT ゲートウェイ (Network Address Translation Gateway) は、VPC のプライベートサブネットに配置されたリソース (Lambda, EC2) がインターネットにアクセスする際に、プライベート IP をパブリック IP に変換するゲートウェイである。通信を開始できるのは VPC 側からだけで、その応答は戻ってくるが、インターネット側から一方的に張られた接続は届かない。

変換は 2 段構えで起きる。NAT ゲートウェイは送信元をまず自身のプライベート IP へ書き換え、パブリック IP (Elastic IP) への対応付けはその先のインターネットゲートウェイが担う。NAT ゲートウェイだけ置いてもインターネットゲートウェイへ向くルートが無ければ外に出られないのは、このためだ。接続タイプにはパブリックとプライベートの 2 種があり、Elastic IP を持ってインターネットへ出るのは前者だけである。プライベート型は Transit Gateway や仮想プライベートゲートウェイ経由で他の VPC やオンプレミスへ抜けるための型で、Elastic IP は関連付けられず、インターネットゲートウェイへ向いた通信は破棄される。

なぜ必要か

プライベートサブネットのリソースはパブリック IP を持たないため、直接インターネットにアクセスできない。外部 API の呼び出し、npm パッケージのダウンロード、外部サービスとの通信に NAT ゲートウェイが必要だ。

[Lambda (プライベートサブネット)]
  → [NAT ゲートウェイ (パブリックサブネット)]
  → [インターネットゲートウェイ]
  → [インターネット]

コスト

NAT ゲートウェイは AWS で最もコストが見落とされやすいサービスの 1 つだ。

項目	料金 (東京リージョン・2026 年 8 月時点)
時間料金	$0.062/時間 (~$45/月)
データ処理	$0.062/GB

見落としが起きるのはデータ処理料金の方だ。時間料金は起動している限り一定額で予測しやすいのに対し、データ処理料金は通信相手がインターネットでも AWS のサービスでも同じように乗るため、S3 へ 1 TB 送れば処理料だけで $60 前後が加算される。

AZ ごとに 1 台という構成は必須ではなく、可用性のための推奨だ。1 台を複数の AZ で共有すれば時間料金は 1 台分で済むが、その AZ が落ちた瞬間に他の AZ のリソースまでインターネットへ出られなくなり、平常時も AZ を跨ぐ通信にデータ転送料金が上乗せされる。2 AZ に置いて冗長化すると時間料金は月 $90 になり、そこにデータ処理料金が積み上がる。

VPC エンドポイントでコスト削減

S3 や DynamoDB へのアクセスは、NAT ゲートウェイではなく VPC エンドポイント (ゲートウェイ型、無料) を使う。

❌ Lambda → NAT GW → インターネット → S3  (有料)
✅ Lambda → VPC エンドポイント → S3        (無料)

アクセス先	推奨方式	コスト (東京リージョン・2026 年 8 月時点)
S3	ゲートウェイエンドポイント	時間料金・データ処理料金なし
DynamoDB	ゲートウェイエンドポイント	時間料金・データ処理料金なし
SQS, SNS	インターフェースエンドポイント	$0.014/時間 (AZ ごと) + データ処理 $0.01/GB
外部 API	NAT ゲートウェイ	$0.062/時間 + データ処理 $0.062/GB

料金が完全に消えるのはゲートウェイ型 (対応するのは S3 と DynamoDB だけ) で、それ以外のサービスはインターフェース型になり、時間料金が AZ ごとに発生する。2 AZ に置いたインターフェースエンドポイント 1 つで月 $20 ほどかかるため、NAT ゲートウェイを別用途で既に立てている環境では、GB あたり $0.052 の差額でこの $20 を回収できるか、つまりそのサービス向けの通信が月 400 GB を超えるかが判断の目安になる。呼び出し量の小さいサービスにまで片端からエンドポイントを並べると、かえって高くつく。

詰まるのは帯域より同時接続

帯域は 5 Gbps から始まり 100 Gbps まで自動で伸び、パケット処理も毎秒 100 万パケットから 1000 万パケットまで拡張されるので、太さそのものが先に限界になることは稀だ。実務で先に当たるのは同時接続数で、1 つの IPv4 アドレスから同一の宛先 (宛先 IP・宛先ポート・プロトコルの組) に張れるのは同時 55,000 接続までである。単一の外部 API へ大量並列でリクエストを投げる構成や、接続を閉じ切らないクライアントを並べた構成では、帯域に余裕があるのにエラーが出る。対処は接続の再利用と宛先の分散が先で、それでも足りなければ NAT ゲートウェイに IPv4 アドレスを追加する (最大 8 個) か、サブネットを分けて台数を増やす。

Lambda を VPC に入れるべきか

Lambda を VPC に収容すること自体に料金はかからない。コストが生まれるのは、VPC に入れた関数がインターネットへ出る必要があり、そのために NAT ゲートウェイを立てるときだ。VPC 内の関数が触るのが S3 や DynamoDB だけならゲートウェイエンドポイントで足り、NAT ゲートウェイは要らない。VPC に入れる必要があるのは:

• RDS/ElastiCache にアクセスする場合
• VPC 内の他のリソースにアクセスする場合

外部 API や AWS サービスだけにアクセスする Lambda は、VPC に入れない方がシンプルでコストが低い。

NAT ゲートウェイの理解を深めるには関連書籍が参考になる。