2026-08-18（火）EC2, EBS, ELB, Auto Scaling
1. 【この範囲の全体像】
本範囲（第3章3-5、p.77-84）は、サーバーの調達やパッチ当てといったインフラ管理を完全に不要にする、AWSのサーバーレス設計の中核をなす 「 AWS Lambda（ラムダ） 」 を扱います [p.54, p.77]。
ミリ秒単位の完全従量課金体系 [p.81]、および他のAWSサービスとの「イベント駆動（トリガー起動）」の連携設計パターンを理解すること、そしてメモリ・タイムアウト・実行ロール・VPC設定などの各種パラメータを要件にマッピングする能力は [p.77-78, p.80-81]、試験で極めて配点比率の高い「スケーラブルなアーキテクチャの設計」や「セキュアな設計」において欠かせない絶対的な得点源となります [p.6, p.81]。
2. 【重要キーワード・サービス一覧】
| キーワード | 説明 |
|---|---|
| AWS Lambda | サーバーの構築や維持管理を一切意識することなく、プログラムコードのみを用意して登録するだけでイベント発生時に動的に実行される、完全サーバーレスなコンピューティングサービス [p.54, p.77]。 |
| イベント駆動 (Event-Driven) | Amazon S3へのデータ保存、DynamoDBテーブルの更新、API Gatewayへのリクエスト受信、Amazon EventBridgeの定期スケジュールなどの「イベント（トリガー）」を検知してプログラムを自動的に実行させる仕組み [p.77-79]。 |
| 実行ロール (Execution Role / IAMロール) | Lambda関数がS3バケット内のオブジェクト取得（GetObject）やDynamoDBへの書き込みなどを安全に実行できるよう、関数自体に割り当てる一時資格情報（IAMロール） [p.81, p.84]。 |
| メモリ割り当て量 (Memory Allocation) | Lambda関数の実行用に割り当てるメモリ容量（128MB〜10,240MB） [p.80, p.81]。割り当てたメモリ量に比例してCPUパワーが内部的に自動決定されます [p.81, p.84]。 |
| タイムアウト制限 (Timeout Limit) | 関数の最大処理時間の設定値。設定値（例：10秒）を超えると処理は強制遮断され、物理的な最大上限値は「15分（900秒）」に制限されます [p.80]。 |
| VPC設定 (Lambda in VPC / VPC外実行) | デフォルト（VPC外）ではLambdaからプライベートサブネット内のリソース（Amazon RDSなど）に通信できません。VPC設定を有効にして特定のサブネットとセキュリティグループを割り当てることで、プライベートリソースへのアクセスを確立する設計手法 [p.81]。 |
| 課金体系（GB-秒 ＆ リクエスト数） | 「リクエスト数（100万リクエストあたり0.20USドル）」および「関数の実行時間（割り当てメモリサイズと、1ミリ秒単位の処理時間の乗算値＝GB-秒）」の2点から算出される、アイドルコストが100%発生しない完全従量課金モデル [p.81]。 |
3. 【試験で問われる比較ポイント】
試験では、「 仮想サーバー（IaaS）」「サーバーレスコンテナ（CaaS）」「完全サーバーレス（FaaS） 」 のコンピューティング特性と運用境界線の使い分けが厳しく問われます [p.54, p.74, p.77]。
① コンピューティング3大モデルの設計比較 [p.54, p.74, p.77, p.80-81]
| 比較項目 | Amazon EC2 [p.54] | Amazon ECS (on Fargate) [p.74] | AWS Lambda [p.77] |
|---|---|---|---|
| 物理ホストOSの管理責任 | すべてユーザー（OSアップデート、パッチ適用） [p.59]。 | AWSが管理。ユーザーはDockerイメージのアップデートのみ [p.72, p.74]。 | AWSが100%管理。ユーザーはコードのアップロードのみ（運用負荷ゼロ） [p.77]。 |
| 起動・スケーリングの特性 | 分単位（サーバー起動に時間がかかる）。Auto Scalingポリシーの定義が必要 [p.68]。 | 秒単位。ECSサービス等を用いて一定の起動数管理が必要 [p.74, p.75]。 | ミリ秒単位。リクエストの急増に対して完全自動で即座に並列スケール [p.81, p.84]。 |
| 実行時間の制約・限界 | なし（サーバーを起動している限り永続的に稼働可能） [p.59]。 | なし（Webサイトや長時間の常時監視バッチ処理等も適合） [p.74]。 | 最大15分（900秒）まで。これを超える重いバッチや常時待機は実行不可 [p.80]。 |
| 基本の課金モデル | 起動している時間あたりの定額課金（停止中もEBS保管料金は継続） [p.59]。 | コンテナタスクが立ち上がっている時間とアサイン容量の従量課金 [p.75]。 | 完全従量課金（リクエスト数＋実行ミリ秒数）。リクエストがない時間はコストが完全ゼロ [p.81]。 |
| 試験での選択基準 | 「OSのカーネル変更が必要、または既存ライセンス製品を単純移行（Lift & Shift）したい」場合 [p.42]。 | 「OS管理負荷を極小化したいが、15分を超える常時Web稼働プロセスやコンテナ化アプリを維持したい」場合 [p.74]。 | 「 急激なアクセススパイクがある軽量API」「ファイル保存等をトリガーとする15分未満の自動バッチ処理 」 [p.78]。 |
4. 【ひっかけ注意ポイント】
ひっかけ①：Lambda関数の処理速度を向上させ、CPUバウンドな重いデータ暗号化処理を高速化するため、Lambda関数のコンソール設定パネルから「割り当てるvCPUコア数」のパラメータのみを明示的に「4」に増やして起動する。
- 真実: AWS Lambdaの設定項目には、「vCPUコア数」や「CPUパフォーマンス」を個別に直接指定・変更するパラメータは物理的に存在しません [p.81, p.84]。
- 解決理由: LambdaにおけるCPU演算能力は、「関数に割り当てたメモリの量」に比例して内部的に一元自動決定されます [p.81, p.84]。したがって、処理速度（CPU能力）を向上させたい場合の唯一のベストプラクティスは、割り当てる「メモリ量（Memory）」の設定値を大きく引き上げることです [p.81]。これにより、比例してCPU能力も自動的に増強されます [p.81, p.84]。
ひっかけ②：ミリ秒単位で突発的に発生する数十万ユーザーからの同時リクエスト（スパイクアクセス）に追従させるため、Lambda関数の前段に「Auto Scaling グループ」を構築し、CPU使用率をターゲットとした段階的なスケーリングポリシーを設定してマッピングする。
- 真実: AWS Lambdaは、EC2等で使用される Auto Scaling グループの傘下に配置して起動するような構成は行いません [p.84]。また、Lambda自身の動作としてスケーリングポリシーの追加定義も不要です [p.84]。
- 解決理由: Lambdaは、実行リクエスト数が増加すると、バックグラウンドのAWSインフラ側で自動的に並列コンテナインスタンスを新規立ち上げて完全に自動スケールアウトします [p.77, p.81, p.84]。ユーザーは自動スケーリングのためのポリシー設計や待機グループの定義といった管理工数を一切かける必要がありません [p.77, p.84]。
ひっかけ③：社内のデータ分析において、Amazon S3に蓄積される数十TBの生ログデータから特定のキーワード行を検索し、データベースへ書き出すバッチ処理をコスト最適化して自動化したい。このバッチ処理には最大で約30分間の連続実行時間がかかるため、イベント駆動で最も安価な「AWS Lambda」のみを使って実装する。
- 真実: Lambdaは物理仕様上の限界制限として、「1回の実行につき最大15分（900秒）」で処理がタイムアウトして強制シャットダウンされます [p.80]。
- 解決理由: どれほどメモリを大きく設定していても、15分を超える連続的なバッチジョブをLambda単体でスルー実行することはできません [p.80]。このような15分を超える処理要件（明確なタイムアウト制限のシグナル）が出た場合は、サーバーレスコンテナの 「 AWS Fargate（ECS） 」 を採用するか、バッチに特化した 「 AWS Batch 」 を起動タイプFargateでデプロイするのが正しいアーキテクチャ設計となります [p.74, p.75]。
5. 【一問一答セルフテスト】
選択肢を選ぶと、その場で正誤と解説が表示されます。