Google Cloud Assosiate Cloud Engineer　第7章　典型アーキテクチャと設計判断

Google Cloud Assosiate Cloud Engineer
第7章　典型アーキテクチャと設計判断

7.1 非公開 Web サービス

この節では、いわゆる「社外には見せない Web サービス」を、Google Cloud 上でどう設計するかを整理します。

ACE レベルで押さえてほしいのは、次の 3 パターンです。

  1. VPC 内だけで完結する非公開 Web（Internal Application Load Balancer）
  2. インターネット経由だが、ユーザ単位で絞り込むゼロトラスト型（IAP）
  3. 別 VPC / 別プロジェクト・組織向けにプライベート公開する（Private Service Connect）

先に結論イメージを出すと、「どこからアクセスさせたいか」「ネットワークで絞るか / ID で絞るか」で構成を選び分けます。

7.1.1 非公開 Web サービスとは何か

ここで扱う「非公開 Web サービス」は、次のような要件を持つシステムです。

  • 一般インターネットからは見せたくない
  • アクセスできるクライアントは限定したい
    • 社内ネットワーク内のみ
    • 社員・パートナーなど認証済みユーザのみ
  • 監査・認可・ネットワーク制御をきちんと行いたい

Google Cloud 上の基本パーツは以下です。

  • VPC / サブネット / ルート / ファイアウォール
    • 内部ネットワーク境界の制御
  • Cloud Load Balancing（internal / external）
    • Web トラフィックの入口
    • 外部向け（external）か VPC 内向け（internal）かをモードで選択
  • Identity-Aware Proxy（IAP）
    • Cloud Run / App Engine / HTTPS Load Balancing / internal HTTP LB へのアクセス制御を、ユーザ ID ベースで行う
  • Private Service Connect（PSC）
    • 別 VPC から、サービス提供側の VPC にあるサービスへ、内部 IP 経由でプライベート接続する仕組み

この組み合わせで、代表的な非公開 Web の構成パターンを組み立てていきます。

7.1.2 パターン 1：VPC 内限定の社内 Web（Internal Application Load Balancer）

概要

Internal Application Load Balancer（内部 HTTP(S) LB） は、VPC 内または VPC に接続されたネットワーク（VPC Peering / Cloud VPN / Cloud Interconnect）からのトラフィックだけを扱う L7 ロードバランサです。

典型的な構成：

  • クライアント
    • 同一 VPC 内の VM / GKE / サービス
    • オンプレミスから Cloud VPN / Interconnect 経由で接続
  • フロントエンド
    • Internal Application Load Balancer（内部 IP アドレスを持つ）
  • バックエンド
    • MIG（Compute Engine）
    • NEG（GKE Service など）

構成イメージ

  1. VPC に社内 Web 用のサブネットを用意
  2. 同じ VPC 内に Internal Application Load Balancer を作成し、バックエンドに MIG / NEG を接続
  3. オンプレミスからは Cloud VPN / Interconnect で VPC に接続
  4. クライアントは Internal LB の 内部 IP に HTTP(S) アクセス

HTTP(S) ロードバランサ自体は、バックエンドの 内部 IP を使ってヘルスチェック・トラフィック分散を行います。

メリット・向いているケース
  • インターネットには一切さらさない構成が取りやすい
  • ネットワーク境界でシンプルに制御できる
    • Cloud VPN / Interconnect のトンネル単位でアクセス制御
    • VPC ファイアウォールでクライアントサブネットを制限

向いている要件：

  • 「社内 LAN / VPN のみからアクセスする社内ポータル」
  • 「バックエンド API を、他の社内システムだけに見せたい」
注意ポイント（ACE 観点）
  • Internal LB は「同一 VPC または接続された VPC / VPN / Interconnect からのトラフィックのみ」を扱う
  • インターネットから直接アクセスさせたい場合は、external LB を別途用意する必要がある

7.1.3 パターン 2：インターネット経由だが ID ベースで絞る（IAP）

Identity-Aware Proxy（IAP）概要

Identity-Aware Proxy（IAP） は、アプリケーションや Web サービスへのアクセスを、ネットワークではなく ユーザの ID / グループ を基準に制御するサービスです。

IAP がサポートする代表的なバックエンド：

  • Cloud Run
  • App Engine
  • Cloud Load Balancing（HTTPS、external / internal HTTP）

IAP を有効にすると、対象サービスへのリクエストは IAP による認証・認可を必ず通るようになります。

典型構成：社員向けゼロトラスト Web

要件例：

  • 社員は社外からも利用する（在宅 / 出張）
  • ただし、認証された社員だけに見せたい
  • VPN 前提にはしたくない

構成イメージ：

  1. External Application Load Balancer（HTTPS）を作成
  2. バックエンドに Cloud Run / App Engine / MIG / NEG を接続
  3. LB またはバックエンドサービスに対して IAP を有効化
  4. Cloud IAM で、「このアプリにアクセス可能なユーザ・グループ」を roles/iap.httpsResourceAccessor などで付与

動作イメージ：

  • ユーザはブラウザから LB の HTTPS エンドポイントへアクセス
  • IAP が認証（Google アカウント / Cloud Identity / Google Workspace）を行い、
    • 認可されたユーザであればバックエンドへリクエストを転送
    • 不正なアクセスは 401 / 403 で拒否
メリット・向いているケース
  • クライアントが「インターネット上のどこにいてもよい」が、認証されたユーザだけに絞りたい
  • IP アドレスや VPN に依存せず、「ユーザ / グループ」単位で制御したい
  • Cloud Run / App Engine / HTTPS LB など、Google Cloud ネイティブサービスと統合したい

代表的なユースケース：

  • 社員向けの内製業務 Web
  • パートナー向けポータル（ユーザ単位発行）
  • SaaS の管理コンソール（管理者だけアクセス可能にする）

IAP とネットワーク制御の併用

IAP は L7 の認証・認可を担当しますが、ネットワーク制御と組み合わせるとより安全です。

  • HTTPS LB のフロントはインターネットに公開しつつ、
    • Cloud Armor で L7 WAF / DDoS 防御
    • VPC ファイアウォールや Org Policy で一部ネットワークからの到達を制限

ACE 試験では、

  • 「ゼロトラスト」「ID ベース」「VPN なしでも社員だけ」
  • 「Cloud Run / App Engine / HTTPS LB へのアクセス制御」

といったキーワードがあれば、IAP を選ぶ流れになります。

7.1.4 パターン 3：Private Service Connect による非公開公開

Private Service Connect（PSC）の概要

Private Service Connect（PSC） は、サービス利用者（コンシューマ）の VPC 内に 内部 IP を持つエンドポイント を作成し、そのエンドポイント経由でサービス提供者（プロデューサ）の VPC 内のサービスにプライベート接続できる仕組みです。

特徴：

  • コンシューマ側から見ると、「自分の VPC 内にある internal IP へ接続しているだけ」に見える
  • 実際には、そのトラフィックが Google のバックボーン経由で、サービス提供者の VPC にある service attachment まで届く
  • Google が提供するマネージドサービス（Cloud SQL / Google APIs など）へのプライベート接続にも使われる

典型構成：パートナー向け非公開 Web / API

要件例：

  • 自社 VPC でホストしている Web / API を、特定の顧客 VPC からだけ使わせたい
  • インターネットには出したくない
  • 接続元は VPN / Interconnect 越しのオンプレではなく、相手側の Google Cloud VPC

構成イメージ（サービス提供側＝プロデューサ）：

  1. Producer VPC に Internal Application Load Balancer + バックエンド（MIG / GKE 等）を構成
  2. Internal LB の背後に PSC service attachment を作成し、「どのプロジェクト / VPC からの接続を許可するか」を制御

