概要
EC2 インスタンスを起動すると、OS やアプリケーションが入ったディスクが最初から付いてきます。このディスクの正体が Amazon EBS(Elastic Block Store)です。EBS は EC2 インスタンスにアタッチして使うブロックストレージで、パソコンに外付けのハードディスクをつなぐのと同じ感覚で、ボリュームを追加したり、容量を後から増やしたりできます。
EBS を使いこなすには、用途に応じたボリュームタイプの選び方、ボリュームが 1 つのアベイラビリティーゾーン(AZ)に属すること、インスタンスストアとの違い、暗号化、そしてバックアップの手段であるスナップショットを押さえておく必要があります。いずれも CLF・SAA で繰り返し問われる基本です。
本記事では、EBS の基本を解説したうえで、起動済みの EC2 インスタンスに gp3 ボリュームを作成・アタッチし、OS からフォーマット・マウントして使い、ボリュームのサイズを拡張してファイルシステムを広げ、最後にスナップショットを作成するまでを体験します。
クラウドおさるEC2 のディスクを後から足したり広げたりできるのでござるか。猿山のバナナ倉庫は一度建てたら広げられぬので、弊猿、手順をしっかり確かめるでござる!


この記事のメリット
- EBS が EC2 インスタンスのディスクとしてどのように動いているかを理解できる
- gp3 / io2 / st1 / sc1 などのボリュームタイプを用途に応じて選び分けられる
- EBS ボリュームが AZ に縛られることと、インスタンスストアとの違いを説明できる
- EBS の暗号化と、スナップショット(増分バックアップ・リージョン間コピー)の仕組みを把握できる
- ボリュームの作成・アタッチ・フォーマット・マウント・サイズ拡張・スナップショット作成を一通り体験できる
執筆者とキャラクター紹介
執筆者:土肥(とひ)
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。


クラウドおさる



はじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。



基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。



猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
EBS は EC2 のディスクの正体



とひさん、EC2 を起動したら、最初からディスクが付いていたでござる。あれは何者でござるか?
それが Amazon EBS のボリュームだよ。EBS は EC2 インスタンスにアタッチして使うブロックストレージで、OS からはローカルのハードディスクと同じように見えるんだ。EC2 のルートボリュームには EBS を使うのが一般的で、AWS も EBS-backed の AMI を使うことをおすすめしているよ。



ネットワークの向こうにあるのに、手元のディスクのように使えるのでござるな。インスタンスを止めたら中身は消えるのでござるか?
消えないよ。EBS ボリュームは EC2 インスタンスの稼働状態とは独立した永続性を持っていて、インスタンスを停止してもデータは残るんだ。さらに、ボリュームのデータは同じ AZ 内の複数のサーバーに自動でレプリケートされるから、1 つのコンポーネントが壊れてもデータが失われないようになっているよ。



倉庫の中身を、同じ猿山の中の別の小屋にも写しておいてくれるのでござるな!
そうそう。ただ「同じ AZ の中で」っていうところは覚えておいてね。あとで大事になるから。
ボリュームタイプの使い分け



ボリュームを作るときに「gp3」とか「io2」とか選ぶ欄があったでござる。どう違うのでござるか?
大きく分けると SSD 系と HDD 系があるよ。主なものをまとめるとこんな感じだね。
| ボリュームタイプ | 種類 | サイズ | 最大 IOPS | 最大スループット | ブートボリューム | 主な用途 |
|---|---|---|---|---|---|---|
| gp3(汎用 SSD) | SSD | 1 GiB~64 TiB | 80,000 | 2,000 MiB/秒 | 可 | ブートボリューム、開発・テスト環境、中規模のデータベース |
| io2 Block Express(プロビジョンド IOPS SSD) | SSD | 4 GiB~64 TiB | 256,000 | 4,000 MiB/秒 | 可 | 高い IOPS を持続的に必要とする I/O 集約型のデータベース |
| st1(スループット最適化 HDD) | HDD | 125 GiB~16 TiB | 500 | 500 MiB/秒 | 不可 | ビッグデータ、データウェアハウス、ログ処理 |
| sc1(Cold HDD) | HDD | 125 GiB~16 TiB | 250 | 250 MiB/秒 | 不可 | アクセス頻度の低いデータ、とにかく保存コストを下げたい場合 |



