--- title: "Amazon EBSとは？ボリュームタイプの選び方と東京の料金・CLIでの作成とマウント手順【2026年版】" url: "https://www.issoh.co.jp/tech/details/15440/" published: 2026-07-22 updated: 2026-10-01 categories: ["AWS"] publisher: "株式会社一創" --- # Amazon EBSとは？ボリュームタイプの選び方と東京の料金・CLIでの作成とマウント手順【2026年版】 Amazon EBS（Elastic Block Store）は、EC2インスタンスにネットワーク経由で接続して使う、AWSのブロックストレージです。OSやデータベースの保存先として使う、ハードディスクのように読み書きできるボリュームのことです。この記事では、EC2に接続するブロックストレージというEBSの位置づけ、単一アベイラビリティゾーンに紐づく可用性の前提、gp3やio2といったボリュームタイプの性能上限と選び分け、S3に増分で保存されるスナップショット、KMS連携の暗号化を、AWS公式ドキュメントを2026年10月1日に確認した内容で整理します。あわせて、AWS CLIでボリュームを作成してEC2にアタッチし、Linuxでマウントするまでのコマンド、東京リージョンの単価で月額を試算する方法、EBSを採用すべき条件と過剰になる場面の判断基準まで、実装者が基盤設計で迷う論点を具体的に示します。 ## まとめ：Amazon EBSの仕組み・ボリュームタイプと採用判断の要点 Amazon EBSは、EC2インスタンスにネットワーク越しに接続するブロックストレージで、OSからは1台のディスクのように見えます。ボリュームは1つのアベイラビリティゾーンに紐づき、そのAZ内でデータが冗長化される仕組みです。AZをまたぐ冗長ではないため、可用性を高めるにはスナップショットや複数AZ構成で補います。ボリュームタイプは、汎用SSDのgp3・旧世代のgp2、高性能なプロビジョンドIOPSのio2 Block Express・io1、大容量シーケンシャル向けHDDのst1・コールドのsc1に分かれ、性能要件とコストのバランスで選びます。 料金は、実際の使用量ではなくプロビジョニングした容量（GB-month）を基準に、gp3やio系で追加指定したIOPS・スループット、スナップショットの保存量が積み上がる構造です。東京リージョンではgp3が1GBあたり月0.096ドル、gp2が0.12ドルで、gp3は容量と独立して3,000 IOPS・125 MiB/sを標準で持つため、多くの新規ボリュームで起点になります。OSやデータベースのようにブロックデバイスが要る用途にはEBS、大量ファイルの保管や配信にはS3、複数のEC2から同時にマウントする共有ファイルにはEFS、という役割分担が基本です。迷う実装者は、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめてください。 ## Amazon EBSとは：EC2に接続するブロックストレージの仕組み EBSを設計へ落とし込むには、まず「ブロックストレージがオブジェクトストレージやローカルディスクとどう違うのか」を押さえます。ここを曖昧にすると、AZをまたいで使えると誤解したり、消えては困るデータをインスタンスストアに置いたりといった事故につながりかねません。AWSやクラウドの全体像から確認したい場合は、[クラウドとは何か・AWSの仕組みを事業者向けに解説した記事](https://www.issoh.co.jp/column/details/13421/)が上位の入り口になります。 ### EC2にネットワーク接続するブロックストレージという位置づけ EBSは、EC2インスタンスにネットワーク経由で接続するブロックストレージです。物理的にインスタンスへ直付けされたディスクではなく、独立したストレージをネットワークでつなぐため、インスタンスを停止・終了してもボリューム側のデータは残せます。OSからは通常のブロックデバイスとして見え、フォーマットしてファイルシステムを作れば、ルートボリュームやデータ用ディスクとして扱えるのが特徴です。Nitro System上のインスタンスでは、EBSボリュームはNVMeデバイス（例：nvme1n1）として認識され、指定したデバイス名と実際の名前が一致しないことがあると[AWSのボリューム利用手順](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-using-volumes.html)に明記されています。接続先となるEC2そのものの仕組みは、[Amazon EC2のインスタンスタイプと料金を実装者目線で解説した記事](https://www.issoh.co.jp/tech/details/15424/)で整理すると、コンピュートとストレージの役割分担が明確になります。 ### 単一アベイラビリティゾーンに紐づくEBSボリュームと可用性の前提 EBSボリュームは、作成したアベイラビリティゾーン（AZ）に紐づきます。同じAZ内のEC2インスタンスにしか接続できず、別のAZのインスタンスへ直接つなぎ替えることはできません。データはそのAZ内で冗長化されますが、AZ全体の障害までは吸収しない設計です。公式の数値では、gp3・gp2の年間故障率（AFR）は0.2%以下（耐久性99.8〜99.9%）、io2 Block Expressは0.001%以下（耐久性99.999%）とされています。別AZへ移したい場合は、スナップショットを取り、そこから別AZに新しいボリュームを復元する手順を踏みます。可用性を高める設計では、複数AZにまたがってインスタンスとボリュームを分散し、スナップショットで復旧点を確保することが設計上の前提です。 ### オブジェクトストレージ（S3）・インスタンスストアとの用途の違い EBSはブロックストレージで、HTTPベースのAPIでオブジェクトを読み書きする[オブジェクトストレージのAmazon S3を解説した記事](https://www.issoh.co.jp/tech/details/15433/)とは用途が異なります。S3は容量上限を気にせず大量のファイルを預ける保管・配信向けで、OSからボリュームとしてマウントはできません。一方、EC2の物理ホストに直付けされた[インスタンスストア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)は高速ですが、インスタンスを停止・終了すると中身が消える一時領域です。消えては困るデータはEBS、キャッシュやスクラッチ領域はインスタンスストア、大量の静的ファイルやバックアップはS3、という切り分けが基本の判断軸になります。S3のなかでもめったに読まない長期保管は、[Amazon S3 Glacierとはの記事](https://www.issoh.co.jp/tech/details/15443/)で解説するアーカイブ向けクラスへ寄せます。 ### EFS・FSxを含むAWSストレージ4種の比較表で置き場所を決める EBSと混同されやすいのが、ファイルストレージのEFSとFSxです。EBSは原則1台のEC2に接続するディスクで、複数台から同時に読み書きする共有ファイルには向きません。複数のEC2やコンテナから同じディレクトリをNFSでマウントしたいなら[Amazon EFSの違いとマウント手順を解説した記事](https://www.issoh.co.jp/tech/details/3418/)、Windowsファイルサーバーや高性能な並列ファイルシステムが要るなら[Amazon FSxの4つのファイルシステムを解説した記事](https://www.issoh.co.jp/tech/details/15463/)が選択肢に入ります。 | サービス | アクセス方法 | 向く用途 | | ---------- | --------------- | ---------------- | | Amazon EBS | ブロックデバイスとしてマウント | OS・DB・単一EC2の作業領域 | | インスタンスストア | 物理ホスト直付けのディスク | キャッシュ・一時ファイル | | Amazon EFS | NFSで複数台からマウント | 共有ファイル・コンテナ | | Amazon S3 | HTTPのAPIで読み書き | 大量ファイル・バックアップ | ## Amazon EBSのボリュームタイプ6種の性能上限と選び分けの基準 EBSで次に押さえるのがボリュームタイプの選択です。求めるIOPS・スループットと容量、そして単価のバランスから、ワークロードごとに置き場所を決めます。上限値は改定されることがあるため、下の数値は[AWS公式のボリュームタイプ一覧](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)を2026年10月1日に確認した時点のものです。 ### SSD系（gp3/gp2/io2）とHDD系（st1/sc1）の選び分けの起点 EBSのボリュームタイプはSSD系とHDD系に大きく分かれます。SSD系は、汎用のgp3と旧世代のgp2、高性能なプロビジョンドIOPSのio2 Block Express・io1で、細かなランダムアクセスが多いOSやデータベース向けです。HDD系は、大容量のシーケンシャル読み書きに向くst1（スループット重視）と、アクセス頻度の低いデータを安く置くsc1（コールド）で、ログ集約やビッグデータのバッチ処理などに向きます。[HDD系の公式ドキュメント](https://docs.aws.amazon.com/ebs/latest/userguide/hdd-vols.html)のとおり、st1とsc1はブートボリュームにできず、小さなランダムI/Oでは効率が落ちる点に注意が要ります。ランダムアクセスが要るならSSD系、順次読みの大容量ならHDD系、という性能特性の違いが選び分けの起点です。 | ボリュームタイプ | 最大サイズ・最大IOPS | 最大スループット | | ----------------- | ------------------ | ----------- | | gp3（汎用SSD） | 64TiB・80,000 IOPS | 2,000 MiB/s | | gp2（旧世代SSD） | 16TiB・16,000 IOPS | 250 MiB/s | | io2 Block Express | 64TiB・256,000 IOPS | 4,000 MiB/s | | io1（SSD） | 16TiB・64,000 IOPS | 1,000 MiB/s | | st1（スループットHDD） | 16TiB・起動不可 | 500 MiB/s | | sc1（コールドHDD） | 16TiB・起動不可 | 250 MiB/s | ### gp3で容量と独立してIOPS・スループットを指定する考え方 gp3は、容量とは別にIOPSとスループットを指定できる汎用SSDです。[汎用SSDの公式ドキュメント](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html)によると、gp3は容量に関係なく3,000 IOPSと125 MiB/sをベースラインとして料金に含み、追加のIOPSは容量1GiBあたり500 IOPSの比率で最大80,000まで、追加のスループットはIOPS 1あたり0.25 MiB/sの比率で最大2,000 MiB/sまで積み増せます。つまり最大IOPSには160GiB以上、最大スループットには8,000 IOPS以上が必要という計算です。gp3はバーストの仕組みを持たず、指定した性能を継続して出せる点もgp2との違いになります。必要な容量と必要な性能を切り離せるため、性能のために容量を水増しする無駄を削れるのがgp3の利点で、公式にもgp2よりGiB単価が20%低いと記載されています。 ### プロビジョンドIOPS（io2 Block Express）が効く高性能要件の見極め gp3では性能が足りない、あるいは高い耐久性が要る場合に選ぶのが、プロビジョンドIOPSのio2 Block Express・io1です。[プロビジョンドIOPSの公式ドキュメント](https://docs.aws.amazon.com/ebs/latest/userguide/provisioned-iops.html)では、2025年4月30日以降に作成済みも含めたすべてのio2がBlock Expressになり、容量1GiBあたり1,000 IOPSの比率で最大256,000 IOPS、16KiBのI/Oで平均500マイクロ秒未満のレイテンシとされています。ただし64,000 IOPSを超える性能はNitro System上のインスタンスでしか出せず、それ以外のインスタンスでは32,000 IOPSが上限です。基幹データベースや、レイテンシと一貫した性能が売上に直結するワークロードが対象になります。io1/io2はMulti-Attachで同一AZ内の複数インスタンスから同時接続もできますが、単価は汎用SSDより大幅に高いため、まずgp3で足りるかを見て、超えるぶんだけio系へ寄せる順序が無駄を生みません。 ### gp2のバーストクレジット枯渇で性能が落ちる仕組みと監視方法 既存環境でgp2を使い続けている場合に見落としやすいのが、バーストクレジットです。gp2のベースラインIOPSは容量1GiBあたり3 IOPS（最小100、最大16,000）で、1TiB未満のボリュームはI/Oクレジットを消費して一時的に3,000 IOPSまでバーストします。初期クレジットは540万で、3,000 IOPSのバーストを少なくとも30分維持できる量とされています。100GiBのgp2ならベースラインは300 IOPSしかなく、クレジットを使い切ると性能が10分の1に落ちる計算です。夜間バッチの途中で急に遅くなる、といった症状の原因になりやすいため、CloudWatchの`BurstBalance`メトリクスにアラームを設定して残量を監視します。根本的な対策はgp3への移行で、gp3にはバーストがないため、この種の性能劣化そのものが起きません。 ## AWS CLIでEBSボリュームを作成しEC2にアタッチ・マウントする手順 ここからは、データ用のgp3ボリュームを1本作ってEC2に接続し、Linuxで使えるようにするまでの作業をコマンドで示します。VPCやEC2、IAMの初期設定がまだの場合は、[AWS環境構築の手順（VPC・EC2・IAMの初期設計）を解説した記事](https://www.issoh.co.jp/tech/details/15359/)で土台を作ってから進めてください。以下の例は東京リージョン（ap-northeast-1）、AWS CLI v2での実行を想定しています。 ### aws ec2 create-volumeでgp3ボリュームを作成しアタッチする ボリュームは、接続したいEC2と同じAZに作ります。[create-volumeのCLIリファレンス](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-volume.html)にあるとおり、gp3ではIOPSとスループットを別の引数で指定できます。次の例は、100GiB・3,000 IOPS・125 MiB/sの暗号化ボリュームを作り、利用可能になるまで待ってからインスタンスへアタッチする流れです。ボリュームIDとインスタンスIDは自分の環境の値に置き換えてください。 ``` aws ec2 create-volume \ --region ap-northeast-1 \ --availability-zone ap-northeast-1a \ --volume-type gp3 \ --size 100 \ --iops 3000 \ --throughput 125 \ --encrypted \ --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=app-data}]' aws ec2 wait volume-available --volume-ids vol-0123456789abcdef0 aws ec2 attach-volume \ --volume-id vol-0123456789abcdef0 \ --instance-id i-0123456789abcdef0 \ --device /dev/sdf ``` AZを間違えるとアタッチ時にエラーになります。インスタンスのAZは`aws ec2 describe-instances`の`Placement.AvailabilityZone`で確認できるので、作成前に照合しておくと手戻りがありません。 ### lsblk・mkfs・fstabでLinuxにマウントし再起動後も維持する アタッチしただけのボリュームは生のブロックデバイスで、ファイルシステムを作ってマウントするまで使えません。手順は[AWS公式のボリューム利用手順](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-using-volumes.html)に沿っています。スナップショットから復元したボリュームにはすでにファイルシステムがあり、mkfsを実行するとデータが消えるため、必ず`file -s`の結果が`data`であることを確認してから初期化します。 ``` # デバイス名を確認（Nitro系では nvme1n1 のように見える） lsblk # 出力が「data」ならファイルシステムなし＝新規ボリューム sudo file -s /dev/nvme1n1 # 新規ボリュームのときだけ実行する sudo mkfs -t xfs /dev/nvme1n1 sudo mkdir /data sudo mount /dev/nvme1n1 /data # 再起動後も自動マウントするため UUID を控える sudo cp /etc/fstab /etc/fstab.orig sudo blkid # /etc/fstab に次の1行を追記する（UUID は blkid の値） UUID=aebf131c-6957-451e-8d34-ec978d9581ae /data xfs defaults,nofail 0 2 # 記述の誤りがないか、アンマウントして一括マウントで確かめる sudo umount /data sudo mount -a ``` fstabにデバイス名ではなくUUIDを書くのは、デバイス名が起動のたびに変わり得るためです。`nofail`を付けておけば、ボリュームを外した状態で起動してもインスタンスが立ち上がらなくなる事故を防げます。 ### Elastic Volumesで容量とIOPSを無停止で増やしファイルシステムを拡張 運用中に容量や性能が足りなくなったら、Elastic Volumesでインスタンスを止めずに変更します。[Elastic Volumesの公式ドキュメント](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modify-volume.html)によると、サイズの拡張は状態が`optimizing`になった時点、通常は数秒で反映されますが、OS側のファイルシステムは自動では広がりません。[ファイルシステム拡張の公式手順](https://docs.aws.amazon.com/ebs/latest/userguide/recognize-expanded-volume-linux.html)に沿って、パーティションとファイルシステムを順に広げます。 ``` # 100GiB から 200GiB へ、IOPS と スループットも同時に引き上げる aws ec2 modify-volume \ --volume-id vol-0123456789abcdef0 \ --size 200 \ --iops 6000 \ --throughput 250 # 変更の進み具合を確認（optimizing または completed になれば容量は使える） aws ec2 describe-volumes-modifications \ --volume-ids vol-0123456789abcdef0 \ --query "VolumesModifications[0].ModificationState" # パーティションなしで mkfs したデータ用ボリュームは XFS を直接拡張する sudo xfs_growfs -d /data # ルートボリュームのようにパーティションがある場合は先に growpart を実行する sudo growpart /dev/nvme0n1 1 sudo xfs_growfs -d / ``` ## Amazon EBSのスナップショット・暗号化を設定する手順と注意点 EBSは単一AZに紐づくため、バックアップと復旧の設計が可用性の要になります。スナップショットと暗号化の仕組みを押さえ、Elastic Volumesの制約も含めて運用手順を決めておきます。 ### S3に保存される増分スナップショットによるバックアップと復元設計 EBSスナップショットは、特定時点のボリュームの状態をS3に保存するバックアップです。[スナップショットの公式ドキュメント](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html)によると、保存先は利用者が直接触れないS3バケットで、前回から変更されたブロックだけを保存する増分方式になっており、データはリージョン内の全AZに複製されます。そのため、スナップショットから同じリージョンのどのAZにも新しいボリュームを復元でき、別リージョンへコピーすればディザスタリカバリも組めます。同じドキュメントには「AWSはEBSのデータを自動ではバックアップしない」と明記されており、定期取得は利用者の責任です。 ``` # スナップショットを取得する aws ec2 create-snapshot \ --volume-id vol-0123456789abcdef0 \ --description "app-data daily" \ --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=app-data-daily}]' # 別のAZ（ap-northeast-1c）へ復元する aws ec2 create-volume \ --snapshot-id snap-0123456789abcdef0 \ --availability-zone ap-northeast-1c \ --volume-type gp3 ``` 定期取得と世代管理は、[Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-lifecycle.html)でタグ単位に自動化するのが手軽です。EBS以外にRDSやEFSもまとめて保護したい場合は、[AWS Backupの対応サービスとバックアッププラン作成手順を解説した記事](https://www.issoh.co.jp/tech/details/3380/)のように横断のバックアップ計画で管理する方法もあります。 ### KMS連携のEBS暗号化をリージョン既定で有効にするCLI設定 保存データの暗号化は、KMS（Key Management Service）と連携したEBS暗号化で扱います。暗号化を有効にすると、ボリュームだけでなく、インスタンスとボリューム間の転送データ、そこから取得するスナップショットまでが暗号化の対象です。[既定の暗号化に関する公式ドキュメント](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html)では、この設定はリージョン単位で、有効にしても既存のボリュームやスナップショットには影響しないと説明されています。 ``` # 東京リージョンで新規ボリュームの暗号化を既定にする aws ec2 enable-ebs-encryption-by-default --region ap-northeast-1 # 設定状態と既定のKMSキーを確認する aws ec2 get-ebs-encryption-by-default --region ap-northeast-1 aws ec2 get-ebs-default-kms-key-id --region ap-northeast-1 ``` 既存の暗号化ボリュームに紐づくKMSキーは後から変えられず、別のキーで暗号化し直すにはスナップショットのコピー時に指定します。この場合は増分でなくフルコピーになり、保存料金が増える点に注意してください。キーポリシーの設計や料金は[AWS KMSの仕組みとキーポリシー設計を解説した記事](https://www.issoh.co.jp/tech/details/15884/)で整理しています。 ### Elastic Volumesの変更回数上限と縮小できない制約への備え Elastic Volumesは便利ですが、公式ドキュメントに次の制約が明記されています。1つのボリュームを変更できるのは直近24時間で4回までで、前の変更が`completed`になるまで次の変更は受け付けられません。送信した変更は取り消せず、サイズは増やす方向にしか変えられません。縮小したい場合は、小さいボリュームを新しく作り、rsyncなどでデータを移す必要があります。1TiBの変更には最大6時間ほどかかることもあり、変更後の構成での課金は変更開始時点から始まります。容量は「後で増やせる」前提で小さめに始め、縮小が要らない見積もりにしておくのが安全な進め方です。なお、gp2からgp3へタイプだけ変える場合、IOPSとスループットを指定しなければ、元のgp2と同等かgp3のベースラインのうち高い方が自動で設定されます。 ## Amazon EBSの料金を東京リージョンの単価で試算する方法 EBSの料金は、容量・性能・スナップショットの3つに分けて見積もると漏れがありません。ここでは、AWSが公開している価格表（Price List API、2026年9月25日公開版）から取得した東京リージョンの単価で、具体的な月額を計算します。最新の単価は[Amazon EBSの公式料金ページ](https://aws.amazon.com/ebs/pricing/)で確認してください。 ### プロビジョニング量・IOPS・スナップショットで積み上がる料金モデル EBSの料金は、実際に書き込んだ量ではなく、プロビジョニングした容量（GB-month）を基準に課金される点が要注意です。使っていない空き領域も、確保した容量ぶんは料金の発生対象です。これに、gp3やio系で追加指定したIOPS・スループット、スナップショットの保存量（GB-month）、任意の高速スナップショット復元が積み上がります。インスタンスから外したまま放置した「available」状態のボリュームにも容量ぶんの料金が発生し続けるため、棚卸しの最初の対象になります。 | 課金項目（東京リージョン） | 単価（USD） | | ------------------ | ------------ | | gp3 容量 | 0.096／GB月 | | gp3 追加IOPS（3,000超） | 0.006／IOPS月 | | gp3 追加スループット | 0.048／MiBps月 | | gp2 容量 | 0.12／GB月 | | io2 容量 | 0.142／GB月 | | io2 IOPS（32,000まで） | 0.074／IOPS月 | | st1 容量 | 0.054／GB月 | | sc1 容量 | 0.018／GB月 | | スナップショット（標準） | 0.05／GB月 | | スナップショット（アーカイブ） | 0.0125／GB月 | ### gp2からgp3へ移行した場合の月額差を100GiBの例で計算する 100GiBのボリュームで比べると差がはっきりします。gp2は100×0.12＝12.00ドルで、性能はベースライン300 IOPS（バーストで3,000）です。gp3は100×0.096＝9.60ドルで、3,000 IOPS・125 MiB/sが常時使えるため、安くなるうえに性能も上がります。gp3で6,000 IOPS・250 MiB/sまで引き上げても、追加分は3,000×0.006＝18.00ドルと125×0.048＝6.00ドルで、合計33.60ドルです。同じ6,000 IOPSをio2で確保すると、容量14.20ドルにIOPS 6,000×0.074＝444.00ドルが加わり458.20ドルになります。高耐久や低レイテンシが本当に必要な場面を除けば、まずgp3の追加IOPSで要件を満たせるかを試算するのが順当です。 次のPythonは、上の単価で月額を計算する簡単なスクリプトです。容量やIOPSを自社の値に変えて比較に使えます。 ``` # EBSの月額を東京リージョンの単価（2026年9月25日公開版）で試算する PRICE = { "gp3_gb": 0.096, "gp3_iops": 0.006, "gp3_mibps": 0.048, "gp2_gb": 0.12, "io2_gb": 0.142, "io2_iops": 0.074, } def gp3(size_gb, iops=3000, mibps=125): extra_iops = max(iops - 3000, 0) extra_mibps = max(mibps - 125, 0) return (size_gb * PRICE["gp3_gb"] + extra_iops * PRICE["gp3_iops"] + extra_mibps * PRICE["gp3_mibps"]) def gp2(size_gb): return size_gb * PRICE["gp2_gb"] def io2(size_gb, iops): # 32,000 IOPS 以下を前提とした簡易計算 return size_gb * PRICE["io2_gb"] + iops * PRICE["io2_iops"] print(f"gp2 100GiB : {gp2(100):.2f} USD") print(f"gp3 100GiB : {gp3(100):.2f} USD") print(f"gp3 100GiB 6000IOPS : {gp3(100, 6000, 250):.2f} USD") print(f"io2 100GiB 6000IOPS : {io2(100, 6000):.2f} USD") ``` 既存のgp2ボリュームを洗い出してgp3へ切り替えるには、次のコマンドが使えます。タイプ変更はElastic Volumesの1回としてカウントされるため、同じ日に容量変更も予定している場合は回数上限に気をつけてください。 ``` # gp2 のボリュームと、どこにもアタッチされていないボリュームを一覧する aws ec2 describe-volumes \ --filters Name=volume-type,Values=gp2 \ --query "Volumes[].{ID:VolumeId,Size:Size,State:State}" --output table aws ec2 describe-volumes \ --filters Name=status,Values=available \ --query "Volumes[].{ID:VolumeId,Size:Size,Type:VolumeType}" --output table # gp2 から gp3 へ無停止で切り替える aws ec2 modify-volume --volume-id vol-0123456789abcdef0 --volume-type gp3 ``` ### スナップショットアーカイブで長期保管コストを下げる保管期間の条件 月次・年次の保管用や、プロジェクト終了時の最後の1本のように、めったに復元しないスナップショットは[EBSスナップショットアーカイブ](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html)へ移すと保存料金を下げられます。公式には、90日以上保管するスナップショットで最大75%安くなると記載されています。東京の単価は標準0.05ドルに対しアーカイブ0.0125ドルです。AMIを登録解除したあとに残るスナップショットの探し方は、[AWS AMIの登録解除とスナップショットの料金](https://www.issoh.co.jp/tech/details/17998/)で解説しています。ただし、アーカイブ時に増分スナップショットはフルスナップショットへ変換されるため、保存量そのものが増えることがあります。取り出しにも1GBあたり0.03ドルがかかり、90日未満で削除すると残り期間分の料金が発生します。日次の世代管理は標準のまま、長期保管の数世代だけをアーカイブへ回す、という使い分けが実務的です。なお、増分方式のため、スナップショットを1本削除しても、他のスナップショットが参照しているブロックは残り、料金が期待ほど減らない場合があります。 ## Amazon EBSを採用すべき条件と各ストレージとの使い分け ここでは判断を言い切ります。EBSはEC2に接続するブロックデバイスとして強い反面、大量ファイルの保管や、消えてよい一時領域、複数台での共有ファイルの代わりには向きません。自社システムのデータ置き場をどこにするかを、条件付きで見極めてください。 ### Amazon EBSの採用が効くワークロードと要件の条件の見極め 採用が効くのは、EC2上でOSやデータベースを動かし、ブロックデバイスとして永続的に読み書きしたい、という条件が重なるときです。具体的に該当する用途は、EC2のルートボリューム、自前で構築するデータベースのデータ領域、細かい上書きが発生するアプリケーションの作業領域です。停止・終了してもデータを残したいなら、インスタンスストアではなくEBSが前提になります。ボリュームは原則gp3で始め、ベースラインの3,000 IOPSで足りるかをCloudWatchの`VolumeReadOps`・`VolumeWriteOps`で確かめてから追加IOPSを決めると、過剰な性能指定を避けられます。こうしたAWS上のストレージ基盤やEC2構成を自社に取り入れるなら、[AWSを含むクラウドインフラ構築の相談窓口](https://www.issoh.co.jp/service/system/aws/)で、ボリュームタイプの選定やスナップショット運用、IOPSとコストの妥当性を相談するとよいでしょう。 ### EBSが過剰・不要な場面とS3・インスタンスストアへ寄せる切り分け 大量の静的ファイルやバックアップをただ保管・配信したいだけなら、EBSは過剰です。容量上限を気にせず安く預けたい保管・配信はS3、停止時に消えてよいキャッシュやスクラッチ領域はインスタンスストアへ寄せます。EBSは単一AZに紐づき、確保した容量ぶんが課金されるため、AZをまたいで共有したいファイルや、めったに読まないアーカイブをEBSに置くのは割高で用途違いです。複数のEC2から同じファイルを読み書きする必要があるなら、EBSのMulti-Attachに頼るよりEFSを選ぶ方が、ファイルシステム側の排他制御を自前で持たずに済みます。マネージドなデータベースが要る場合は、内部でストレージを管理する[Amazon RDSのようなマネージドDBサービスを解説した記事](https://www.issoh.co.jp/tech/details/15426/)を検討すると、EBSを自前で運用する手間を省けます。アクセス方法（マウントか、APIか、マネージドに任せるか）を軸に選定してください。 ### RAIDや他のストレージと組み合わせる場面での全体の見取り図 EBSは単体でも冗長化されていますが、要件によっては他の仕組みと組み合わせます。オンプレミスのディスク冗長化で使われるRAIDの考え方は、EBSでも複数ボリュームをストライピング（RAID 0）してスループットを稼ぐ設計で応用できます。ただしEBSは各ボリュームが単一AZ内で冗長化済みのため、可用性目的でRAID 1のミラーリングを重ねる必要性は低く、性能目的の使い分けが中心です。gp3の上限が64TiB・80,000 IOPS・2,000 MiB/sまで引き上げられた現在は、単一ボリュームで収まる範囲が広がっており、RAID 0が必要になる場面は以前より限られます。RAIDの各構成と使いどころは、[RAID0/1/5/6/10の違いと冗長化設計を解説した記事](https://www.issoh.co.jp/tech/details/13465/)で整理できます。まずは単一のgp3ボリュームで足りるかを見極め、スループットが不足する場面に限って複数ボリューム構成やio系へ広げる順序が実務的です。 ## よくある質問 Amazon EBSの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。 ### Amazon EBSとインスタンスストアはどう使い分ければよいですか？ 停止・終了してもデータを残したい永続領域はEBS、停止時に消えてよいキャッシュやスクラッチ領域はインスタンスストアが基本の分岐です。インスタンスストアは物理ホスト直付けで高速ですが、インスタンスのライフサイクルとともに中身が消えます。データベースのデータや消えては困るファイルはEBSに置き、一時的な高速領域だけインスタンスストアを使う設計が安全です。 ### gp3とgp2ではどちらを選べばよいですか？ 新規のボリュームはgp3が起点です。東京リージョンのGB単価はgp3が0.096ドル、gp2が0.12ドルで、gp3は容量に関係なく3,000 IOPS・125 MiB/sを常時使えます。gp2はIOPSが容量に比例し、小さいボリュームではバーストクレジットが尽きると性能が落ちる仕組みです。既存のgp2も、Elastic Volumesで無停止のままgp3へタイプ変更できるため、棚卸しのタイミングで切り替えるとコストと性能の両方が改善します。 ### EBSボリュームは別のアベイラビリティゾーンで使えますか？ EBSボリュームは作成したAZに紐づき、別AZのインスタンスへ直接つなぎ替えることはできません。別AZで使いたい場合は、スナップショットを取り、そこから別AZに新しいボリュームを復元します。スナップショットはリージョン内の全AZに複製されており、別リージョンへのコピーもできるため、ディザスタリカバリや地理的な冗長を組む際の起点になります。 ### EBSのスナップショットはどのくらいの頻度で取るべきですか？ 許容できるデータ損失時間（目標復旧時点）から逆算して決めます。更新の激しいデータベースなら数時間ごと、変更の少ないデータなら日次といった具合です。スナップショットは2回目以降が増分保存のため、頻度を上げても保存量の増加は抑えられます。Amazon Data Lifecycle Managerで取得と世代管理を自動化し、90日以上残す長期保管分だけスナップショットアーカイブへ移す運用が実務的です。 ### EBSの料金を抑えるにはどうすればよいですか？ EBSは使用量でなくプロビジョニングした容量に課金されるため、まずどこにもアタッチされていないボリュームと、空き容量の多いボリュームを洗い出します。次にgp2をgp3へ切り替えると、100GiBあたり月12.00ドルが9.60ドルに下がり、性能のために確保していた余分な容量も削減が可能です。加えて、不要になった古いスナップショットをライフサイクルで失効させ、gp3のベースラインで足りる場面では追加IOPSを指定しないことが、コストを適正な水準へ寄せる打ち手になります。 ## 関連記事 - [クラウドとは？AWSとは何かを仕組み・料金・移行の判断まで解説](https://www.issoh.co.jp/column/details/13421/)：EBSの前提となるクラウド・AWS全体像を事業者向けに整理した上位概念の記事 - [Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を解説](https://www.issoh.co.jp/tech/details/15424/)：EBSの接続先となるEC2の仕組みと料金を実装者目線で整理した記事 - [Amazon S3とは？オブジェクトストレージの仕組み・料金・採用判断を解説](https://www.issoh.co.jp/tech/details/15433/)：EBSと用途が異なるオブジェクトストレージの選び分けを整理した記事 - [Amazon EFSとは？S3・EBS・FSxとの違いと東京の料金・マウント手順](https://www.issoh.co.jp/tech/details/3418/)：複数のEC2から共有するファイルストレージを選ぶときの比較対象の記事 - [Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を解説](https://www.issoh.co.jp/tech/details/15426/)：EBSを自前運用する代わりに使えるマネージドDBサービスの記事 - [AWS KMSとは？仕組み・料金とキーポリシー設計・採用判断を解説](https://www.issoh.co.jp/tech/details/15884/)：EBS暗号化の鍵を管理するKMSの設計を整理した記事 - [RAIDとは？RAID0/1/5/6/10の違いと構成・企業のディスク冗長化設計を解説](https://www.issoh.co.jp/tech/details/13465/)：EBSの複数ボリューム構成に応用するRAIDの考え方を整理した記事 --- 出典: [Amazon EBSとは？ボリュームタイプの選び方と東京の料金・CLIでの作成とマウント手順【2026年版】]()（株式会社一創）