GCP VM の IP アドレス設定 — EC2 との差分ガイド
対象： AWS SAA 保有者向け。
結論（先出し）： 名前は似てるが、「停止時にIPが消えるか」「グローバルIPの意味」「サブネットのスコープ」で挙動が違う。
EC2の感覚で解いていたら詰まったCompute Engineの立ち上げでややこしいところメモ
0. 出発点：
Q: VM作成時にIPアドレスを明示的に指定しなかった場合、どうなるか？
A: サブネットのIP範囲から自動的に「エフェメラルIPアドレス」が割り当てられる
不正解肢のポイント：
- 静的外部IP／静的内部IP → 予約リソースとして別途作成し、アタッチ/解放が必要（明示指定しない場合は使われない）
- グローバル静的外部IP → グローバルLB用。VMには付けられない
これらは全部「AWSと同じ感覚だと踏むミス」なので、以下で対比する。
1. VM作成時のデフォルト挙動：GCP vs EC2
| 観点 | GCP Compute Engine | AWS EC2 |
|---|---|---|
| 内部（プライベート）IP | ✅ 必ずサブネットから自動割当（エフェメラル） | ✅ 必ずサブネットから自動割当（プライマリENIに固定） |
| 外部（パブリック）IP | デフォルトでエフェメラル外部IPが付く（無効化可能） | サブネット設定「Auto-assign Public IP」次第（デフォルトは有効） |
| IPを明示指定しなかった時 | 内外とも自動エフェメラル | 内は自動、外はサブネット設定に従う |
→ 両者とも「何も指定しなければ自動で付く」は共通。ここまでは同じ感覚でOK。
2. ここが違う：停止時にIPが消えるかどうか
最大の落とし穴。SAA感覚だと確実に踏む。
| ケース | GCP | EC2 |
|---|---|---|
| エフェメラル内部IP：VM停止(stop) | 保持される（停止中も同じIP） | 保持される（ENIが残るため） |
| エフェメラル外部IP：VM停止(stop) | ⚠️ 解放される（次回起動時に別のIPになる） | ⚠️ 解放される（再起動で別IP） |
| エフェメラル外部IP：VM削除 | 解放 | 解放 |
| 静的外部IP：VM停止 | 保持（明示解放するまでプロジェクトに保持） | Elastic IPで対応：保持 |
→ 「停止したら外部IPが変わる」はどちらも同じ。ただし用語がすぐズレる：
| 意味 | GCP | AWS |
|---|---|---|
| 一時的なパブリックIP | エフェメラル外部IP | Public IPv4 address（自動割当） |
| 予約済みパブリックIP | 静的外部IP | Elastic IP (EIP) |
要は「エフェメラル ≒ 自動割当パブリックIP」「静的 ≒ EIP」。名前を置換して読めば9割は通じる。
3. ここが違う：リージョン vs グローバル IP の概念
GCPはグローバルという概念がある（AWSにはEIPのグローバル版は存在しない）。試験の不正解肢④はここ。
| IPの種類 | GCPでの用途 | AWSの対応 |
|---|---|---|
| リージョン外部IP（静的/エフェメラル） | VMインスタンス、リージョンLB、Cloud NAT、Cloud VPN | Elastic IP（リージョン単位） |
| グローバル外部IP（静的のみ） | グローバルLB専用（外部アプリLB、外部プロキシNLB）。VMには付けられない | AWSには直接の対応なし。CloudFront/Global Accelerator等がエニーキャストIPを提供 |
| グローバル内部IP | Private Service Connect、プライベートサービスアクセス | AWSにはこの概念自体薄い（PrivateLinkが近い） |
→ 「グローバルIPをVMに」は不可。これはVPCがグローバルなGCPでも変わらない。リソース種別ごとに使えるIPスコープが決まってる。
VPC自体のスコープも逆
| AWS | GCP | |
|---|---|---|
| VPC | リージョン | グローバル（複数リージョンにまたがれる） |
| サブネット | AZ（1つのAZに紐づく） | リージョン（そのリージョンの全ゾーンをまたぐ） |
→ サブネット/AZの粒度感がずれる。ACE頻出。
4. ここが違う：内部IPの「静的」がGCPには明示的にある
| GCP | AWS | |
|---|---|---|
| 内部IPの予約 |
静的内部IPリソースを明示予約できる（gcloud compute addresses create --subnet=... --region=...） |
通常はENIに固定してあるプライマリIPで対応。予約という別リソース概念は無い |
GCPでは「内部IPも静的にできる（別リソースとして予約→VMにアタッチ）」が正式に用意されてる。用途：
- 内部LB用に固定IPを事前確保
- IP変更を許さないオンプレ連携
- DNSに固定内部IPを載せたい
→ EC2感覚だと「内部IPの予約？」となるが、これはGCP側で明示的に予約リソース化されてる。
5. ここが違う④：ネットワークサービスティア（Premium/Standard）
AWSには存在しないGCP独自の概念。
| ティア | 内容 | 影響 |
|---|---|---|
| Premium（デフォルト） | 全球のGoogleバックボーンを使う。世界中どこからでもGoogle網まで最短で入る | 品質高・料金高。外部IPを持つとほぼ強制的にこれ |
| Standard | 通常のインターネット経由。リージョン単位 | 品質そこそこ・料金安 |
- グローバル外部IPは常にPremium
- リージョン外部IPはPremium/Standardを選べる（一部）
- 内部IPは常にPremium相当
→ AWSは「品質1択、料金はデータ転送単価で調整」だが、GCPはIPの持ち方＝ネットワーク品質＝料金が連動する。ACE/PMLEで問われる。
6. アタッチ/解放の運用手順の差
ポイント。
| ケース | 手順 |
|---|---|
| GCP：静的IPを使いたい |
gcloud compute addresses create で予約リソース作成 → VM作成時に --address=<名前> で紐付け → 使い終わったら addresses delete で明示解放 |
| AWS：EIPを使いたい |
allocate-address で確保 → associate-address でEC2に付ける → release-address で解放 |
構造は同じ（予約→アタッチ→解放）。ただし GCP は 「予約解放し忘れると課金され続ける」（未使用状態が高い）。AWSも同じ挙動（EIP未アタッチは課金）だが、GCPの方が料金が明確に高い設計。試験でも「未使用の静的IPを持ち続けるとコストが発生」と問われる。
7. 表で総まとめ（早見表）
| 目的 | GCP | AWS |
|---|---|---|
| VMに自動で付くパブリックIP | エフェメラル外部IP | Public IPv4（Auto-assign） |
| 予約したパブリックIP | 静的外部IP（リージョン） | Elastic IP (EIP) |
| VMに自動で付くプライベートIP | エフェメラル内部IP | Primary Private IPv4 |
| 予約したプライベートIP | 静的内部IP（別リソースで予約） | ENI上に固定 |
| グローバルLB用の固定IP | グローバル静的外部IP（LB専用・VM不可） | ALB/CloudFront/Global Acceleratorが提供 |
| 停止するとエフェメラル外部IPは？ | 解放（再起動で変わる） | 解放（再起動で変わる） |
| VPCのスコープ | グローバル | リージョン |
| サブネットのスコープ | リージョン | AZ |
| ネットワーク品質選択 | Premium/Standard ティア選択あり | なし（1択） |
8. SAA保有者が特に注意する3点（試験の落とし穴）
- 「グローバルIPをVMに付ける」は不可 — グローバルIPはグローバルLBのみ。EC2のEIPと同じ感覚でグローバル指定を選ぶと不正解
- VPCとサブネットのスコープがAWSと逆 — VPCがグローバル、サブネットがリージョン
- 静的内部IPが「予約リソース」として明示的にある — EC2ではあまり意識しない概念
10. 一言まとめ
エフェメラル ≒ EC2の自動割当パブリックIP／静的 ≒ EIP、と置換すれば7割通じる。
残り3割は「グローバルIPの概念」「VPC/サブネットのスコープ逆転」「ネットワークサービスティア」でズレるので、そこだけ差分として押さえる。