週3EC2 / EBS / ELB / Auto Scaling
2026-08-21（金）EC2, EBS, ELB, Auto Scaling
1. 【この範囲の全体像】
第3章は、AWSのコアサービスである仮想サーバー（Amazon EC2）、ブロックストレージ（Amazon EBS）、負荷分散（ELB）、および自動伸縮（Auto Scaling）について、インフラ設計の基本原理を網羅する最重要領域です [11, p.53, p.54, p.66, p.88]。
システムが単一障害点（SPOF）を排除し、アクセス増減に自動対応して自己回復する「高可用性」と「弾力性」をいかに確立するかが共通のテーマとなります [11, p.66, p.69, p.291]。
試験では、単純なサービスの仕様暗記ではなく、コスト効率、パフォーマンス、可用性のトレードオフを論理的に判断してベストプラクティスを設計する応用力が厳格に試されます [11, p.60, p.67, p.300]。
2. 【重要キーワード・サービス一覧】
| キーワード | 説明 |
|---|---|
| Amazon EC2 (Elastic Compute Cloud) [11, p.56] | 必要なときに数秒から数分で柔軟に構築・起動できる、完全に請求が使用した分だけの従量課金制となる仮想サーバーサービス（IaaS）です [11, p.56]。 |
| スポットインスタンス (Spot Instance) [11, p.60] | AWS上の余剰コンピューティング容量を利用し、オンデマンド料金から最大90%引きの圧倒的な低コストで利用できるインスタンス起動オプションです [11, p.60]。ただし、AWS側の需要により2分前に警告されて強制終了する可能性があるため、ステートレスなバッチや処理の中断が許容できるワークロードに限定して設計します [11, p.60, p.83]。 |
| Savings Plans (SP) / リザーブドインスタンス (RI) [11, p.60, p.61] | 1年または3年の期間、一定のコンピューティング使用量をコミット（契約）することで、オンデマンドに比べ最大72%の割引が適用されるコスト最適化オプションです [11, p.60, p.61]。 |
| インスタンスメタデータ (IMDSv2) [11, p.62] | 起動中のEC2インスタンス内部からのみHTTPリクエスト経由で参照可能な、インスタンス自身の構成情報（プライベートIP、インスタンスID、セキュリティグループ、アタッチされているIAMロールの認証情報など）を取得する安全な仕組みです [11, p.62]。 |
| ユーザーデータ (User Data) [11, p.62] | EC2の初回起動時にのみ全自動で強制実行されるシェルスクリプトや初期化設定用の機能です [11, p.62]。パッケージのアップデートやミドルウェアのインストールなど、起動時のデプロイ自動化に用います [11, p.62]。 |
| プレイスメントグループ (Placement Group) [11, p.63] | EC2インスタンスを物理ハードウェア上でどのように配置するかを決定する論理的な設定グループです [11, p.63]。遅延を極小化する「クラスター」、障害に備えてラックを分離する「スプレッド」、複数ラックグループに分散する「パーティション」の3つがあります [11, p.63]。 |
| Application Load Balancer (ALB) [11, p.67] | OSI参照モデルのレイヤー7（アプリケーション層）で動作し、HTTP/HTTPSリクエストのパス（例：/images/*）やホスト（例：api.domain）に基づいて、指定されたターゲットグループへトラフィックを柔軟に振り分けることができるロードバランサーです [11, p.67]。 |
| Network Load Balancer (NLB) [11, p.67] | OSI参照モデルのレイヤー4（トランスポート層）で動作し、TCP/UDPプロトコルに基づく超高スループット・超低遅延な負荷分散を行います [11, p.67]。プレウォーミングなしで秒間数百万の突発的なアクセススパイクに対応可能で、静的IPアドレス（Elastic IP）をバランサーにアタッチして接続先を固定できます [11, p.67, p.169]。 |
| Amazon EC2 Auto Scaling [11, p.68] | CPU使用率などの負荷アラームに応じてEC2の台数を自動的に水平スケーリング（増減）させ、常に適正なパフォーマンスと低コストを維持する伸縮自在な設計を実現するサービスです [11, p.68]。異常が発生したインスタンスをヘルスチェックで検知して自動で破棄・再作成する自己修復（セルフヒーリング）機能も備えています [11, p.68, p.69]。 |
| Amazon EBS (Elastic Block Store) [11, p.88] | EC2にアタッチしてOS起動（ルートボリューム）やデータベースのデータ領域として1対1で利用する、高パフォーマンスで低遅延なブロックストレージです [11, p.86, p.88]。作成されたアベイラビリティゾーン（AZ）の物理的な境界に制限されるため、同じAZのEC2にしかアタッチできません [11, p.88]。 |
3. 【試験で問われる比較ポイント】
① 要件に応じた「EC2購入オプション」の選定境界 [11, p.60, p.61, p.301]
| 購入オプション | 割引率と特徴 [11, p.60, p.61] | 中断リスク [11, p.60] | 決定的な選定シグナル（試験の頻出キーワード） [11, p.61, p.301] |
|---|---|---|---|
| オンデマンド [11, p.60] | 割引なし（標準料金）。秒単位の完全従量。 | なし | 🎯 「 短期の予測不可能なテスト、仕様検証、または開発時の一時ジョブ実行 」 |
| Savings Plans [11, p.61] | 最大 72% 割引（通年で常時稼働する本番インフラに最も柔軟） [11, p.61]。 | なし | 🎯 「 24時間365日常時起動し、数年間利用し続けることが決定している最小ベースライン（本番環境） 」 [11, p.61, p.301] |
| スポットインスタンス [11, p.60] | 最大 90% 割引（圧倒的な最安コスト） [11, p.60]。 | あり（2分前の猶予通知で強制回収） [11, p.60]。 | 🎯 「 いつでも処理を中断・再開でき、複数ノードで並列実行可能なバッチ処理やビッグデータ解析、テスト環境 」 [11, p.60, p.83] |
② ネットワークおよびプロトコル特性に基づく「ELB」の選定境界 [11, p.67]
| 比較項目 | Application Load Balancer (ALB) [11, p.67] | Network Load Balancer (NLB) [11, p.67] |
|---|---|---|
| 対応レイヤー | レイヤー7（L7） （HTTP / HTTPS / HTTP/2） [11, p.67]。 | レイヤー4（L4） （TCP / UDP / TLS） [11, p.67]。 |
| 高度なルーティング | パス（/api/*）やホスト（shop.domain）に基づく振分対応 [11, p.67]。 |
ポートおよびトランスポートプロトコルによる単純中継のみ。 |
| IPアドレスの固定 | 不可（負荷に応じてバランサーのIPが動的に増減・変化） [11, p.67]。 | 可能（「静的IPアドレス」や「Elastic IP」の割り当てに対応） [11, p.67, p.169]。 |
| スパイク負荷への耐性 | 急激なアクセス増加には自動スケーリングが追いつかず、事前申請（プレウォーミング）を推奨 [11, p.67]。 | プレウォーミングなしで秒間数百万リクエストの極端なアクセススパイクを瞬時に等速処理可能 [11, p.67]。 |
| 決定的な選定シグナル | 🎯 「 標準的なWebサイト、マイクロサービス間通信、Cookieによるセッション維持、高度なリクエスト分岐 」 [11, p.67] | 🎯 「 セキュリティ監査上、通信先のIPをあらかじめ固定（ホワイトリスト化）する必要がある場合や、金融システムなどの超低遅延処理 」 [11, p.67, p.169] |
③ 物理的な配置を制御する「プレイスメントグループ」の選定境界 [11, p.63]
| 配置戦略 [11, p.63] | 物理配置のルール [11, p.63] | ネットワーク遅延特性 [11, p.63] | 決定的な選定シグナル（試験の頻出キーワード） [11, p.63] |
|---|---|---|---|
| クラスター (Cluster) [11, p.63] | 単一のAZ内において、インスタンス同士を可能な限り物理的な同一ラック内に密集して配置する [11, p.63]。 | 極めて高速・超低遅延（広帯域ネットワーク） [11, p.63]。 | 🎯 「 HPC（高性能計算）、ビッグデータの高頻度な分散並列ノード間通信、超高速な計算バッチ 」 [11, p.63] |
| スプレッド (Spread) [11, p.63] | インスタンスを異なる物理ラック（電源やネットワークの異なる物理筐体）に完全に1台ずつ隔離してデプロイする [11, p.63]。 | 標準。 | 🎯 「 絶対に同じ物理ラックの物理故障（共倒れ）に巻き込まれたくない、少数の重要な基幹システム 」 [11, p.63] |
| パーティション (Partition) [11, p.63] | グループ内を論理的な「パーティション」に分割し、それぞれ異なるラックを共有しないように物理分散させる [11, p.63]。 | 標準。 | 🎯 「 Hadoop、Cassandra、Kafkaなどの、大規模な分散型レプリケーションシステムをハードウェア境界で隔離したい 」 [11, p.63] |
4. 【ひっかけ注意ポイント】
ひっかけ①：「クラスタープレイスメントグループ」を複数AZにまたがって展開し、マルチAZの高可用性を狙う罠 [11, p.63]
- なぜ間違いか: クラスタープレイスメントグループは、物理仕様上「単一のAZ内（可能な限り同一物理ラック付近）」にのみEC2を配置するルールです [11, p.63]。物理的な境界がある複数の異なるAZをまたいでクラスターを組むことはシステム制約上できません [11, p.63]。
- 正しい解決策: 高可用性（マルチAZ）を狙う場合は、プレイスメントグループを指定せず、Auto Scalingやロードバランサー（ALB）の機能を用いて、明示的に「複数の異なるサブネット（別AZ）」にインスタンスを均等配置する設計を選択してください [11, p.34, p.67, p.68, p.69]。
ひっかけ②：Auto ScalingグループでEC2が自動増減するシステムにおいて、セッションデータや共通ファイルを「各インスタンスのローカルディスク（EBS）」に保存する罠 [11, p.69]
- なぜ間違いか: Auto Scalingグループにおいて、EC2の台数は負荷に応じて動的に増減し、不要になったインスタンスは即座に破棄されます [11, p.68, p.69]。ローカルEBSにデータを保持する「ステートフル」な設計をしていると、破棄された瞬間にそのデータは完全消失します [11, p.59, p.69]。
- 正しい解決策: サーバー台数の増減がいつ起きても影響を受けないよう、Webサーバー群は一切状態を保持しない 「ステートレス（Stateless）」に設計します [11, p.69]。セッションデータは外部のインメモリキャッシュ（ElastiCache for Redis）やDynamoDBへ、共通の画像ファイルなどは共有ストレージ（Amazon EFSやS3）へと、必ずコンポーネントの外にデータを逃がして一括管理（デカップリング）させます [11, p.69, p.87, p.101, p.149, p.218]。
ひっかけ③：EC2インスタンス内部から自身のパブリックIPやインスタンスIDを取得するために、誤って「ユーザーデータ」を呼び出す罠 [11, p.62]
- なぜ間違いか: 「ユーザーデータ」は、初回起動時に一度だけ強制的に実行される初期化用スクリプトそのものを指します [11, p.62]。自身の稼働情報（IP、インスタンスID、一時セキュリティ認証など）を取得・参照するための機能境界は「ユーザーデータ」ではなく 「 インスタンスメタデータ (IMDSv2) 」 です [11, p.62]。
- 正しい解決策: 起動中のEC2インスタンス固有の稼働設定を正確に把握したい場合は、インスタンス内部から http://169.254.169.254/latest/meta-data/（リンクローカルアドレス）へHTTPアクセスを送信して、安全かつ確実に「インスタンスメタデータ」を読み取る設計を指定します [11, p.62]。
5. 【一問一答セルフテスト】
選択肢を選ぶと、その場で正誤と解説が表示されます。