2026-08-17（月）EC2, EBS, ELB, Auto Scaling

1. 【この範囲の全体像】

本範囲（第3章3-1・3-4、p.54-55, 72-76）は、AWSにおける主要な「コンピューティングモデル」のアーキテクチャの分類と、近代的なアプリケーション開発の主流である「コンテナ（Docker）環境」の設計・運用を扱います [p.54, p.72]。

IaaSである「EC2」、コンテナオーケストレーションの「ECS」、サーバーレスの「Lambda」それぞれの設計思想と使い分け [p.54-55]、そしてECSにおける論理コンポーネントの階層構造（タスク定義、サービス、タスク、クラスター） [p.73-74]、ホスト管理を不要にする「AWS Fargate」のサーバーレスコンテナの必然性を深く理解することは、システムの「弾力性（スケーラビリティ）」や「運用上の優秀性」を評価する試験問題で確実に得点を稼ぐための防衛ラインです [p.8, p.74]。

2. 【重要キーワード・サービス一覧】

キーワード	説明
Amazon EC2 (Elastic Compute Cloud) [p.54]	OSレベルからユーザーが自由に管理・構成できる、IaaS（Infrastructure as a Service）型の仮想サーバーサービス [p.54]。
Amazon ECS (Elastic Container Service) [p.54, p.72]	Dockerコンテナ化されたアプリケーションをAWS上で簡単に起動、停止、管理（オーケストレーション）できるフルマネージドサービス [p.72]。
AWS Lambda [p.54]	サーバーのプロビジョニングや管理を一切行うことなく、プログラムコードを登録するだけでイベント駆動で実行できるサーバーレスコンピューティングサービス [p.54, p.77]。
タスク定義 (Task Definition) [p.73, p.74]	コンテナイメージ、割り当てるCPU・メモリ、ポートマッピング、環境変数などの「コンテナの設計図（仕様書）」をJSON等で記述した設定オブジェクト [p.73, p.74]。
タスク (Task) [p.73, p.74]	タスク定義に基づいてクラスター上で実際に起動された「コンテナの実体（稼働している仮想プロセス）」 [p.73, p.74]。
サービス (Service) [p.74]	タスク定義で指定されたタスクを、指定された数（例：常時3タスク）だけ維持・実行し、ELB（ロードバランサー）と自動連携してトラフィックを分散・制御する管理コンポーネント [p.74]。
クラスター (Cluster) [p.73, p.74]	コンテナ（タスク）を実行するためのコンピューティングリソース（EC2やFargateなど）を論理的にまとめた「器（実行グループ）」 [p.73, p.74]。
AWS Fargate [p.74]	ホストとなるEC2インスタンスの調達、OS管理、パッチ適用、スケーリングといったインフラ管理を完全にAWSへオフロードし、コンテナ（タスク）を「直接サーバーレスに実行」できるマネージド起動タイプ [p.74, p.75]。
Amazon ECR (Elastic Container Registry) [p.75]	コンテナイメージを安全に保存、管理、デプロイするためのAWS上のフルマネージドなレジストリサービス [p.75]。IAMポリシーによるpush/pull権限管理が可能です [p.75]。
AWS Batch [p.75]	大規模なバッチ計算ジョブを効率的に管理・自動実行するためのオーケストレーションサービス [p.75]。処理の実体（コンピューティング資源）として、ECSのEC2タイプまたはFargateタイプを自動調達して実行します [p.75]。

3. 【試験で問われる比較ポイント】

試験では、アプリケーションの特性や運用の制約条件に応じて、適切なコンピューティングモデルを選択できるかが問われます [p.54-55, p.74-75]。

① コンピューティング3大モデルのアーキテクチャ比較 [p.54-55]

比較項目	Amazon EC2 [p.54]	Amazon ECS (on Fargate) [p.54, p.74]	AWS Lambda [p.54, p.80-81]
アーキテクチャ分類	IaaS (Infrastructure as a Service) [p.54]。	CaaS (Container as a Service) / サーバーレスコンテナ [p.54, p.74]。	FaaS (Function as a Service) / 完全サーバーレス [p.54, p.77]。
管理・所有権の境界	最も広い。ゲストOSのアップデート、ミドルウェアの設定、セキュリティパッチの適用はすべてユーザーの責任 [p.59]。	狭い。OSやホストの管理はAWS。ユーザーは「Dockerコンテナのパッケージング」とアプリコードの維持管理のみ [p.72, p.74]。	最も狭い。インフラ管理は完全に隠蔽。ユーザーは「プログラムの関数コード」のみを管理 [p.54, p.77]。
スケーリングスピード	分単位（新しいサーバーOSがブートする時間がかかる）。	秒単位（すでに用意されたFargateホスト上でコンテナがスピンアップ） [p.74]。	ミリ秒単位。リクエストの流入に応じて、完全に自動でスケールアウト・並列実行 [p.81]。
最大実行制限時間	なし（サーバーが起動している限り永続稼働可能）。	なし（Webアプリなどの常時稼働プロセスにも適合） [p.74]。	最大15分（15分を超える重いバッチや常時接続プロセスは実行不可） [p.80]。
試験での選択指標	OS固有のカーネル変更、ライセンス製品の持ち込み、または既存のオンプレ環境からの単純移行（Lift & Shift） [p.42]。	Webアプリやコンテナ化されたマイクロサービス群の、インフラ管理を排した安定的かつ柔軟な運用 [p.72]。	急激なスパイクアクセスへの対応、画像アップロードを契機とする「イベント駆動バッチ処理」、Web APIの超軽量実行 [p.78]。