種類が多くて迷うでござる……。まずはどれを選べばよいのでござる?
迷ったら gp3 から考えるといいよ。gp3 はボリュームのサイズに関係なく、ベースラインとして 3,000 IOPS と 125 MiB/秒のスループットが料金に含まれていて、必要なら IOPS とスループットを別々に追加できるんだ。gp3 で足りないくらい高い IOPS を持続的に出したいミッションクリティカルなデータベースなら io2 Block Express。io2 Block Express は耐久性が 99.999% と、ほかのタイプより高いのも特徴だよ。



HDD の st1 と sc1 は、どういうときに使うのでござるか?
大きなファイルを先頭から順番に読み書きするような処理向けだよ。ログ処理やデータウェアハウスみたいに、頻繁にアクセスして高いスループットがほしいなら st1、めったに読まないデータを安く置いておきたいなら sc1 だね。どちらも小さいランダム I/O には向かないし、ブートボリュームにはできないから注意してね。



迷ったら gp3、速さが命なら io2、大きなデータを順番に流すなら st1、寝かせておくなら sc1 でござるな。バナナも、毎日食べる分は手元、熟成用は奥の蔵、と置き場所を分けるのと同じでござる!
AZ に縛られることと、インスタンスストアとの違い



さっき「同じ AZ の中で」と言っていたのは、どういうことでござるか?
EBS ボリュームは 1 つの AZ に作られて、同じ AZ にあるインスタンスにしかアタッチできないんだ。たとえば ap-northeast-1a に作ったボリュームは、ap-northeast-1c のインスタンスには付けられないよ。



では、別の AZ のインスタンスにデータを持っていきたいときは困るのでござるな……。
そこで使うのが、あとで出てくるスナップショットだよ。スナップショットから同じリージョン内の好きな AZ に新しいボリュームを作れるんだ。それと、もう 1 つ紛らわしいものにインスタンスストアがあるから、違いを整理しておこうか。
| 項目 | Amazon EBS | インスタンスストア |
|---|---|---|
| 実体 | ネットワーク経由でアタッチするブロックストレージ | ホストコンピュータに物理的にアタッチされたディスク |
| データの永続性 | インスタンスの停止・終了とは独立して保持できる | インスタンスの停止・休止・終了、ディスク障害などで失われる(再起動では保持) |
| 付け外し | 同じ AZ の別のインスタンスに付け替えられる | そのインスタンス専用 |
| 料金 | プロビジョニングした分の料金がかかる | インスタンスの料金に含まれる |
| 主な用途 | OS、データベース、アプリケーションのデータ | バッファ、キャッシュ、スクラッチデータなどの一時データ |





インスタンスストアは、当番猿が手元に置いておく黒板のようなものでござるな。当番が交代したら消してしまう、と。
いい例えだね! 停止しても残したいデータはインスタンスストアには置かない、と覚えておけば大丈夫だよ。
暗号化



ボリュームの中身を盗み見られないようにする方法はあるのでござるか?
EBS の暗号化を使えばいいよ。暗号化したボリュームでは、保存されているデータだけでなく、インスタンスとボリュームの間でやり取りされるデータ、そのボリュームから作ったスナップショット、さらにそのスナップショットから作ったボリュームまで暗号化されるんだ。鍵は AWS KMS のキーを使っていて、何も指定しなければ AWS マネージドキーの aws/ebs が使われるよ。



すでに暗号化せずに作ってしまったボリュームは、後から暗号化できるのでござるか?
暗号化されていない既存のボリュームを、そのまま直接暗号化することはできないんだ。スナップショットを取って、そこから暗号化したボリュームを新しく作る流れになるよ。最初から漏れなく暗号化したいなら、リージョン単位の「デフォルトで暗号化」の設定を有効にしておくと、そのリージョンで新しく作る EBS ボリュームが自動で暗号化されるんだ。



