SAP-C02-084 · セクション 10 / タスク 2.5

Elastic Compute Architecture

Amazon EC2 Auto Scaling / AWS Lambda / Amazon ECS / Amazon EKS / AWS Fargate / AWS App Runner / AWS Batch / 水平スケーリング / 伸縮性

ゴール

負荷が増えたとき、

コンピューティングを増やす

だけでは、設計として十分ではありません。

AWSでは実行方式によって、

何を増減するのか
誰が基盤を管理するのか
どの単位で処理を分散するのか
どの程度AWSへ管理を委任するのか

が異なります。

例えば、

Amazon EC2 Auto Scaling
→ EC2インスタンスを増減

AWS Lambda
→ 実行環境を需要に応じて増減

Amazon ECS
→ タスクを増減

Amazon EKS
→ Podを増減
  ＋ 必要ならノードも増減

AWS Fargate
→ ECSタスク / EKS Podを実行する
   コンピューティングを提供

AWS App Runner（既存顧客）
→ ウェブサービスのインスタンスを自動増減

AWS Batch
→ ジョブを実行する
   コンピューティングキャパシティを管理

という違いがあります。

このページでは、「この負荷なら何台増やすか」ではなく、「どの実行モデルなら需要に合わせて適切な単位を伸縮させられるか」を判断します。

1. 水平スケーリングでは「何を増やすか」がサービスごとに違う

水平スケーリングでは、同じ役割を持つ処理単位を増やします。

ただし、その単位はサービスによって異なります。

実行方式	主なスケーリング単位
Amazon EC2 Auto Scaling	EC2インスタンス
AWS Lambda	実行環境・同時実行
Amazon ECS	タスク
Amazon EKS	Pod
AWS Fargate	—（独自に個数を決めず、ECSタスク / EKS Pod用のコンピューティングを提供）
AWS App Runner（既存顧客）	サービスインスタンス
AWS Batch	ジョブを実行するコンピューティングキャパシティ

したがって、

水平スケーリングしたい

だけではサービスは決まりません。

まず、

どの単位を
独立して増減したいのか

を考えます。

AWS Fargateは、独自にタスク数やPod数を決めるスケーリングサービスではありません。Amazon ECSやAmazon EKSで決定されたタスク / Podを実行するコンピューティングを提供します。

2. 伸縮性の基本を実行方式の選択条件として使う

伸縮性では、需要増加時にキャパシティを増やし、需要減少時に減らせることが基本です。

ここで重要なのは伸縮性そのものを再確認することではなく、

EC2インスタンス
関数の実行環境
コンテナタスク
Pod
ジョブ用キャパシティ

のどれを需要へ追従させるのがワークロードに合うかです。

3. Amazon EC2 Auto Scalingは仮想マシン単位で伸縮する

EC2で、

OS
常駐プロセス
特殊なエージェント
カーネル設定
特定のインスタンスタイプ

などを細かく制御する必要がある場合、EC2を複数台で構成し、Amazon EC2 Auto Scalingによってインスタンス数を増減できます。

負荷増加
↓
希望するキャパシティ増加
↓
EC2インスタンス追加
↓
アプリケーション起動
↓
処理キャパシティ増加

という流れです。

ここでの伸縮単位は、

EC2インスタンス

です。

4. EC2を選ぶのはOS・VMレベルの制御が必要なとき

伸縮させたい
=
必ずAmazon EC2 Auto Scaling

ではありません。

例えば、

OSレベルまで制御したい
長時間稼働プロセスがある
特殊なエージェントが必要
カーネル設定が必要

ならEC2が適する可能性があります。

一方、

短いイベント処理
コンテナ単位で実行したい
Kubernetesが必要
単純なHTTPウェブサービス
大量のバッチジョブ

なら、別の実行モデルを評価します。

5. AWS Lambdaはイベントやリクエストに応じて実行環境を増やす

