Cloud NAT

解決する課題

外部 IP アドレスを割り当てない VM やコンテナ、ジョブから、インターネットや一部の Google API へ安全に外向き通信したい、という要件を満たします。

• 攻撃面を減らすため VM に外部 IP を付けたくないが、OS パッケージ更新や外部 API 呼び出しの外向き通信は必要
• 多数のインスタンスの送信元を少数の共有 IP に集約し、相手側の許可リスト（アローリスト）を簡素にしたい
• インバウンドは一切許さず、アウトバウンドと戻りの応答だけを通したい
• NAT 機器の冗長化・スケール・運用を Google に任せたい

主要概念と用語

• Cloud NAT ゲートウェイ: VPC ネットワークの特定リージョン・特定サブネットに対して、送信元 NAT を提供する論理的な構成。物理的な単一機器ではなく Google が分散実装する
• Public NAT: 外部 IPv4 アドレスを持たない VM などから、インターネット上の宛先へ送信するための変換。共有する外部 IP とポートを使う
• Private NAT: Cloud VPN や Cloud Interconnect などで接続されたオンプレミス・他クラウド・別 VPC との間で、重複するプライベートアドレスを変換する機能
• Cloud Router: Cloud NAT の設定（NAT 対象や IP の割り当て情報）を配布する制御プレーン。リージョン単位で関連付ける。NAT のデータ経路そのものではなく設定を司る点に注意
• 変換の方向: 往路では送信元を変換し、確立済み接続の応答では対応表を使って宛先を元へ戻す。外部から開始される未承諾の受信接続は提供しない
• NAT IP の割り当て: NAT に使う外部 IP を自動割り当て（auto）にするか、予約済みの静的 IP を手動割り当て（manual）にするかを選ぶ
• エンドポイント非依存マッピング（EIM）: 同一の内部送信元に対し、宛先が変わっても同じ NAT IP・ポートを再利用する挙動。一部のピアツーピア通信で必要になる
• NAT 対象範囲: ゲートウェイがどのサブネットのプライマリ／セカンダリ範囲を NAT 対象にするかの指定。サブネット単位で細かく選べる

仕様・制限・クォータ

• リージョン単位のサービス。1 つのゲートウェイは 1 つの VPC・1 つのリージョンを対象とし、複数リージョンをまたぐ場合はリージョンごとに作成する
• 接続開始は内側から。Public NAT はインターネットから VM への接続を開始できず、Private NAT も接続先ネットワークからの未承諾な受信を許可しない。戻りの応答だけを通す
• Private NAT は自動モード VPC をサポートせず、変換用の専用サブネットと接続先への経路を設計する必要がある
• NAT には外部 IP ごとに利用可能なポート数の上限があり、1 つの IP で同時に張れる接続数は有限。多数の同時接続が必要なら、割り当て IP を増やすか VM あたりの最小ポート数を調整する
• ポート枯渇を起こすと新規接続が失敗するため、IP 数と VM あたりポート数のバランス設計が重要
• TCP / UDP / ICMP を対象にできる。プロトコルごとにタイムアウト（アイドル時間）が設定可能
• 外部 IP を持つ VM、外部ロードバランサ配下で直接応答する経路など、そもそも別経路で外へ出る通信は NAT 対象外
• 具体的なポート数・タイムアウト・クォータの数値は変動するため、設計時は公式ドキュメントで最新値を確認する

内部の仕組み

横にスクロール

Cloud NAT はソフトウェア定義の分散 NAT です。図の Public NAT でも Private NAT でも、トラフィックを集約する専用の NAT 機器やプロキシ VM を経由させず、基盤側で変換するため、単一のボトルネックや単一障害点を持ちにくい構造になっています。