構成イメージ（サービス利用側＝コンシューマ）：

  1. Consumer VPC で PSC エンドポイント を作成
  2. そのエンドポイントに internal IP が割り当てられる
  3. アプリケーションは、その internal IP を向いて HTTP(S) アクセス
メリット・向いているケース
  • 相手側からは「自分の VPC 内の private IP にアクセスしているだけ」に見える
  • サービス提供側は、インターネットへ晒さずにマルチテナントな非公開サービスを提供できる
  • 複数コンシューマを持つ BtoB SaaS / API との相性が良い

ACE 試験では、「サービス提供側 VPC と利用側 VPC を、プライベートにピンポイントでつなぐ」「Google Cloud APIs や独自サービスに internal IP でアクセス」というキーワードが出たときは、Private Service Connect が選択肢に上がります。

7.1.5 どのパターンを選ぶか：判断ポイント

非公開 Web を設計するときの判断軸を、ACE 向けにシンプルに落とします。

軸 1：クライアントの場所

  • 社内 VPC / オンプレ（VPN / Interconnect 経由）だけ
    • → Internal Application Load Balancer
  • インターネット上のどこからでも可、ただし認証済みユーザだけ
    • → External HTTPS LB + IAP、または IAP を直接有効化した Cloud Run / App Engine
  • 別 VPC / 別プロジェクト / 別組織の VPC からのみ
    • → Private Service Connect（必要に応じて internal LB + PSC service attachment）

軸 2：制御の単位（ネットワークか、ID か）

  • ネットワーク単位で制御したい
    • VPC / サブネット / Cloud VPN / Interconnect / VPC ファイアウォール
    • Internal LB + VPN の構成がベース
  • ユーザ / グループ単位で制御したい
    • IAP + Cloud IAM
    • ネットワークはインターネットでも可

軸 3：マルチテナント / パートナー提供か

  • 社内のみで完結
    • Internal LB / IAP で十分
  • 複数顧客 VPC に対して、同じサービスを安全に提供
    • Private Service Connect を検討

7.1.6 ACE 試験で狙われやすいポイント

最後に、この分野でよく出る勘違いと、それに対応する正しい考え方を整理します。

誤解 1：「非公開ならとりあえず VPN」

VPN は有力な選択肢ですが、「社員がどこからでも使いたい」 場合には運用負荷が高くなります。

  • ゼロトラスト型の要件（どこからでも、ID ベースでアクセス）には IAP がマッチする
  • 問題文に「VPN クライアントをインストールさせたくない」「ブラウザと ID だけで制御したい」とあれば、VPN より IAP を優先して考える

誤解 2：「Internal LB は HTTP だけの話」

Internal Application Load Balancer は HTTP(S) 用の L7 LB ですが、Google Cloud には TCP/UDP 向けの Internal TCP/UDP Load Balancer も存在します。

ACE レベルでは、

  • 「HTTP(S) → Internal Application LB」
  • 「TCP/UDP → Internal TCP/UDP LB」

という使い分けができれば十分です。

誤解 3：「パートナー VPC とプライベートに繋ぐなら VPC Peering 一択」

VPC Peering は VPC 同士を広くつなぐ仕組みで、「ネットワークをほぼ一つにまとめてしまう」性質があります。

対して、Private Service Connect は「特定のサービスだけをエンドポイント経由で提供する」方式です。

  • 全体ネットワークを相互接続したい → VPC Peering
  • 特定サービスだけをプライベートに提供したい → Private Service Connect

という整理ができていれば、選択肢で迷いにくくなります。

誤解 4：「IAP があれば LB は適当でいい」

IAP は Cloud Run / App Engine / HTTPS Load Balancing / internal HTTP LB に対する認証・認可を提供しますが、
ロードバランサの種類・配置は、可用性・レイテンシ・ネットワーク構成に直接影響します。

ACE 的には、

  • HTTP(S) でグローバル公開 → External Application Load Balancer
  • 内部 HTTP(S) → Internal Application Load Balancer
  • その上で、必要に応じて IAP を有効化

という順番で考える癖をつけておくと、構成選択問題に強くなります。

この節では、「非公開 Web サービス」を

  • VPC 内限定
  • ゼロトラスト（IAP）
  • PSC によるプライベート公開

という 3 つの典型構成に分けて整理しました。
ACE 試験では、問題文の要件を 「クライアントの場所」「制御単位（ネットワーク / ID）」「マルチテナント性」 に分解してから、どのパターンがハマるかを選べるかどうかがポイントになります。

7.2 VM から安全に Cloud Storage 書き込み

この節のテーマはシンプルです。

「Compute Engine VM から Cloud Storage バケットに、安全に書き込むにはどう設計するか？」

ここでいう「安全」は、次の 3 点を満たすことを指します。

  1. 認証: サービス アカウント（SA）を正しく使い、長期鍵をばらまかない
  2. 認可: Cloud Storage 側の権限を最小限にする（書き込み専用など）
  3. ネットワーク: できるだけインターネットにさらさず、必要ならデータ流出対策も行う

ACE 試験では、コードではなく「どの機能を組み合わせるか」が問われます。
順番に、判断の軸を整理していきます。

7.2.1 ユースケースと前提

典型的なユースケースは以下のようなものです。

  • VM から Cloud Storage に
    • バックアップファイルをアップロードする
    • アプリケーションログやレポートファイルを書き込む
    • ユーザがアップロードしたファイルを一時保存する

前提としたい基本方針:

  • サービス アカウント キー（JSON）を VM に置かない
  • VM にアタッチしたサービス アカウント + メタデータサーバ で認証
  • Cloud Storage 側は IAM によるバケットレベル権限 を利用

Google は、Compute Engine 上のワークロードに対して
「メタデータサーバからサービス アカウントのトークンを取得して API にアクセスする」方法を、推奨パターンとしてドキュメント化しています。

7.2.2 認証のベストプラクティス: インスタンス SA + メタデータサーバ

インスタンスにサービス アカウントをアタッチ

Compute Engine VM には「インスタンスに紐づくサービス アカウント」を設定できます。

  • VM 起動時に
    • どのサービス アカウントを使うか
    • どの OAuth スコープ（古い UI）を許可するか
      を指定
  • VM 上のアプリは、メタデータサーバ（http://metadata.google.internal）からその SA のアクセストークンを取得し、Cloud Storage API などを呼び出せる

公式ドキュメントでは、メタデータサーバ経由でトークンを取得する手順が示されており、
「この方式はサービス アカウント キーを扱うより安全」とされます。

Google Cloud クライアントライブラリ（Python / Go / Java など）を使う場合、

  • Application Default Credentials (ADC) を利用すれば、
    ライブラリが内部でメタデータサーバからトークンを自動取得します。

サービス アカウント キーを避けるべき理由

サービス アカウント キー（JSON）を VM に配置すると:

  • VM が侵害されたときに 長期有効な鍵が漏れる
  • キーローテーションや失効の運用が必要になる

公式ガイドでも、クラウド上のワークロードに対しては メタデータサーバ経由のトークン取得 が推奨されています。

ACE 試験の観点でも、

  • 「VM から安全に Cloud Storage にアクセスしたい。どう認証するか？」 →
    インスタンスにサービス アカウントをアタッチし、メタデータサーバ経由でトークン取得
  • 「サービス アカウント キーを VM に置く」選択肢は、基本的に誤り扱い

と考えて問題ありません。

7.2.3 Cloud Storage 側の権限設計（IAM）

事前定義ロールの整理

Cloud Storage には IAM の事前定義ロールが用意されています。