後から鍵を付けるのは手間がかかるので、最初から鍵付きの蔵を建てるのが楽でござるな!
スナップショット(増分バックアップとコピー)



スナップショットとは、ボリュームの写真のようなものでござるか?
そう、ある時点のボリュームの中身を丸ごと保存したバックアップだよ。スナップショットは Amazon S3 に保存されるんだけど、自分の S3 バケットに見えるわけじゃなくて、EC2 のコンソールや API から管理するんだ。



毎回まるごと保存していたら、すぐに容量があふれそうでござる……。
そこがよくできているところで、スナップショットは増分バックアップなんだ。2 回目以降は、前回のスナップショットから変更されたブロックだけが保存されるから、作成時間もストレージ料金も抑えられるよ。



増分だと、古いスナップショットを消したら新しいほうが壊れたりしないのでござるか?
大丈夫。スナップショットを削除すると、そのスナップショットだけが参照しているデータが消えて、ほかのスナップショットが参照しているデータは残るようになっているよ。だから逆に「古いものを 1 つ消したのに、料金があまり減らない」ってことも起こるんだ。



スナップショットからは、どこにでもボリュームを戻せるのでござるか?
スナップショットのデータはリージョン内の全 AZ に自動でレプリケートされるから、同じリージョンならどの AZ にでもボリュームを復元できるよ。さっきの「AZ をまたいでデータを持っていきたい」はこれで解決だね。さらに、スナップショットは別のリージョンにコピーすることもできて、災害対策や別リージョンへの移行に使えるんだ。コピーのときに、暗号化されていないスナップショットを暗号化したり、別の KMS キーで暗号化し直したりもできるよ。
| やりたいこと | 方法 |
|---|---|
| 別の AZ にボリュームを移す | スナップショットを取り、移したい AZ を指定してボリュームを作成する |
| 別のリージョンにバックアップを置く | スナップショットを別リージョンへコピーする |
| 暗号化されていないボリュームを暗号化する | スナップショットを取り、暗号化を有効にしてボリュームを作成する(またはスナップショットを暗号化してコピーする) |





毎日スナップショットを取るのは、手作業だと忘れそうでござる。
定期的な取得と古いスナップショットの削除は、Amazon Data Lifecycle Manager で自動化できるよ。EBS 以外もまとめてバックアップを管理したいなら AWS Backup だね。今回は仕組みを理解するために、手動で 1 つ作ってみよう。
ボリュームの変更と料金の考え方



容量が足りなくなったら、インスタンスを止めて付け替えるのでござるか?
止めなくていいんだ。Elastic Volumes という機能で、アタッチしたまま使い続けながらサイズやボリュームタイプ、IOPS などを変更できるよ。ただし注意点が 3 つあるんだ。
- サイズは増やすことしかできない(小さくしたい場合は、小さいボリュームを作ってデータを移す)
- ボリュームを広げても、OS 側のファイルシステムは自動では広がらない。変更が
optimizing状態になったら、OS でファイルシステムを拡張する - 同じボリュームへの変更は、前の変更が
completedになってから。変更できるのはローリング 24 時間で最大 4 回まで



「とりあえず大きく作って後で小さくする」はできないのでござるな。料金はどう決まるのでござる?
EBS はプロビジョニングした分、つまり作ったボリュームのサイズに対して料金がかかるんだ。中身が空でも 20GiB で作れば 20GiB 分だね。それから、インスタンスからデタッチしたボリュームも、削除するまで料金がかかり続けるよ。スナップショットも削除するまで保存料金がかかるから、使い終わったものは消すのが基本だね。



