Amazon EBS入門 EC2のディスク管理を理解する ボリュームタイプ・スナップショット・料金の基礎知識

オンプレミスの世界でサーバーを管理してきたエンジニアなら、ディスク容量の見積もりやRAID構成の設計に何度も頭を悩ませた経験があるはずです。「あのサーバー、ディスクが足りなくなりそうだけど、増設するには週末の深夜メンテが必要だな」——こんな会話が日常だったのではないでしょうか。

AWSのクラウド環境では、Amazon EBS（Elastic Block Store）がこのディスク管理の役割を担います。物理ディスクの調達も不要、容量変更もオンラインで可能、バックアップもボタンひとつ。ただし、オンプレとは考え方がかなり違うため、知らずに使うと「想定外の請求」や「パフォーマンス不足」に直面することになります。

この記事では、Amazon EBSの基本概念からボリュームタイプの選び方、スナップショットによるバックアップ、料金体系まで、オンプレ経験者の視点で体系的に解説します。EC2を使い始めたばかりの方はもちろん、すでに運用しているがEBSの仕組みを整理し直したい方にも役立つ内容です。

Amazon EBSとは？オンプレのディスクとの違い

Amazon EBS（Elastic Block Store）は、EC2インスタンスにアタッチして使うブロックストレージサービスです。オンプレミスでいえば、サーバーに接続するSASディスクやSAN（Storage Area Network）のLUNに相当します。

ただし、オンプレのディスクとは根本的に異なる点がいくつかあります。

特に重要なのは、EBSボリュームは「AZ（アベイラビリティゾーン）に紐づく」という点です。東京リージョン（ap-northeast-1）のap-northeast-1aに作成したEBSボリュームは、ap-northeast-1cのEC2インスタンスにはアタッチできません。これはオンプレのSANとは異なる制約で、マルチAZ構成を設計する際に必ず意識する必要があります。

EBSボリュームタイプの選び方

EBSには用途に応じた複数のボリュームタイプがあり、選び方を間違えるとパフォーマンス不足やコスト過多に直結します。オンプレでいえば「SSD/HDD/NVMeのどれを使うか」に近い判断です。

1. gp3（汎用SSD）——ほとんどのワークロードに最適

2024年以降、新規で作成するならまずgp3を選んでおけば間違いありません。gp2の後継として登場し、ベースラインIOPSが3,000、スループットが125 MB/sとなっており、追加料金を払えばIOPS・スループットを独立してスケールできます。

・ベースラインIOPS: 3,000 IOPS（最大16,000 IOPSまで増加可能）
・ベースラインスループット: 125 MB/s（最大1,000 MB/sまで増加可能）
・料金: $0.08/GB/月（東京リージョン、2026年4月時点）
・適したワークロード: Webサーバー、開発環境、中規模DB、一般業務アプリ

gp2との決定的な違いは、IOPSとスループットを容量とは独立して設定できる点です。gp2はボリュームサイズに比例してIOPSが決まるため、「IOPSが欲しいだけなのに容量を増やす」という無駄が発生していました。gp3ではその問題が解消されています。

2. io2 Block Express（プロビジョンドIOPS SSD）——高性能DB向け

Oracle、SQL Server、大規模MySQLなど、IOPSが命のデータベースワークロードにはio2 Block Expressが適しています。

・最大IOPS: 256,000 IOPS
・最大スループット: 4,000 MB/s
・料金: $0.142/GB/月 + $0.074/プロビジョンドIOPS/月（東京リージョン、2026年4月時点）
・適したワークロード: 大規模RDB、SAP HANA、I/O集約型アプリケーション

オンプレでいえば、専用のフラッシュストレージアレイ（Pure StorageやNetApp AFF相当）に近い性能を、必要な分だけオンデマンドで使える感覚です。ただし料金は高額になるため、本当に必要かどうかを見極めてから選択してください。

3. st1（スループット最適化HDD）——大量データの順次読み書き

ログ分析やデータウェアハウスなど、大容量データを順番に読み書きするワークロードに向いています。

・最大スループット: 500 MB/s
・料金: $0.054/GB/月（東京リージョン、2026年4月時点）
・適したワークロード: Hadoop/EMR、ログ処理、ビッグデータ分析

ランダムI/Oには弱いため、データベースのデータボリュームには使わないでください。オンプレでいえば、大容量のSATA HDDアレイに近い位置づけです。

4. sc1（Cold HDD）——アクセス頻度の低いデータ

最も安価なEBSボリュームタイプです。アーカイブ的な用途や、たまにしかアクセスしないデータの保管に適しています。