特に VM からの「書き込み」で使うのは以下です。

  • Storage Object Viewer（roles/storage.objectViewer）
    • オブジェクトの閲覧・一覧のみ
    • 書き込み不可
  • Storage Object Creator（roles/storage.objectCreator）
    • 新規オブジェクトの作成 / 書き込みは可能
    • 既存オブジェクトの削除や上書きはできない
    • 「追記専用」的なロールとして使える
  • Storage Object Admin（roles/storage.objectAdmin）
    • オブジェクトの作成 / 読み取り / 削除 / リストなど、オブジェクトに対するフルコントロール
  • Storage Admin（roles/storage.admin）
    • バケット含めほぼすべてを管理できる、強いロール
    • バケット作成 / 削除・バケット設定変更なども可能

また、個々の権限としては

  • storage.objects.create（オブジェクト作成）
  • storage.objects.delete（削除）
    などがあり、オブジェクトの上書きには create + delete 両方が必要と明記されています。

「安全に書き込み」の権限パターン

ACE レベルで押さえておきたい基本パターンは 2 つです。

パターン A: 追記専用（ログ・監査・証跡など）

要件:

  • VM からログ / 監査証跡をバケットにアップロード
  • 既存オブジェクトの削除や上書きはさせたくない

推奨構成

  • バケットに対して、インスタンス SA に roles/storage.objectCreator を付与
  • 必要なら読み取り用に別 SA + roles/storage.objectViewer を別途用意

→ VM からは「書くだけ」で、誤って消したり上書きしたりしにくい構成になります。

パターン B: 読み書きフル（アプリのアップロード / 更新など）

要件:

  • ユーザがアップロードしたオブジェクトをアプリ側で更新 / 削除したい
  • バケット単位での運用（オブジェクトごとの細かな ACL は不要）

推奨構成

  • バケットに対して、インスタンス SA に roles/storage.objectAdmin を付与

バケットやプロジェクト全体に roles/storage.admin を付けると権限が強すぎるので、
ACE 的にはまず objectAdmin レベルで足りるかどうか を考える癖をつけると良いです。

Uniform bucket-level access（IAM のみで制御）

Cloud Storage には、ACL と IAM を混在させないための機能として
Uniform bucket-level access（均一なバケットレベル アクセス） が用意されています。

  • 有効化すると:
    • オブジェクト ACL が無効化され、アクセス制御は IAM のみになる
    • バケットレベルの IAM 設定が、そのバケット内の全オブジェクトに適用される
  • セキュリティ上は、「IAM だけで一貫管理」できるので推奨とされることが多い

ACE 試験で「バケットとオブジェクトのアクセス制御を簡略化したい」「ACL と IAM の併用を避けたい」と出たら、
Uniform bucket-level access を有効にして IAM に統一、という方向性が正解です。

7.2.4 ネットワーク設計: 外部 IP なしで Cloud Storage にアクセス

権限だけ安全でも、VM にパブリック IP を付けっぱなしにすると攻撃面が増えます。
Google は、外部 IP を持たない VM から Google APIs（Cloud Storage 等）にアクセスする方法として
Private Google Access を提供しています。

Private Google Access の動作

  • 外部 IP を持たない VM は、本来「VPC 内の内部 IP にしか送信できない」
  • サブネット側で Private Google Access を有効化すると、
    • そのサブネット内の VM が、
      Google APIs & Services（Cloud Storage 含む）の外部 IP に到達できるようになる
  • VM には外部 IP を付けずに済むので、インターネットへの直接公開を避けられる

まとめると:

  • VM: 内部 IP のみ
  • サブネット: Private Google Access 有効
  • → Cloud Storage を含む Google APIs へは、Google のバックボーン経由で到達可能

ACE 試験での典型パターン:

「外部 IP のない VM から Cloud Storage バケットにアクセスしたい。どうすればよいか？」

答え: VM が属するサブネットで Private Google Access を有効化する です。

Cloud NAT との違い

外部 IP を持たない VM からインターネットに出たい場合、Cloud NAT という選択肢もあります。

  • Cloud NAT:
    • VM から一般のインターネット宛てのトラフィックを、NAT Gateway の外部 IP に変換して出してくれる
    • Google APIs 以外（GitHub など）にもアクセスしたい場合に利用

Cloud Storage のみであれば、

  • Google APIs にだけ行ければ十分 → Private Google Access だけでもよい
  • それ以外の外部サイトにも出たい → Cloud NAT（＋必要に応じて Private Google Access）

という整理で十分です。

7.2.5 データ流出対策（VPC Service Controls：上級）

「安全に書き込む」の上級編として、VPC Service Controls（VPC-SC） を挙げておきます。

VPC Service Controls の役割

VPC Service Controls は、Cloud Storage / BigQuery などのマネージドサービスの周りに「セキュリティ境界（perimeter）」を作り、
データの持ち出し（exfiltration）を防ぐための仕組みです。

  • 指定したプロジェクト / サービス（例: Cloud Storage）のリソースを「保護された境界内」に閉じ込める
  • 境界外（別プロジェクト / 別組織 / 匿名ユーザなど）へのデータコピーを制限できる

Cloud Storage バケットを VPC-SC の perimeter 内に置くことで、

  • 誤った設定で「インターネットから誰でも読み取り」になった場合でも
  • 境界外からのアクセスがブロックされる

といった多重防御が可能です。

ACE 試験では、VPC-SC は「名前と目的（データ流出対策）」を知っていれば十分なレベルですが、
選択肢に出てきたときに Network Firewall などと混同しない ように注意してください。

7.2.6 ACE 試験向け：典型シナリオと判断基準

最後に、試験で出やすいパターンを「どう判断すべきか」という形で整理します。

シナリオ 1: ログ専用バケットへの書き込み

要件:

  • VM から Cloud Storage にアプリログをアップロード
  • ログは削除・上書きさせたくない

判断

  • 認証: インスタンスに SA をアタッチし、メタデータサーバからトークン取得（ADC 利用）
  • IAM: バケットに対して SA に roles/storage.objectCreator を付与（追記専用）
  • ネットワーク: 外部 IP 不要なら、サブネットに Private Google Access を有効化

シナリオ 2: バックアップバケットへの読み書き

要件:

  • VM からバックアップファイルを Cloud Storage にアップロード・更新・削除
  • 1 つのバケットにまとめて管理したい

判断

  • 認証: インスタンス SA + メタデータサーバ
  • IAM: バケットに対して SA に roles/storage.objectAdmin（オブジェクトのフル制御）
  • アクセス制御の簡素化: Uniform bucket-level access を有効化し、ACL を使わず IAM に統一

シナリオ 3: 外部 IP を持たない VM から Cloud Storage へ

要件:

  • セキュリティのため VM に外部 IP を付けたくない
  • それでも Cloud Storage バケットへの書き込みが必要

判断

  • サブネットで Private Google Access を有効化
  • 認証・IAM は上記シナリオと同様

問題文で「外部 IP 無しの VM から Cloud Storage へアクセスしたい」に対して
「Cloud NAT だけ」と答えるのは不正解で、
「Private Google Access を有効化」が最低限の条件になります。

シナリオ 4: 高機密データの保管

要件:

  • 機密データを格納するバケットに対し、外部からの持ち出しリスクを最小化したい
  • VM からは引き続き書き込みが必要

判断

  • 認証 / IAM / ネットワークは上記と同様
  • 追加で、組織レベルの対策として VPC Service Controls の perimeter に Cloud Storage プロジェクトを含める

7.2.7 まとめ：判断基準の整理