AWS Lambdaでは、利用者が通常のEC2インスタンス数を直接管理しません。

イベント / リクエスト
↓
Lambda関数
↓
必要な実行環境

という形で、需要に応じてAWSが実行環境をスケールします。

例えば、

Amazon S3へのオブジェクト作成
APIリクエスト
メッセージ
イベント

を契機とした処理に利用できます。

特に、

普段はほとんど処理なし
↓
突然イベント急増
↓
再び低負荷

のような、変動が大きいイベント駆動処理では有力な候補になります。

6. Lambdaでは同時実行と下流への影響も考える

需要が増えるとLambdaの実行環境も増えます。

ただし、

Lambda側の同時実行

と、

データベース
外部API
その他の依存先

が処理できる量は同じとは限りません。

必要に応じて予約済み同時実行数などを利用し、関数が利用できる同時実行数を制御することもできます。

7. Amazon ECSではタスクがアプリケーション側の伸縮単位

Amazon ECSサービスでは、

必要なタスク数

を増減できます。

例えば、

HTTP API
↓
Amazon ECSサービス

通常
10タスク

ピーク
40タスク

という構成です。

Amazon ECS サービスの自動スケーリングを利用すると、CloudWatchメトリクスなどに基づいて必要タスク数を増減できます。

つまり、Amazon ECSにおけるアプリケーション側の主な伸縮単位は、

タスク

です。

8. ECSではタスクとEC2キャパシティを分ける

Amazon ECSをEC2キャパシティで実行する場合、

Amazon ECSサービス
↓
タスク
↓
EC2インスタンス

という2つのレイヤーがあります。

例えば、

必要タスク数
10 → 40

となっても、EC2クラスター側に配置可能なCPUやメモリが不足していれば、新しいタスクを実行できません。

したがって、

アプリケーション側
→ 必要タスク数

基盤側
→ EC2キャパシティ

を分けて考えます。

Auto Scalingグループのキャパシティプロバイダーでマネージドスケーリングを利用すると、Amazon ECSから必要なEC2キャパシティを追従させる構成を取れます。

9. AWS Fargateではコンテナホストの管理を委任する

Amazon ECSの実行キャパシティとしてAWS Fargateを使用すると、

EC2インスタンス群を
自分でプロビジョニング
設定
パッチ適用
スケーリング

する必要がありません。

構造は、

Amazon ECS
↓
必要タスク数
↓
AWS Fargate
↓
タスク用コンピューティング

となります。

したがって、

コンテナとして実行したい
+
EC2ノード群は管理したくない

という場合に有力です。

ただし、Fargateそのものが、

アプリケーションは
何タスク必要か

を決めるわけではありません。

Amazon ECSではサービスの自動スケーリングなどが必要タスク数を決定し、Fargateがそのタスクを実行するコンピューティングを提供します。

10. Amazon ECSとAWS Fargateは同じ役割ではない

Amazon ECSは、コンテナのオーケストレーションを担当します。

AWS Fargateは、コンテナを実行するコンピューティングを提供します。

したがって、

Amazon ECS
+
AWS Fargate

という組み合わせが成立します。

ECSかFargateか

という単純な二者択一ではありません。

11. Amazon EKSはKubernetesを必要とするワークロードで評価する

Amazon EKSではKubernetes APIを利用します。

アプリケーション側では、

Pod

が実行単位になります。

例えば、

Horizontal Pod Autoscaler
↓
Podレプリカ数
3 → 12

のように、メトリクスに基づいてPod数を変化させられます。

したがって、

既存のHelmチャート
カスタムリソース定義（CRD）
Kubernetes API
Kubernetesエコシステム

などを利用する必要がある場合、Amazon EKSを評価します。

12. EKS Auto ModeはKubernetesを維持しながら基盤管理を減らせる

Kubernetesを必要としつつ、

EC2ノードの準備
ノードのスケーリング
ノードOSの更新
基盤コンポーネントの管理