・最大スループット: 250 MB/s
・料金: $0.018/GB/月（東京リージョン、2026年4月時点）
・適したワークロード: コールドデータ、バックアップの一時保管

ボリュームタイプ比較まとめ

※料金は東京リージョン（ap-northeast-1）、2026年4月時点の値です。最新の料金はAWS公式サイトで確認してください。

EBSボリュームの基本操作

1. ボリュームの作成とアタッチ

EC2インスタンスを起動する際にルートボリュームは自動的に作成されますが、追加のデータボリュームを後から作成してアタッチすることもできます。

AWS CLIで追加ボリュームを作成する例を見てみましょう。

# 100GBのgp3ボリュームを作成（東京リージョン、AZ-a）
aws ec2 create-volume \
  --volume-type gp3 \
  --size 100 \
  --availability-zone ap-northeast-1a \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=data-vol-01}]'

# 作成したボリュームをEC2インスタンスにアタッチ
aws ec2 attach-volume \
  --volume-id vol-0123456789abcdef0 \
  --instance-id i-0123456789abcdef0 \
  --device /dev/sdf

アタッチ後、OS側でファイルシステムを作成してマウントする必要があります。この手順はオンプレで新しいディスクを追加したときと同じです。

# デバイスの確認
lsblk

# ファイルシステムの作成（初回のみ）
sudo mkfs -t xfs /dev/xvdf

# マウントポイント作成とマウント
sudo mkdir /data
sudo mount /dev/xvdf /data

# /etc/fstabに追記して再起動後も自動マウント
echo '/dev/xvdf /data xfs defaults,nofail 0 2' | sudo tee -a /etc/fstab

2. オンラインでのボリュームサイズ変更

これがオンプレ経験者にとって最も嬉しい機能の一つです。EBSボリュームは、EC2インスタンスを停止することなく、サイズやIOPS、ボリュームタイプを変更できます。

# ボリュームサイズを100GB→200GBに変更
aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --size 200

# 変更状況の確認（optimizingステータスになるまで待つ）
aws ec2 describe-volumes-modifications \
  --volume-id vol-0123456789abcdef0

AWS側の変更が完了したら、OS側でファイルシステムを拡張します。

# パーティションの拡張（NVMeデバイスの場合）
sudo growpart /dev/nvme1n1 1

# XFSファイルシステムの拡張
sudo xfs_growfs /data

# ext4の場合はこちら
# sudo resize2fs /dev/xvdf

オンプレでは「ディスクの増設＝深夜メンテ」が当たり前でしたが、EBSならサービスを動かしたまま数分で完了します。ただし、ボリュームサイズの縮小はできない点に注意してください。変更は「拡大」の一方通行です。

3. gp2からgp3への変更

既存のgp2ボリュームをgp3に変更するのも、オンラインで可能です。多くの場合、これだけでコスト削減になります。

# gp2→gp3への変更
aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3

# 複数ボリュームを一括変更する場合
aws ec2 describe-volumes \
  --filters "Name=volume-type,Values=gp2" \
  --query 'Volumes[*].VolumeId' --output text | \
  tr '\t' '\n' | while read vid; do
    echo "Converting $vid to gp3..."
    aws ec2 modify-volume --volume-id "$vid" --volume-type gp3
    sleep 5
  done

スナップショットでバックアップと復元

EBSスナップショットは、ボリュームのポイントインタイムバックアップです。オンプレでいえば、ストレージのスナップショット機能やVSSバックアップに近い概念ですが、保存先がS3（Amazon内部で管理）である点と、増分バックアップが自動で行われる点が大きく異なります。

1. スナップショットの仕組み

・増分保存: 初回はフルバックアップ、2回目以降は変更ブロックのみを保存するため、ストレージ料金が抑えられる
・リージョン間コピー: スナップショットを別リージョンにコピーでき、災害復旧（DR）に活用できる
・AMI作成: スナップショットからAMI（Amazon Machine Image）を作成し、同じ構成のEC2を複製できる
・取得中も稼働継続: スナップショット取得中もEC2インスタンスは停止不要（ただしI/O整合性に注意）

2. スナップショットの作成と復元

# スナップショットの作成
aws ec2 create-snapshot \
  --volume-id vol-0123456789abcdef0 \
  --description "data-vol-01 daily backup 2026-04-09" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=data-vol-01-backup}]'

# スナップショットから新しいボリュームを復元
aws ec2 create-volume \
  --snapshot-id snap-0123456789abcdef0 \
  --volume-type gp3 \
  --availability-zone ap-northeast-1a