VM から Cloud Storage へ「安全に書き込む」構成を選ぶときの軸は、次の 4 つです。

  1. 認証
    • SA キーではなく、インスタンス SA + メタデータサーバ を使う
  2. 認可（IAM）
    • 追記だけなら roles/storage.objectCreator
    • 読み書き・削除が必要なら roles/storage.objectAdmin
    • 可能なら Uniform bucket-level access で IAM に統一
  3. ネットワーク
    • 外部 IP を避ける場合は Private Google Access
    • 追加で一般インターネットにも出たい場合は Cloud NAT
  4. データ流出対策（上級）
    • 高機密データには VPC Service Controls で perimeter を構成

ACE 試験では、これらのキーワードと役割が頭に入っていれば、
「どのサービスをどう組み合わせるか」を問う問題に対して、十分に対応できるはずです。

7.3 コスト最適化

この節では、Google Cloud 全体を Compute / Storage / ネットワーク という 3 つの視点から俯瞰し、「どのように設計すれば ACE レベルで“賢く安く”使えるか」を整理します。

試験で問われるのは、細かい単価そのものではなく、

  • どのサービスにどのような料金モデルがあるか
  • どの構成がコスト面で合理的か
  • どのような判断軸で選ぶべきか

といった「設計判断」です。

7.3.1 コスト最適化の考え方

まず、大枠の考え方を押さえておきます。

クラウドのコストは、ざっくり次の式で表せます。

クラウドコスト ＝ 単価 × 利用量

したがって、最適化の方向性は常に以下の 3 つに集約されます。

  1. 単価を下げる
    • 割引（Sustained Use / Committed Use / Spot VMs など）
    • より安価なストレージクラスやリージョンの選択
  2. 利用量を減らす
    • オートスケーリング / シャットダウンで無駄な VM を止める
    • 不要なデータ / 古いスナップショットを削除
    • ネットワーク経路を見直し、不要な egress を減らす
  3. そもそものアーキテクチャを変える
    • 常時起動 VM から、イベント駆動のサーバレスへ
    • マルチリージョン必須でなければ、単一リージョン構成にする
    • バッチ処理を Spot VMs にオフロードする

ACE 試験の問題文では、これらを直接書かずに

  • 「トラフィックは日中だけ急増する」
  • 「データは年に 1 回だけ参照する」
  • 「同じ VM が 1 年以上、常時稼働している」

といったシナリオで出してきます。
ここから「どの料金モデル／どのサービスを選ぶべきか」を逆算できるかどうかがポイントです。

7.3.2 Compute のコスト最適化

インスタンスタイプとサイジング

Compute Engine のコストは主に

  • マシンタイプ（vCPU / メモリ）
  • 追加リソース（GPU / Local SSD）
  • 接続ディスク（Persistent Disk / Hyperdisk）

で決まります。

無駄なコストの典型例は「CPU 使用率 5% なのに N2-highmem で動いている」といったケースです。
Google Cloud には、VM インスタンスの CPU / メモリ利用状況から最適なマシンタイプを提案する Rightsizing Recommender が用意されています。

ACE レベルでは、次のような判断ができれば十分です。

  • 「明らかにオーバースペックな VM → サイジング見直し」
  • 「CPU は足りているがメモリだけ不足 → メモリ最適化マシン or カスタムマシン」
  • 「ピークは短時間だけ → オートスケーリングで台数変動」

割引モデル：SUD / CUD / Spot VMs

Compute のコスト最適化で、試験で特に問われやすいのが 割引モデル の使い分けです。

Sustained Use Discounts（SUD）
  • 対象となる VM を 1 か月のうち 25% を超えて継続利用すると、自動的に割引が適用される仕組みです。
  • 1 か月フル稼働させた場合、リソースコストに対して最大約 30% の割引が得られます。
  • 申請や予約は不要で、「長時間動かしているだけで勝手に安くなる」 のが特徴です。
Committed Use Discounts（CUD）
  • 1 年または 3 年 の利用コミットと引き換えに、Compute Engine リソースの料金を大きく割り引く仕組みです。
  • 「特定のマシンタイプを固定で予約する」方式だけでなく、
    vCPU / メモリ量に基づく リソースベース CUD も提供されています。
  • 長期稼働が確実なワークロード（DB 用 VM 等）には CUD が有効、というのが基本的な考え方です。
Spot VMs（旧 preemptible VMs）
  • Compute Engine の余剰キャパシティを利用することで、大幅な割引を受けられる VM です。
  • Spot VMs は、標準 VM と比べて 最大 91% の割引 が提供されます（マシンタイプ等による）。
  • その代わり、Google Cloud がリソースを必要とした場合、いつでも事前通知付きで停止（preempt）される可能性がある ため、
    • バッチ処理
    • 分散バッチ / ETL
    • 再実行可能な ML トレーニング
      などの「中断に耐えられる」ワークロード向けです。

ACE 的には、問題文に

  • 「バッチ処理」「中断されても再実行できる」「コストを最小化したい」 → Spot VMs
  • 「 1 年以上にわたり 24 時間稼働」「安定した負荷」 → Committed Use Discounts
  • 「常時稼働だが、コミットはまだ難しい」 → SUD の自動適用を前提に設計

という読み替えができれば OK です。

サーバレスの活用

「常時 VM を立てる必要がない」ワークロードは、サーバレスに寄せることでコストを下げられます。

  • Cloud Run / Cloud Functions
    • 実行時間・リクエスト数・メモリ使用量に応じた課金
    • アイドル時コストをゼロにできる
  • App Engine（Standard）
    • トラフィックに応じて自動スケール
    • 軽負荷サービスや管理系 API に向く

ACE 試験では、「利用時間が短い」「リクエストが断続的」「ピークが読みにくい」ような要件が出てきたときに、
常時起動 VM ではなくサーバレスを選べるかどうか が問われます。

7.3.3 Storage のコスト最適化

Storage のコストは主に

  • ストレージクラス
  • ロケーション（リージョン / デュアルリージョン / マルチリージョン）
  • データ量 / 操作回数 / ネットワーク egress

で決まります。

ストレージクラスと最低保存期間

Cloud Storage の代表的なストレージクラスと最低保存期間は、公式ドキュメントで以下のように定義されています。

クラス最低保存期間用途の目安
Standardなし頻繁にアクセスされるデータ（API、Web コンテンツなど）
Nearline30 日月 1 回程度アクセスされるバックアップなど
Coldline90 日四半期に 1 回以下のアクセスを想定したデータ
Archive365 日ほとんどアクセスしないアーカイブ・コンプライアンス用途

Nearline / Coldline / Archive では、

  • 最低保存期間内に削除した場合も、その期間分の料金が課金される点に注意が必要です。

ACE では、次のような読み替え問題がよく出ます。

  • 「月次バックアップだが、基本的に復元はしない」 → Nearline
  • 「年に 1 回程度の監査時だけ参照。10 年以上保管」 → Archive
  • 「ユーザが頻繁にダウンロードする静的コンテンツ」 → Standard

ロケーションタイプの選択

同じストレージクラスでも、ロケーションタイプによって料金が変わります。

  • 単一リージョン: 最も安価。レイテンシもそのリージョン内の Compute からは低い
  • デュアルリージョン: 2 リージョンにレプリカを持つ高可用構成。単一リージョンより高価
  • マルチリージョン: 広域に複数レプリカを持つ。さらに高価

公式の料金表でも、Standard クラスは 単一リージョン < デュアルリージョン < マルチリージョン の順に高くなることが示されています。

ACE では、次のような観点で判断します。

  • 「利用者は特定の地域からのみ」 → 単一リージョン
  • 「RPO/RTO から、地理的冗長が必須」 → デュアルリージョンやマルチリージョン

災害対策の要件が明確にないのに、なんとなくマルチリージョンを選ぶのはコスト面で不利です。

ライフサイクル管理と削除