にかかる運用負荷を減らしたい場合、EKS Auto Modeを評価できます。

EKS Auto Modeは、ワークロード需要に応じてノードを追加・削除できます。

つまり、

Kubernetes APIを維持
+
基盤側の管理をよりAWSへ委任

という選択肢です。

13. Amazon EKSでもAWS Fargateを利用できる

AWS FargateはAmazon ECSだけで利用するものではありません。

Amazon EKSでも、

Pod
↓
AWS Fargate

として実行できます。

この場合、

Amazon EKS
→ Kubernetesオーケストレーション

AWS Fargate
→ Pod実行用コンピューティング

という関係です。

14. Amazon ECSとAmazon EKSは「どちらが速いか」で選ばない

Amazon ECSとAmazon EKSは、

性能が高い方

という単純な比較で選びません。

重要なのは、

Kubernetes APIが必要か
既存Kubernetes資産があるか
必要なオーケストレーション機能は何か
どの制御レイヤーを管理したいか

です。

どちらもコンテナワークロードを実行できますが、求める制御モデルが異なります。

15. AWS App Runnerは既存利用ではHTTPウェブサービスを大きくマネージド化する

2026年9月時点の提供条件

AWS App Runnerは新規顧客には開放されていません。既存のApp Runner顧客はサービスを継続利用でき、新しいApp Runnerリソースも作成できます。一方、新規設計やApp Runnerからの移行では、AWSはAmazon ECS Express Modeの評価を推奨しています。

AWS App Runnerでは、

ソースコード
または
コンテナイメージ
↓
AWS App Runner
↓
実行中のウェブサービス

という形でHTTPウェブサービスを構築できます。

App Runnerは、

コンピューティングの起動
サービスの実行
負荷分散
自動スケーリング

を管理します。

そのため、

ステートレスなウェブサービス
+
Kubernetes不要
+
EC2フリートも管理したくない
+
インフラ制御より
アプリケーション実行を優先

という場合に候補になります。

16. App Runnerは同時リクエスト数を使って自動スケーリングできる

App Runnerでは、自動スケーリング設定として、

MaxConcurrency
MinSize
MaxSize

を指定できます。

概念的には、

1インスタンス当たりの
同時リクエスト増加
↓
MaxConcurrencyを超える
↓
サービスをスケールアウト

という動作です。

MinSizeは最低限プロビジョニングするインスタンス数、MaxSizeは最大インスタンス数を制御します。

したがってApp Runnerは、

Lambdaと同じように
必ずゼロまで縮退する

サービスではありません。

17. App Runnerは汎用コンテナオーケストレーターではない

App Runnerはコンテナイメージからサービスを実行できますが、

Amazon ECS
Amazon EKS

と同じ目的のサービスではありません。

App Runnerは主に、

HTTPウェブサービス

を高い管理レベルで実行するサービスです。

一方、

複数種類のサービス
複雑なコンテナ配置
Kubernetes API
細かいタスク制御

が必要なら、Amazon ECSやAmazon EKSを評価します。

18. AWS Batchは「待って実行できる仕事」をキューへ入れる

AWS Batchは、

利用者リクエストへ
その場で応答するウェブサービス

とは異なります。

例えば、

画像変換
シミュレーション
大量のデータ処理
機械学習処理
数万件の独立ジョブ

などを、

ジョブ
↓
ジョブキュー
↓
スケジューラ
↓
コンピューティング環境
↓
実行

という形で処理します。

ジョブをキューに保持できるため、仕事の到着と実際のコンピューティングキャパシティを分離できます。

19. AWS Batchではオーケストレーターごとのコンピューティング環境を分ける

AWS Batchのコンピューティング環境は、同じ階層にすべての実行方式が並ぶわけではありません。

Amazon ECSベースのコンピューティング環境

