Amazon EBSとは？仕組み・ボリュームタイプと料金モデル・採用判断を実装者目線で解説

Amazon EBS（Elastic Block Store）は、EC2インスタンスにネットワーク経由で接続して使う、AWSのブロックストレージです。OSやデータベースの保存先として使う、ハードディスクのように読み書きできるボリュームです。この記事では、EC2に接続するブロックストレージというEBSの位置づけ、単一アベイラビリティゾーンに紐づく可用性の前提、gp3やio2といったボリュームタイプの選び分け、容量と独立してIOPSを指定できるgp3の考え方、S3に増分で保存されるスナップショット、KMS連携の暗号化、そしてプロビジョニング量とIOPS・スナップショットで積み上がる料金モデルを一次情報で整理します。オブジェクトストレージのS3やインスタンスストアとの違い、EBSを採用すべき条件と過剰になる場面の判断基準まで、実装者が基盤設計で迷う論点を具体的に示します。

まとめ：Amazon EBSの仕組み・ボリュームタイプと採用判断の要点

Amazon EBSは、EC2インスタンスにネットワーク越しに接続するブロックストレージで、OSからは1台のディスクのように見えます。ボリュームは1つのアベイラビリティゾーンに紐づき、そのAZ内でデータが冗長化される仕組みです。AZをまたぐ冗長ではないため、可用性を高めるにはスナップショットや複数AZ構成で補います。ボリュームタイプは、汎用SSDのgp3・旧世代のgp2、高性能なプロビジョンドIOPSのio2、大容量シーケンシャル向けHDDのst1・コールドのsc1に分かれ、性能要件とコストのバランスで選びます。

料金は、実際の使用量ではなくプロビジョニングした容量（GB-month）を基準に、gp3やio系で追加指定したIOPS・スループット、スナップショットの保存量が積み上がる構造です。gp3は容量と独立してIOPSを指定でき、gp2よりGB単価が安いため、多くの新規ボリュームで起点になります。OSやデータベースのようにブロックデバイスが要る用途にはEBS、大量ファイルの保管や配信にはS3、といった役割分担が基本です。迷う実装者は、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめてください。

Amazon EBSの仕組みとEC2向けブロックストレージのデータモデル

EBSを設計へ落とし込むには、まず「ブロックストレージがオブジェクトストレージやローカルディスクとどう違うのか」を押さえます。ここを曖昧にすると、AZをまたいで使えると誤解したり、消えては困るデータをインスタンスストアに置いたりといった事故につながりかねません。AWSやクラウドの全体像から確認したい場合は、クラウドとは何か・AWSの仕組みを事業者向けに解説した記事が上位の入り口になります。

EC2にネットワーク接続するブロックストレージという位置づけ

EBSは、EC2インスタンスにネットワーク経由で接続するブロックストレージです。物理的にインスタンスへ直付けされたディスクではなく、独立したストレージをネットワークでつなぐため、インスタンスを停止・終了してもボリューム側のデータは残せる点が特徴です。OSからは通常のブロックデバイスとして見え、フォーマットしてファイルシステムを作れば、ルートボリュームやデータ用ディスクとして扱えます。接続先となるEC2そのものの仕組みは、Amazon EC2のインスタンスタイプと料金を実装者目線で解説した記事で整理すると、コンピュートとストレージの役割分担が明確になります。

単一アベイラビリティゾーンに紐づくEBSボリュームと可用性の前提

EBSボリュームは、作成したアベイラビリティゾーン（AZ）に紐づきます。同じAZ内のEC2インスタンスにしか接続できず、別のAZのインスタンスへ直接つなぎ替えることはできません。データはそのAZ内で冗長化されますが、AZ全体の障害までは吸収しません。別AZへ移したい場合は、スナップショットを取り、そこから別AZに新しいボリュームを復元する手順を踏みます。可用性を高める設計では、複数AZにまたがってインスタンスとボリュームを分散し、スナップショットで復旧点を確保するのが前提になります。