長期運用では、「作ったまま放置されるデータ」がコストを圧迫します。
Cloud Storage の オブジェクト ライフサイクル管理 を使うと、

  • 一定期間後により安価なストレージクラスへ自動移行
  • 期限切れデータ・古いバックアップを自動削除

といったルールを設定できます。

ACE のシナリオ問題で

「 3 年以上経過したログは、自動的に削除してよい」

とあれば、「手動削除」よりも ライフサイクル管理のルールを設定 できるかどうかが問われていると考えてください。

7.3.4 ネットワークのコスト最適化

ネットワークコストで最も重要なのは egress（送信） です。

公式ドキュメントでも、VPC の料金ページで

  • プロジェクトをまたぐ VM 間
  • リージョンをまたぐトラフィック
  • インターネット向け egress

など、さまざまなパターンごとに GiB 単価が定義されています。

一般的なポイントは次の通りです。

  • Ingress（受信）は基本無料
  • 同一リージョン内のサービス間通信は安価か無料（例: 同一リージョンの VM と Cloud Storage 間など）
  • リージョン間・大陸間の egress は高価
  • インターネットへの egress は、宛先・リージョンで単価が変わる

リージョン設計で egress を減らす

ACE の典型パターンは、

  • Compute Engine / GKE と Cloud Storage / Cloud SQL のリージョンをきちんと合わせるか
  • 別リージョンや別大陸に置いてしまっていないか

という設計判断です。

原則として、

  • Compute と Storage を同じリージョンに置く
  • マルチリージョンバケットから別リージョンの VM へ大量配信、のような構成は避ける

ことで、リージョン間 egress を抑えられます。

Cloud Interconnect / Cloud VPN

オンプレミスと Google Cloud を接続する場合も、トラフィック量が多いと egress コストが問題になります。

  • Cloud VPN
    • 手軽だが、トラフィックが増えると egress コスト + VPN 自体のコストが効いてくる
  • Cloud Interconnect
    • 専用線 / パートナー経由で接続
    • egress 単価が Internet egress より低く設定されており、大量トラフィックには有利

ACE 観点では、「オンプレから大量データを継続レプリケーションする」といった文脈があれば、
単純なインターネット経由より Cloud Interconnect を検討する方がコスト効率が良い、と判断できるかがポイントです。

Cloud CDN による egress 削減

静的コンテンツを世界中に配信する場合、Cloud Storage やバックエンド VM から直接配信すると egress が増大します。

  • Cloud CDN を HTTPS ロードバランサと組み合わせることで、
    • 「キャッシュヒット分」はエッジロケーションから配信
    • オリジンへのトラフィック（＝ egress）はキャッシュミス分だけに抑えられる

Cloud CDN では、キャッシュからクライアントへの配信（cache egress）と、オリジンからキャッシュへの転送（cache fill）に対して料金が設定されています。

ACE レベルでは、

  • 「世界中のユーザに静的コンテンツを配信」「レイテンシと egress コストを下げたい」
    → Cloud CDN + External Application Load Balancer

という構成を選べるかどうかが問われます。

7.3.5 コスト管理ツールと運用

構成を工夫するだけでなく、「継続的にモニタする仕組み」も重要です。
Google Cloud には、コスト管理をサポートするいくつかの公式ツールがあります。

Pricing Calculator による事前見積もり

新しいシステムを設計する際は、Google Cloud Pricing Calculator で概算コストを試算しておくのが基本です。

  • 利用予定のサービス（Compute Engine / Cloud Storage / Cloud SQL など）を追加
  • リージョン・インスタンス数・ストレージ容量・トラフィック量などを入力
  • 月額の見込みコストを算出し、プロジェクトの予算設計に活用

ACE 試験では、ツール名そのものが問われることは少ないものの、
「設計段階で料金シミュレーションを行う」 というスタンスは正しい選択肢として出てきます。

Budgets & Alerts による予算管理

Cloud Billing の Budgets & alerts 機能を使うと、

  • プロジェクト / 請求先アカウントに対して予算額を設定し
  • 実際の利用額がしきい値（50%、90% など）を超えたときにメール等で通知

させることができます。

重要なのは、

  • 予算アラートは利用や請求を自動停止しない（あくまで通知）
  • 必要であれば、Pub/Sub 連携などを使ってプログラム的に制御（自動停止など）を組み合わせる

といった挙動を理解しておくことです。

Recommender による最適化提案

Recommender は、Google Cloud の利用状況を分析し、

  • Compute Engine のマシンタイプの rightsizing
  • 未使用 / 低利用リソースの削除提案
  • ストレージ最適化 など

の推奨事項を提示するサービスです。

ACE では、シナリオとして

「運用開始後にコストが増え続けている。コスト削減のためにどの機能を利用すべきか？」

といった問いに対し、

  • 「Recommender を有効化して rightsizing や削除候補を確認する」
  • 「Billing レポートや Budgets & alerts と組み合わせて継続的にモニタする」

という回答が選べるかどうかがチェックされます。

7.3.6 試験での押さえどころまとめ

この節の内容を、ACE 試験のために圧縮すると次のようになります。

  • Compute
    • 長時間稼働 → SUD 自動適用
    • 1〜3 年の長期・安定負荷 → CUD を検討
    • 中断許容バッチ → Spot VMs
    • オーバースペック VM → Rightsizing Recommender で見直し
  • Storage
    • アクセス頻度と保管期間に応じて Standard / Nearline / Coldline / Archive を選択（最低保存期間に注意）
    • 不要データはライフサイクルルールで自動削除・クラス変更
    • 単一リージョン / デュアルリージョン / マルチリージョンのどれが本当に必要かを吟味
  • ネットワーク
    • egress が課金の中心になる
    • Compute と Storage を同一リージョンに配置し、リージョン間 egress を抑える
    • オンプレとの大容量接続には Cloud Interconnect を検討
    • 静的コンテンツの世界配信には Cloud CDN
  • 運用ツール
    • 設計段階で Pricing Calculator で見積もり
    • Budgets & alerts で予算超過を検知
    • Recommender で rightsizing や未使用リソースを継続的に洗い出し

問題文に出てくる要件を、「Compute / Storage / ネットワーク / 運用」のどこに効いてくる話かに分解し、それぞれのカテゴリで最もコスト効率の良い選択肢を選び出せれば、この分野の問題は安定して得点できるようになります。

7.4 耐障害性・スケーラビリティ判断

（Multi-zone / MIG / LB の使い分け）

この節では、Compute Engine ベースの Web / API システムを例に、

  • Multi-zone（マルチゾーン）配置
  • Managed Instance Group（MIG）
  • Cloud Load Balancing（LB）

をどう組み合わせれば、耐障害性とスケーラビリティを両立できるかを整理します。

ACE 試験では、「単一 VM」か「MIG」か、「単一ゾーン」か「マルチゾーン」か、「LB を置くか置かないか」の選択をさせる問題が頻出です。ここで判断軸を固めておくと、多くの問題を機械的に解けるようになります。

7.4.1 耐障害性とスケーラビリティの前提

ゾーン / リージョンと障害

Google Cloud のリージョンは複数のゾーンで構成され、ゾーンごとに電源・ネットワーク・冷却などのインフラが分離されています。1 つのゾーンに障害が起きても、同じリージョン内の他ゾーンには影響しない設計です。

そのため、

  • 単一ゾーンにしかリソースがない構成
    → 「ゾーン障害」がそのままサービス停止につながる
  • 複数ゾーンに分散した構成
    → あるゾーンが落ちても、他ゾーンでサービス継続できる

という違いが生まれます。

可用性とスケーラビリティを支える 3 つの要素