小さく作って足りなくなったら広げる、使わなくなったら消す。バナナを無駄にしない作法でござるな!
実践
起動済みの EC2 インスタンスに gp3 ボリュームを追加し、OS からフォーマット・マウントしてファイルを書き込みます。続いてボリュームのサイズを拡張してファイルシステムを広げ、最後にスナップショットを作成します。
前提条件
- リージョン:
ap-northeast-1(東京) - AWS マネジメントコンソールにログイン済みであること
- 以下のリソースが作成済みであること
| リソース種別 | リソース名 | 内容 |
|---|---|---|
| VPC | ebs-vpc | 10.0.0.0/16 |
| サブネット | ebs-public-subnet | 10.0.1.0/24(ap-northeast-1a、インターネットゲートウェイ経由で外部に出られる) |
| EC2 インスタンス | ebs-server | Amazon Linux 2023 / t3.micro / ap-northeast-1a。AmazonSSMManagedInstanceCore を含む IAM インスタンスプロファイルが付与されており、Session Manager で接続できる |
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| EBS ボリューム | ebs-data-volume | ebs-server に追加するデータ用ボリューム(gp3 / 10GiB で作成し、20GiB に拡張) |
| EBS スナップショット | ebs-data-snapshot | ebs-data-volume のバックアップ |
ステップ1: インスタンスの AZ を確認する
EBS ボリュームはインスタンスと同じ AZ に作る必要があるため、先に ebs-server の AZ を確認します。
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1(東京)であることを確認します - 上部の検索バーに
EC2と入力し、表示された「EC2」を選択します - 左側ナビゲーションの「インスタンス」→「インスタンス」を選択します
ebs-serverを選択し、下部の「ネットワーキング」タブで「アベイラビリティーゾーン」がap-northeast-1aであることを確認します- 下部の「ストレージ」タブで、ルートデバイスとして EBS ボリュームが 1 つアタッチされていることも確認しておきます
ステップ2: gp3 ボリュームを作成する
- 左側ナビゲーションの「Elastic Block Store」→「ボリューム」を選択します
- 右上の「ボリュームの作成」をクリックします
- 「ボリューム設定」で以下を入力します
- ボリュームタイプ:
汎用 SSD (gp3) - サイズ (GiB):
10 - IOPS:
3000(デフォルト) - スループット (MiB/秒):
125(デフォルト) - アベイラビリティーゾーン:
apne1-az4 (ap-northeast-1a)(ステップ1で確認した AZ) - スナップショット ID:
スナップショットから作成しない(デフォルト) - 暗号化: 「このボリュームを暗号化する」にチェックを入れ、KMS キーは
(デフォルト) aws/ebsを選択します(リージョンで「デフォルトで暗号化」が有効な場合は、最初からチェックが入っています) - 「タグ – オプション」で「新しいタグを追加」をクリックし、キー
Name、値ebs-data-volumeを入力します - その他の項目はデフォルトのままにします


- 右下の「ボリュームの作成」をクリックします
- ボリューム一覧で
ebs-data-volumeの「ボリュームの状態」が「使用可能」になるまで待ちます
ステップ3: ボリュームをインスタンスにアタッチする
- ボリューム一覧で
ebs-data-volumeを選択し、右上の「アクション」→「ボリュームのアタッチ」をクリックします - 「インスタンス」で
ebs-serverを選択します(同じ AZ のインスタンスだけが候補に表示されます) - 「デバイス名」で
/dev/sdfを選択します - 「ボリュームのアタッチ」をクリックします
- ボリューム一覧で
ebs-data-volumeの「ボリュームの状態」が「使用中」になり、「アタッチされたリソース」にebs-serverのインスタンス ID が表示されることを確認します