AWS Batch
↓
Amazon ECSベース
↓
Amazon EC2
または
AWS Fargate
または
Amazon ECS Managed Instances

を利用できます。

Amazon EKSベースのコンピューティング環境

AWS Batch
↓
Amazon EKS
↓
Amazon EC2
オンデマンド / スポット

としてジョブを実行します。

AWS Batch on Amazon EKSではAWS Fargateを使用しません。

FargateでAWS Batchジョブを実行したい場合は、Amazon ECSベースのコンピューティング環境を使用します。

重要なのは、AWS Batchがジョブをキューとコンピューティング環境へ割り当てる役割を持ち、その下で利用する実行基盤を選択できることです。

20. 同じシステムでもコンポーネントごとに実行方式を変えられる

1つのシステムですべて同じコンピューティング方式を使う必要はありません。

例えば、

公開ウェブAPI
→ Amazon ECS + AWS Fargate

画像アップロード後の軽量処理
→ AWS Lambda

大量の夜間処理
→ AWS Batch

という構成も可能です。

重要なのは、

システム全体で
EC2かLambdaか

と一括選択することではありません。

コンポーネントごとの処理形態と負荷パターンに合わせて実行方式を選択します。

21. スケーリング単位と基盤キャパシティを分ける

特にコンテナでは、

アプリケーション単位のスケーリング

と、

基盤コンピューティングのスケーリング

を区別する必要があります。

例えばAmazon ECSをEC2上で実行する場合、

サービスの必要タスク数
↓
タスクの水平スケーリング

EC2クラスターキャパシティ
↓
基盤側のスケーリング

という2つの制御があります。

一方、AWS Fargateを利用すれば、タスクを実行するEC2フリート自体を利用者が管理する必要はありません。

22. キャパシティが利用可能になるまでの時間も選択条件

伸縮性のあるサービスでも、新しいキャパシティが処理可能になるまでの時間がゼロとは限りません。

したがって実行方式を選ぶときは、需要変化の速さに対して、その方式が十分な速度でキャパシティを利用可能にできるかを確認します。

23. 下流の処理能力は別の制約として扱う

コンピューティング側をスケールアウトできても、データベースや外部APIなどの下流が処理できなければ、システム全体の性能は伸びません。

このページでは、その一般原則を前提として、どのコンピューティング単位を伸縮させるかの選択に集中します。

24. 自動スケーリングにも上限があることを前提にする

自動スケーリングを利用する場合も、サービスクォータや設定した最大キャパシティなどの上限があります。

したがって、自動化されていることと無制限に伸縮できることを同一視しないことを前提に実行方式を選びます。

25. 実行方式の選び方

ワークロード特性	最初に評価する候補
OSやVMレベルの制御が必要	Amazon EC2 + Auto Scaling
イベント駆動で需要変動が大きい関数処理	AWS Lambda
コンテナを使いKubernetesは不要	Amazon ECS
Kubernetes API / Kubernetesエコシステムが必要	Amazon EKS
コンテナホストのEC2管理を避けたい	AWS Fargate
シンプルなHTTPウェブサービスを高い管理レベルで実行	新規設計：Amazon ECS Express Mode / 既存利用：AWS App Runnerの継続またはECS Express Modeへの移行を評価
キューへ投入できる大量のバッチジョブ	AWS Batch

ただし、

Amazon ECS
+
AWS Fargate

や、

Amazon EKS
+
AWS Fargate

のように組み合わせて利用するサービスもあります。

26. よくある誤判断