オブジェクトストレージ（S3）・インスタンスストアとの用途の違い

EBSはブロックストレージで、HTTPベースのAPIでオブジェクトを読み書きするオブジェクトストレージのAmazon S3を解説した記事とは用途が異なります。S3は容量上限を気にせず大量のファイルを預ける保管・配信向けで、OSからボリュームとしてマウントはできません。一方、EC2の物理ホストに直付けされたインスタンスストアは高速ですが、インスタンスを停止・終了すると中身が消える一時領域です。消えては困るデータはEBS、キャッシュやスクラッチ領域はインスタンスストア、大量の静的ファイルやバックアップはS3、という切り分けが基本の判断軸になります。S3のなかでもめったに読まない長期保管は、Amazon S3 Glacierとはの記事で解説するアーカイブ向けクラスへ寄せます。

Amazon EBSのボリュームタイプと性能・容量設計の前提

EBSで次に押さえるのがボリュームタイプの選択です。求めるIOPS・スループットと容量、そして単価のバランスから、ワークロードごとに置き場所を決めます。

SSD系（gp3/gp2/io2）とHDD系（st1/sc1）の選び分けの起点

2026年7月時点で、EBSのボリュームタイプはSSD系とHDD系に大きく分かれます。SSD系は、汎用のgp3と旧世代のgp2、高性能なプロビジョンドIOPSのio2 Block Express・io1で、細かなランダムアクセスが多いOSやデータベース向けです。HDD系は、大容量のシーケンシャル読み書きに向くst1（スループット重視）と、アクセス頻度の低いデータを安く置くsc1（コールド）で、ログ集約やビッグデータのバッチ処理などに向きます。ランダムアクセスが要るならSSD系、順次読みの大容量ならHDD系、という性能特性の違いが選び分けの起点です。

gp3で容量と独立してIOPS・スループットを指定する考え方

gp3は、容量とは別にIOPSとスループットを指定できる汎用SSDです。旧世代のgp2はIOPSが容量に比例し、性能を上げるために不要な容量を増やす必要がありましたが、gp3ではベースラインとして概ね3,000 IOPSと125 MiB/sが容量に関係なく付き、そこから追加でIOPS・スループットをプロビジョニングできます。必要な容量と必要な性能を切り離せるため、性能のために容量を水増しする無駄を削れる点がgp3の利点です。gp3はgp2よりGB単価が安いとされ、多くの新規ボリュームで起点になります。gp3の上限（最大サイズ・最大IOPS・最大スループット）は2025年に引き上げられているため、具体値はAWS公式で対象リージョンと時点を確認してください。

プロビジョンドIOPS（io2 Block Express）が効く高性能要件の見極め

gp3では性能が足りない、あるいは高い可用性が要る場合に選ぶのが、プロビジョンドIOPSのio2 Block Express・io1です。指定した数のIOPSを安定して確保でき、io2 Block Expressは1ボリュームあたりの最大IOPSやスループットがgp3より高く、耐久性も99.999%とされる高信頼のタイプです。基幹データベースや、レイテンシと一貫した性能が売上に直結するワークロードが対象になります。io1/io2はMulti-Attachで同一AZ内の複数インスタンスから同時接続もできますが、単価は汎用SSDより高いため、性能要件が明確な場面に絞って使うのが実務的です。まずgp3で足りるかを見て、超えるぶんだけio系へ寄せる順序が無駄を生みません。

Amazon EBSのスナップショット・暗号化と料金モデルの設計前提

EBSは単一AZに紐づくため、バックアップと復旧の設計が可用性の要になります。スナップショットと暗号化、無停止変更の仕組みを押さえたうえで、料金の積み上がり方を理解します。

S3に保存される増分スナップショットによるバックアップと復元設計