Compute Engine 中心の構成では、以下 3 つをセットで考えます。

  1. Multi-zone（ゾーン分散）
    • 同一リージョン内で、複数ゾーンにインスタンスを配置しておくこと
  2. Managed Instance Group（MIG）
    • 同一構成の VM をまとめて管理し、オートスケール と オートヒーリング を行う仕組み
  3. Cloud Load Balancing
    • 複数インスタンスへのトラフィック分散
    • ヘルスチェックにより「死んでいる VM に流さない」

この 3 つを組み合わせることで、

  • トラフィック増減に応じて自動スケール
  • VM 障害やゾーン障害が起きてもサービス継続
  • 単一 IP / ドメインでの公開

が実現できます。

7.4.2 Multi-zone（ゾーン分散）の判断軸

Zonal MIG と Regional MIG

Compute Engine の Managed Instance Group には、次の 2 種類があります。

  • Zonal MIG
    • 1 つのゾーン内だけに VM を持つ
  • Regional MIG
    • 同一リージョン内の複数ゾーンに VM を分散して持つ

公式ドキュメントでは、Regional MIG について、

「MIG の VM をリージョン内の複数ゾーンに分散させることで、ゾーン障害に対して耐性を持つ」

と明記されています。

いつ Multi-zone にすべきか

Regional MIG（Multi-zone）を選ぶべきケース：

  • サービス停止許容時間を極力短くしたい Web / API
  • 1 ゾーン障害程度ではサービスを止めたくない
  • バックエンドがステートレスで、複数ゾーンへ簡単に複製できる

Zonal MIG のままでもよいケース：

  • 開発 / テスト環境
  • 短時間の停止が許容されるバッチ専用クラスタ
  • コスト最優先で、HA 要件が低いシステム

ACE の問題では、「ゾーン障害でもサービスを継続したい」という一文が出た時点で、Regional MIG（Multi-zone 配置） にするのがセオリーです。

7.4.3 MIG の役割：オートスケール & オートヒール

Managed Instance Group の機能

MIG は、同一テンプレートから作成された VM 群を「1 つのサービス」としてまとめて扱う仕組みです。公式には次の機能が挙げられています。

  • オートスケーリング（autoscaling）
    • CPU 利用率や Cloud Monitoring メトリクス、LB の負荷などに応じて VM 台数を自動増減する
  • オートヒーリング（autohealing）
    • ヘルスチェックで不健康と判定された VM を自動再作成
  • ローリング更新 / マルチバージョン展開
    • インスタンステンプレート更新時に、一度に全台を落とさず段階的に切り替え

ACE では、単一 VM ではなく MIG を選ぶべきかどうかを問う問題がよく出ます。

典型的な判断：

  • 「トラフィック増減に応じて台数を自動調整したい」 → MIG + autoscaling
  • 「障害 VM を自動で入れ替えたい」 → MIG + autohealing（ヘルスチェック）」
  • 「ゾーン障害にも耐えたい」 → Regional MIG

オートスケーリングの指標

Autoscaler は、以下のような指標に基づいてスケールを行えます。

  • CPU 利用率（最も基本的）
  • Cloud Monitoring のカスタムメトリクス
    • QPS、遅延、キュー長など
  • LB の serving capacity
    • Application Load Balancer のバックエンドとしての「満杯度合い」でスケール

ACE では、

「平均 CPU 利用率 60% を維持するようにインスタンス数を自動調整したい」

といった問題が典型的で、その場合は MIG の autoscaler に CPU ベースのポリシーを設定する選択になります。

7.4.4 ロードバランサの役割：入口と障害切り離し

Cloud Load Balancing の基本

Cloud Load Balancing は、トラフィックを複数のバックエンド（MIG / NEG / Cloud Run など）に分散し、高いスケーラビリティと可用性を提供するマネージドサービスです。

特徴（ACE で必要な範囲）：

  • HTTP(S) / TCP / UDP 用の LB 種類（L7 / L4）
  • グローバル / リージョナル LB（Application / Network Load Balancer 等）
  • ヘルスチェックにより、不健康なバックエンドにはトラフィックを送らない
  • Regional / Global LB + Regional MIG により、「ゾーン障害時に生きているゾーンへルーティング」

MIG + LB での HA パターン

公式チュートリアルでは、Regional MIG と LB を組み合わせて以下を実現する例が紹介されています。

  • Regional MIG により、VM をリージョン内の複数ゾーンに分散
  • HTTP(S) Load Balancer を front に設置
  • ゾーン障害などで一部の VM が利用不可になっても、LB のヘルスチェックにより残りのゾーンの VM へトラフィックを継続的に分散

ACE 的な読み替えは次の通りです。

  • 「ゾーン障害時にもサービスを継続したい」
    → Regional MIG + LB（+ ヘルスチェック）
  • 「特定の VM だけ高負荷にならないようにしたい」
    → LB で均等分散 & MIG の autoscaling

7.4.5 パターン別：耐障害性・スケーラビリティ設計

ここからは、試験に出やすいパターンを「どこまでやるか」の観点で整理します。

パターン 1：最小構成（単一 VM）

  • 構成
    • 単一 Compute Engine VM
    • パブリック IP + ファイアウォールルールで公開
  • 特徴
    • 安いが、インスタンス障害・ゾーン障害で即アウト
    • スケールアウトできない
  • 使いどころ
    • 学習 / 検証環境
    • 個人利用レベル

ACE 試験では、本番システムにこの構成を選ばせる設問は「罠」です。

パターン 2：Zonal MIG + LB

  • 構成
    • 1 つのゾーン内で Zonal MIG に複数インスタンス
    • HTTP(S) Load Balancer のバックエンドに MIG
  • 特徴
    • インスタンス障害には耐えられる（別インスタンスが応答）
    • トラフィック増減に応じてスケールアウト / スケールイン
    • ゾーン障害には弱い
  • 使いどころ
    • 開発 / ステージング環境
    • ゾーン障害が許容できる商用システム

ACE 的には、

  • 「インスタンス障害には耐えたいが、ゾーン障害への言及がない」
    → まず Zonal MIG + LB でも一定の妥当性あり

パターン 3：Regional MIG + LB（単一リージョン HA）

  • 構成
    • Regional MIG で複数ゾーンにインスタンスを分散
    • Regional（または Global）Application Load Balancer のバックエンドに Regional MIG
  • 特徴
    • インスタンス障害 + ゾーン障害に対する耐性
    • トラフィック増減に応じた autoscaling
    • コストは Zonal 構成より高いが、その分可用性も高い
  • 使いどころ
    • 通常の商用 Web / API システム
    • 「リージョン障害までは想定しないが、ゾーン障害には耐えたい」システム

ACE 試験では、「Multi-zone / Regional MIG」「ゾーン障害」といったキーワードが出たら、この構成を選ぶ問題が多いです。

パターン 4：マルチリージョン + Global LB（上級）

ACE レベルでは詳細まで要求されませんが、方向性として知っておくとよい構成です。

  • 複数リージョン（例: asia-northeast1 / us-central1）にそれぞれ Regional MIG
  • Global External Application Load Balancer で各リージョンをバックエンドとして束ねる

特徴：

  • リージョン障害に対する耐性
  • ユーザを最寄りリージョンへ自動ルーティング
  • 復旧やデータレプリケーションは別途設計が必要

ACE 試験では、「単一グローバル IP」「複数リージョン」「最寄りリージョンへルーティング」などが出てきたら、
Global Application Load Balancer + 複数リージョンのバックエンド という構成が正解方向になります。

7.4.6 ACE 試験での典型パターンと誤り方

最後に、ACE の問題でよく問われる「判断ミス」を整理します。

ミス 1：高可用要件なのに単一インスタンス / 単一ゾーン