ステップ4: Session Manager で接続し、フォーマット・マウントする
アタッチしただけのボリュームは、まだファイルシステムがない「生のディスク」です。OS からフォーマットしてマウントします。
- 左側ナビゲーションの「インスタンス」→「インスタンス」を選択し、
ebs-serverを選択して右上の「接続」をクリックします - 「セッションマネージャー」タブを選択し、「接続」をクリックします
- ブラウザ上にターミナルが開いたら、ブロックデバイスの一覧を確認します
lsblkt3.micro のような Nitro ベースのインスタンスでは、EBS ボリュームが NVMe デバイスとして見えます。そのため、コンソールで指定した /dev/sdf ではなく nvme1n1 のような名前で表示されます。サイズが 10G でパーティションもマウントポイントもないデバイスが、追加した ebs-data-volume です。以下は表示例です(ルートボリュームのパーティション構成は AMI によって異なります)。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 8G 0 disk
├─nvme0n1p1 259:1 0 8G 0 part /
├─nvme0n1p127 259:2 0 1M 0 part
└─nvme0n1p128 259:3 0 10M 0 part /boot/efi
nvme1n1 259:4 0 10G 0 disk以降のコマンドの /dev/nvme1n1 は、lsblk で確認したデバイス名に置き換えてください。まず、ファイルシステムがまだないことを確認します。
sudo file -s /dev/nvme1n1/dev/nvme1n1: data と表示されれば、ファイルシステムがない空のボリュームです。XFS でフォーマットします。
sudo mkfs -t xfs /dev/nvme1n1マウントポイントを作成してマウントし、ファイルを書き込みます。
sudo mkdir /data
sudo mount /dev/nvme1n1 /data
echo "hello ebs" | sudo tee /data/hello.txt
df -hT /data/data の行に、タイプ xfs、サイズ約 10G のファイルシステムが表示されれば、マウントは成功です。


ここでは一時的なマウントです。インスタンスの再起動後も自動でマウントしたい場合は、sudo blkid で確認した UUID を使って /etc/fstab に UUID=<UUID> /data xfs defaults,nofail 0 2 の形で追記します。nofail を付けておくと、ボリュームがアタッチされていない状態でもインスタンスが起動できます。
ステップ5: ボリュームのサイズを 20GiB に拡張する
ebs-data-volume をアタッチしたまま、サイズを 10GiB から 20GiB に増やします。
- Session Manager のタブはそのままにして、EC2 コンソールのタブに戻ります
- 左側ナビゲーションの「Elastic Block Store」→「ボリューム」を選択します
ebs-data-volumeを選択し、右上の「アクション」→「ボリュームの変更」をクリックします- 「サイズ (GiB)」を
20に変更します。ボリュームタイプ・IOPS・スループットはそのままにします


- 右下の「変更」をクリックします。確認のダイアログが表示された場合は、内容を確認して「変更」をクリックします
- ボリューム一覧で
ebs-data-volumeを選択し、「ボリュームの状態」にoptimizingが表示されるまで待ちます(サイズの増加は、変更がoptimizing状態になった時点で有効になります)
ステップ6: ファイルシステムを拡張する
ボリュームを広げただけでは、OS 側のファイルシステムは 10GiB のままです。Session Manager のターミナルに戻り、確認します。
lsblk /dev/nvme1n1
df -hT /datalsblk ではデバイスのサイズが 20G になっている一方、df ではファイルシステムのサイズが約 10G のままであることが確認できます。今回のボリュームはパーティションを作らずに丸ごと XFS でフォーマットしたので、パーティションの拡張(growpart)は不要です。XFS のファイルシステムを拡張します。
sudo xfs_growfs -d /data
df -hT /data
cat /data/hello.txtdf の /data のサイズが約 20G に増え、hello.txt の中身 hello ebs もそのまま読めることが確認できます。インスタンスを止めず、データも消さずに容量を増やせました。





コンソールで広げるのは「蔵の拡張」、xfs_growfs は「中の棚を広げる」作業でござる。両方やってはじめてバナナを多く置けるのでござるな。
ステップ7: スナップショットを作成する
ebs-data-volume のスナップショットを作成します。スナップショットにはリクエストした時点でボリュームに書き込まれているデータが含まれるので、書き込み中の処理がない状態で取るのが推奨されています。今回は書き込みをしていないため、このまま進めます。
- EC2 コンソールの左側ナビゲーションの「Elastic Block Store」→「スナップショット」を選択します
- 右上の「スナップショットの作成」をクリックします
- 以下を設定します
- リソースタイプ:
ボリューム - ボリューム ID:
ebs-data-volumeのボリューム ID を選択 - 説明:
ebs-data-volume backup - 「タグ」で「新しいタグを追加」をクリックし、キー
Name、値ebs-data-snapshotを入力します - 「暗号化」の欄に元のボリュームの設定(「暗号化済み」)が表示され、変更できないことを確認します


