Kubernetes と Cloud Run と ECS｜コンテナ運用の比較（小さめ構成）
目次 クリックで開く
現代のシステム開発において、コンテナ技術は「標準」となりました。しかし、いざコンテナを本番環境で動かそうとした際、多くのエンジニアやプロジェクトマネージャーが直面するのが「どのプラットフォームを選ぶべきか」という問題です。
「将来を考えてKubernetes（K8s）にすべきか？」「AWSを使っているからECS（Fargate）か？」「Google CloudのCloud Runが楽だと聞くが本当か？」
本記事では、特に「小規模〜中規模の構成」において、これら3つの選択肢を実務的な視点で徹底比較します。公式サイトの仕様に基づいた技術的な差異から、運用フェーズで発生する「隠れたコスト」まで、1つずつ解き明かしていきます。
コンテナ運用における3つの選択肢：Kubernetes、Cloud Run、ECSの基本特性
まずは、比較の対象となる3つのサービスの立ち位置を整理しましょう。これらはすべてコンテナを動かすためのものですが、その思想と運用の手離れ（抽象度）が大きく異なります。
Kubernetes（EKS/GKE）：プラットフォームを作るためのプラットフォーム
Kubernetesは、コンテナオーケストレーションの世界標準です。AWSならAmazon EKS、Google CloudならGoogle Kubernetes Engine（GKE）として提供されています。
- 特徴： 極めて高い柔軟性と拡張性。宣言的な設定ファイル（YAML）により、自己修復、オートスケーリング、サービスディスカバリを高度に制御可能。
- デメリット： 「学習コスト」と「管理コスト」が最大。コントロールプレーンの管理費用が発生するほか、ネットワーク（CNI）やストレージ（CSI）の深い知識が求められます。
AWS ECS（Fargate）：AWSエコシステムに特化したマネージドサービス
Amazon Elastic Container Service（ECS）は、AWS独自のコンテナオーケストレーションサービスです。特にAWS Fargateを使用することで、サーバー（EC2インスタンス）の管理が不要になります。
- 特徴： AWSの他サービス（IAM、ALB、CloudWatch等）との親和性が抜群に高い。Kubernetesほど複雑ではなく、AWSエンジニアにとって馴染みやすい。
- デメリット： AWS固有の仕様が多いため、他クラウドへの移行（ポータビリティ）はKubernetesに劣ります。
Google Cloud Run：サーバーレスの究極形、イベント駆動にも対応
Cloud Runは、Knative（Kubernetes上で動くサーバーレス基盤）をベースにした、Google Cloudのマネージドサービスです。
- 特徴： 「0へのスケール（リクエストがない時は料金ゼロ）」が可能。インフラの構築をほぼ意識せず、コンテナイメージを指定するだけでURLが発行される手軽さ。
- デメリット： 1リクエストの処理時間に制限（最大60分）がある、ステートフルな処理には向かないなど、サーバーレス特有の制約があります。
これらの基盤選びは、バックオフィスのシステム刷新においても重要です。例えば、SaaSコストとオンプレ負債を断つために自社でマイクロサービスを構築する場合、運用に人員を割けない小規模チームでは、ECSやCloud Runの選択が現実解となります。
【徹底比較】スモールスタートにおける「運用コスト」と「料金構造」
小規模構成において最も重視すべきは、「エンジニアの工数（人件費）」と「月額の最低維持費」です。以下の表に、主要な項目を比較しました。
| 比較項目 | Amazon EKS (Fargate) | Amazon ECS (Fargate) | Google Cloud Run |
|---|---|---|---|
| 管理の難易度 | 非常に高い | 中程度 | 低い（サーバーレス） |
| 最低維持コスト | 約73〜/月 (クラスター利用料)</td> <td>ほぼ0（タスク稼働分のみ） |
$0（0スケール時） | |
| スケーリング | Pod単位（やや遅い） | タスク単位（分単位） | リクエスト単位（秒単位） |
| 学習コスト | K8s、Manifest、Helm等 | ECS独自のTask Definition等 | Dockerfileの知識のみ |
| 主な用途 | 複雑な依存関係、マルチクラウド | AWS中心の標準的Webアプリ | API、Web、イベント処理 |
※料金は2024年現在の米東部（バージニア北部）リージョンを参考。最新の正確な数値は、AWS公式（EKS）、AWS公式（Fargate）、Google Cloud公式（Cloud Run）を必ずご確認ください。
管理コスト：誰がOSのパッチを当てるのか？
「小さめ構成」を維持する上で、セキュリティパッチの適用やOSのアップデートは大きな負担です。
Cloud RunやECS Fargateは、データプレーン（実行環境）が完全にマネージドであるため、基盤側のOS管理は不要です。一方、Kubernetes（EKS/GKE）であってもFargateやAutopilotモードを使えば軽減されますが、Kubernetes自体のバージョンアップ（APIの廃止対応など）に伴うマニフェストの修正作業は依然として発生します。
料金比較：アイドル時のコストとスケーリングの優位性
特に注意が必要なのが、「クラスター管理料」です。Amazon EKSの場合、1クラスターあたり0.10ドル/時（月額約73ドル）の固定費が発生します。これに対し、ECSやCloud Runは管理料が無料であり、動かしたリソース分だけ課金されます。
夜間にアクセスがゼロになる社内ツールや開発環境であれば、Cloud Runの「0へのスケール」は圧倒的なコストメリットを生みます。逆に、常に一定のトラフィックがある場合は、ECS Fargateの方がリザーブドキャパシティなどの割引を適用しやすく、安価になるケースもあります。
実務で直面する「ネットワークとセキュリティ」の設計差異
コンテナを単体で動かすのは簡単ですが、実務ではデータベース（RDSやCloud SQL）への接続や、社内ネットワークとのVPN接続が必須となります。
VPC内リソースへのアクセスとプライベート接続
- ECS (Fargate): 最初からVPC（Virtual Private Cloud）内で動作することが前提です。セキュリティグループによって、DBへのアクセス制御を細かく設定できます。ただし、インターネット通信にはNAT Gatewayが必要になり、そのコスト（月額約30ドル〜）が小規模構成では無視できません。
- Cloud Run: 基本はVPC外（Googleの共有ネットワーク）で動作します。VPC内のリソース（Cloud SQLなど）に接続するには「サーバーレスVPCコネクタ」または「ダイレクトVPC下り」の設定が必要です。
こうしたインフラの自動化やデータ連携の全体像を考える際、SFA・CRM・MA・Webの違いを解説した全体設計図の考え方が役立ちます。コンテナはあくまで「計算資源」であり、それらがどのように他のデータソースとセキュアに結びつくかがシステムの成否を分けます。
認証・認可の仕組み（IAM vs RBAC）
セキュリティの要となる権限管理ですが、ECSとCloud RunはそれぞれのクラウドのIAM（Identity and Access Management）に統合されています。コンテナに与える権限（S3への書き込み、メール送信など）をロール単位で制御可能です。
Kubernetesの場合、クラウドのIAMに加えて、K8s内部のRBAC（Role-Based Access Control）を管理する必要があります。この二重の管理構造が、小規模チームにおける運用の「落とし穴」になりがちです。
構成パターン別：どれを選ぶべきかの判断基準
Cloud Runを選ぶべきケース：最速で価値を届けたい場合
- 開発者がインフラ管理に時間を割きたくない。
- アクセス数に激しい波がある（または夜間はゼロになる）。
- ステートレスなHTTPリクエスト処理がメイン。
- Google Cloudの強力なデータ基盤（BigQueryなど）を活用する予定がある。
例えば、BigQueryとリバースETLを用いた行動トリガー型LINE配信のようなデータ駆動型の仕組みを構築する場合、APIエンドポイントとしてCloud Runを採用するのは非常に賢い選択です。
ECS (Fargate)を選ぶべきケース：AWS環境に統合したい場合
- 既に社内インフラがAWSで統一されている。
- RDS、ElastiCache、S3などとの高度なネットワーク制御・セキュリティ要件がある。
- 長時間実行されるバッチ処理や、常時稼働が必要なデーモンプロセスがある。
- 「サーバーレス」すぎる制約（処理時間の制限など）を受けたくない。
Kubernetes (EKS/GKE)を選ぶべきケース：ポータビリティと高度な制御が必要な場合
- 複数のクラウドやオンプレミスをまたいで同じ運用をしたい。
- Pod間の通信制御（Service Mesh）や、独自のリソース定義（CRD）が必要な特殊なアプリケーション。
- 既に組織内にKubernetesの熟練エンジニアが複数名存在し、共通基盤として提供する場合。
注意： 「とりあえず流行っているから」という理由で3人以下の開発チームがKubernetesを選択すると、機能開発よりも「K8sの機嫌を取る時間」の方が長くなるリスクがあります。
導入手順：Cloud RunとECSで「小さく」コンテナを動かすステップ
具体的な導入イメージを掴むため、小規模構成で推奨される2つのパターンのデプロイフローを確認しましょう。
Cloud Runでの最短デプロイ手順とよくあるエラー
- イメージのビルド：
gcloud builds submit --tag gcr.io/PROJECT_ID/app-nameでGoogle Cloud上にイメージを作成。 - デプロイ：
gcloud run deploy --image gcr.io/PROJECT_ID/app-name --platform managed。 - 認証： パブリックに公開する場合は
--allow-unauthenticatedを指定。
よくあるエラー：Cloud SQLへの接続失敗
原因の多くは、Cloud Runのサービスアカウントに「Cloud SQLクライアント」権限がないこと、またはVPCコネクタの設定ミスです。ローカル環境では動くのにデプロイすると動かない場合、まずはIAM権限を疑いましょう。
ECS Fargateでの構成手順とネットワーク設定の落とし穴
- ECRへのPush： DockerイメージをAmazon Elastic Container Registryにプッシュ。
- タスク定義の作成： CPU/メモリの割り当て、コンテナイメージ、環境変数を設定。
- サービスの作成： ALB（Application Load Balancer）と紐付け、ターゲットグループを設定。
よくあるエラー：タスクがすぐに停止する（Essential container in task exited）
ECSで最も多いトラブルです。CloudWatch Logsを確認し、アプリケーションが正常に起動しているか、ヘルスチェックパスが正しいかを確認してください。また、FargateタスクがECRからイメージをプルするために、パブリックサブネットに配置するか、VPCエンドポイント（S3およびECR用）を作成しているかを確認しましょう。
まとめ：運用フェーズを見据えた「持続可能な」選択を
コンテナ運用の選定において、最も避けるべきは「オーバーエンジニアリングによる自滅」です。小規模な構成でスタートする場合、以下の優先順位で検討することをお勧めします。
- Google Cloud環境なら： まずは Cloud Run。制約に当たらない限り、これ以上に「楽」な選択肢はありません。
- AWS環境なら： まずは ECS (Fargate)。AWSの堅牢なエコシステムを最大限に享受しつつ、サーバー管理から解放されます。
- Kubernetesは： 明確な「K8sでなければならない理由」が説明できるようになった段階で、初めて検討の遡上に載せるべきです。
技術の選定は、単なるスペック比較ではありません。自社のチームがどれだけの運用負荷を許容できるか、そしてビジネスのスピードを最大化できるのはどれか。その視点を持つことが、優れたIT実務担当者への第一歩となります。
もし、インフラの刷新と同時に、経理やバックオフィスのDXも進める必要があるなら、freee会計導入マニュアルなども参考に、システム全体の最適化を俯瞰して進めてみてください。
コンテナ選定で見落としがちな「実務上の隠れたコスト」と対策
サービスのスペック表には現れない、運用開始後に「意外と高い」「手間がかかる」と気づくポイントがいくつかあります。特に小規模構成では、これらがプロジェクトの利益率を圧迫する要因となります。
ネットワークコストの罠：NAT GatewayとVPC接続
AWS ECS（Fargate）を使用する場合、プライベートサブネット内のコンテナが外部（APIやS3等）と通信するには、NAT Gatewayの設置が推奨されます。しかし、NAT Gatewayは1台あたり月額約30ドル以上の固定費がかかるため、極小規模な構成ではコンテナの実行環境よりもネットワーク維持費が高くなる逆転現象が起こります。
一方、Google Cloud Runでは「ダイレクトVPC下り」を利用することで、複雑なゲートウェイ管理なしにVPC内のデータベース（Cloud SQL）等へセキュアに接続可能です。こうしたネットワークトポロジーの簡素化は、運用工数の削減に直結します。
開発サイクルを加速させるCI/CDの選定基準
コンテナ基盤の真価は、デプロイの自動化にあります。それぞれのサービスに適したデプロイ戦略は以下の通りです。
| ツール | Cloud Run | ECS (Fargate) | Kubernetes (EKS) |
|---|---|---|---|
| 推奨フロー | gcloudコマンド直叩き / Cloud Build | GitHub Actions (aws-actions) | GitOps (ArgoCD / Flux) |
| 環境分離 | タグ付けで容易に分岐 | タスク定義の更新で管理 | NamespaceやHelmでの抽象化が必要 |
| 難易度 | ★☆☆（初心者でも可） | ★★☆（IAM設計が肝） | ★★★（マニフェスト管理が必須） |
こうした「デプロイの摩擦」を最小化する設計思想は、フロントエンドに近い領域でも重要です。例えば、摩擦ゼロの顧客獲得アーキテクチャを構築する際、バックエンドの基盤が軽量であればあるほど、フロントの改善サイクルを高速に回すことができます。
設計を深掘りするための公式リソース集
実務で詳細設計に入る前に、必ず目を通しておくべき公式のベストプラクティスをまとめました。
- EKS ベストプラクティスガイド（日本語）：Kubernetesを本気で運用する場合のバイブルです。
- Cloud Run のオートスケーリング（公式）：最大・最小インスタンス数設定による「コールドスタート対策」と「予算超過防止」が学べます。
- AWSにおけるマイクロサービスの設計（AWS公式ブログ）：コンテナだけでなく、SQSやLambdaを組み合わせたサーバーレスアーキテクチャの勘所が解説されています。
インフラの選定は一度決めると変更が容易ではありません。もしコンテナ化の目的が「バックオフィスの自動化」にあるなら、経理の完全自動化とアーキテクチャの記事も併せて参照し、単なるコンテナ化に留まらない「データ連携の最適解」を模索してみてください。
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。