NATの費用はネットワーク経路の費用である
AWS NAT Gatewayの費用は時間単価一つで決まりません。実際の請求額は、Gatewayが動いていた時間、NATを通過したリクエストとレスポンスのデータ、その前後のData Transfer経路、パブリックIPv4やEndpointといった隣接構成が同時に積み上がった結果です。
したがってNAT費用を分析するときは、「NAT Gatewayが何台あるか」より、どのワークロードがどのAZからどの宛先へどれだけ通信しているかを先に描きます。S3・DynamoDBのトラフィック、特定のAWS API、一般のIPv4インターネット、IPv6の宛先は、それぞれ違う経路と代替へつながります。
Regional NAT Gatewayもこの原則を変えません。Regional NATは単一のIDと自動のAZ拡張で多AZ運用を簡単にします。しかし有効化または構成されたAZごとに時間料金が付き、処理データとData Transfer、パブリックIPv4の費用はそのまま残ります。[2]
同じPrivate Subnetから出たトラフィックでも宛先によって経路が分かれます。S3とDynamoDBはGateway EndpointでNAT経路から切り離します。PrivateLink対応のサービスはInterface Endpointを使いますが、AZごとに時間料金が新たに付きます。IPv6の宛先にはEgress-only Internet Gatewayを使い、IPv4-onlyの宛先まで届かせるにはNAT64が要ります。[3]
NAT経路の費用式
NAT費用は五項目に分解するのが安全です。NAT経路総費用は下記の計算項目で定義します。各項目の意味は次のとおりです。
Zonal NATを一台ひと月使えば、ゲートウェイ一台分の時間費用が付きます。Regional NATが同じ期間に三つのAZを支えたなら、リソースIDは一つでもAZ-hourは三倍です。自動モードでは実際に拡張されたAZ、手動モードでは構成したAZを置いて時間費用を確認します。一部の時間は1時間に切り上げられます。[1][2]
月の時間を一律730時間で置きません。730時間は年平均の計算に便利な値であって、実際の請求期間ではありません。30日の月は720時間、31日の月は744時間、閏年でない2月は672時間です。途中で作成または削除したなら実際のプロビジョニング時間を入れます。Regional NATではこの時間をさらにAZごとに分けます。あるAZが月の途中で追加されたなら、すべてのAZに同じ月間時間を入れてはいけません。
NATの処理量はOutbound一つを意味しません。NAT Gatewayは宛先へ出るリクエストと戻るレスポンスの両方を処理します。リクエスト1GBを送りレスポンス3GBを受けたなら、処理量の推定は4GBです。CloudWatchで推定するときは、BytesInFromSourceとBytesInFromDestinationの一組、またはBytesOutToDestinationとBytesOutToSourceの一組だけを使います。四つの指標をすべて足すと、同じパケットをNATへの進入と離脱で二度数えることになります。[6]
最終的な費用検証はCloudWatchの推定値より、CURやCost ExplorerのNAT Data Processed使用量を優先します。Regional NATの指標はNatGatewayIdとAvailabilityZoneの次元を併せて見ます。[5]
GBとGiBを一つの計算の中で混ぜません。AWSの価格表と請求書はふつうGBを使い、CloudWatchは生のBytesを返します。ワークシートではCUR・Cost Explorerが出す請求GBをそのまま使うか、生のバイトを使うならGB=10⁹ bytesとGiB=2³⁰ bytesのどちらの規則かを明示します。二つの規則を途中で混ぜず、最後に請求のline itemと誤差を突き合わせます。価格表のGBの数値に変換済みの値を入れて、さらに1,024で割る方式も避けます。
- H_nat,z
- Zonal NATのゲートウェイごとの稼働時間、またはRegional NATのAZごとの支援時間です。
- B_nat,billed
- 実際にNATを通過して課金されたリクエスト・レスポンスのデータです。
- B_leg,billed
- Cross-AZ、インターネットOut、リージョン間転送など、課金対象になった各経路のデータです。
- H_ip
- NATに紐づく実際のパブリックIPv4の使用時間です。
- C_adjacent
- Interface EndpointやNAT Instanceなど、代替構成で新たに付く費用です。
- NAT経路総費用
- C_NAT_PATH = Σz ceil(H_nat,z) × P_nat_hour + B_nat,billed × P_nat_process + Σleg (B_leg,billed × P_transfer,leg) + Σip (H_ip × P_public_ipv4) + C_adjacent
費用の要因から継続的な管理へ — 支出を業務とリソース単位に分け、影響を確認した対策と予算管理を運用につなげます。
ソウルリージョンで何が加わるか
ソウルリージョンの価格表でNAT Gatewayは1時間あたり$0.059、処理データは1GBあたり$0.059です。ここに実際の経路に応じて三項目が加わります。[1]
一つ目はAZ境界を越える費用です。Private WorkloadがAZ-Aにあり、Zonal NATがAZ-Bにあると、ワークロードとNATの間のリクエストとレスポンスがAZ境界を通ります。AWSのVPC価格ページも、EC2とNATが別のAZにあるとData Transfer費用が付くと明記します。同一リージョンのAZ間のEC2系転送は、一般に送信側と受信側にそれぞれ$0.01/GBが記録される経路があります。ただしLoad Balancer、PrivateLink、VPC Peeringなど経由するリソースによって、請求主体と免除の条件は変わります。費用式に一律でトラフィック × 2を入れず、CURのAPN2-DataTransfer-Regional-Bytesの行と実際の境界を突き合わせます。[1][5][7]
二つ目はインターネットのData Transfer Outです。NATの処理料金はインターネット転送料金を含みません。外部APIやインターネットの宛先へデータを送れば、EC2 Data Transfer Outの宛先・月間区間ごとの料金が別に付きます。逆に同一リージョンのS3へファイルを送る場合、EC2とS3の間の転送費用はなくても、NATを経由したならNATの処理料金は残ります。だから宛先の種類を先に分けます。[1]
三つ目はパブリックIPv4の時間費用です。Public NAT Gatewayにはインターネット通信のためのパブリックIPv4が付き、パブリックIPv4はアドレスごとに時間費用が付きます。Regional NATが処理量や接続数に応じて複数のIPを使うなら、実際のIP-hourも併せて確認します。アドレス数をNATの台数と同じと仮定せず、Public IP InsightsやAPN2-PublicIPv4:InUseAddressの請求行から集計するほうが安全です。[5]
Regional NAT Gatewayが変えた選択肢
従来の多AZ Zonal NAT構成では、一般に五つが必要でした。各AZの公開サブネット、AZごとに置くNAT Gateway、Private Subnetごとのローカル NAT経路、NATサブネットからInternet Gatewayへの経路、そして新しいAZを追加するたびのNAT・Route Tableの修正です。
Regional NATはVPC単位の単一のNAT IDを与えます。公開サブネットにNATを配置しなくてもよく、自動モードではワークロードのネットワークインターフェースが存在するAZを検知して拡張と縮小を行います。各AZでは可能な限りそのAZのRegional NAT地点を使い、zonal affinityを保ちます。[2]
ただし選ぶ前に七つの条件を確認します。AZごとの課金はそのまま残ります。Private NATに対応しないため、Transit Gateway・VPN・オンプレミス接続でプライベートアドレス変換が必要ならZonal NATを検討します。新しいAZへの拡張には最大60分かかり、その間は他のAZで処理されるため、実際のCross-AZ経路を確認します。Constrained AZには対応しません。手動モードではAZとIPの拡張を運用者が管理します。既存のNATから切り替えると接続が初期化されるため、保守時間と外部Allowlist IPの変更可否が必要です。パブリックIPv4の数が増えることがあり、Regional NATはAZあたり最大32個のIPに対応するため、接続規模とIP-hourを併せて見ます。
Regional NATは主に多AZ NAT運用の複雑さと誤ったルーティングの可能性を減らす選択肢です。費用の判断は、同じAZ数と処理量、パブリックIP、転送経路を入れてZonal構成と計算し直します。[2]
代替比較Matrix
八つの選択肢を同じ軸に置いて見ます。固定費と変動費、可用性、運用負担、対象トラフィック、注意する条件です。
Gateway EndpointはS3・DynamoDBに限られますが、Endpoint自体の時間・処理料金がありません。Interface EndpointはサービスごとにAZごとのEndpoint ENIが作られ、データの方向に関係なく処理量の料金が付きます。本番では二つ以上のAZが推奨されるため、可用性の要求が高いほど時間の固定費も大きくなります。[3]
Egress-only Internet GatewayはIPv6のアウトバウンド接続だけを許すステートフルなGatewayで、自体の時間料金はありません。しかし外部の宛先がIPv6に対応している必要があり、インターネットのData Transferは別です。IPv4-onlyの宛先にはDNS64とNAT64を使い、この経路には再びNAT Gatewayの課金が付きます。[1][8]
AWSは管理負担と可用性、帯域を挙げてNAT Gatewayを既定として勧めます。NAT Instanceを選ぶなら、古いNAT AMIではなく現行のAmazon Linuxを土台に自分で構成し、冗長化とパッチ、監視、Failoverを利用者が負います。[4]
選択肢 | 固定費 | 変動費 | 可用性 | 運用負担 | 対象トラフィック | 注意する条件 |
|---|---|---|---|---|---|---|
| Zonal NAT Gateway | Gateway × 稼働時間 | NAT処理量、Data Transfer、IPv4 | AZ内の管理型冗長化。多AZはAZごとの構成が必要 | 低～中 | 一般のIPv4インターネット、Public・Private NAT | 他AZのNATを共有すると費用と障害範囲が広がる |
| Regional NAT Gateway | 有効・構成済みAZ × 稼働時間 | NAT処理量、Data Transfer、実際のIPv4 | 自動モードでのAZ拡張とzonal affinity | 低 | 一般のPublic IPv4インターネット | Private NAT不可、拡張の遅延、切替時に接続が初期化 |
| Gateway Endpoint | Endpointの追加費用なし | Endpointの処理費用なし | AWS管理 | 低 | 同一リージョンのS3・DynamoDB | 他のサービスには適用されず、VPCの外へ広げるのに制約 |
| Interface Endpoint / PrivateLink | サービス × Endpoint AZ × 時間 | Endpoint処理量、必要なData Transfer | 多AZ構成で向上 | 中 | 対応するAWSサービス・SaaS・Endpoint Service | サービスが多くトラフィックが少ないと固定費が大きくなる |
| Native IPv6 + Egress-only IGW | Gatewayの費用なし | インターネットData Transferなど | AWS管理 | 中 | IPv6に対応する宛先 | アプリケーション・DNS・ファイアウォール・外部依存のIPv6対応が必要 |
| DNS64 + NAT64 | NAT Gatewayの時間とIPv4 | NAT処理量と転送 | NAT構成に従う | 中 | IPv6-only SourceからIPv4-only Destinationへ | NAT費用が残り、DNS64・64:ff9b::/96の経路が必要 |
| NAT Instance | EC2・EBS・IPv4・HAインスタンス | 転送量、インスタンス使用量 | 冗長化とFailoverを自前で設計 | 高 | 一般のNATとカスタムのネットワーク機能 | パッチ・容量・障害・ポート枯渇・復旧を自分で負う |
| NATが必要なトラフィックの削減 | Cache・Mirror・Endpointなどの構築費 | 減ったトラフィックと新構成の費用 | 構成による | 中 | 繰り返しのダウンロード、Polling、Retry、Telemetry、Artifact | トラフィックを消したのか、別の費用へ移しただけかを確認 |
Endpointの損益分岐点はデータ量だけで決まらない
Interface Endpointの月額費用はおよそ C_INTERFACE = N_services × Σaz ceil(H_endpoint,az) × P_endpoint_hour + B_endpoint × P_endpoint_process + C_transfer です。NATからInterface Endpointへ移すときの単純な損益分岐点は、Interface Endpointの固定時間費用を、回避されるNAT処理単価と回避される転送単価の和からEndpointの処理単価を引いた値で割ったものです。
分母が0以下なら、データ量が増えても費用だけではEndpointが有利になりません。この計算には六つを別途反映します。Endpointが必要なサービスの数、本番で必要なEndpoint AZの数、Endpointが避けるCross-AZまたはインターネットの経路、Private DNSとセキュリティ方針の価値、NAT Gatewayが他のトラフィックのためにどのみち残るかどうか、そしてEndpoint導入後にも残るNATの最小固定費です。
NATを完全に消せない環境でEndpointが減らすのは、たいていNATの処理量の一部です。そのときはEndpointの時間固定費と、減る変動費を並べて比べます。
監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。
Decision Matrix
現在のトラフィックがどの形かによって、最初に開く選択肢が変わります。下の九行は、トラフィックの形とそのとき検討する代替、続いて確認する項目を対にしたものです。
現在のTraffic | 最初に検討する選択肢 | 次に確認する項目 | 判断の理由 |
|---|---|---|---|
| 同一リージョンのS3・DynamoDBの比重が大きい | Gateway Endpoint | Route Table、Endpoint Policy、既存接続の切替 | Endpoint自体の時間・処理料金がなく、NAT処理経路を切り離せる |
| 少数のAWS API・SaaSへ継続的に多いトラフィック | Interface Endpoint | サービスの対応可否、AZ数、Private DNS、損益分岐点 | Private pathとアクセス制御を得る代わりに、サービス・AZごとの固定費が付く |
| 多数の不特定なIPv4インターネット宛先 | ZonalまたはRegional NAT | AZ数、Private NATの要否、Allowlist IP、運用方式 | Endpointで一般インターネット全体を置き換えられない |
| 多AZのPublic NAT運用が頻繁に変わる | Regional NAT | 自動・手動モード、対応AZ、拡張の遅延、IP方針 | NATとRoute Tableの運用を簡単にしつつAZごとのaffinityを与える |
| オンプレミス・TGW経路にプライベートNATが必要 | Zonal Private NAT | ルーティング、AZ冗長化、アドレス重複 | Regional NATはPrivate NATに対応しない |
| 宛先とアプリケーションがIPv6対応 | Native IPv6 + Egress-only IGW | DNS、Security Group、NACL、外部API、観測ツール | NAT44の処理経路を使わずに済む |
| IPv6-only SourceがIPv4-only APIを呼ぶ | DNS64 + NAT64 | DNS64、64:ff9b::/96、Public NAT、テスト | IPv6-onlyのワークロードは維持できるが、NAT費用は残る |
| 低頻度・断続的で、独自機能が必要 | NAT Instanceを候補に | EC2の仕様、HA、Failover、パッチ、Source/Destination Check | 管理型の費用の代わりに運用責任と容量リスクを引き受ける |
| Artifact・パッケージ・ログ・RetryがNAT使用量の大半 | Traffic自体の削減 | Cache hit、再試行、転送頻度、圧縮、Mirror | ネットワーク機器を替える前に不要なバイトを減らす |
NAT Cost Worksheet
ワークシートは三つのブロックです。Aはすべての計算に共通で入る入力です。Bは宛先別のTraffic Rowで、Cは費用項目ごとの計算式です。
BのTraffic Rowは一行に一つの経路を書きます。列はSourceとAZ、Destination、IP Family、Request、Response、現在の経路、NAT TypeとAZ、Cross-AZ境界、Endpoint AZ、Internet Outです。
各行で三つの値を計算します。NAT処理量はNATを通過したRequestとResponseの和です。Cross-AZの課金量は実際に課金される各AZ境界のBytesの和です。Internet Outはインターネットへ出た実際のResponseとUploadから、該当する無料枠や免除を引いた値です。
RequestとResponseのうちEndpointやキャッシュへ抜けたデータはNAT処理量から除きます。逆に、インターネットOutとNAT処理量が同じデータだからといって、どちらか一方だけを計算してもいけません。別々のMeterだからです。
- 基準日
- 実際に価格を検証した日付です。価格表は変わるため、計算のたびに確認し直します。
- Region
- すべてのリソースと価格が属するリージョンです。ソウルはap-northeast-2です。
- 通貨
- 為替を適用する前の表示通貨です。
- 税
- 見積もりと実際の請求を比べるため、含むか含まないかを分けて記します。
- 分析期間
- 開始日と終了日です。暦月か任意期間かも併せて記します。
- 単位
- CUR GB、GB、GiBのいずれか一つに固定した規則です。
- コミットメント・クレジット
- サービス原価と最終請求を分けるため、金額を記すか除外と明記します。
Cost Component | Formula |
|---|---|
| Zonal NATの時間 | Σ ゲートウェイごとのrounded hours × $0.059 |
| Regional NATの時間 | Σ AZごとのrounded support hours × $0.059 |
| NAT処理 | CUR NAT processed GB × $0.059 |
| Cross-AZ | Σ billed leg GB × 該当するData Transfer rate |
| Internet Out | 該当GB × ソウルリージョンの宛先・区間別rate |
| Public IPv4 | 実際のIP hours × $0.005 |
| Gateway Endpoint | $0 endpoint hour + $0 endpoint processing |
| Interface Endpointの時間 | サービス数 × AZごとのendpoint hours × $0.013 |
| Interface Endpointの処理 | 実際のprocessed GB × 適用tier |
| NAT Instance Compute | インスタンスごとの実行時間 × ソウルのOn-Demand rate |
| NAT Instanceのその他 | EBS + IPv4 + Transfer + Monitoring + HA Replica |
| 運用費用 | パッチ・障害対応・Failoverテスト・On-callに投じる社内費用 |
分析の前に揃えるMetric Checklist
指標は五つの領域に分けて集めます。BillingとTopology、Traffic、Reliability、Change Planです。
Cost ExplorerとCURには、NATの時間と処理量、Inter-AZ Data Transfer、Internet Out、VPC Endpointの時間と処理量、パブリックIPv4が別々の使用タイプとして現れます。一つの「VPC費用」の合計だけを見ると、どの経路が原因か分かりにくくなります。[5]
領域 | 揃える項目 | 分析の目的 |
|---|---|---|
| Billing | NAT Gateway Running Hours、Data Processed | 時間費と処理量を分ける |
| Billing | APN2-DataTransfer-Regional-Bytes | Cross-AZ費用の確認 |
| Billing | Internet Data Transfer Out | NAT処理費とインターネット転送費を分ける |
| Billing | APN2-VpcEndpoint-Hours、APN2-VpcEndpoint-Bytes | Endpointの固定費と変動費 |
| Billing | APN2-PublicIPv4:InUseAddress | NATとその他リソースのIPv4費用 |
| Billing | NAT InstanceのEC2・EBS・Data Transfer | 自前NATの総費用 |
| Topology | NAT ID、Zonal/Regional、Automatic/Manual | 課金単位と運用モデルの確認 |
| Topology | Subnet・Route Table・AZのマッピング | Cross-AZ Hairpinの検出 |
| Topology | Regional NATの対応AZと実際のIP | AZ-hourとIP-hourの確認 |
| Topology | Gateway・Interface Endpointの一覧 | NATから切り離せる宛先 |
| Topology | Private DNS・Endpoint Policy | 実際のトラフィックがEndpointへ向かうかの確認 |
| Topology | IPv6 CIDR、::/0、64:ff9b::/96 | Native IPv6とNAT64の経路確認 |
| Traffic | BytesInFromSource、BytesInFromDestination | リクエストとレスポンスを合わせた処理量の推定 |
| Traffic | ActiveConnectionCount | 接続規模とポート使用の確認 |
| Traffic | ErrorPortAllocation | ポート不足の有無 |
| Traffic | VPC Flow LogsのSource・Destination・Bytes | 宛先と原因ワークロードの分類 |
| Traffic | Retry・Polling・Artifact・Telemetryの比重 | 除去できるTrafficの確認 |
| Reliability | AZ障害時のEgress経路 | 費用より可用性が優先する区間の確認 |
| Reliability | Regional NATの拡張時間の許容可否 | 新規AZ配置時の一時的なCross-AZ影響 |
| Reliability | 外部Allowlist IPの要求 | NATの変更・切替の可否 |
| Reliability | NAT InstanceのFailover・Patch記録 | 運用費用と障害リスクの算定 |
| Change Plan | Route変更の順序とRollback | Endpoint・Regional NAT切替の安全性 |
| Change Plan | 接続初期化の許容時間 | NAT切替のMaintenance Window |
| Change Plan | 切替前後の同一期間のCUR | 削減の有無と費用移動の検証 |
どの順序で変えるべきか
最初の段階はNATを消すことではなく、宛先別のTraffic Inventoryを作ることです。S3・DynamoDBのトラフィックをGateway Endpointの候補として切り出し、繰り返し大きな比重を占める対応サービスをInterface Endpointの候補として切り出します。外部インターネットのトラフィックはAPI、Artifact、Telemetry、Update、利用者データに分けます。
次にSourceとNATのAZ境界を確認し、IPv6で直接届く宛先とNAT64が要る宛先を分けます。各代替が新たに作る時間の固定費と運用責任を計算したうえで、同じ期間のCURで変更の前後を比べます。
この過程を経ると、「NATを別の機器に替えるか」より正確な問いに届きます。どのトラフィックはNATから切り離し、どのトラフィックは管理型NATに残し、どのトラフィックはそもそも減らすべきかです。
