先に要点
- クラウドで 「アプリをどこで動かすか」 の主要 3 選択肢: VM(EC2)・コンテナ(ECS / EKS / Fargate)・サーバレス(Lambda)。運用負荷とスケール特性が階段状に違う ので、「書きたいアプリの形」 と 「運用できる体制」 で選ぶのが基本。
- VM(EC2 等): 「OS から自分で管理」 する最も自由度の高い形。「既存資産の移行」 「 OS 固有の依存が必要」 「 GPU / 特殊ハードが要る」 場面で使う。運用負荷は最大、料金は時間課金。
- コンテナ(ECS / EKS / Fargate): 「アプリと依存を Dockerfile で固める」 形。移植性が高く、複数クラウドでもほぼ同じように動く。「常時起動アプリ」 「 マイクロサービス」 「 Web/API バックエンド」 の現代の標準。
- サーバレス(Lambda 等): 「イベントごとに関数が起動」 する形。使った分だけ料金」 「 自動スケール」 「 サーバ管理ゼロ が強み。「イベント駆動」 「 トラフィックが波のある API」 「 短時間処理」 に向く。「常時高負荷」 では料金が逆に高くなる。
- 判断軸: 常時負荷の高さ」 「 起動時間の許容度(Cold Start)」 「 OS / ライブラリ依存」 「 運用体制(チームサイズ)。「小〜中規模なら Fargate or Lambda、大規模で安定負荷なら ECS on EC2、特殊要件なら VM」 が現代の AWS での素直な選び方。
「AWS でアプリを動かしたい」 と思った時、「EC2 にする?ECS にする?Lambda にする?」 で迷うのはほぼ全員が通る道です。「それぞれ何が違うのか」 「 どんなアプリに向くのか」 を理解せずに選ぶと、「料金が想定外に高い」 「 運用が回らない」 「 機能が足りない」 のような失敗に当たります。
ざっくり言うと、3 選択肢は 運用負荷とスケール特性が階段状に違う もので、「どこまで AWS に任せるか」 の度合いで並べると見通しが立ちます。「VM は全部自分で、コンテナはアプリだけ自分で、サーバレスは関数だけ書く」 という整理です。
この記事では、3 つの特性と判断軸を実務目線で整理します。AWS の前段選択ガイド と IAM の使い分け も併読すると、「どこで動かすか + 前段に何を置くか + 権限はどう設計するか」 のセットで理解できます。
まず特性を一覧で
3 選択肢を表で並べます。
| 項目 | VM(EC2) | コンテナ(ECS / Fargate) | サーバレス(Lambda) |
|---|---|---|---|
| 抽象化レベル | OS + ハードウェア | アプリ + 依存(コンテナイメージ) | 関数コード |
| 料金モデル | 時間課金(起動中は常時) | 時間課金(Fargate は使用分のみ) | リクエスト + 実行時間 |
| Cold Start | なし(常時起動) | あり(数秒〜) | あり(数百 ms 〜数秒) |
| スケール | Auto Scaling グループで台数調整 | タスク数で自動調整 | 完全自動(リクエストごとに即拡張) |
| 運用負荷 | OS パッチ、AMI、セキュリティ更新 | コンテナイメージ更新、Fargate なら基盤管理不要 | 関数コードと環境変数だけ |
| 移植性 | 低(AMI / OS 依存) | 高(Docker イメージで移植可) | 低(プラットフォーム依存が強い) |
| 長時間処理 | ○ 制限なし | ○ 制限なし | △ 最大 15 分 |
| 典型用途 | 既存資産移行、GPU、特殊ハード | 常時起動 Web / API、マイクロサービス | イベント駆動、波のある API、バッチ |
「抽象化レベル」 が右に行くほど高く、「AWS に任せる範囲」 が広がります。
VM(EC2)── 全部自分で管理する自由
最も自由度が高い代わりに、運用負荷も最大。
向いている場面
「 既存オンプレシステムの移行(Lift & Shift)」 「 OS 固有のソフトウェアが必要」 「 GPU / 特殊ネットワークが必要」 「 ライセンス制約で特定ハード必須」。「コンテナ化が困難なレガシー資産」 で第一選択。
料金感
「 起動している間ずっと時間課金」。t3.medium(2 vCPU / 4GB)で月 4,000 円程度〜、本番向け m5.large(2 vCPU / 8GB)で月 12,000 円程度〜。Reserved Instance / Savings Plans で 30〜70% 削減 可能だが、「コミットメント期間に縛られる」 トレードオフあり。
コンテナ(ECS / EKS / Fargate)── 移植性と現代のデファクト
「現代の Web/API バックエンド」 の事実上の標準。AWS 内でも複数の選択肢がある。
ECS on EC2
EC2 インスタンス上に ECS タスクを配置する形。大規模で常時負荷が高い 場合のコスト効率が良い。「EC2 を Reserved にしてコンテナで効率配置」 が定石。クラスタ容量管理は自前。
ECS on Fargate
「 インフラを AWS が完全管理」 する 「サーバレスコンテナ」。「タスクごとに必要な vCPU / メモリを指定して、使った分だけ課金」。中小規模 / 不定期負荷 で運用負荷が劇的に下がる。「EC2 より単価は高い」 が 運用コスト込みで Fargate が安いことが多い。
EKS(Kubernetes)
「 Kubernetes 互換が必要」 「 マルチクラウド対応」 「 大規模マイクロサービス」 で選ぶ。学習コストと運用負荷が高い ので、小規模サービスでは過剰。「Kubernetes の運用知識がチームにある」 ことが前提。
移植性が最大の価値
「 Dockerfile + コンテナイメージ」 さえあれば、「AWS / GCP / Azure / 自前サーバ」 のどこでも動かせる。「 クラウドロックインを避けたい」 戦略にも有効。「オンプレに戻す」 という可能性も残せる。
サーバレス(Lambda)── 使った分だけ、自動スケール
「関数だけ書けば動く」 最も抽象化された選択肢。
向いている場面
「 イベント駆動(S3 アップロード、SQS、SNS、EventBridge)」 「 API Gateway + Lambda の REST API」 「 トラフィックが時間帯で大きく変動する」 「 短時間処理(数秒〜数分)」。起動していない時間はゼロ円 なので、「使わない時間が長いアプリ」 でコストが激安になる。
料金感
「 リクエスト数 + 実行時間(GB-秒)」 で課金。「月 100 万リクエスト + 100ms 実行(128MB メモリ)」 で約 30 円程度。小規模 API は無料枠内で運用可能。一方、` 常時高負荷の API では EC2 / ECS の方が安くなる損益分岐点 が存在する。
Cold Start の制約
「 久しぶりに呼ばれた関数」 は 数百 ms〜数秒の Cold Start。「常時 ms レベルのレスポンスが必要な公開 API」 では問題になる。Provisioned Concurrency(常時ウォームに保つ機能)で緩和できるが、「料金が EC2 並みに上がる」 こともある。
運用負荷ゼロ
「 OS パッチ・容量管理・スケール調整」 すべて AWS 任せ。「関数のコードと環境変数」 だけ管理。小規模チームに圧倒的に優しい。
判断フロー — どれを選ぶか
「どれを選ぶか」 を 7 ステップで決めるフロー。
この 7 ステップを通れば、「どれを選ぶべきか」 がほぼ一意に決まります。
典型ユースケース別の推奨
具体的なユースケースで、どれが向くかを並べます。
| ユースケース | 推奨 | 理由 |
|---|---|---|
| 新規 Web アプリ(中規模、Laravel / Rails) | ECS on Fargate | 運用負荷低、常時起動でも料金許容、コンテナで移植性 |
| 個人開発のサーバレス API | Lambda + API Gateway | 無料枠で運用、コスト最小 |
| 大規模マイクロサービス(常時高負荷) | EKS or ECS on EC2(Reserved) | コスト効率、Kubernetes エコシステム |
| イベント駆動(S3 アップロード処理) | Lambda | イベントごとに起動、使った分だけ |
| バッチ処理(深夜の集計) | Lambda(短時間) or AWS Batch / ECS(長時間) | 処理時間で選択 |
| GPU 機械学習推論 | EC2(GPU インスタンス) or SageMaker | GPU 必須、Lambda では動かない |
| レガシーアプリ移行(Lift & Shift) | EC2 | OS 環境をそのまま移植 |
| Cron ジョブ / 定期処理 | EventBridge + Lambda | cron 表記で簡単に組める |
| WebSocket / リアルタイム通信 | ECS / Fargate | 長時間接続、Lambda は不向き |
損益分岐点 — Lambda と Fargate どちらが安い?
「 使った分だけ」 の Lambda が必ずしも最安ではない。常時負荷が高くなると、コンテナの方が安くなる 損益分岐点が存在する。
Lambda の損益分岐点
「 月の累計実行時間」 が一定を超えると、「常時起動のコンテナ(Fargate)」 の方が安くなる。1 リクエスト 100ms、月 1 億リクエスト あたりが目安(モデルによる)。トラフィック予測ができれば、必ず両方の料金を試算する。
Provisioned Concurrency の罠
「 Lambda の Cold Start を解消するため Provisioned Concurrency を有効化 → 常時ウォームに保つ料金が EC2 / Fargate 並みに高くなる」。「それなら最初から ECS / Fargate にすればよかった」 となるケースが多い。
Fargate の損益分岐点
「 常時高負荷で安定 + Reserved できる」 場合は、EC2(Reserved) + ECS のほうが Fargate より 40〜60% 安い。「大規模本番環境」 では 「ECS on EC2 + Reserved Instance」 が定番。
試算ツール
「 AWS Pricing Calculator」 や 「Vantage」 のような第三者ツールで、「同じワークロードを Lambda / Fargate / EC2 で動かしたらいくら」 を比較できる。採用前に必ず試算 する習慣を持つ。
ハマりやすいポイント
選択時 / 運用時に踏みやすい落とし穴を整理します。
Lambda の 15 分上限
「 長時間処理を Lambda で組んで、15 分を超えてタイムアウト」。15 分以上かかる処理は Step Functions で分割 or ECS / Fargate に変更。
Fargate の起動時間
「 Fargate タスク起動に 30 秒〜1 分かかる」 ことがある。「バーストに即応」 には向かない。ある程度の常時タスク数」 + `Auto Scaling で予熱 を組み合わせる。
コンテナ vs サーバレス vs VM に関するよくある質問
Q. 個人開発で AWS を始めるなら何が良いですか?
A. 「 Lambda + API Gateway + DynamoDB」 が圧倒的に安価。「月数百〜数千リクエスト」 なら ほぼ無料で運用できます。「Web フロントは S3 + CloudFront」 と組み合わせると、「月数百円」 で本格的な構成が組めます。
Q. ECS と EKS、どっちを選ぶべき?
A. Kubernetes 互換が必要 or 既に Kubernetes 経験がある」 なら EKS、それ以外は ECS。ECS は AWS 専用だが学習コストが圧倒的に低い。EKS は 「Kubernetes エコシステム(Helm / Istio / ArgoCD)」 を活かしたい大規模組織向け。小〜中規模なら ECS が圧倒的に楽。
Q. Lambda の Cold Start を回避する方法は?
A. Provisioned Concurrency」 「 ARM ベース(Graviton)」 「 関数の小型化」 「 SnapStart(Java/Python) の組み合わせ。それでも数十 ms の遅延は残るので、Cold Start を許容できない場合は最初から Fargate / EC2 に切り替える 判断も必要。
Q. Fargate と EC2 on ECS、どっちを選ぶ?
A. 小〜中規模ならまず Fargate、大規模 + 安定負荷で EC2(Reserved) on ECS。Fargate は 運用負荷ゼロ、EC2 on ECS は 30〜60% コスト削減可 のトレードオフ。「Fargate で運用しつつ、大きくなったら EC2 に移行」 のパスも取れる(Task 定義は共通)。
Q. 既存の EC2 アプリをコンテナ化する判断軸は?
A. 「 運用負荷の削減効果」 と 「コンテナ化の工数」 のバランスで判断。「OS 依存が少ないアプリ」 「 ステートレスに書き換えやすい」 場合はコンテナ化のメリット大。「OS と密に絡んだレガシー」 は EC2 のまま運用するのが現実解。
Q. Vercel / Cloudflare Pages はどの枠に入る?
A. サーバレス + エッジ計算のミックス です。「基本はサーバレスに近い」 が、「CDN とエッジコンピュート(Vercel Edge Functions / Cloudflare Workers)が前段に統合」 されています。Cloudflare Workers と CloudFront Functions / Lambda@Edge の違い も参考に。
Q. 移行は後からでも可能?
A. 可能だがコストがかかる。「Lambda → ECS / Fargate」 は比較的容易(関数を Web フレームワーク化してコンテナに包む)、「 EC2 → コンテナ」 は OS 依存の洗い出しに時間がかかる。「将来の移行可能性も含めて、最初から適切に選ぶ」 のがコスト効率良い。
まとめ
クラウドの計算リソース 3 選択肢は、「抽象化レベルと運用負荷」 で階段状に並びます。「書きたいアプリの形」 「 起動時間の許容度」 「 負荷パターン」 「 運用体制」 「 マルチクラウド戦略」 で素直に選び分けるのが基本。
「小〜中規模なら Fargate or Lambda、大規模で安定負荷なら ECS on EC2、特殊要件なら VM」 が現代の AWS での素直な選び方です。「過剰な抽象化は料金で損し、過剰な低レベルは運用で損する」 ので、「身の丈に合った選択」 が長く運用するときの本質です。
参考リンク
- AWS: Amazon ECS
- AWS: AWS Lambda
- AWS: Amazon EC2
- AWS: AWS Fargate
- AWS: Amazon EKS