EBSスナップショットは、特定時点のボリュームの状態をS3に保存するバックアップです。利用者からS3のバケットとしては見えませんが、内部的にS3へ増分で保存され、2回目以降は前回から変更されたブロックだけを保存するため、保存量と時間を抑えられます。スナップショットはリージョン単位で管理され、そこから別のAZに新しいボリュームを復元したり、別リージョンへコピーして地理的な冗長やディザスタリカバリを構成したりできるのも利点です。単一AZに紐づくEBSの弱点を補うには、Amazon Data Lifecycle Managerなどで定期的にスナップショットを自動取得し、復旧点を確保する運用が起点になります。

KMS連携の暗号化とElastic Volumesによる無停止でのボリューム変更

保存データの暗号化は、KMS（Key Management Service）と連携したEBS暗号化で扱う仕組みです。暗号化を有効にすると、ボリュームだけでなく、インスタンスとボリューム間の転送データ、そこから取得するスナップショットまで暗号化され、リージョン単位で新規ボリュームの暗号化を既定で有効にもできます。運用中の変更については、Elastic Volumesにより、ボリュームのサイズ拡張・タイプ変更・IOPS変更をインスタンスを止めずに実施できる点がElastic Volumesの利点です。稼働中のシステムでストレージ性能が足りなくなっても、停止せずにgp3のIOPSを引き上げる、といった対応が取れるため、無停止での増強を前提に容量と性能を設計できます。

プロビジョニング量・IOPS・スナップショットで積み上がる料金モデル

EBSの料金は、実際に書き込んだ量ではなく、プロビジョニングした容量（GB-month）を基準に課金される点が要注意です。使っていない空き領域にも、確保したぶんの料金がかかります。これに、gp3やio系で追加指定したIOPS・スループット、スナップショットの保存量（GB-month）、任意の高速スナップショット復元が積み上がります。コストを抑えるには、余った容量を放置せず実態に合わせて縮小方向も含めて見直し、不要になった古いスナップショットをライフサイクルで失効させるのが基本の打ち手です。gp2からgp3へ切り替えるとGB単価が下がるとされるため、既存ボリュームの棚卸しでコストを適正な水準へ寄せられます。

Amazon EBSを採用すべき条件と各ストレージとの使い分け

ここでは判断を言い切ります。EBSはEC2に接続するブロックデバイスとして強い反面、大量ファイルの保管や、消えてよい一時領域の代わりには向きません。自社システムのデータ置き場をどこにするかを、条件付きで見極めてください。

Amazon EBSの採用が効くワークロードと要件の条件の見極め

採用が効くのは、EC2上でOSやデータベースを動かし、ブロックデバイスとして永続的に読み書きしたい、という条件が重なるときです。具体例は、EC2のルートボリューム、自前で構築するデータベースのデータ領域、細かい上書きが発生するアプリケーションの作業領域が当てはまります。停止・終了してもデータを残したいなら、インスタンスストアではなくEBSが前提になります。こうしたAWS上のストレージ基盤やEC2構成を自社に取り入れるなら、AWSを含むクラウドインフラ構築の相談窓口で、ボリュームタイプの選定やスナップショット運用、IOPSとコストの妥当性を相談するとよいでしょう。

EBSが過剰・不要な場面とS3・インスタンスストアへ寄せる切り分け

大量の静的ファイルやバックアップをただ保管・配信したいだけなら、EBSは過剰です。容量上限を気にせず安く預けたい保管・配信はS3、停止時に消えてよいキャッシュやスクラッチ領域はインスタンスストアへ寄せます。EBSは単一AZに紐づき、確保した容量ぶんが課金されるため、AZをまたいで共有したいファイルや、めったに読まないアーカイブをEBSに置くのは割高で用途違いです。マネージドなデータベースが要る場合は、内部でストレージを管理するAmazon RDSのようなマネージドDBサービスを解説した記事を検討すると、EBSを自前で運用する手間を省けます。アクセス方法（マウントか、APIか、マネージドに任せるか）を軸に選定してください。

