2026-08-20（木）EC2, EBS, ELB, Auto Scaling

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

本範囲（第3章コンピューティング＆第4章EBS）は、AWSにおけるシステムインフラの「3大構成要素（コンピューティング、負荷分散・自動スケーリング、永続ブロックストレージ）」を最適に組み合わせる設計力を扱います [p.54, p.66, p.88]。

高可用性と弾力性を担保するマルチAZ配置の設計原則 [p.70]、急激なアクセススパイクやサーバーフリーズに対処するELBとAuto Scalingの自己修復（セルフヒーリング）連携 [p.68-69]、そしてアクセス特性（IOPS、スループット、容量）に応じて最適なEBSボリュームタイプを選択し、オンラインで動的変更・保護するブロックストレージ設計が試験の最頻出ポイントです [p.89, p.92-93]。

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

キーワード	説明
Amazon EC2 (Elastic Compute Cloud) [p.54]	OSレベルから自由に管理・運用可能な、従量課金制の仮想サーバーサービス [p.54, p.56]。
Amazon EBS (Elastic Block Store) [p.88]	EC2インスタンスに1対1（基本）でアタッチして使用する、高可用・低遅延な不揮発性のブロックストレージ（仮想物理ディスク） [p.88]。
Elastic Load Balancing (ELB) [p.66-67]	流入するWebトラフィックを、複数のアベイラビリティゾーン（AZ）に分散配置された複数のターゲット（EC2等）へ自動的に均等配分するロードバランサー [p.67, p.70]。
Application Load Balancer (ALB) [p.67]	HTTP/HTTPS（L7レイヤー）通信の制御に特化し、URLパスやホスト名に応じた高度なコンテキストルーティングを処理するバランサー [p.67]。
Network Load Balancer (NLB) [p.67]	TCP/UDP/TLS（L4レイヤー）通信に特化し、ミリ秒以下の極小遅延で秒間数百万の超高負荷アクセスを処理でき、かつ固定IPを保持できるバランサー [p.67]。
Auto Scaling [p.68]	CPU使用率などのしきい値をトリガーとして、あらかじめ指定したインスタンス数の範囲内（最小・最大）で、EC2の台数を完全に自動で水平スケーリング（増減）させる機能 [p.68]。
ヘルスチェック (Health Check) [p.68]	ELBが配下のEC2に対して定期的にリクエストを送り、応答のない「異常（Unhealthy）」なサーバーを配分対象から自動除外する生存監視システム [p.68]。

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

① EBSボリュームタイプの使い分け（gp3 vs io2 vs st1 vs sc1） [p.89-91]

「SSDかHDDか」「要求されるのは入出力回数（IOPS）か、シーケンシャルな最大速度（MB/秒）か」でマッピングします [p.91]。

ボリュームタイプ [p.89, p.90]	メディア [p.89]	最大IOPS / ボリューム [p.91]	最大スループット / ボリューム [p.91]	試験での決定的な選定シナリオ（なぜ選ぶのか）
汎用SSD (gp3)	SSD	16,000 [p.91]	1,000 MB/秒 [p.91]	「最も標準的なブートドライブ（OS起動領域）、開発・テスト環境、一般的なデータベース」。ボリューム容量を増やさずとも、IOPSとスループットを個別に最小コストで引き上げ可能 [p.89]。
プロビジョンドIOPS SSD (io2 / io2 Block Express)	SSD	64,000 (io2) ※Block Expressはさらに高速 [p.90, p.91]	1,000 MB/秒 [p.91]	「極めて高いI/O処理能力とミリ秒未満の応答性が要求される、本番環境のミッションクリティカルな大規模データベース（SQL Server、Oracle、PostgreSQL等）」 [p.90]。99.999%の極めて高い耐久性を提供 [p.90]。
スループット最適化HDD (st1)	HDD	500 [p.91]	500 MB/秒 [p.91]	「大容量データのシーケンシャルアクセス（順次読み書き）を重視する、ビッグデータ、EMR/MapReduce、データウェアハウス、大容量のログ解析バッチ」 [p.90]。ブートボリューム（OS起動用）としては使用不可 [p.91]。
コールドHDD (sc1)	HDD	250 [p.91]	250 MB/秒 [p.91]	「アクセス頻度が極めて低い大規模データ、バックアップ、アーカイブ保管用の格安ディスク要件」 [p.90]。容量単価が最も安いが、パフォーマンスは最低限 [p.90]。ブート不可 [p.91]。

