Cloud Run と AWS Fargate を比較する（コンテナ実行基盤編）
GCP×AWS 比較シリーズ第5弾。今回は コンテナをサーバーレスで動かす基盤 ＝ GCP の Cloud Run と AWS の Fargate を比較する。
どちらも「サーバー（VM）を意識せずコンテナを動かす」点は同じだが、思想とスコープがかなり違う。結論を先に言うと：
Cloud Run = 「コンテナ版の関数」に近い、URLが即生える単体サービス。
Fargate = 「VMを管理しなくていい実行エンジン」。単体では使えず ECS / EKS とセットで使う。
1. まず立ち位置の違い
ここが最大のポイント。**Fargate は単体プロダクトではなく「起動タイプ（実行エンジン）」**である。
| GCP Cloud Run | AWS Fargate | |
|---|---|---|
| 何か | 完結したサーバーレスコンテナサービス | ECS / EKS の実行エンジン（起動タイプ） |
| 単体で使える？ | Yes（これだけでデプロイ完了） | No（ECS か EKS の上で使う） |
| 組み合わせ | 不要 | ECS + Fargate or EKS + Fargate |
| オーケストレーション | Google がフルマネージド（Knativeベース） | ECS / EKS が担当 |
AWS で Cloud Run に一番近い体験は 「ECS + Fargate」。
「EKS + Fargate」は Kubernetes 前提なので、別物（GCPなら GKE Autopilot が近い）。
2. 詳細比較
| 観点 | Cloud Run | ECS + Fargate |
|---|---|---|
| デプロイ単位 | サービス（1コンテナ中心） | タスク定義 + サービス |
| 必要な構成要素 | コンテナimageだけ | クラスタ / タスク定義 / サービス / （ALB等） |
| 公開URL | 自動で HTTPS URL が生える | 自前で ALB/NLB を立てる |
| スケール | 0までスケールイン（ゼロスケール） | 0は不可（最小タスク数≥0設定はあるが常時起動が基本） |
| スケール契機 | リクエスト数 / 同時実行数 で自動 | CPU/メモリ等のメトリクスで Auto Scaling |
| 起動の速さ | 速い（コールドスタートあり） | やや遅め（タスク起動） |
| 課金単位 | リクエスト処理中のms課金（ゼロ時は無料） | タスク起動中ずっと（vCPU/メモリ×時間） |
| 常駐ワークロード | 可（min-instances設定） | 得意 |
| ネットワーク | サーバーレスVPCコネクタ / Direct VPC | VPC ネイティブ（ENI を持つ） |
| ローカル開発 |
docker + gcloud run deploy
|
docker + タスク定義(JSON) |
| 学習コスト | 低（最小） | 中（ECSの概念を覚える） |
課金モデルの違い（重要）
- Cloud Run：リクエストを処理している間だけ課金。アイドル時はゼロ（min-instances=0なら）。スパイク型・たまにしか来ないAPIに圧倒的に有利。
- Fargate：タスクが起動している間は使っていなくても課金。常時稼働・安定負荷に向く。
「アクセスがまばらなAPI / バッチ的な処理」→ Cloud Run、
「常に一定の負荷がかかる常駐サービス」→ Fargate、が大きな目安。
3. アーキテクチャ対応表
| 役割 | GCP | AWS |
|---|---|---|
| コンテナ実行 | Cloud Run | Fargate（ECS/EKS経由） |
| イメージ置き場 | Artifact Registry | ECR |
| ロードバランサ | 不要（標準で付く）/ Cloud Load Balancing | ALB / NLB（自前で用意） |
| 秘密情報 | Secret Manager | Secrets Manager / SSM Parameter Store |
| 自動スケール | 組み込み | Application Auto Scaling |
| ジョブ実行 | Cloud Run Jobs | ECS タスク（単発実行） |
| Kubernetes版 | GKE / GKE Autopilot | EKS（+Fargate） |
4. 基本的な使い方：Cloud Run
Cloud Run の手軽さが一番の特徴。コンテナイメージがあれば1コマンドで公開URLまで行く。
4-1. 事前準備
gcloud config set project MY_PROJECT
gcloud services enable run.googleapis.com artifactregistry.googleapis.com
# Artifact Registry リポジトリを作成（イメージ置き場）
gcloud artifacts repositories create my-repo \
--repository-format=docker \
--location=asia-northeast1
4-2. イメージをビルドして push
# Cloud Build でビルド＆push（ローカルにdocker不要）
gcloud builds submit \
--tag asia-northeast1-docker.pkg.dev/MY_PROJECT/my-repo/my-app:1.0.0
4-3. デプロイ（ここでURLが生える）
gcloud run deploy my-app \
--image=asia-northeast1-docker.pkg.dev/MY_PROJECT/my-repo/my-app:1.0.0 \
--region=asia-northeast1 \
--platform=managed \
--allow-unauthenticated \
--min-instances=0 \
--max-instances=10 \
--memory=512Mi \
--cpu=1
# => Service URL: https://my-app-xxxx-an.a.run.app
curl https://my-app-xxxx-an.a.run.app
たったこれだけ。ロードバランサもTLS証明書も自動。ソースから直接デプロイ（
gcloud run deploy --source .）もでき、その場合は Dockerfile すら無くても Buildpacks で自動ビルドされる。
4-4. よく使う運用コマンド
gcloud run services list # 一覧
gcloud run services describe my-app --region=... # 詳細
gcloud run services update my-app --memory=1Gi --region=... # 設定変更
gcloud run revisions list --service=my-app --region=... # リビジョン履歴
gcloud run services delete my-app --region=... # 削除
Cloud Run は リビジョン単位で履歴が残り、トラフィック分割（カナリア）も
--to-revisions=REV=50のように簡単。
5. 基本的な使い方：ECS + Fargate（対比）
同じことを AWS でやると 構成要素が増える。最小でも「タスク定義」「クラスタ」「サービス」が要る。
5-1. イメージを ECR に push
aws ecr create-repository --repository-name my-app
# docker build → tag → docker push（ECRログイン後）
aws ecr get-login-password | docker login --username AWS --password-stdin <ECR_URI>
docker build -t <ECR_URI>/my-app:1.0.0 .
docker push <ECR_URI>/my-app:1.0.0
5-2. タスク定義（JSON）を登録
{
"family": "my-app",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "256",
"memory": "512",
"containerDefinitions": [
{
"name": "my-app",
"image": "<ECR_URI>/my-app:1.0.0",
"portMappings": [{ "containerPort": 8080 }]
}
]
}
aws ecs register-task-definition --cli-input-json file://task-def.json
5-3. クラスタとサービスを作る
aws ecs create-cluster --cluster-name my-cluster
aws ecs create-service \
--cluster my-cluster \
--service-name my-app \
--task-definition my-app \
--desired-count 2 \
--launch-type FARGATE \
--network-configuration "awsvpcConfiguration={subnets=[subnet-xxx],securityGroups=[sg-xxx],assignPublicIp=ENABLED}"
5-4. 公開するには ALB が必要
Fargate 自体は URL を持たない。外部公開するには ALB を作成 → ターゲットグループ → サービスに紐づけ が必要。
Internet → ALB → Target Group → ECS Service (Fargate Tasks)
Cloud Run が「デプロイ＝公開URL」なのに対し、Fargate は 公開導線を自分で組む ぶん手数が多い。代わりにネットワーク（VPC/SG/サブネット）を細かく制御できる。
6. どっちを選ぶ？
| こういう時 | おすすめ |
|---|---|
| とにかく速くコンテナを公開したい | Cloud Run |
| アクセスがまばら／コスト最適化したい（ゼロスケール） | Cloud Run |
| HTTPリクエスト駆動のAPI・Webアプリ | Cloud Run |
| 常時稼働の安定負荷ワークロード | Fargate（or Cloud Run min-instances） |
| 既存の ECS/EKS 資産・運用に乗せたい | Fargate |
| VPC/SG レベルで細かくネットワーク制御したい | Fargate |
| Kubernetes が前提 | EKS+Fargate ／ GCPなら GKE Autopilot |
7. まとめ
| 観点 | Cloud Run | Fargate (ECS) |
|---|---|---|
| 立ち位置 | 単体で完結するサービス | ECS/EKSの実行エンジン |
| 公開URL | 自動 | ALB自前 |
| ゼロスケール | できる | 基本できない |
| 課金 | リクエスト処理中のms | タスク起動中ずっと |
| 手数 | 1コマンド | クラスタ/タスク定義/サービス/ALB |
| 強み | 手軽・スパイク・コスト | 細かい制御・常駐・既存ECS資産 |
3行まとめ
- Cloud Run ≒ ECS + Fargate。ただし Cloud Run は単体完結＆URL自動、Fargateは実行エンジンで周辺を自分で組む。
- ゼロスケール×ms課金の Cloud Run はスパイク/まばらアクセスに強い。常駐負荷は Fargate。
- Kubernetes前提なら GCP は GKE Autopilot、AWS は EKS + Fargate。
関連記事：
- [GCP のリソース階層を AWS と比較する（Organization / Folder / Project 編）]
- [GCP と AWS で比較する IAM とポリシー継承の仕組み]
- [GCP CLI を AWS CLI と比較する（gcloud / gsutil / bq 編）]
- [GCP の API 管理サービスを AWS API Gateway と比較する]