週3EC2 / EBS / ELB / Auto Scaling

2026-08-19（水）EC2, EBS, ELB, Auto Scaling

この記事の目次
  1. この範囲の全体像
  2. 重要キーワード・サービス一覧
  3. 試験で問われる比較ポイント
  4. ひっかけ注意ポイント
  5. 一問一答セルフテスト

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

本範囲は、AWSにおけるストレージ設計の基本分類である「ブロック」「ファイル」「オブジェクト」の違いを整理し [p.86, p.87]、EC2に直結する高性能ブロックストレージ Amazon EBS の性質を深く理解する極めて重要なセクションです [p.88]。

試験では、システムのI/O要件（IOPS重視かスループット重視か）やコスト制約に合わせて最適なボリュームタイプ（SSD系・HDD系）を選定するロジカルな判断力が問われます [p.89-91]。

さらに、EBS特有の「同一AZ（アベイラビリティゾーン）内制限」や「容量縮小不可ルール」などの物理制約を、スナップショット等を駆使していかに安全に解決（マイグレーションや暗号化）するかという実務応用力が合格への合否境界線となります [p.88, p.92, p.93]。

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

キーワード 説明
ブロックストレージ (Amazon EBS) [p.86, p.88] データを固定サイズのブロック単位で管理し、OSの起動領域（ルートボリューム）やデータベースのデータ格納領域など、極めて低遅延かつ高頻度な読み書きが求められる用途に使用するストレージ [p.86, p.88]。
ファイルストレージ (Amazon EFS / Amazon FSx) [p.87] ネットワークを介して複数のEC2インスタンスから同時にマウントし、ディレクトリ階層構造でファイルをリアルタイム共有できる共有ストレージ [p.87]。
オブジェクトストレージ (Amazon S3) [p.87] データを「バケット」にオブジェクト単位で平坦に保存する、耐久性「99.999999999%」を誇るインターネット向けの極めて安価な大容量ストレージ [p.87, p.101, p.102]。
AZ（アベイラビリティゾーン）制限 [p.88] EBSボリュームは特定の1つのAZ内に作成され、同じAZ内でしかEC2インスタンスにアタッチ（接続）できないという強固な物理制約 [p.88]。
汎用SSD (gp2 / gp3) [p.89] 一般的なシステム起動や本番環境で最も選ばれるSSDボリューム [p.89]。旧世代のgp2は容量に比例してIOPS（性能）が決まりましたが、新世代のgp3は容量と関係なくIOPSやスループットを個別指定してコストを最適化可能です [p.89]。
プロビジョンドIOPS SSD (io1 / io2) [p.90] 最高クラスのスループットと、ミリ秒未満の極めて安定した高IOPSが必要な、大規模かつ高負荷なリレーショナルデータベース専用の高性能SSD [p.90, p.91]。
スループット最適化HDD (st1) [p.90] シーケンシャル（連続的）なデータの読み書き転送速度（MB/秒）を重視した安価なHDD。DWH、ビッグデータバッチ、ログ解析処理などに最適 [p.90, p.91]。
Cold HDD (sc1) [p.90] データアクセス頻度が極めて低いものの、テラバイト級の大容量データを限界まで低コストで長期保持したい場合に選ばれる最安のHDD [p.90, p.91]。
EBSスナップショット [p.88, p.93] EBSボリュームの特定時点のデータを、Amazon S3に増分バックアップ（リージョン単位で管理）として保存する機能 [p.88, p.93]。別AZへの複製や暗号化移行のマスターデータとなります [p.88, p.93]。

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

① ユースケース別：EBSボリュームタイプの決定境界 [p.89-91]

ボリュームタイプ 性能の評価指標 最適なユースケース [p.91] 決定的な選定シグナル（試験上のキーワード） [p.91]
汎用SSD (gp3) [p.89] IOPS ＆ スループット システム起動（OS領域）、Webサーバー、開発/テスト環境 [p.89, p.91] 🎯 「 一般的な本番・検証環境において、サイズを大きくすることなく、低コストでベースライン以上のI/O性能（3,000 IOPS）を確保したい 」 [p.89]
プロビジョンドIOPS SSD (io2) [p.90] 任意の超高IOPSを指定 瞬間的なアクセスが超激しい基幹データベース（Oracle, SQL Server等） [p.90, p.91] 🎯 「 ミリ秒未満の極小遅延が必須であり、gp3の上限（16,000 IOPS）を超える、極めて安定した超高I/Oパフォーマンスを求められるデータベース 」 [p.90, p.91]
スループット最適化HDD (st1) [p.90] スループット（MB/秒） ビッグデータ処理、DWH、ログ収集・解析システム、巨大ファイルの連続読み込み [p.90, p.91] 🎯 「 細かなアクセス回数（IOPS）は問わないが、数百GB〜テラバイト級の巨大な連続ファイルをバッチで一気に読み込む処理を、極力安価なHDDで運用したい 」 [p.90, p.91]
Cold HDD (sc1) [p.90] スループット（最低限） アクセス頻度の極端に低いデータ、バックアップ目的のアーカイブ [p.90, p.91] 🎯 「 I/O性能は低くても構わないため、アクセス頻度の低いデータをとにかくEBS内で最安値で保管したい 」 [p.91]