② ロードバランサーの使い分け（ALB vs NLB） [p.67]

比較項目	Application Load Balancer (ALB) [p.67]	Network Load Balancer (NLB) [p.67]
動作レイヤー	L7（アプリケーションレイヤー） [p.67]。	L4（トランスポートレイヤー：TCP/UDP/TLS） [p.67]。
ルーティング機能	HTTPのURLパス（例: `/images/*`）、ホストヘッダー、HTTPヘッダーベースでの高度な振り分けが可能 [p.67]。	ポート番号とプロトコル（TCP/UDP）のみによる、極めてシンプルな高速転送 [p.67]。
IPアドレス仕様	ロードバランサーに割り当てられるパブリックIPアドレスは動的に可変（接続には常にDNS名（FQDN）を使用） [p.67]。	各サブネットに「固定（EIP：Elastic IP）」のアドレスを直接アタッチして保持可能 [p.67]。
通信負荷への追従性	スパイクアクセス（テレビ放映や秒間の急増）に対しては、数分程度の段階的なスケーリング（必要に応じてプレウォーミング申請）を伴う [p.67]。	一切の遅延・事前申請なしで、突発的な秒間数百万リクエストに即座に自動追従 [p.67]。
主な用途シグナル	通常のWebサイト、Web API（マイクロサービス、パスベース分割など） [p.67]。	ネットワークアプライアンス、金融取引システム、固定IPのみを許可するファイアウォール越しからの接続要件 [p.67]。

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

ひっかけ①：「作成済みの非暗号化EBSボリュームがアタッチされているEC2インスタンスにおいて、データ保護基準を満たすため、EC2を停止することなく、ボリュームプロパティ画面から『暗号化：有効』に直接オンライン変更する。」
- 真実と解決策: すでに作成されたEBSボリュームの暗号化ステータスを、直接オンラインで「非暗号化 ➡ 暗号化」に切り替えることは物理仕様上一切不可能です [p.93]。
- 正しいベストプラクティス: 安全に暗号化を施すには、「 ① 該当EBSのスナップショットを取得」➡「② スナップショットを暗号化を有効にして別名コピー」➡「③ 暗号化されたスナップショットから新規EBSボリュームを復元」➡「④ 古いEBSをデタッチし、新規暗号化EBSをマウントし直す」という4つのステップを正確に辿る必要があります [p.93]。
ひっかけ②：「ディスクの容量不足を解消するためにEBSボリュームのサイズを拡張した後、直ちにOS内のファイルシステム側への認識処理を一切行わずにEC2への直接の読み書き処理を続行し、容量拡張プロセスを完了とする。」
- 真実と解決策: AWSコンソール上でEBSのサイズ（例: 100GB ➡ 500GB）をオンライン拡張しただけでは、接続しているEC2上のOS（Linux/Windows）は拡張された新規領域を「未割り当ての空き領域」として認識しているだけであり、利用可能なストレージとしては認識していません [p.92]。
- 正しいベストプラクティス: コンソール変更後、必ずEC2にリモートログインし、OS固有のコマンド（Linuxであれば resize2fs や xfs_growfs など）を直接手動実行して、「ファイルシステム自体の拡張処理（マウント認識）」を完了させる必要があります [p.92]。なお、EBSボリュームはオンラインで「拡張（大きくする）」ことは可能ですが、「縮小（小さくする）」することは一切できません [p.92]。