② ECS起動タイプの比較：EC2起動タイプ vs Fargate起動タイプ [p.74-75]

ホストとなる「EC2（仮想サーバーの箱）」を、ユーザーが管理するかAWSに完全に任せるかのトレードオフです [p.74-75]。

比較項目	EC2 起動タイプ [p.74, p.75]	Fargate 起動タイプ [p.74, p.75]
物理ホストの所有	あり。ユーザーのVPC内にEC2インスタンスが起動し、その上でDockerデーモンが走る [p.74]。	なし。ユーザーのVPC内にはEC2はデプロイされず、AWSの管理スペースで実行 [p.74, p.75]。
ホストのスケーリング	EC2自体のスケーリング（台数管理）と、コンテナ（タスク）のスケーリングの「二重管理」が必要。	コンテナ（タスク）の希望数を指定するだけで、ホスト側の容量は自動的にスケーリング [p.75]。
課金対象	コンテナが動いているか否かに関わらず、「起動しているEC2サーバーの時間料金」に対して固定課金 [p.59]。	コンテナ（タスク）が実際に起動している間にアサインされた「vCPUとメモリ量」に対しての秒単位課金 [p.75]。
試験での選択基準	「既存のEC2リザーブドインスタンスやSavings Plansの余剰コミットメントを流用してコンテナを最安で動かしたい」場合。	「OSのセキュリティパッチ適用などのサーバーメンテナンス運用負荷（運用オーバーヘッド）を100%ゼロに抑えたい」場合。

4. 【ひっかけ注意ポイント】

ひっかけ①：ECSクラスター上で実行する複数のコンテナタスク（Webサーバータスク、S3ログアップロードタスク等）に対して、それぞれのタスクがAWSリソースへ安全にアクセスできるよう、ホストとなっているEC2インスタンスに「強力な権限（S3へのフルアクセス等）を付与したIAMロール（インスタンスプロファイル）」をアタッチする。
- 真実: これはセキュリティガバナンスにおける重大なアンチパターンです [p.74]。ホストEC2に過剰な権限を持たせてしまうと、同じホスト上で稼働する「本来S3に触るべきではない無関係なコンテナ（例: Redisタスク）」からも、ホストの資格情報が盗用・悪用可能となってしまいます [p.74]。
- 解決理由: AWSのセキュリティベストプラクティス（最小権限の原則）に基づき、ホストEC2には権限を与えず、「タスク定義（Task Definition）」の中に、個々のタスク専用の「IAMタスクロール（Task Role）」を個別にマッピングしてアタッチします [p.74]。これにより、同一のEC2インスタンス上で動作していても、コンテナ（タスク）ごとに厳密に隔離された安全な認可境界が確立されます [p.74]。
ひっかけ②：ミリ秒単位で処理されるWebリクエストや、時々発生する短いデータ検証APIを最もコスト効率良く実装するため、常時稼働させる「Amazon ECS on AWS Fargate」をプロビジョニングし、ELB配下でタスクの最小起動数を「2」に固定マッピングする。
- 真実: Fargateはホスト管理が不要な便利なサーバーレスですが、コンテナが「起動して待機している時間」に対しても定常的にvCPU・メモリの課金が秒単位で発生し続けます [p.75]。リクエストが全く来ない夜間でもタスクが2台立ち上がっている限り、無駄なアイドルコストを払い続けることになります [p.75]。
- 解決理由: 「リクエストが来た時だけミリ秒〜数秒単位でコードを動かしたい（イベント駆動）」、かつ「待機中のアイドルコストを完全にゼロに削減したい」という要件シグナルに対しては、コンテナを常時待機させるECSではなく、実行時のみ完全従量課金される「 AWS Lambda 」を適用するのが絶対的なアーキテクチャの正解パターンです [p.54, p.81]。
ひっかけ③：AWS Batchにおいて、一連の並列バッチ処理ジョブを実行する際、ジョブAが正常終了したことをトリガーにしてジョブBとジョブCを並行実行し、双方の完了を待ってジョブDを実行するような複雑な「タスク依存関係（ワークフロー）」を構成するため、AWS Batchの定義ファイルの中に独自のShellスクリプトやcronコマンドを埋め込んで密結合に同期制御する。
- 真実: AWS Batch自体はジョブキュー管理やコンピューティングリソース（ECS等）を効率調達して処理を実行する能力に優れていますが、Batch単体のスクリプトのみで複数の複雑なジョブの依存関係、エラー時の再試行（リトライ）、および並行プロセスの合流を構築しようとすると、スパゲッティコード化して運用が破綻します [p.75]。
- 解決理由: 複数のジョブの動的な実行順序やエラーハンドリングといったオーケストレーション（ワークフロー制御）は、バッチ定義内にハードコードするのを避け、サーバーレスなワークフロー管理サービスである「 AWS Step Functions 」をAWS Batchの前段にマッピングして密結合を避ける（疎結合化する）のがAWSの絶対的な設計ベストプラクティスです [p.75, p.225]。