• 設計上、NAT 用の外部 IP とポートを各 VM へ事前に割り当てておき、VM はその範囲を使って外へ出る。Cloud Router がこの割り当て情報を配布する
• アウトバウンドのパケットは内部 IP・ポートから NAT IP・ポートへ付け替えられ、戻りの応答は元の内部アドレスへ戻される
• 一方で、宛先ごとに NAT IP・ポートを使い分けるエンドポイント依存の挙動が既定で、これが NAT としての安全性に寄与する。ピアツーピアで穴あけが必要な場合のみ EIM を検討する
• マネージドサービスとしてスケールするため、インスタンス数の増加に合わせて追加の NAT 機器をプロビジョニングする必要はない

設計パターン / ベストプラクティス

• VM には外部 IP を付けず、外向き通信は Cloud NAT に集約して攻撃面を最小化する
• 相手先の許可リストが必要なら、手動割り当ての静的 IP を NAT に使い、送信元 IP を固定・公開する
• オンプレミスや他クラウドと CIDR が重複する場合は Private NAT を使い、変換用サブネットと往復経路を明示する
• 同時接続が多いワークロードでは、NAT IP を複数用意し、必要なら動的ポート割り当てを有効化して枯渇を避ける
• ゲートウェイはリージョンごとに用意し、ワークロードと同一リージョンで NAT して不要なリージョン間転送を避ける
• 多くの Google API はプライベート経路（限定公開の Google アクセスなど）で到達できるため、API 向け通信に Cloud NAT を必須にしない設計も検討する
• GKE のプライベートクラスタからの外向き通信や、外部 IP を持たないバッチ・パイプラインの egress に活用する

運用・監視

• Cloud Monitoring で、割り当て済みポート数・使用中ポート数・ドロップされた接続数などのメトリクスを監視し、ポート枯渇の予兆を捉える
• NAT ロギングを有効化すると、変換された接続やドロップされた接続を Cloud Logging に記録できる。ログ対象は「変換のみ」「エラーのみ」「両方」から選べる
• 枯渇の兆候（ドロップ増加）が出たら、NAT IP の追加または VM あたりポート数の調整で対応する
• アイドルタイムアウトが長すぎるとポートが解放されず枯渇しやすいため、ワークロードに合わせて調整する

コスト

課金は「NAT ゲートウェイの稼働」と「処理データ量」が中心です。外部 IP アドレス自体の料金も考慮します。

セキュリティ

• インバウンドを一切許さない設計が基本価値。外部から VM への接続開始を構造的に防ぐ
• VM に外部 IP を付けないことで、直接到達できる攻撃面を排除する
• NAT IP を固定すれば、相手側で送信元ベースの許可・監査がしやすくなる
• ファイアウォール（VPC ファイアウォールルール）で egress 自体も制御し、行き先を必要なものに絞る
• NAT ロギングで外向き接続の可視性を確保し、不審な egress を検知する

Well-Architected の観点

• セキュリティ: 外部 IP を排除しインバウンドを遮断、egress を NAT とファイアウォールで集約・制御する。最小権限ならぬ「最小到達面」を実現する
• 運用上の優秀性: 冗長化・スケール・パッチを Google に委ね、メトリクスとログで枯渇や異常を検知できる運用に寄せる。自前 NAT VM の保守から解放される

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# NAT 用の静的外部 IP を予約（送信元 IP を固定したい場合）
gcloud compute addresses create nat-ip-1 --region=asia-northeast1

# Cloud Router を作成（NAT 設定の配布に使う）
gcloud compute routers create nat-router \
  --network=my-vpc \
  --region=asia-northeast1

# Cloud NAT ゲートウェイを作成（手動 IP・全サブネット範囲を対象）
gcloud compute routers nats create my-nat \
  --router=nat-router \
  --region=asia-northeast1 \
  --nat-custom-subnet-ip-ranges=all \
  --nat-external-ip-pool=nat-ip-1 \
  --enable-logging

# 設定を確認
gcloud compute routers nats describe my-nat \
  --router=nat-router \
  --region=asia-northeast1