3. Amazon Data Lifecycle Manager（DLM）で自動化

手動でスナップショットを取り忘れるリスクを排除するために、DLMを使ってスケジュール管理を自動化するのが実運用のベストプラクティスです。

・スケジュール設定: 「毎日0時にスナップショットを取得」のようなポリシーを定義
・世代管理: 「過去7世代を保持、それ以前は自動削除」で無限増殖を防止
・タグベースの対象指定: 特定のタグが付いたボリュームだけを対象にできる

オンプレでバックアップジョブのスケジュールを設定していたのと同じ感覚で、AWSコンソールやCLIからポリシーを定義するだけです。

料金の仕組みと見積もりのポイント

EBSの料金体系はシンプルに見えて、見落としがちな項目がいくつかあります。

ボリューム料金

基本はGB単位の月額課金です。「使った分だけ」ではなく「確保した分だけ」課金される点に注意してください。100GBのgp3ボリュームを作成して実際に10GBしか使っていなくても、100GB分の料金が発生します。

※東京リージョン（ap-northeast-1）、2026年4月時点。

スナップショット料金

スナップショットの保存料金は$0.05/GB/月（東京リージョン、2026年4月時点）です。増分保存のため、実際に変更されたデータ量に対して課金されます。

見落としがちなのが、「不要になったスナップショットの削除忘れ」です。開発・テスト環境で大量のスナップショットを作成して放置すると、じわじわと料金が膨らんでいきます。DLMの世代管理で自動削除するか、定期的に棚卸しする運用を入れてください。

コスト見積もりの具体例

Webサーバー3台（gp3 50GB×3）＋ DBサーバー1台（gp3 200GB、IOPS 6,000）＋ 日次スナップショット7世代の構成で試算してみましょう。

・Webサーバー: 50GB × 3台 × $0.08 = $12.00/月
・DBサーバー（ストレージ）: 200GB × $0.08 = $16.00/月
・DBサーバー（追加IOPS）: (6,000 – 3,000) × $0.006 = $18.00/月
・スナップショット（変更分のみ、全体の20%と仮定）: 350GB × 20% × $0.05 = $3.50/月
・合計: 約$49.50/月（約7,400円、1ドル=150円換算）

オンプレでSANストレージを調達する場合と比較すると、初期投資ゼロで始められる点は大きなメリットです。ただし、長期運用ではリザーブド（年単位の前払い）の検討も忘れずに。

よくあるトラブルと対処法

1. 「ボリュームがアタッチできない」

最も多い原因はAZ（アベイラビリティゾーン）の不一致です。EBSボリュームは作成したAZのEC2インスタンスにしかアタッチできません。別AZのインスタンスに移動したい場合は、スナップショットを取得してから目的のAZで新しいボリュームを作成してください。

2. 「ディスクI/Oが遅い」

gp2を使っている場合、ボリュームサイズが小さいとベースラインIOPSが不足することがあります。gp2のIOPSはサイズ×3（最大16,000）で決まるため、100GBなら300 IOPSしかありません。gp3に変更すれば、サイズに関係なく3,000 IOPSが保証されます。

io2を使っていても遅い場合は、EC2インスタンスタイプ側のEBS帯域幅がボトルネックになっている可能性があります。EBS最適化インスタンス（c5、m5、r5以降は標準で有効）を使っているか確認してください。

3. 「スナップショットが終わらない」

スナップショットの作成自体は非同期で実行され、バックグラウンドで完了します。「pending」ステータスが長時間続くのは、変更データ量が大きい場合の正常な動作です。スナップショット取得中もボリュームは通常通り使えるため、完了を待つ必要はありません。

4. 「削除したはずのボリュームに課金されている」

EC2インスタンスを終了しても、「Delete on Termination」がNoに設定されたEBSボリュームは残り続けます。AWS Cost Explorerで「未アタッチのEBSボリューム」を定期的にチェックし、不要なものを削除する運用を入れてください。

# 未アタッチのボリュームを一覧表示
aws ec2 describe-volumes \
  --filters "Name=status,Values=available" \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime}' \
  --output table

本記事のまとめ

Amazon EBSは、EC2を使ううえで避けて通れないストレージサービスです。ポイントを整理しておきましょう。

オンプレミスでのディスク管理経験があるエンジニアなら、EBSの概念自体は難しくありません。違いを正しく理解して、クラウドならではの柔軟性とコスト効率を最大限に活かしてください。

Linuxサーバーでのディスク管理（fdisk、mount、fstab）の詳細については、姉妹サイトLinuxMaster.JPで詳しく解説しています。