- 右下の「スナップショットを作成」をクリックします
- スナップショット一覧で
ebs-data-snapshotの「スナップショットのステータス」が「保留中」から「完了済み」になるまで待ちます。作成中もボリュームはそのまま使い続けられます - 「完了済み」になったら、
ebs-data-snapshotを選択し、下部の「詳細」タブでボリュームサイズが20 GiB、暗号化が「暗号化済み」になっていることを確認します


このスナップショットから、ap-northeast-1 内の別の AZ にボリュームを作成したり、「アクション」→「スナップショットをコピー」で別のリージョンにコピーしたりできます。



デタッチしたボリュームも、元のボリュームを消した後のスナップショットも、削除するまで料金がかかり続けるのでござる。試し終わったら、ボリュームとスナップショットの両方が残っていないか確かめるでござるぞ。
まとめ
- Amazon EBS は EC2 インスタンスにアタッチして使うブロックストレージで、インスタンスの停止とは独立してデータを保持できる
- ボリュームタイプは、迷ったら gp3、高い IOPS を持続的に必要とするなら io2 Block Express、大きなシーケンシャル処理なら st1、アクセス頻度の低いデータを安く置くなら sc1 を選ぶ。HDD 系はブートボリュームにできない
- EBS ボリュームは 1 つの AZ に属し、同じ AZ のインスタンスにしかアタッチできない。インスタンスストアはホストに付いた一時ストレージで、停止・終了でデータが失われる
- 暗号化したボリュームでは、保存データ・インスタンスとの間の通信・スナップショットまで暗号化される。既存の暗号化されていないボリュームは、スナップショット経由で暗号化する
- スナップショットは S3 に保存される増分バックアップで、リージョン内の任意の AZ への復元や、別リージョンへのコピーができる。定期取得は Data Lifecycle Manager や AWS Backup で自動化する
- Elastic Volumes でアタッチしたままサイズを増やせるが、小さくはできない。拡張後は OS 側でファイルシステムを広げる必要がある
- EBS はプロビジョニングしたサイズに課金され、デタッチしたボリュームやスナップショットも削除するまで料金がかかる
関連記事:
- Amazon EC2 でインスタンスを起動しSSH接続する
- Amazon Data Lifecycle Manager で EBS スナップショットを自動管理する
- AWS Backup でリソースのバックアップを一元管理する
参照先
- Amazon Elastic Block Store とは?
- Amazon EBS ボリューム
- Amazon EBS ボリュームの種類
- Amazon EBS 汎用 SSD ボリューム
- Amazon EBS プロビジョンド IOPS SSD ボリューム
- Amazon EBS スループット最適化 HDD ボリュームと Cold HDD ボリューム
- EC2 インスタンス用のインスタンスストアの一時ブロックストレージ
- Amazon EC2 インスタンスストアボリュームのデータの永続性
- Amazon EC2 インスタンスのルートボリューム
- Amazon EBS 暗号化
- Amazon EBS スナップショット
- Amazon EBS スナップショットのコピー
- Amazon EBS スナップショットの削除
- Amazon EBS ボリュームの作成
- Amazon EBS ボリュームを Amazon EC2 インスタンスにアタッチ
- Amazon EBS ボリュームを使用できるようにする
- Elastic Volumes オペレーションを使用して Amazon EBS ボリュームを変更する
- Amazon EBS ボリューム変更の進行状況のモニタリング
- Amazon EBS ボリュームのサイズ変更後にファイルシステムを拡張
- EBS ボリュームのスナップショットを作成する
- Amazon EC2 インスタンスから Amazon EBS ボリュームをデタッチ
- ステップ 1: Session Manager の前提条件を満たす













