EBS・インスタンスストア
Amazon EBS(Elastic Block Store)は、EC2 インスタンスにディスクとして接続するブロックストレージです。SAA では「性能要件からボリュームタイプを選ぶ」「インスタンスを止めたり消したりしたときにデータが残るか」「スナップショットで別の AZ やリージョンへ移す」問題がよく出ます。
ひとことで言うと: EBS は EC2 に差し込む「外付けディスク」、インスタンスストアは EC2 のサーバー本体に内蔵された「使い捨てのディスク」です。
たとえるなら、EBS はケーブルでつないだ外付け HDD なので、パソコンを買い替えても付け替えて使えます。インスタンスストアはパソコンの中のディスクなので、そのパソコンを手放すと中身も一緒になくなります。
このページで押さえる論点
EBS の基本
EBS ボリュームは、EC2 インスタンスから OS のディスクとして見えるブロックストレージ(データを決まった大きさのブロック単位で読み書きする方式)です。OS 領域(ルートボリューム)やデータベースのデータ置き場に使います。
- ボリュームは 1 つの AZ(アベイラビリティーゾーン)の中に作られ、同じ AZ のインスタンスにだけアタッチ(接続)できます。別の AZ で使いたいときは、スナップショットから新しいボリュームを作ります
- インスタンスとはネットワーク越しにつながる独立した部品です。インスタンスを停止しても、ボリュームのデータは残ります。インスタンスから切り離して、同じ AZ の別のインスタンスに付け替えることもできます
- ボリュームはサイズやタイプを後から変更できます(Elastic Volumes)
- 耐久性(データが失われにくさ)は、io2 Block Express が 99.999%、その他のタイプは 99.8〜99.9% です。S3 の 99.999999999% と比べると低いので、大事なデータはスナップショットでバックアップします
ボリュームタイプの選び方
ボリュームタイプは大きく SSD 系と HDD 系に分かれます。SSD は小さな読み書きをたくさんこなす性能(IOPS: 1 秒あたりの読み書き回数)が得意で、HDD は大きなデータを順番に読み書きする性能(スループット: 1 秒あたりに運べるデータ量)あたりの料金が安いのが特徴です。
| タイプ | 分類 | サイズ | 最大 IOPS | 最大スループット | 使いどころ |
|---|---|---|---|---|---|
| gp3 | 汎用 SSD | 1 GiB〜64 TiB | 80,000 | 2,000 MiB/秒 | 多くのワークロードの既定。ブートボリューム、開発環境、中規模の DB |
| gp2 | 汎用 SSD | 1 GiB〜16 TiB | 16,000 | 250 MiB/秒 | 旧来の汎用 SSD。IOPS がサイズに比例する |
| io2 Block Express | プロビジョンド IOPS SSD | 4 GiB〜64 TiB | 256,000 | 4,000 MiB/秒 | 高い性能と耐久性(99.999%)が必要な重要 DB |
| io1 | プロビジョンド IOPS SSD | 4 GiB〜16 TiB | 64,000 | 1,000 MiB/秒 | 一定の高い IOPS が必要な DB |
| st1 | スループット最適化 HDD | 125 GiB〜16 TiB | 500 | 500 MiB/秒 | ビッグデータ、ログ処理、データウェアハウスなど大きな連続読み書き |
| sc1 | Cold HDD | 125 GiB〜16 TiB | 250 | 250 MiB/秒 | アクセスが少ない大容量データを最安で |
st1 と sc1 はブートボリューム(OS を起動するディスク)に使えません。起動ディスクにできるのは SSD 系(と旧世代のマグネティック)です。HDD の IOPS は 1 MiB の大きな読み書きで数えた値なので、小さなランダムアクセスには向きません。
gp3 と gp2 の違い
- gp3: サイズに関係なく、ベースラインとして 3,000 IOPS と 125 MiB/秒が料金に含まれます。足りなければ、サイズとは別に IOPS(1 GiB あたり 500 IOPS まで、最大 80,000)とスループット(最大 2,000 MiB/秒)を追加料金で上乗せできます
- gp2: IOPS がサイズに比例します(1 GiB あたり 3 IOPS、最小 100、最大 16,000)。1 TiB 未満のボリュームは、I/O クレジットがある間だけ 3,000 IOPS までバースト(一時的に性能を上げること)できます
「性能を上げるためだけに gp2 の容量を大きくしている」状況なら、gp3 に変えて IOPS だけを指定したほうが安くなります。
プロビジョンド IOPS SSD(io1 / io2)は、必要な IOPS を指定して、その性能を安定して出すためのタイプです。問題文に「持続的に高い IOPS」「ミッションクリティカルな DB」「16,000 IOPS を超える」とあれば io2 Block Express が候補です(gp3 も 80,000 IOPS まで出せますが、耐久性 99.999% やさらに高い性能が必要なら io2)。
インスタンスストアとデータの残り方
インスタンスストアは、EC2 が動いている物理サーバー(ホスト)に直接つながったディスクです。ネットワークを経由しないので非常に高速ですが、データは一時的です。どのインスタンスタイプでも使えるわけではなく、インスタンスストアを持つタイプだけで使えます。
| 操作・出来事 | インスタンスストア | EBS |
|---|---|---|
| 再起動 | ✓ 残る | ✓ 残る |
| 停止・休止 | ✕ 消える | ✓ 残る |
| 終了 | ✕ 消える | DeleteOnTermination の設定しだい |
| インスタンスタイプの変更 | ✕ 消える | ✓ 残る |
| 基盤のディスク障害 | ✕ 障害が起きたディスクのデータは消える | — |
EBS ボリュームには DeleteOnTermination(インスタンスの終了と一緒にボリュームを削除するか)という属性があります。既定値は付け方によって違います。
- インスタンスの起動時に作られたルートボリューム → 既定で削除される
- 起動後にアタッチしたデータボリューム → 既定で残る
- 起動時に追加したデータボリューム → コンソールなら残る、CLI なら削除される
「インスタンスを終了してもルートボリュームのデータを残したい」なら、ルートボリュームの DeleteOnTermination を無効にします。
操作したあと、データは残る?
ストレージの種類と操作を選ぶと、データが残るかどうかと、その理由が表示されます。
※簡略化しています: DeleteOnTermination は既定値のまま(変更していない)と仮定しています。休止やインスタンスタイプの変更、ディスク障害は上の表で補っています。
インスタンスストアは、消えても困らないデータ、または複数のインスタンスに同じデータを複製しているデータに使います。「一時的なキャッシュ」「スクラッチデータ」「最高の I/O 性能が必要で、データは他で複製済み」といった問題文が目印です。
EBS マルチアタッチ
EBS は原則として 1 台のインスタンスにだけアタッチします。例外がマルチアタッチで、プロビジョンド IOPS SSD(io1 / io2)のボリュームを、同じ AZ にある Nitro System ベースのインスタンス最大 16 台に同時にアタッチできます。
ただし XFS や EXT4 などの通常のファイルシステムは、複数のサーバーからの同時書き込みを想定していません。マルチアタッチで使うには、クラスター対応のファイルシステムが必要です。「複数の EC2 からファイルを共有したい」だけなら、EBS ではなく EFS を選ぶのが基本です。
スナップショット
スナップショットは、EBS ボリュームのある時点のバックアップです。
- 増分: 2 回目以降は、前回から変更されたブロックだけを保存するので、時間と保存料金を抑えられます
- 保存先は Amazon S3 ですが、S3 バケットとして直接は見えません。EC2 のコンソールや API で操作します
- スナップショットはリージョン内の複数の AZ に複製されるため、どの AZ でもボリュームを復元できます。これが「EBS を別の AZ へ移す」方法です
- スナップショットを別のリージョンにコピーすれば、別リージョンでボリュームや AMI を作れます(災害対策・リージョン移行)
| 関連機能 | 何ができるか |
|---|---|
| EBS スナップショットアーカイブ | 90 日以上保存し、ほとんどアクセスしないスナップショットの保存料金を最大 75% 削減できる |
| 高速スナップショット復元(FSR) | スナップショットから作ったボリュームが、最初から完全な性能で使えるようにする(通常は初回アクセス時に遅くなる) |
| ごみ箱 | 誤って削除したスナップショットや AMI を、保持期間内なら元に戻せる |
| Amazon Data Lifecycle Manager | スナップショットの作成・保持・削除をスケジュールで自動化する |
| AWS Backup | EBS を含む複数のサービスのバックアップを一元管理する |
EBS の暗号化
EBS の暗号化は AWS KMS のキーを使います。暗号化したボリュームでは、保存されているデータ、インスタンスとボリュームの間でやり取りされるデータ、そのボリュームから作ったスナップショット、スナップショットから作ったボリュームがすべて暗号化されます。暗号化の処理はホスト側で行われるので、アプリケーションを変える必要はありません。
- 既定の暗号化: アカウントのリージョンごとに有効にでき、有効にすると新しく作るボリュームとスナップショットのコピーが必ず暗号化されます
- 暗号化されていない既存のボリュームを、そのまま暗号化することはできません。スナップショットを作成し、そこから暗号化した新しいボリュームを作ります(スナップショットを暗号化してコピーしてもよい)
- 暗号化したボリューム・スナップショットから、暗号化を外すことはできません
- 暗号化したスナップショットは公開(パブリック)できません。特定のアカウントとの共有はできます
問題文のキーワード → 選ぶべき答え
| 問題文によく出る言い回し | 選ぶべき答えと理由 |
|---|---|
| 「汎用」「コスト効率のよいブートボリューム」「サイズと別に IOPS を指定したい」 | gp3。3,000 IOPS・125 MiB/秒が標準で含まれ、IOPS とスループットを個別に追加できる |
| 「ミッションクリティカルな DB」「持続的に高い IOPS」「最高の耐久性」 | io2 Block Express(最大 256,000 IOPS、耐久性 99.999%) |
| 「ビッグデータ」「ログ処理」「大きな連続読み書き」「スループット重視で低コスト」 | st1(スループット最適化 HDD) |
| 「アクセス頻度が低い大容量データ」「最低コストのブロックストレージ」 | sc1(Cold HDD)。ブートボリュームには使えない |
| 「一時的なキャッシュ」「最高の I/O 性能」「消えてもよいデータ」 | インスタンスストア |
| 「インスタンスを終了してもルートボリュームを残したい」 | ルートボリュームの DeleteOnTermination を無効にする |
| 「EBS ボリュームを別の AZ で使いたい」 | スナップショットを作り、目的の AZ でボリュームを復元する |
| 「別リージョンで同じ環境を立ち上げたい」「災害対策」 | スナップショット(または AMI)を別リージョンへコピー |
| 「暗号化されていない既存ボリュームを暗号化したい」 | スナップショット → 暗号化したボリュームを作成(またはスナップショットを暗号化してコピー) |
| 「今後作るボリュームは必ず暗号化したい」 | リージョンの EBS の既定の暗号化を有効にする |
| 「スナップショットを定期的に作って古いものを消したい」 | Amazon Data Lifecycle Manager(または AWS Backup) |
| 「同じ AZ の複数インスタンスから 1 つのブロックボリュームに同時アクセス」 | io1 / io2 の マルチアタッチ(クラスター対応ファイルシステムが必要) |
引っかけポイント
- 「EBS ボリュームは同じリージョンのどの AZ のインスタンスにもアタッチできる」→ ✕。同じ AZ だけ。別の AZ へはスナップショット経由で移す
- 「インスタンスを停止してもインスタンスストアのデータは残る」→ ✕。残るのは再起動のときだけ。停止・休止・終了で消える
- 「st1 をブートボリュームにしてコストを下げる」→ ✕。st1 と sc1 はブートボリュームに使えない
- 「既存の暗号化されていないボリュームの設定を変えて暗号化する」→ ✕。スナップショットから暗号化した新しいボリュームを作る
- 「複数の EC2 でファイルを共有するなら EBS のマルチアタッチ」→ ✕(多くの場合)。マルチアタッチは io1 / io2・同じ AZ・クラスター対応ファイルシステムが前提。ファイル共有は EFS
- 「gp2 の IOPS を上げるには、ボリュームを大きくするしかないので gp2 のまま拡張する」→ ✕(コスト面)。gp3 に変えれば、サイズと別に IOPS を指定できる
- 「スナップショットは毎回ボリューム全体をコピーするので高い」→ ✕。2 回目以降は変更分だけを保存する増分バックアップ
まとめ: SAA 試験で押さえるポイント
- EBS は 1 つの AZ に属し、同じ AZ のインスタンスにアタッチする。別 AZ・別リージョンへはスナップショットで移す
- 汎用は gp3(3,000 IOPS・125 MiB/秒が標準、IOPS とスループットを個別に追加)。高性能・高耐久の DB は io2 Block Express
- 大きな連続読み書きは st1、低頻度の大容量は sc1。どちらもブートボリュームには使えない
- インスタンスストアは高速だが一時的。再起動では残り、停止・休止・終了で消える
- ルートボリュームは既定で終了時に削除される。残すなら DeleteOnTermination を無効に
- スナップショットは増分で、リージョン内のどの AZ でも復元でき、別リージョンにもコピーできる。自動化は Data Lifecycle Manager
- 既存の暗号化されていないボリュームは直接暗号化できない。スナップショット経由で暗号化したボリュームを作る。既定の暗号化はリージョン単位
確認問題
参考リンク
AWS 公式ドキュメント(外部サイトが開きます)。