GCP Cloud NAT の費用：ゲートウェイ、データ、egress

Public NAT の費用には、NAT gateway、gateway が処理したデータ、使用する外部 IP アドレス、該当する outbound データ転送が含まれます。Gateway 料金は NAT の割り当てを受けるリソース数に左右されるため、ほぼアイドルの fleet でも大量のデータを送る前から gateway と IP の費用が発生します。

Private NAT も gateway の稼働時間と処理データに課金され、Cloud Interconnect、Cloud VPN、Network Connectivity Center を通る通信には各サービスの費用が加わる場合があります。接続リソースと後続の転送料金が異なるため、Public NAT と Private NAT の経路は分けて見積もります。

リージョンごとの gateway について、月間稼働時間、NAT が割り当てられた VM instance または対応リソース数、処理した inbound・outbound GiB、NAT IP 数、宛先を記録します。各項目に公式の最新 Cloud NAT 料金を適用し、インターネットまたは hybrid network の転送料金を加えます。GiB 単位の NAT 処理料金だけをネットワーク費用の総額とみなしてはいけません。

通常時と急増時のシナリオを作ります。GKE node、batch worker、更新の download、外部 API、retry、大容量 export は、利用者向けのリクエスト数が少なく見えても接続数や byte を増やします。Cloud Run などの serverless リソースも、対応する VPC egress 構成を介して Cloud NAT を利用できます。

すべての subnet とリソースに NAT が必要か確認し、未使用の gateway とアドレスを削除し、構成要件が許せば依存サービスを近くに配置します。Cache や artifact mirror で反復する outbound download も減らせます。ただし NAT IP は接続需要に合わせる必要があり、単純に減らすと port 不足で接続が drop する場合があります。

Cloud Monitoring で処理 byte、接続数、port 使用量、allocation error、dropped packet を確認します。Cloud NAT monitoring 自体は無料ですが、出力した NAT log には Cloud Logging の料金が適用されます。運用要件を満たすなら error-only logging から始め、exclusion と retention を意図的に設定し、公開後は実際の gateway metric と公式の最新料金表で再計算してください。