誤判断	正しい判断
伸縮性が必要なら必ずEC2 Auto Scaling	ワークロードの実行モデルから選ぶ
Lambdaなら無制限にスケールする	クォータや下流制約も考慮する
ECSのタスク数を増やせばEC2キャパシティも必ず増える	アプリケーションと基盤のスケーリングは別
FargateはECSの代わり	FargateはECS/EKSで利用できるコンピューティング
Kubernetesが必要でもECSとEKSは同じ	Kubernetes APIが必要ならEKSを評価する
App RunnerはLambdaと同じく必ずゼロまで縮退	MinSizeを持つウェブサービス向けの自動スケーリング
AWS BatchはウェブAPIの水平スケーリングサービス	ジョブキューとコンピューティング環境でバッチを実行
1つのシステムは1種類のコンピューティングだけを使う	コンポーネントごとに適切な実行方式を選べる
新規のHTTPウェブサービスならApp Runnerを第一候補にする	新規顧客はApp Runnerを利用できないため、Amazon ECS Express Modeなどを評価する

27. SAP-C02での判断フロー

コンピューティング処理の形は？
        ↓
OS / VMレベルの制御が必要？
├─ はい
│   ↓
│  Amazon EC2
│  + Auto Scaling
│
└─ いいえ
    ↓
    イベント / リクエスト単位の
    関数処理？
    ├─ はい
    │   ↓
    │  AWS Lambda
    │
    └─ いいえ
        ↓
        コンテナ？
        ├─ はい
        │   ↓
        │   Kubernetes APIが必要？
        │   ├─ はい
        │   │   ↓
        │   │  Amazon EKS
        │   │  基盤管理を減らすなら
        │   │  EKS Auto Mode等も評価
        │   │
        │   └─ いいえ
        │       ↓
        │      Amazon ECS
        │
        │   コンテナホストを
        │   管理したくない？
        │       ↓
        │      AWS Fargateも評価
        │
        └─ いいえ
            ↓
            HTTPウェブサービスを
            高い管理レベルで実行したい？
            ├─ はい
            │   ↓
            │  新規設計：Amazon ECS Express Mode
            │  既存App Runner：継続利用または移行を評価
            │
            └─ いいえ
                ↓
                キューへ投入できる
                バッチジョブ？
                ↓
               AWS Batch

実際には排他的な一択ではなく、同じシステムのコンポーネントごとに異なるサービスを組み合わせることもできます。

まとめ

伸縮自在なコンピューティング設計では、

負荷が増えた
↓
何かを増やす

だけでは不十分です。

まず、

処理形態
負荷パターン
管理したいレイヤー
必要な実行環境

を確認します。

そして、

EC2
→ インスタンス

Lambda
→ 実行環境 / 同時実行

ECS
→ タスク

EKS
→ Pod

Fargate
→ タスク / Pod用コンピューティング

App Runner（既存顧客）
→ ウェブサービスインスタンス

新規のシンプルなコンテナHTTPサービス
→ Amazon ECS Express Modeを評価

Batch
→ ジョブ用コンピューティング

という伸縮単位と管理境界の違いを理解します。

SAP-C02では、「自動スケーリングできるサービスはどれか」ではなく、「このワークロードでは何を伸縮単位にし、どのレイヤーをAWSへ委任すれば需要変化に適切に追従できるか」を判断することが重要です。

主要AWS公式資料

AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク2.5 伸縮自在なアーキテクチャ
AWS Well-Architected パフォーマンス効率の柱 PERF02-BP01 — ワークロードに適したコンピューティング選択
AWS Well-Architected PERF02-BP05 — コンピューティングの動的スケーリング
Amazon EC2 Auto Scaling — EC2インスタンスキャパシティの伸縮
AWS Lambda — 同時実行と自動スケーリング
Amazon ECS — サービスの自動スケーリング・キャパシティプロバイダー
Amazon EKS — Pod・EKS Auto Mode
AWS Fargate — ECSタスク / EKS Pod用コンピューティング
AWS App Runner — ウェブサービスと自動スケーリング
AWS Batch — ジョブキューとコンピューティング環境
AWS App Runner — availability change / ECS Express Modeへの移行
Amazon ECS Express Mode — コンテナウェブアプリケーションの簡易デプロイ

理解確認

このページの内容を7問で確認します。

理解確認7問へ →