AWS・Google Cloud・Azureの実行基盤比較：VM・コンテナ・サーバーレスをどう選ぶ？

2026年10月26日 · 約10分で読めます

EC2・Compute Engine・Azure VM、ECS on Fargate・Cloud Run・Container Apps、EKS・GKE・AKSを、制御範囲・起動遅延・スケール・DB接続・費用から比較。変動する受注APIを例に、運用を委ねる範囲と採用前の試験を決めます。

比較の出発点：受注APIで何を委ねたいか

既存のコンテナで動く受注APIがあり、昼のアクセスが夜より多いとします。アプリはステートレスで、注文は外部のPostgreSQLへ保存します。チームがOSやクラスタの保守を減らしたいなら、まずマネージドなコンテナ実行が候補です。Kubernetes APIを使う独自OperatorやゲストOSの変更が必要になれば、比較する段を変えます。

VM・Kubernetes・マネージドコンテナの対応表

必要な制御	AWS	Google Cloud	Azure
ゲストOSを管理するVM	Amazon EC2	Compute Engine	Azure Virtual Machines
Kubernetes APIとリソース	Amazon EKS	Google Kubernetes Engine（GKE）	Azure Kubernetes Service（AKS）
ノードを管理せずコンテナを実行	Amazon ECS on AWS Fargate	Cloud Run	Azure Container Apps
イベント起点の関数	AWS Lambda	Cloud Run functions	Azure Functions

これは探索の入口です。Fargateはコンテナ向けの計算基盤で、ECSと組み合わせた構成を表に載せています。Cloud RunとContainer Appsはアプリの入口や実行方式も提供します。「サーバーレス」という呼び名だけで、HTTP公開やゼロ台からの復帰まで同じになるとは判断できません。

Kubernetesでも委任範囲は一律ではありません。EKS StandardとAuto Mode、GKE StandardとAutopilotなどで、ノード管理と制約が変わります。どの方式でも、アプリの権限、リソース設定、リリース、監視の責任は確認します。コンテナイメージが共通でも、IAMやネットワーク設定まで無変更で移せるわけではありません。

ECS on Fargate・Cloud Run・Container Appsの違い

候補	選定に効く特徴	採用前に確かめること
ECS on Fargate	タスクのCPU・メモリ、ネットワーク、IAMを指定して実行	公開APIのロードバランサー、サービスの台数制御、起動時間
Cloud Run	サービスのHTTPS入口と要求ベースのスケール。ジョブ等も別の実行方式で提供	サービス・ジョブ・worker poolの使い分け、同時要求数、CPUの割り当て方式
Container Apps	HTTPやキュー等を使うKEDAベースのスケール、リビジョンとジョブ	使うスケール規則、最小レプリカ、環境のネットワークとプラン

この受注APIでは、3候補それぞれで同じ認証・タイムアウト・接続先を用意し、実際のコンテナを動かします。HTTP以外の常駐処理や長いバッチが加わるなら、その実行方式を別に評価します。Container Appsは内部でKubernetesを使いますが、利用者へKubernetes APIを直接公開するサービスではありません。独自のKubernetes制御が必要ならAKSなどを比較します。

低頻度と突発負荷では、コールドスタートとスケールの遅れを見る

夜にゼロ台まで縮める構成では、最初の要求が起動を待つことがあります。最低限の実行環境を維持すると待ちを減らせますが、その容量の費用が残ります。Cloud Runの最小インスタンス、Container Appsの最小レプリカなどを比較するときは、名前ではなく「何台が準備済みで、超えた要求がどうなるか」を確かめます。

一定負荷だけでなく、無通信の後の初回、急増、デプロイ直後を試す。起動・初期化の時間とその発生割合を測り、全体のp95・p99と照合する。
既知の昼のピークには事前に容量を用意できるかを検討する。CPUやキュー長による反応型の増設は、到着後に効く。
同時要求数を増やす設定と実際の処理能力を区別する。1コンテナが多く受けられても、CPU・メモリ・DB待ちで遅くなる場合がある。

増設の上限は、DB接続の予算とセットで決める

仮に、1インスタンスに2プロセス、各プロセスのDBプール上限を10とします。20台では20 × 2 × 10 = 400接続、50台では1,000接続を開き得ます。これはプールを満たしたときの設定上の合計で、常時使われる接続数や処理能力の実測ではありません。

仮定の接続設定：2プロセス/台 × 10接続/プロセス。デプロイ中は20台に10台が重なる

平常20台: 400接続
デプロイ中30台: 600接続
増設後50台: 1,000接続

DBからアプリへ割り当てられる枠が500接続なら、20台が収まってもデプロイ中は超えます。新旧の版や複数のサービスを合算し、プロキシを使うならクライアント側とDB側を分けて数えます。最大台数だけに頼らず、プール上限、全体の同時処理制御、待ちの期限を設計します。

費用比較は、暇な時間と常時稼働の両方を含める

特性	比較する費用	判断が変わる条件
低頻度・変動が大きい	処理時の計算、要求、最低容量	待機容量を置かずに起動遅延を満たせるか
一日中高い利用率	必要な常時容量、割引契約、運用工数	単価だけでなく、余力と保守の費用を含めても有利か
非公開ネットワークと大量の通信	ロードバランサー、NAT等の経路、転送、ログ	同じCPUでも周辺サービスが総費用を変えるか

各社で同じリージョン相当、稼働時間、HA要件、転送量、ログ保持を見積もり条件にします。コンテナの計算料金だけを並べて最安とはしません。このAPIでマネージド実行が要件を満たすなら、削減できる保守時間も採用理由です。既存チームがKubernetesを十分運用でき、固有機能を使う場合には別の結論になり得ます。

採用前の試験と設計レビューで残す結論

実コンテナで公開・非公開アクセス、アプリの認可、必要なプロトコルを確認する。ローカルの永続状態に依存していないかを調べる。
低頻度・急増・デプロイを再現し、起動時間、エラー率、遅延、DBの接続待ちを一緒に測る。
最低容量と増設上限を変えて、遅延目標とDBの許容量を満たす構成の費用を見積もる。
「このHTTP APIは候補の実行条件を満たし、試験で遅延と接続数を確認したため採用する。Kubernetes固有の制御が必要になったら再評価する」と判断条件を記録する。