Contents
スポンサードリンク
サービス概要と主な特徴
| 項目 | GCP Cloud Run | AWS Fargate (ECS/EKS) |
|---|---|---|
| 管理レベル | 完全マネージド（インフラは Google が全て管理） | 完全マネージド（タスク実行基盤だけを抽象化） |
| スケーリング単位 | リクエストごとに 0〜∞ のコンテナ数へ自動スケール | タスク単位で Auto Scaling 可能 |
| デプロイ対象 | コンテナイメージ（任意のランタイム） | コンテナイメージ（ECS または EKS 上の Fargate） |
| 主な利点 | リクエスト単位課金、Cold Start が速い、無料枠が手厚い | ECS/EKS と統合できるため既存のサービスと併用しやすい、タスクレベルで細かく権限付与可能 |
| 主な留意点 | 同時リクエスト数はコンテナごとにデフォルト 1 000 件上限（--max-instances で調整） |
タスクの vCPU・メモリは起動時に固定。過剰割り当てがコスト増につながることがある |
料金体系・無料枠の最新情報
Cloud Run（2026年4月時点）
| 計測項目 | 単価 (USD) | 月間無料枠 |
|---|---|---|
| vCPU‑秒 | $0.000024 | 180,000 vCPU‑秒 (= 2 vCPU × 100 h) |
| メモリ‑秒 | $0.0000035 | 360,000 GiB‑秒 (= 1 GiB × 100 h) |
| リクエスト | $0.40 / 1M | 2 M 件 |
出典: GCP 公式料金ページ https://cloud.google.com/run/pricing（2026年4月閲覧）。無料枠は全リージョン共通で、毎月自動的に適用されます。
AWS Fargate（2026年4月時点）
| 計測項目 | 単価 (USD) |
|---|---|
| vCPU‑秒 | $0.000025 |
| メモリ‑秒 | $0.0000042 |
無料枠（AWS Free Tier）
- 新規 AWS アカウントに対し、最初の 12 ヶ月間 毎月 750 時間 の Fargate 使用が無料。
- 無料枠はすべてのリージョンで合算され、ECS と EKS のどちらでも同じく適用可能です。
出典: AWS 公式料金ページ https://aws.amazon.com/fargate/pricing/（2026年4月閲覧）。無料枠は「新規顧客限定」「12か月間」の条件に注意してください。
Go アプリのデプロイ手順比較
共通 Dockerfile（マルチステージビルド）
|
1 2 3 4 5 6 7 8 9 10 11 |
# ---------- Builder ---------- FROM golang:1.22 AS builder WORKDIR /src COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -o /app/server . # ---------- Runtime ---------- FROM gcr.io/distroless/static-debian12 COPY --from=builder /app/server /server ENTRYPOINT ["/server"] |
- ポート設定
- Cloud Run は環境変数
PORTが必須。 - Fargate（ECS/EKS）はデフォルトで
8080を使用するか、タスク定義のportMappingsに合わせてください。
Cloud Run デプロイ手順（gcloud CLI）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# 1. プロジェクト・リージョン設定 gcloud config set project YOUR_PROJECT_ID gcloud config set run/region asia-northeast1 # 東京リージョン例 # 2. イメージビルド & Container Registry へプッシュ gcloud builds submit --tag gcr.io/$PROJECT_ID/go-sample # 3. デプロイ gcloud run deploy go-sample \ --image gcr.io/$PROJECT_ID/go-sample \ --platform managed \ --allow-unauthenticated \ --cpu 1 --memory 512Mi \ --max-instances 100 # 必要に応じて調整 |
Fargate デプロイ手順（AWS CLI）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
# 1. ECR リポジトリ作成 & イメージプッシュ aws ecr create-repository --repository-name go-sample ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) REGISTRY="${ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com" $(aws ecr get-login-password --region ap-northeast-1 | \ docker login --username AWS --password-stdin $REGISTRY) docker tag go-sample:latest $REGISTRY/go-sample:latest docker push $REGISTRY/go-sample:latest # 2. タスク定義（task-def.json）作成例 cat > task-def.json <<'EOF' { "family": "go-sample", "networkMode": "awsvpc", "requiresCompatibilities": ["FARGATE"], "cpu": "256", "memory": "512", "containerDefinitions": [ { "name": "go-sample", "image": "'$REGISTRY/go-sample:latest'", "portMappings": [{ "containerPort": 8080, "protocol": "tcp" }], "essential": true, "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "/ecs/go-sample", "awslogs-region": "ap-northeast-1", "awslogs-stream-prefix": "ecs" } } } ] } EOF # 3. タスク定義登録 aws ecs register-task-definition --cli-input-json file://task-def.json # 4. サービス作成（Auto Scaling 設定は別途追加） aws ecs create-service \ --cluster default \ --service-name go-sample \ --task-definition go-sample \ --desired-count 1 \ --launch-type FARGATE \ --network-configuration "awsvpcConfiguration={subnets=[subnet-xxxxxx],securityGroups=[sg-xxxxx],assignPublicIp=ENABLED}" |
ポイント
- Dockerfile はどちらのプラットフォームでも同一。CLI とリソース定義（gcloud run deployvsaws ecs create-service）だけが異なるため、CI/CD に組み込む際はビルドステップを共有すれば管理負荷が大幅に削減できます。
パフォーマンス指標とベンチマーク結果
ベンチマーク概要（2024‑2025 年実施）
- 対象：Go 1.22 + 標準
net/httpのシンプル JSON API - テスト環境：東京リージョン (ap-northeast-1 / asia-northeast1)
- ツール：k6（30 分ロードテスト、RPS 10,000）
| 指標 | Cloud Run | Fargate |
|---|---|---|
| Cold Start（0 インスタンス時） | 120 ms ※ minimum‑instances=1 設定で ≈30 ms |
210 ms |
| Warm Start 平均 | 45 ms | 40 ms |
| 同時リクエスト上限（CPU 2 vCPU） | 約 500 RPS | 約 460 RPS |
| 30 分間最大スループット | 1.8 M リクエスト/日 | 1.6 M リクエスト/日 |
出典:
- Google Cloud Blog「Improving Cold Starts on Cloud Run」 (2024年10月)
- AWS Compute Blog「Benchmarking Fargate with Go workloads」 (2025年3月)
考察
- Cold Start：最低インスタンス数を 1 に設定すれば Cloud Run の Cold Start が大幅に短縮され、Fargate よりも有利です。
- スループット差は約10 %程度で、実運用では Auto Scaling 設定やタスク/インスタンス数の調整次第で埋められます。
運用・モニタリング・CI/CD の比較
| 項目 | Cloud Run (GCP) | Fargate (AWS) |
|---|---|---|
| ログ | Cloud Logging に自動ストリーム（標準出力） | CloudWatch Logs に自動転送 |
| メトリクス | Cloud Monitoring（CPU、Memory、Request Latency など） | CloudWatch Metrics（CPUUtilization、MemoryUtilization 等） |
| IAM / ロール | Cloud Run Service Account → 最小権限でリソースへアクセス | Task Execution Role + Task Role → ポリシーで細分化 |
| CI/CD | Cloud Build → gcloud run deploy（YAML でパイプライン定義） |
CodePipeline + CodeBuild → aws ecs update-service または CloudFormation デプロイ |
CI/CD のサンプルフロー
Cloud Run（Cloud Build）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# cloudbuild.yaml steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/$PROJECT_ID/go-sample', '.'] - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk' entrypoint: gcloud args: - run - deploy - go-sample - --image=gcr.io/$PROJECT_ID/go-sample - --platform=managed - --region=asia-northeast1 - --allow-unauthenticated images: - 'gcr.io/$PROJECT_ID/go-sample' |
Fargate（CodePipeline + CodeBuild）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# buildspec.yml version: 0.2 phases: pre_build: commands: - $(aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com) build: commands: - docker build -t go-sample . - docker tag go-sample:latest $ECR_REPO_URI/go-sample:latest post_build: commands: - docker push $ECR_REPO_URI/go-sample:latest artifacts: files: '**/*' |
ポイント
両プラットフォームとも「ビルド → イメージプッシュ → デプロイ」のフローが共通です。CI 設定を分離すれば、同一リポジトリでマルチクラウドデプロイが可能になります。
マルチクラウド対応と移行戦略
1. コードレイヤの抽象化 – Go Cloud ライブラリ
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
import ( "context" "gocloud.dev/blob" _ "gocloud.dev/blob/gcsblob" // GCP _ "gocloud.dev/blob/s3blob" // AWS ) func upload(ctx context.Context, bucketURL, key string, data []byte) error { b, err := blob.OpenBucket(ctx, bucketURL) if err != nil { return err } defer b.Close() w, err := b.NewWriter(ctx, key, nil) if err != nil { return err } if _, err = w.Write(data); err != nil { return err } return w.Close() } |
bucketURLをgs://my-bucketからs3://my-bucketに変えるだけでストレージを切り替えられます。- 同様に Pub/Sub と SNS のインターフェースも
gocloud.dev/pubsubが提供。
2. IaC（Infrastructure as Code）で環境ごとに分離
|
1 2 3 4 5 6 7 |
/infra │─ main.tf # 共通プロバイダー設定 ├─ gcp/ │ └─ cloudrun.tf # Cloud Run リソース定義 └─ aws/ └─ fargate.tf # ECS/Fargate タスク・サービス定義 |
- Terraform workspaces（
gcp-prod,aws-staging等）で環境ごとの変数を切り替えるだけで、同一コードベースから GCP と AWS を管理できます。
3. 段階的なトラフィックシフト手順
| フェーズ | 内容 |
|---|---|
| ① 共通化 | Go Cloud ライブラリと Terraform モジュールで抽象化。CI パイプラインは両方のデプロイを同時に走らせる設定にする。 |
| ② トラフィック分割 | DNS（Route53 / Cloud DNS）や API Gateway のカナリアリリース機能で、全体トラフィックの 10 % を Cloud Run に向ける。 |
| ③ 観測・調整 | Cloud Monitoring と CloudWatch のメトリクスを比較し、レイテンシ・コスト・エラー率を評価。 |
| ④ シフト拡大 | 問題がなければ 30 % → 50 % …と段階的に増やす。最終的にどちらか一方へ完全移行するか、ハイブリッド運用を継続するか決定。 |
| ⑤ 後処理 | 不要になったリソースは Terraform destroy で削除し、コストリークを防止。 |
注意点
- 無料枠の残量管理：Cloud Run と Fargate の無料枠はそれぞれ別管理なので、トラフィックシフト時に「どちらが余っているか」を自動で可視化できるダッシュボードを作成すると便利です。
- ログフォーマット統一：JSON 形式で出力し、Elastic Stack や CloudWatch Logs Insights の共通クエリで分析できるようにする。
- リクエスト ID：
X-Request-IDヘッダーを必ず付与し、分散トレーシング（OpenTelemetry）と連携させれば、プラットフォーム横断のデバッグが容易になります。
まとめと選定ポイント
| 観点 | Cloud Run が向いているケース | Fargate が向いているケース |
|---|---|---|
| スタートアップ・小規模サービス | 無料枠でほぼ無償、Cold Start が速く開発サイクルが短い | 既に ECS/EKS 基盤がある場合は追加コストなし |
| 大規模トラフィック・長時間稼働 | リクエスト単位課金でスパイク時も自動拡張、無料枠の恩恵は限定的 | タスクごとのリソース固定が予測しやすく、既存のオートスケーリングポリシーを再利用できる |
| マルチクラウド戦略 | Cloud Run の API がシンプルで抽象化が容易 | AWS 環境と統合した IAM / VPC 設計がすでに整っている場合は有利 |
| 運用成熟度 | GCP の Cloud Logging/Monitoring が標準装備 | AWS の CloudWatch と CodePipeline が社内標準の場合はシームレス |
結論
- コスト最適化は無料枠と実際のリクエスト量・稼働時間の組み合わせで決まります。両プラットフォームとも 100 USD 前後になるケースが多いため、Free Tier の残量管理が選定の鍵となります。
- パフォーマンス要件（Cold Start 重視か、スループット重視か）に応じて、minimum‑instances設定やタスク数調整を行えばどちらでも要件は満たせます。
- 組織の既存インフラと開発フロー（ECS/EKS か GKE/Cloud Run）に合わせて、マルチクラウド抽象化レイヤー（Go Cloud + Terraform）を導入すれば、将来的なベンダーロックインリスクも低減できます。
参考リンク
| 内容 | URL |
|---|---|
| Cloud Run 料金ページ | https://cloud.google.com/run/pricing |
| AWS Fargate 料金ページ | https://aws.amazon.com/fargate/pricing/ |
| Google Cloud Blog – Cold Start 改善 | https://cloud.google.com/blog/products/serverless/improving-cold-starts-on-cloud-run |
| AWS Compute Blog – Fargate ベンチマーク | https://aws.amazon.com/jp/blogs/compute/benchmark-fargate-go/ |
| Go Cloud ライブラリ（blob） | https://gocloud.dev/howto/blob/ |
| Terraform Provider – Google Cloud | https://registry.terraform.io/providers/hashicorp/google/latest |
| Terraform Provider – AWS | https://registry.terraform.io/providers/hashicorp/aws/latest |
| OpenTelemetry Go SDK | https://opentelemetry.io/docs/instrumentation/go/ |
スポンサードリンク