② 共有範囲の決定境界：EBS vs EFS vs S3 [p.86, p.87, p.88]

比較項目 Amazon EBS (ブロック) [p.86, p.88] Amazon EFS (ファイル) [p.87] Amazon S3 (オブジェクト) [p.87]
同時接続の最大数 原則「1台のEC2」 にのみ直結マウント（AZ物理制限あり） [p.88]。 「 数千台のLinuxインスタンス 」 から同時にネットワーク経由でマウント共有可能 [p.87]。 インターネット（REST API）を介して全世界・無制限に同時アクセス可能 [p.87, p.101]。
拡張性の特性 オンライン拡張は可能だが、容量縮小は絶対にできない（上限16TB） [p.92]。 容量上限はなく、データの増減に合わせて全自動で無制限にスケールアップ/ダウン [p.87, p.95]。 容量制限はなく、バケット内に無限にオブジェクトを格納可能 [p.87, p.101]。
決定的な選定シグナル 🎯 「 OSブート領域や、1対1で超高速な物理読み書きを行うRDBのデータディスク 」 [p.86, p.88] 🎯 「 Auto Scalingで自動増減する多数のWebサーバー間で、同じプログラムコードや画像ファイルを安全にマウント共有したい 」 [p.68, p.87] 🎯 「 動画、静的Webアセット、ログファイルを、最も安価にかつ11ナインの超高耐久性で長期保持したい 」 [p.87, p.101]

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

  • ひっかけ①：障害対策として「別AZのEC2に、既存のEBSを直接マウントし直す」手順を正解とする罠 [p.88]

    • 罠: 「アベイラビリティゾーン ap-northeast-1a のWeb用EC2が突然物理障害で停止した。復旧のため、別の健全なAZ ap-northeast-1c に新しいEC2インスタンスを即時デプロイし、被災した ap-northeast-1a の既存EBSボリュームをオンラインデタッチして、新EC2に直接アタッチし直してシステムを再開した。」
    • なぜ間違いか: EBSボリュームは物理的に「特定のアベイラビリティゾーン（AZ）」の内部に固着して作成されます [p.88]。AZをまたいで別空間にいるEC2に直接ネットワークマウントすることは物理仕様上100%不可能です [p.88]。
    • 正しいベストプラクティス: まず停止したEBSから 「 EBSスナップショット 」 を取得します [p.88, p.93]。スナップショットはリージョンレベル（裏側はS3）に保存されるため、復旧先である ap-northeast-1c を指定してスナップショットから新規EBSボリュームをプロビジョニング作成し、新しいEC2にアタッチするステップを選択するのが絶対の正解です [p.88]。

  • ひっかけ②：コスト最適化のために「既存EBSボリュームのオンライン容量縮小（Elastic Volumes）」を実行させる罠 [p.92]

    • 罠: 「長期間運用していたデータベース用EBSボリューム（gp3）のデータ整理を行い、実容量が半分以下になった。インフラ費用を今すぐ節約するため、EBSのオンラインボリューム変更機能を用いて、ボリュームサイズ設定を 1TB から 500GB へと縮小変更し、即時適用した。」
    • なぜ間違いか: EBSの「Elastic Volumes（オンライン容量変更）」は、サーバーを停止することなくボリュームタイプ変更や容量の「拡張（拡大）」を可能にしますが、「容量の縮小（縮小変更）」はシステムデータ保全の制約上、1GBたりとも絶対にできません [p.92]。
    • 正しいベストプラクティス: 縮小が必要な場合は、新規に必要な小さいサイズ（500GBなど）のEBSボリュームを別途新規作成し、EC2インスタンスに追加アタッチしてOSレベルでデータを手動コピー（移行）した上で、古い大きなEBS（1TB）を切り離して削除する二段階移行を設計する必要があります。

  • ひっかけ③：稼働中の非暗号化EBSを「ボタン一つで直接オンライン暗号化」できるとする罠 [p.93]

    • 罠: 「社内セキュリティ要件の改定により、現在稼働している非暗号化のEC2起動用ボリューム（EBS）を暗号化する必要が生じた。そのため、EC2を稼働させたままAWSマネジメントコンソールのEBS設定画面を開き、対象ボリュームの『暗号化を有効化』にチェックを入れて直接上書き適用した。」
    • なぜ間違いか: すでに「非暗号化」で作成されて稼働しているEBSボリュームの設定を、後からオンラインのまま直接「暗号化有効」に一発設定変更する機能はAWS上に存在しません [p.93]。
    • 正しいベストプラクティス: 安全に暗号化移行を完了させるために、以下の4ステップを踏む手順を選択します [p.93]。
      1. 稼働中の非暗号化EBSの 「スナップショット」を取得 する [p.93]。
      2. 取得したスナップショットを 「暗号化を有効」にチェックを入れてコピー（複製） する [p.93]。
      3. その暗号化済みのコピーから 「新規暗号化EBSボリューム」を作成 する [p.93]。
      4. EC2を停止し、古い非暗号化ボリュームを切り離して、新たに作成した暗号化済みボリュームへとマウントを差し替えて再起動する [p.93]。

5. 【一問一答セルフテスト】

選択肢を選ぶと、その場で正誤と解説が表示されます。