問題文：

Web アプリケーションは、ゾーン障害が発生しても利用可能である必要がある。
どの構成を選ぶべきか？

誤った選択肢の典型：

  • 「単一ゾーンの Zonal MIG + LB」
  • 「マネージドインスタンスを持たない単一 VM」

正しい方向性：

  • Regional MIG（Multi-zone） + Application Load Balancer

ミス 2：スケーラビリティ要件を満たしていない

問題文：

トラフィックは日中に急増し、夜間はほとんどアクセスされない。
コストを最適化しつつ、ピークトラフィックにも対応したい。

誤答例：

  • 単一 VM を高スペックにして常時稼働
  • 手動でインスタンス数を増減

正解方向：

  • MIG の autoscaling を利用して、CPU 利用率や LB の負荷に応じてインスタンス数を自動調整

ミス 3：LB を置かずにインスタンス個別公開

複数インスタンスにスケールアウトしたのに、各インスタンスに個別の外部 IP を振ってクライアント側でラウンドロビンする、といった構成は、

  • 可用性
  • スケーラビリティ
  • 運用性

のいずれも悪く、ACE の観点では不正解です。

適切な構成は、

  • MIG の前に Cloud Load Balancing を置き、
  • 単一 IP / ドメインで公開
  • ヘルスチェックで不健康なインスタンスを自動的に除外

という形になります。

7.4.7 まとめ：判断のためのチェックリスト

MIG / Multi-zone / LB をどう組み合わせるか迷ったときは、次のチェックリストに沿って考えます。

  1. ゾーン障害に耐える必要があるか？
    • YES → Regional MIG（Multi-zone）
    • NO → Zonal MIG でもよい（ただし本番なら Regional 推奨が多い）
  2. トラフィック変動に自動追従したいか？
    • YES → MIG + autoscaler（CPU / LB / メトリクス）
    • NO → 固定サイズ MIG でもよいが、将来的には autoscaling を前提に設計
  3. インスタンス障害時に自動復旧が必要か？
    • YES → MIG の autohealing + LB のヘルスチェック
  4. 利用者に見えるエンドポイントは単一 IP / ドメインにしたいか？
    • ほぼ常に YES → Cloud Load Balancing を front に配置
  5. リージョン障害まで考慮するか？
    • YES → 複数リージョンに同等構成を作成し、Global HTTP(S) LB で束ねる

これらを一つずつ潰していけば、ACE 試験で問われる「耐障害性・スケーラビリティの構成判断」は、落ち着いて選択肢を消していくだけの作業になります。

7.5 サーバーレス選択

（Cloud Run / Cloud Functions / App Engine）

この節では、ACE 試験で頻出のサーバーレス 3 兄弟

  • Cloud Run
  • Cloud Functions（Cloud Run functions / 第 2 世代）
  • App Engine（Standard / Flexible）

を、「どれを選ぶべきか」という判断基準にフォーカスして整理します。

細かい課金単価や全オプションを暗記する必要はありません。
試験で問われるのは、問題文に書かれた要件から

  • どのサービスが一番自然か
  • どの選択肢は不適切か

を切り分ける力です。

7.5.1 3 つのサーバーレスに共通すること

まず共通点から押さえます。Cloud Run / Cloud Functions / App Engine は、いずれも Google Cloud の「サーバーレス コンピュート」として扱われ、次のような特徴を共有します。

  • インフラ（VM / OS）のプロビジョニング・パッチ適用は不要
  • トラフィックに応じて自動スケール（多くの場合、スケールアウトもスケールインも自動）
  • 利用量ベースの課金（リクエスト数、CPU 時間、メモリ時間など）
  • Google Cloud の Operations（Monitoring / Logging）と統合されている

そのうえで、それぞれの性格はかなり違います。

  • Cloud Run: 「コンテナをそのままサーバレス実行」
  • Cloud Functions: 「イベントドリブンな関数単位の実行」
  • App Engine: 「アプリケーション プラットフォーム（PaaS）」

この違いを踏まえたうえで、選択基準を整理していきます。

7.5.2 Cloud Run の特徴と向いているワークロード

Cloud Run の位置づけ

公式ドキュメントでは、Cloud Run は

「コンテナ化したアプリケーションやコードを、Google のスケーラブルなインフラ上でフルマネージドに実行するプラットフォーム」

と説明されています。

主な特徴：

  • コンテナベース
    • 任意の言語・フレームワークを利用可能（コンテナにパッケージできればよい）
  • HTTP ベースのリクエスト処理
    • HTTP(S) リクエストを受け取ってレスポンスを返すアプリに最適
  • イベント駆動も可
    • Pub/Sub / Cloud Storage / Cloud Audit Logs などから Eventarc 経由でイベントを受け取り実行可能
  • 自動スケール & スケール・トゥ・ゼロ
    • リクエスト数に応じてインスタンス数を自動で増減
    • トラフィックゼロ時はインスタンス数 0、課金もほぼゼロ（常駐オーバーヘッドなし）
  • コンカレンシー
    • 1 インスタンスが複数リクエストを同時処理可能（デフォルト 80、上限 1000 程度）

典型ユースケース（ACE 視点）

ACE レベルで「これは Cloud Run」と判断すべきパターン：

  • コンテナ化された HTTP API / Web アプリ
  • 言語やランタイムを柔軟に選びたい（カスタムランタイム、ミドルウェア利用など）
  • バッチ的な HTTP エンドポイント（キックされたら数秒〜数分動く）
  • イベントを受けるエンドポイントを自前で持ちつつ、コンテナで制御したい

逆に、Cloud Run を選ぶべきではないパターン：

  • 単純なイベント処理だけで足りるのに、わざわざコンテナ化する必要がない → Cloud Functions で十分
  • App Engine に強く依存したレガシーアプリの拡張 → 現行 App Engine 上で動かした方が移行コストが小さい場合もある

7.5.3 Cloud Functions（Cloud Run functions）の特徴

Cloud Functions 第 2 世代（Cloud Run functions）

ここ数年で、Cloud Functions（第 2 世代）は Cloud Run + Eventarc 上に実装された「Functions as a Service」 として整理されています。

特徴をまとめると：

  • 関数単位のデプロイ
    • アプリケーション全体ではなく「1 関数」を単位としてデプロイ
  • イベントドリブン
    • Pub/Sub メッセージ
    • Cloud Storage のオブジェクト変更
    • Cloud Audit Logs / Cloud Scheduler 等のイベント
      でトリガー可能（Eventarc 経由）
  • HTTP トリガーもサポート
    • HTTP(S) エンドポイントとして公開し、REST API 的に扱うことも可能
  • スケール・トゥ・ゼロ / 自動スケール
    • リクエストやイベントに応じて自動的に関数インスタンスを増減
  • 管理の粒度が細かい
    • 1 つの機能ごとにデプロイ・ロールバック・権限制御が可能

ACE 試験ガイドでも、「イベントドリブンなサーバレス コンピュートとして Cloud Functions を利用してアプリをデプロイ・保守する」ことが、アプリケーション デプロイのオプションの一つとして想定されています。

典型ユースケース（ACE 視点）

  • Cloud Storage バケットへのオブジェクトアップロードをトリガーに、画像変換やメタデータ処理を行う
  • Pub/Sub メッセージを契機に、小さな業務ロジックを実行する
  • Cloud Scheduler で定期的に HTTP トリガーを叩き、簡易バッチを起動する

「トリガーで少量の処理を走らせる」「1 回の処理が短時間」「ステートレス」
この条件に当てはまるものは、ほぼ Cloud Functions を選んで問題ありません。

