0. はじめに
8/2に投稿した記事でGoogle Cloud認定資格のCloud Digital Leader(CDL)に合格したことをご紹介しましたが、その中で「AWSとGoogle Cloudのサービスの対比は別記事でまとめる予定です」とお伝えしていました。今回はその記事の整理ができたため、AWSの知識をベースにGoogle Cloudのサービスを整理していこうと思います。
AWSの資格をひとしきり取得してきましたが、Google Cloudについても根本的なベースの考えは同じであり、基本的にはサービス名の読み替えで問題ない印象です。
ただし、細かい差異などがありそこをしっかりと把握することが一番大事かと感じますので、同じようにAWSからGoogle Cloudへ足を踏み入れる方の参考になればと思い、カテゴリごとに対応表と各サービスの特徴をセットでまとめていきます。
ボリュームが大きくなりそうなので、カテゴリ単位でシリーズ記事として分けて投稿する予定です。第1回の今回はコンピューティング系のサービスから始めます。
なお内容は執筆時点の情報をベースにしているため、料金体系やサービス名は変更されることがあります。
公式ドキュメントや本、AIにMCPのナレッジベース経由で正確な情報を問い合わせているものの、特にGoogle CloudはVertex AIがGemini Enterprise Agent Platformに改称されるなど、最近も名称変更が続いているので、実際に利用する際は必ず公式ドキュメントで最新情報を確認してください。
1. コンピューティング
まずはコンピューティング系のサービスからです。仮想マシンからコンテナ、サーバーレスまで一通り対応関係を並べてみます。
| カテゴリ | AWS | Google Cloud |
|---|---|---|
| 仮想マシン (IaaS) | EC2 | Compute Engine |
| PaaS | Elastic Beanstalk | App Engine |
| サーバーレスコンテナ | App Runner / Fargate | Cloud Run |
| コンテナ管理 (CaaS) | EKS | Google Kubernetes Engine (GKE) |
| マルチクラウド/オンプレ統合管理 | - | GKE Enterprise (旧 Anthos、現在は機能の多くが標準GKEに統合) |
| サーバーレス関数 (FaaS) | Lambda | Cloud Run functions (旧 Cloud Functions) |
| IDE拡張 | - | Cloud Code |
| Infrastructure as Code管理 | CloudFormation | Infrastructure Manager |
1-1. Compute Engine
EC2に相当する、Googleのデータセンターで稼働する仮想マシンを提供するIaaSです。
- OSレイヤーに対する完全なアクセス権と制御権を持つため、既存のカスタムイメージを持ち込んでの「リホスト(移行)」に向いています。
- インフラ管理(OSのパッチ適用やスケーリング設定)は利用者側で行う必要があります。
- トラフィックがない時に自動でインスタンスをゼロにする「ゼロスケール」機能は提供されません。
- 中断可能なワークロードには「スポット VM」を使うことで60%〜91%の大幅な割引を受けられます。
- N1・N2/N2D・M1/M2などの特定マシンタイプでは、月の稼働時間が一定割合を超えると自動的に「継続利用割引(Sustained Use Discounts, SUD)」が適用されます。手動設定は不要です(E2やC3などの最新世代マシンタイプは対象外)。
- Windows Serverライセンス: 週末など断続的にしか稼働しないワークロードでは、ライセンス料も稼働時間分のみ課金される従量課金(Pay-As-You-Go)モデルが有利です。一方、既存ライセンスを持ち込むBYOLは多くの場合「単独占有ノード(Sole-tenant nodes)」が必要となり、VMを停止しても物理ホスト全体の費用が発生し続けるため、断続的な稼働には不向きです。
1-2. App Engine
Elastic Beanstalkに相当する、Webアプリケーションやバックエンド向けのサーバーレスPaaSです。
- ハードウェアやOSの管理はGoogleが自動で行うため、開発者はコードに集中できます。
- 「スタンダード環境」はリクエストがない場合にインスタンスをゼロにできますが、「フレキシブル環境」はゼロスケールをサポートしていません。
- 特定の言語・フレームワーク向けに最適化されているため、既存のWindows Serverワークロードをそのまま移行する先には適していません。
1-3. Cloud Run
App Runner/Fargateに相当する、コンテナ化されたアプリケーションを実行するフルマネージドなサーバーレスプラットフォームです。
- 基盤OS自体のカスタムイメージを直接管理したり、OSレイヤーの設定を維持したりすることはできません。
- デプロイにはArtifact Registry等のコンテナレジストリに保管されたイメージが必要です。
gcloud run deploy --sourceでソースコードから直接デプロイした場合も、裏側でCloud Buildがビルドし、Artifact Registryに格納されます。Cloud Storageへの直接配置やVM用ディスクイメージでは代用できません。 - AWS App Runnerは新規顧客の受け付けを終了しており、Amazon ECS Express Modeへの移行が案内されています。
1-4. Google Kubernetes Engine (GKE)
EKSに相当する、Kubernetesベースのコンテナオーケストレーションサービス(CaaS)です。
-
Autopilotモードを選択することで、ノード管理を大きく簡素化できます。
-
クラスターという基盤インフラの概念があるため、標準ではトラフィックがない時にゼロへスケールする機能はありません。
-
ネットワークポリシーやCloud Service Meshを使ってPod間通信を細かく制御でき、水平/垂直ポッドオートスケーラー(HPA/VPA)による詳細なスケーリング設定も可能です。大規模で複雑なマイクロサービス構成では、App EngineやCloud Runより高い柔軟性・制御性を発揮します。
-
「GKE Enterprise」(旧Anthos)を利用することで、オンプレミスや他社クラウド(AWS, Azure)のクラスターを「フリート」単位で一元管理できます。2025年9月2日付で、Fleetダッシュボードやマルチチーム管理、Config Sync、Connect Gatewayなどは無償で標準GKEに統合されました。一方、Managed Cloud Service Mesh、Binary Authorization、Multicluster Gateway、GKE Extended Support(LTS)などは引き続き個別SKUとして提供されています。
1-5. Cloud Run functions (旧 Cloud Functions)
Lambdaに相当する、特定のイベント(ファイルアップロードやメッセージ受信)に応じてコードを実行するFaaSです。
- インフラ管理が不要なサーバーレスで、リクエストがない場合は自動的にインスタンスがゼロになります。
- OSレイヤーの制御は行えないため、カスタムOSイメージは利用できません。
- 2024年8月にCloud FunctionsからCloud Run functionsへ改称されました。
1-6. Cloud Code
AWS側に直接の対応サービスがない、VS CodeやIntelliJなどのIDE向け拡張機能です。
- 開発者がクラウドネイティブなアプリケーションをローカル環境で効率よく記述・デバッグ・デプロイするのを支援するツールです。
- サーバーサイドでのビルド・テスト自動化パイプラインそのものは提供しません(その用途はCloud Build)。
1-7. Infrastructure Manager
CloudFormationに相当する、Terraformを使ってGoogle Cloudのインフラをプロビジョニング・管理するマネージドサービスです。
- アプリケーションコードのビルド・テストを行うCI/CDツールではない点に注意が必要です(その用途はCloud Build)。
- CloudFormationが独自のテンプレート言語(YAML/JSON)を使うのに対し、Infrastructure ManagerはTerraformの実行を代行するサービスという位置づけです。
2. まとめ
今回はコンピューティング系のサービスをAWSと対比しながらまとめました。
次回はストレージ系のサービスをまとめる予定です。
参考