RAIDや他のストレージと組み合わせる場面での全体の見取り図

EBSは単体でも冗長化されていますが、要件によっては他の仕組みと組み合わせます。オンプレミスのディスク冗長化で使われるRAIDの考え方は、EBSでも複数ボリュームをストライピング（RAID 0）してスループットを稼ぐ設計で応用できます。ただしEBSは各ボリュームが単一AZ内で冗長化済みのため、可用性目的でRAID 1のミラーリングを重ねる必要性は低く、性能目的の使い分けが中心です。RAIDの各構成と使いどころは、RAID0/1/5/6/10の違いと冗長化設計を解説した記事で整理できます。まずは単一のgp3ボリュームで足りるかを見極め、スループットが不足する場面に限って複数ボリューム構成やio系へ広げる順序が実務的です。

よくある質問

Amazon EBSの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Amazon EBSとインスタンスストアはどう使い分ければよいですか？

停止・終了してもデータを残したい永続領域はEBS、停止時に消えてよいキャッシュやスクラッチ領域はインスタンスストアが基本の分岐です。インスタンスストアは物理ホスト直付けで高速ですが、インスタンスのライフサイクルとともに中身が消えます。データベースのデータや消えては困るファイルはEBSに置き、一時的な高速領域だけインスタンスストアを使う設計が安全です。

gp3とgp2ではどちらを選べばよいですか？

新規のボリュームは、容量と独立してIOPS・スループットを指定でき、GB単価も安いとされるgp3が起点になります。gp2はIOPSが容量に比例するため、性能を上げるために不要な容量を確保しがちです。既存のgp2ボリュームも、Elastic Volumesで無停止のままgp3へタイプ変更できるため、棚卸しのタイミングで切り替えるとコストを抑えられます。

EBSボリュームは別のアベイラビリティゾーンで使えますか？

EBSボリュームは作成したAZに紐づき、別AZのインスタンスへ直接つなぎ替えることはできません。別AZで使いたい場合は、スナップショットを取り、そこから別AZに新しいボリュームを復元します。スナップショットは別リージョンへのコピーもできるため、ディザスタリカバリや地理的な冗長を組む際の起点になります。

EBSのスナップショットはどのくらいの頻度で取るべきですか？

許容できるデータ損失時間（目標復旧時点）から逆算して決めます。更新の激しいデータベースなら数時間ごと、変更の少ないデータなら日次といった具合です。スナップショットは2回目以降が増分保存のため、頻度を上げても保存量の増加は抑えられます。Amazon Data Lifecycle Managerで取得と世代管理を自動化し、古い世代を失効させる運用が実務的です。

EBSの料金を抑えるにはどうすればよいですか？

EBSは使用量でなくプロビジョニングした容量に課金されるため、まず空き容量を実態に合わせて見直します。gp2をgp3へ切り替えるとGB単価が下がるとされるうえ、性能のために確保していた余分な容量も削れるのが利点です。加えて、不要になった古いスナップショットをライフサイクルで失効させ、gp3のベースラインで足りる場面で追加IOPSを指定しないことが、コストを適正な水準へ寄せる打ち手になります。

関連記事

• クラウドとは？AWSとは何かを仕組み・料金・移行の判断まで解説：EBSの前提となるクラウド・AWS全体像を事業者向けに整理した上位概念の記事
• Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を解説：EBSの接続先となるEC2の仕組みと料金を実装者目線で整理した記事
• Amazon S3とは？オブジェクトストレージの仕組み・料金・採用判断を解説：EBSと用途が異なるオブジェクトストレージの選び分けを整理した記事
• Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を解説：EBSを自前運用する代わりに使えるマネージドDBサービスの記事
• RAIDとは？RAID0/1/5/6/10の違いと構成・企業のディスク冗長化設計を解説：EBSの複数ボリューム構成に応用するRAIDの考え方を整理した記事