逆に、Cloud Functions が向かないケース：

  • ランタイムや依存ミドルウェアを細かく制御したい → コンテナ前提の Cloud Run 向き
  • 常時起動が前提のアプリケーション（長時間接続、重いバックグラウンド処理など）
  • 大規模な Web アプリ全体を 1 つのモノリスとして動かしたい → App Engine / Cloud Run などで検討

7.5.4 App Engine の特徴（Standard / Flexible）

App Engine 概要

App Engine は、Google Cloud の 「フルマネージドなアプリケーション プラットフォーム（PaaS）」 です。

  • アプリケーションを サービス / バージョン 単位でデプロイ
  • トラフィックに応じて自動スケール
  • インスタンスの管理や OS パッチ当てなどは Google が実施

App Engine には 2 つの環境があります。

  1. Standard environment
    • 対応ランタイムが決まっている（Java / Python / Go / Node.js など）
    • クイックなスケールアウト / スケールダウン
    • スケール・トゥ・ゼロも可能（トラフィックがなければインスタンス 0）
  2. Flexible environment
    • コンテナベース（Docker）で、より自由度の高いランタイム
    • 常に最低 1 インスタンス以上は稼働
    • スケールはするが、起動時間などは Standard より長い

ACE で押さえるべき Standard / Flexible の違い

ACE レベルでは、次の程度を押さえておけば十分です。

  • Standard
    • 対応言語は限られる
    • 高速にスケールし、トラフィック 0 のときは 0 インスタンスまで縮小可能
    • ローカルファイルシステムや任意ポートなど、環境制約がある
  • Flexible
    • コンテナベースで柔軟なランタイム
    • 最低 1 インスタンスが常時動く
    • 起動に時間がかかる分、より「長時間動くアプリ」向き

一般的な「Web アプリ / API」を実行するフルマネージド環境として、
App Engine Standard は今も公式にサポートされており、ACE 試験の範囲にも含まれています。

7.5.5 サーバーレス選択の判断軸

ここからが本題です。Cloud Run / Cloud Functions / App Engine のどれを選ぶか迷ったら、次の 4 軸で考えます。

軸 1：トリガーの種類（HTTP か、イベントか）

  • HTTP リクエスト中心
    • Web サイト / API / Webhook など
    • → 第一候補: Cloud Run または App Engine
    • シンプルな HTTP 関数だけなら Cloud Functions も可
  • イベント駆動（Pub/Sub / Storage / Audit Logs 等）
    • 「何かが起きた時だけ実行したい」処理
    • → 第一候補: Cloud Functions（Cloud Run functions）

軸 2：ランタイムの自由度

  • 任意言語 / 任意ミドルウェア / OS レベルの制御が必要
    • 独自ライブラリ / ネイティブ依存など
    • → Cloud Run（コンテナ） or App Engine Flexible（コンテナ）
  • サポートされたランタイムだけで足りる
    • 代表的な Web フレームワーク程度
    • → App Engine Standard / Cloud Functions / Cloud Run いずれも候補

ACE 的には、「コンテナをデプロイできるかどうか」が選択の大きな分かれ目です。

軸 3：アプリケーションの粒度

  • アプリケーション全体として管理したい
    • バージョン切り替え、トラフィック分割などをアプリ単位で制御したい
    • → App Engine（サービス / バージョン） or Cloud Run（複数サービスで構成）
  • 小さな機能単位で分割したい
    • 1 関数ごとに権限・デプロイを分ける
    • → Cloud Functions

軸 4：スケーリング特性と常時稼働

3 つとも自動スケールですが、挙動には違いがあります。

  • Cloud Run
    • リクエスト量に応じてインスタンス数を増減
    • アイドル時はスケール・トゥ・ゼロ
    • コンカレンシー設定で 1 インスタンスが捌くリクエスト数を制御
  • Cloud Functions
    • イベントや HTTP リクエスト数に応じて関数インスタンス数を自動増減
    • スケール・トゥ・ゼロ前提
  • App Engine Standard
    • 自動スケーリングでインスタンス数をダイナミックに変化
    • トラフィックに応じて 0 まで減ることも可能
  • App Engine Flexible
    • 最低 1 インスタンスは常時稼働
    • スケールアウトはできるが、起動に時間がかかる

「ほぼ常にだれかが使っている大規模 Web サイト」なら App Engine Standard / Cloud Run でもよく、
「突発的なイベントでたまに動くだけ」なら Cloud Functions / Cloud Run が自然です。

7.5.6 ACE 試験パターン：どれを選ぶか

最後に、試験でよく出るシナリオをいくつか挙げます。

パターン 1：Cloud Storage へのアップロード時にサムネイル生成

要件：

  • 画像ファイルが Cloud Storage バケットにアップロードされた際にサムネイルを生成
  • 処理は短時間で完了する
  • インフラ管理はできるだけしたくない

選択

  • Cloud Functions（Cloud Run functions）
    • Storage トリガーで関数を起動
    • イベントドリブン / 短時間処理 / サーバレスという要件に合致

Cloud Run でも Eventarc 経由で似たことはできますが、ACE レベルでは「単純なイベント処理 → Cloud Functions」を選ぶのが素直です。

パターン 2：任意の言語で書かれた REST API をサーバレスで提供

要件：

  • 既存のコンテナ化された REST API（任意言語）をサーバレスで公開したい
  • トラフィックに応じて自動スケール
  • インフラ管理を最小限に

選択

  • Cloud Run
    • コンテナをそのままデプロイ
    • HTTP 基盤のスケール / 認証 / ログ連携などをフルマネージドで利用

App Engine Flexible でもコンテナは動きますが、スケール・トゥ・ゼロや高速スケールという観点では Cloud Run の方が自然な選択です。

パターン 3：既存の Web アプリを最小変更でマネージド環境へ

要件：

  • 既存の Web アプリ（サポートされているランタイム）を、ほぼコード変更なしでクラウド化したい
  • ログ / モニタリング / バージョン切り替えなど、PaaS としての機能が一通り欲しい

選択

  • App Engine Standard
    • サポートランタイムに乗っていれば、app.yaml を用意してデプロイ
    • 自動スケーリング / バージョン切り替え / トラフィック分割などを簡単に利用可能

パターン 4：小さな定期バッチをクラウドで動かしたい

要件：

  • 1 日 1 回、数分で終わる処理
  • cron で起動したい
  • インスタンスを立てっぱなしにしたくない

選択

  • Cloud Scheduler → Cloud Functions（HTTP トリガー）
    もしくは
  • Cloud Scheduler → Cloud Run の HTTP エンドポイント

どちらも ACE の範囲ですが、「スクリプト 1 本レベルで済む小さめの処理」なら Cloud Functions の方が書き始めやすい、というイメージです。

7.5.7 まとめ：サーバーレス選択のショートカット

ACE 試験で迷ったときのショートカットを、最後にもう一度整理します。

  • イベントドリブン / 小さな処理単位
    • Pub/Sub / Storage / Audit Logs / Scheduler などがトリガー
      → Cloud Functions（Cloud Run functions）
  • HTTP API / Web アプリをコンテナで動かしたい
    • 任意ランタイム / ミドルウェア使用可
      → Cloud Run
  • 既存の Web アプリを PaaS で動かしたい
    • 対応ランタイム内で収まる
      → App Engine Standard
  • より自由度の高い PaaS が欲しいが、App Engine の機能は使いたい
    → App Engine Flexible

問題文を読んだら、

  1. 「トリガーは何か（HTTP かイベントか）」
  2. 「コンテナが前提か」
  3. 「アプリ全体か、関数単位か」

の 3 つだけを冷静に確認すれば、Cloud Run / Cloud Functions / App Engine のどれを選ぶべきかは、かなり機械的に判断できるようになります。