翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EBS ボリューム
Amazon EBS ボリュームは、耐久性に優れたブロックレベルのストレージボリュームであり、インスタンスにアタッチできます。ボリュームをインスタンスにアタッチすると、他の物理ハードドライブと同じように使用できます。EBS ボリュームには柔軟性があります。現行世代のインスタンスタイプにアタッチされた現行世代のボリュームの場合、サイズの拡張、プロビジョンド IOPS の容量の変更、実稼働ボリュームのボリュームタイプの変更を動的に行うことができます。
EBS ボリュームは、インスタンス用のシステムドライブ、データベースアプリケーションのストレージなど、頻繁に更新する必要があるデータのプライマリストレージとして使用できます。連続ディスクスキャンを実行するスループットが高いアプリケーションにも使用できます。EBS ボリュームは、EC2 インスタンスの運用状況から独立した永続性を持ちます。
複数の EBS ボリュームを 1 つのインスタンスにアタッチできます。ボリュームとそのアタッチ先インスタンスは同じアベイラビリティーゾーンに存在している必要があります。ボリュームとインスタンスタイプによっては、[マルチアタッチ](ebs-volumes-multi.md)を使用してボリュームを複数のインスタンスに同時にマウントできます。
Amazon EBS には、次ののボリュームタイプが用意されています。汎用 SSD (`gp2` および `gp3`)、プロビジョンド IOPS SSD (`io1` および `io2`)、スループット最適化 HDD (`st1`)、Cold HDD (`sc1`)、磁気 (`standard`) です。それらはパフォーマンス特性と料金が異なるため、アプリケーションのニーズに応じてストレージのパフォーマンスとコストを調整できます。詳細については、「[Amazon EBS ボリュームの種類](ebs-volume-types.md)」を参照してください。
アカウントには、利用できるストレージの合計に制限があります。これらの制限、および制限の引き上げをリクエストする方法についての詳細は、「[Amazon EBS エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/ebs-service.html#limits_ebs)」を参照してください。
*マネージド EBS ボリューム*は、Amazon EKS Auto Mode などのサービスプロバイダーによって管理されます。管理された EBS ボリュームの設定を直接変更することはできません。管理された EBS ボリュームは **管理された**フィールドの **正** 値によって識別されます。詳細については、「[Amazon EC2 マネージドインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html)」を参照してください。
料金の詳細については、[Amazon EBS 料金表](https://aws.amazon.com/ebs/pricing/)を参照してください。
**Topics**
+ [Amazon EBS ボリュームの特徴と利点](EBSFeatures.md)
+ [Amazon EBS ボリュームの種類](ebs-volume-types.md)
+ [Amazon EBS ボリュームの制約](volume_constraints.md)
+ [Amazon EBS ボリュームと NVMe](nvme-ebs-volumes.md)
+ [Amazon EBS ボリュームのライフサイクル](ebs-volume-lifecycle.md)
+ [スナップショットを使用した Amazon EBS ボリュームの置き換え](ebs-restoring-volume.md)
+ [Amazon EBS ボリュームステータスチェック](monitoring-volume-checks.md)
+ [Amazon EBS での障害テスト](ebs-fis.md)
# Amazon EBS ボリュームの特徴と利点
EBS ボリュームには、インスタンスストアボリュームにはない利点があります。
**Topics**
+ [データの可用性](#availability-benefit)
+ [データの永続性](#persistence-benefit)
+ [データの暗号化](#encryption-benefit)
+ [データセキュリティ](#security-benefit)
+ [スナップショット](#backup-benefit)
+ [柔軟性](#flexibility-benefit)
## データの可用性
EBS ボリュームを作成すると、そのボリュームは同じアベイラビリティーゾーン内で自動的にレプリケートされます。これは、1 つのハードウェアコンポーネントの障害が原因でデータが失われることを防ぐためです。EBS ボリュームは、同じアベイラビリティーゾーン内の任意の EC2 インスタンスにアタッチできます。アタッチしたボリュームは、ハードドライブや他の物理デバイスと同じようなネイティブブロックとして表示されます。その時点で、インスタンスはローカルドライブと同じようにボリュームとやり取りできます。インスタンスに接続してファイルシステム (Linux インスタンスの `Ext4` または Windows インスタンスの `NTFS`) を持った EBS ボリュームをフォーマットし、アプリケーションをインストールできます。
指定したデバイスに複数のボリュームをアタッチする場合は、ボリュームにまたがってデータをストライプすることで I/O とスループットのパフォーマンスを向上させることができます。
`io1` および `io2` の EBS ボリュームを、最大 16 個の Nitro ベースのインスタンスにアタッチできます。詳細については、[マルチアタッチを使用して EBS ボリュームを複数の EC2 インスタンスへアタッチ](ebs-volumes-multi.md)を参照してください。それ以外の場合は、EBS ボリュームを 1 つのインスタンスにアタッチできます。
EBS ボリュームのモニタリングデータは無料で取得できます (EBS-backed インスタンスのルートデバイスボリュームのデータも含まれます)。メトリクスのモニタリングの詳細については、[Amazon EBS の Amazon CloudWatch メトリクス](using_cloudwatch_ebs.md)を参照してください。ボリュームのステータスの追跡の詳細については、[Amazon EBS 用 Amazon EventBridge イベント](ebs-cloud-watch-events.md)を参照してください。
## データの永続性
EBS ボリュームは、インスタンスの運用状況に左右されない永続性のあるストレージを提供します。データが維持される限り、ボリュームの使用料が発生します。
EC2 コンソール上で使用する EBS ボリュームを設定するときに [**Delete on Termination (終了時に削除)**] チェックボックスをオフにした場合、実行中のインスタンスにアタッチされている EBS ボリュームを、インスタンスの終了時にデータがそのままの状態でインスタンスから自動的にデタッチすることができます。デタッチされたボリュームは新しいインスタンスに再アタッチできるので、迅速な復旧が可能です。[**Delete on Termination (終了時に削除)**] のチェックボックスがオンの場合、ボリュームは EC2 インスタンスの終了後に削除されます。EBS-backed インスタンスを使用している場合は、アタッチしたボリュームに格納されているデータに影響を与えることなく、インスタンスを停止および再起動できます。ボリュームは停止/起動のサイクルを通じてアタッチされたままです。これにより、必要なときに処理リソースとストレージリソースを使用するだけで、ボリュームでのデータの処理と格納を永続的に実行できるようになります。データは、ボリュームを明示的に削除するまでボリュームに保持されます。削除した EBS ボリュームが使用していた物理的なブロックストレージは、別のアカウントに再割り当てされる前に、ゼロで上書きされます。機密データを扱っている場合は、手動によるデータの暗号化や、Amazon EBS 暗号化 で保護されているボリュームへのデータの格納を検討してください。詳細については、「[Amazon EBS 暗号化](ebs-encryption.md)」を参照してください。
デフォルトでは、インスタンスの起動時に作成およびアタッチされた ルート EBS ボリュームは、インスタンスの終了時に削除されます。この動作を変更するには、インスタンスの起動時にフラグ `DeleteOnTermination` の値を `false` に変更します。値を変更すると、インスタンスが終了してもボリュームが保持されるので、そのボリュームを別のインスタンスにアタッチできます。
デフォルトでは、インスタンスの起動時に作成およびアタッチされた 追加の EBS ボリュームは、インスタンスの終了時に削除されません。この動作を変更するには、インスタンスの起動時にフラグ `DeleteOnTermination` の値を `true` に変更します。値の変更により、ボリュームはインスタンスの終了時に削除されます。
## データの暗号化
簡素化されたデータの暗号化を使用するには、Amazon EBS 暗号化 機能を使用して、暗号化の対象となる EBS ボリュームを作成できます。暗号化は、すべての EBS ボリュームタイプでサポートされています。暗号化された EBS ボリュームを使用することで、規制/監査されるデータとアプリケーションの保管時の広範な暗号化要件に対応できます。Amazon EBS 暗号化では、256 ビットの Advanced Encryption Standard アルゴリズム (AES-256) と Amazon が管理するキーインフラストラクチャが使用されます。暗号化は EC2 インスタンスをホストするサーバーで行われ、EC2 インスタンスから Amazon EBS ストレージに転送されるデータが暗号化されます。詳細については、「[Amazon EBS 暗号化](ebs-encryption.md)」を参照してください。
Amazon EBS 暗号化は、暗号化されたボリュームと、暗号化されたボリュームから作成されたスナップショットを作成する AWS KMS keys ときに を使用します。リージョンで暗号化された EBS ボリュームを初めて作成すると、デフォルトの AWS マネージド KMS キーが自動的に作成されます。このキーは、ユーザーがカスタマーマネージドキーを作成して使用しない限り、Amazon EBS 暗号化に使用されます。独自のカスタマーマネージドキーを作成すると、アクセスコントロールを作成、ローテーション、無効化、定義できるほか、データの保護に使用される暗号化キーを監査できるなど、より高い柔軟性が得られます。詳細については、[AWS Key Management Service デベロッパーガイド](https://docs.aws.amazon.com/kms/latest/developerguide/)を参照してください。
## データセキュリティ
Amazon EBS ボリュームは、初期化されていない raw ブロックデバイスとして表示されます。これらのデバイスは、EBS インフラストラクチャ上に作成される論理デバイスであり、Amazon EBS サービスは、お客様による利用または再利用の前に、デバイスが論理的に空になっている (つまり、raw ブロックがゼロになっている、または暗号で擬似ランダムデータが含まれている) ようにします。
**DoD 5220.22-M** (National Industrial Security Program Operating Manual) や **NIST 800-88** (Guidelines for Media Sanitization) に詳述されているような、使用後もしくは使用前 (またはその両方) に特定の方法を使用してすべてのデータを消去する必要がある手順がある場合、Amazon EBS でこれを行うことができます。ブロックレベルのアクティビティは、Amazon EBS サービス内の基盤となるストレージメディアに反映されます。
## スナップショット
Amazon EBS は、Amazon S3 ボリュームのスナップショット (バックアップ) を作成し、ボリューム内のデータのコピーを EBS に書き込む機能を備えています。そこで、データは複数のアベイラビリティーゾーンに冗長的に保存されます。スナップショットを作成するために、対象のボリュームが実行中のインスタンスにアタッチされている必要はありません。ボリュームにデータを書き込み続けながら、そのボリュームのスナップショットを定期的に作成して、新しいボリュームのベースラインとして使用できます。このスナップショットは、新しい EBS ボリュームを複数作成したり、アベイラビリティーゾーン間でボリュームを移動したりするときに使用できます。暗号化された EBS ボリュームのスナップショットは自動的に暗号化されます。
スナップショットから新規ボリュームを作成する場合、このボリュームはスナップショット作成時における元のボリュームの正確なコピーになります。暗号化されたスナップショットから作成された EBS ボリュームは、自動的に暗号化されます。別のアベイラビリティーゾーンを指定し、この機能を使用してそのゾーンにボリュームを複製することもできます。スナップショットは、特定の AWS アカウントと共有することも、公開することもできます。スナップショットを作成すると、ソースボリュームのサイズではなく、バックアップされるサイズに基づいて、Amazon S3 で料金が発生します。同じボリュームの後続スナップショットは、増分スナップショットです。このスナップショットには、前回のスナップショット作成以降にボリュームに書き込まれた変更データと新規データのみが含まれ、この変更データと新規データに対してのみ料金が発生します。
スナップショットは増分バックアップです。つまり、最後にスナップショットを作成した時点から、ボリューム上で変更のあるブロックだけが保存されます。例えば、100 GiB のデータが格納されているボリュームがあるとします。最後にスナップショットを作成してから、そのうちの 5 GiB 分のデータしか変更されていない場合は、その変更された 5 GiB のデータだけが Amazon S3に書き込まれます。スナップショットの保存は増分ベースで行われるものの、スナップショット削除プロセスは最新のスナップショットのみ保持するように設計されています。
ボリュームとスナップショットを分類および管理しやすくするため、任意のメタデータでタグ付けすることができます。
ボリュームを自動的にバックアップするには、[Amazon Data Lifecycle Manager](snapshot-lifecycle.md) または [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/) を使用できます。
## 柔軟性
EBS ボリュームは、実稼働環境での設定変更をサポートします。サービスを中断せずに、ボリュームタイプ、ボリュームサイズ、IOPS 容量を変更できます。詳細については、[Elastic Volumes オペレーションを使用して Amazon EBS ボリュームを変更する](ebs-modify-volume.md)を参照してください。
# Amazon EBS ボリュームの種類
Amazon EBS では以下のボリュームタイプを提供しており、これらはパフォーマンス特性と料金が異なるため、アプリケーションのニーズに応じてストレージのパフォーマンスとコストを調整できます。
**重要**
インスタンスの構成、I/O 特性、ワークロードのデマンドなど、EBS ボリュームのパフォーマンスに影響を与える可能性がある要因は複数存在します。EBS ボリュームにプロビジョニングされた IOPS を最大限に活用するには、[EBS に最適化されたインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)を使用します。EBS ボリュームを最大限活用するための詳細については、[Amazon EBS ボリュームパフォーマンス](ebs-performance.md)を参照してください。
料金の詳細については、[Amazon EBS 料金表](https://aws.amazon.com/ebs/pricing/)を参照してください。
**ボリュームの種類**
+ [ソリッドステートドライブ (SSD) ボリューム](#vol-type-ssd)
+ [ハードディスクドライブ (HDD) ボリューム](#vol-type-hdd)
+ [旧世代のボリューム](#vol-type-prev)
## ソリッドステートドライブ (SSD) ボリューム
SSD-backed のボリュームは、主要なパフォーマンス属性は IOPS である I/O サイズの小さい頻繁な読み取り/書き込み操作を伴うトランザクションワークロード用に最適化されています。SSD-backed のボリュームタイプには、**汎用 SSD** と**プロビジョンド IOPS SSD** があります。SSD-Backed ボリュームの使用例と特性の概要を次に示します。
| | [Amazon EBS 汎用 SSD ボリューム](general-purpose.md) | [Amazon EBS プロビジョンド IOPS SSD ボリューム](provisioned-iops.md) |
| --- | --- | --- |
| ボリュームタイプ | gp3 6 | gp2 | io2 Block Express | io1 |
| 耐久性 | 99.8%～99.9% の耐久性 (0.1%～0.2% の年間故障率) | 99.999% の耐久性 (0.001% の年間故障率) | 99.8%～99.9% の耐久性 (0.1%～0.2% の年間故障率) |
| ユースケース | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-volume-types.html) | 必要なワークロード [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-volume-types.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-volume-types.html) |
| ボリュームサイズ | 1 GiB～64 TiB | 1GiB - 16TiB | 4 GiB～64 TiB | 4 GiB～16 TiB |
| 最大 IOPS | 80,000 3 (64 KiB I/O 4) | 16,000 (16 KiB I/O 4) | 256,000 3 (16 KiB I/O 4) | 64,000 (16 KiB I/O 4) |
| 最大スループット | 2,000 MiB/秒 | 250 MiB/秒 1 | 4,000 MiB/秒 | 1,000 MiB/秒 2 |
| Amazon EBS マルチアタッチ | サポート外 | サポート |
| NVMe 予約 | サポート外 | サポート | サポートされていません |
| ブートボリューム | サポート |
1 スループットの制限は、ボリュームサイズに応じて 128 MiB/秒〜250 MiB/秒です。詳細については、「[`gp2` ボリュームのパフォーマンス](general-purpose.md#gp2-performance)」を参照してください。**2018 年 12 月 3 日**以前に作成され、作成後に変更されていないボリュームの場合は、[そのボリュームを変更](ebs-modify-volume.md)しない限り、完全なパフォーマンスには到達しない可能性があります。
2 1,000 MiB/秒の最大スループットを実現するには、ボリュームを 64,000 IOPS でプロビジョニングし、[Nitro ベースのインスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)にアタッチする必要があります。**2017 年 12 月 6 日**以前に作成され、作成後に変更されていないボリュームの場合は、[そのボリュームを変更](ebs-modify-volume.md)しない限り、完全なパフォーマンスには到達しない可能性があります。
3 [ Nitro ベースのインスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)は、最大 256,000 IOPS でプロビジョニングされたボリュームをサポートします。他のインスタンスタイプは、最大 64,000 IOPS まででプロビジョニングされたボリュームにアタッチできますが、最大 32,000 IOPS までプロビジョニングできます。
4 ボリュームのスループット上限内で最大 IOPS に達するために必要な I/O サイズを表します。
5 `io2` Block Express ボリュームは、16 KiB の I/O オペレーションで 500 マイクロ秒未満の平均レイテンシーを実現するように設計されています。
6 Outposts では、gp3 ボリュームは最大 16 TiB のサイズ、最大 16,000 の IOPS、最大 1,000 MiB/秒のスループットをサポートします。
SSD-backed のボリュームタイプの詳細については、以下を参照してください。
+ [Amazon EBS 汎用 SSD ボリューム](general-purpose.md)
+ [Amazon EBS プロビジョンド IOPS SSD ボリューム](provisioned-iops.md)
## ハードディスクドライブ (HDD) ボリューム
HDD-backed のボリュームはパフォーマンスの主要な属性がスループットである大規模なストリーミングワークロード用に最適化されています。HDD ボリュームタイプには、**スループット最適化 HDD** と **Cold HDD** があります。以下は、HDD-Backed ボリュームのユースケースと特性の概要です。
| | [スループット最適化 HDD ボリューム](hdd-vols.md#EBSVolumeTypes_st1) | [Cold HDD ボリューム](hdd-vols.md#EBSVolumeTypes_sc1) |
| --- | --- | --- |
| ボリュームタイプ | st1 | sc1 |
| 耐久性 | 99.8%～99.9% の耐久性 (0.1%～0.2% の年間故障率) |
| ユースケース | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-volume-types.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-volume-types.html) |
| ボリュームサイズ | 125 GiB～16 TiB |
| ボリュームあたりの最大 IOPS (1 MiB I/O) | 500 | 250 |
| ボリュームあたりの最大スループット | 500 MiB/秒 | 250 MiB/秒 |
| Amazon EBS マルチアタッチ | サポートされていません |
| ブートボリューム | サポートされていません |
ハードディスクドライブ (HDD) ボリュームの詳細については、「[Amazon EBS スループット最適化 HDD ボリュームと Cold HDD ボリューム](hdd-vols.md)」を参照してください。
## 旧世代のボリューム
マグネティック (`standard`) ボリュームは、磁気ドライブによってバックアップされた旧世代のボリュームです。それらは、データへのアクセス頻度が低く、パフォーマンスが最も重要ではない小規模なデータセットを持つワークロードに適しています。これらのボリュームは、平均約 100 IOPS を実現し、バースト能力は最大約数百 IOPS です。ボリュームのサイズは 1 GiB～1 TiB です。
**ヒント**
磁気ボリュームは、旧世代のボリュームタイプです。旧世代のボリュームより高いパフォーマンスまたはパフォーマンスの整合性が必要であれば、現行世代のボリュームタイプの使用を検討するようお勧めします。
次の表は、旧世代の EBS ボリュームタイプを示しています。
| | マグネティック |
| --- | --- |
| ボリュームタイプ | standard |
| ユースケース | データへのアクセス頻度が低いワークロード |
| ボリュームサイズ | 1 GiB～1 TiB |
| ボリュームあたりの最大 IOPS | 40～200 |
| ボリュームあたりの最大スループット | 40～90 MiB/秒 |
| ブートボリューム | サポート |
# Amazon EBS 汎用 SSD ボリューム
汎用 SSD (gp2 および gp3) ボリュームは、ソリッドステートドライブ (SSD) によってサポートされます。これらは、さまざまなトランザクションワークロードに対して、料金とパフォーマンスのバランスをとります。これらには、仮想デスクトップ、中規模のシングルインスタンスデータベース、レイテンシーの影響を受けやすいインタラクティブなアプリケーション、開発およびテスト環境、およびブートボリュームが含まれます。これらのボリュームは、ほとんどのワークロードに推奨されます。
Amazon EBS は、次のタイプの汎用 SSD ボリュームを提供します。
**Topics**
+ [汎用 SSD (gp3) ボリューム](#gp3-ebs-volume-type)
+ [汎用 SSD (gp2) ボリューム](#EBSVolumeTypes_gp2)
## 汎用 SSD (gp3) ボリューム
汎用 SSD (gp3) ボリュームは、最新世代の汎用 SSD ボリュームであり、Amazon EBS が提供する最も低コストの SSD ボリュームです。このボリュームタイプは、ほとんどの用途で料金とパフォーマンスの適切なバランスを提供するのに役立ちます。また、ボリュームサイズにかかわらず、ボリュームのパフォーマンスをスケールするのにも役立ちます。つまり、追加のブロックストレージ容量をプロビジョニングしなくても、必要なパフォーマンスをプロビジョニングできます。さらに、gp3 ボリュームでは、GiB あたりの料金が汎用 SSD (gp2) ボリュームよりも 20% 低くなります。
gp3 ボリュームは、1 桁ミリ秒のレイテンシーと 99.8% から 99.9% のボリューム耐久性を提供し、年間障害率 (AFR) は 0.2% 以下です。つまり、1 年間で実行中のボリューム 1,000 個あたり最大 2 つのボリューム障害が発生します。 は gp3 ボリュームを AWS 設計して、プロビジョニングされたパフォーマンスを 99% 実現します。
**ヒント**
レイテンシーの影響を受けやすいワークロードの場合は、io2 Block Express ボリュームを使用することをお勧めします。`io2`Block Express ボリュームは、16 KiB の I/O オペレーションで 500 マイクロ秒未満の平均レイテンシーを実現するように設計されています。`io2`Block Express ボリュームでは、汎用ボリュームと比較して外れ値のレイテンシーも改善され、800 マイクロ秒を超える I/O の頻度が 10 分の 1 以下に減少します。詳細については、「[プロビジョンド IOPS SSD (`io2`) Block Express ボリューム](provisioned-iops.md#io2-block-express)」を参照してください。
**Topics**
+ [gp3 ボリュームのパフォーマンス](#gp3-performance)
+ [gp3 ボリュームサイズ](#gp3-sie)
+ [gp2 から gp3 に移行する](#migrate-to-gp3)
### gp3 ボリュームのパフォーマンス
**ヒント**
gp3 ボリュームはバーストパフォーマンスを使用しません。これらは、フルプロビジョンド IOPS とスループットパフォーマンスを無期限に維持できます。
**IOPS パフォーマンス**
gp3 ボリュームは、ストレージの料金に含まれている 3,000 IOPS の一貫したベースライン IOPS パフォーマンスを提供します。追加料金を支払うことで、ボリュームサイズの GiB あたり 500 IOPS の割合で追加の IOPS (最大 80,000 まで) をプロビジョニングできます。最大 IOPS は、160 GiB 以上のボリューム (500 IOPS/GiB × 160 GiB = 80,000 IOPS) にプロビジョニングできます。
**スループットパフォーマンス**
gp3 ボリュームは、ストレージの料金に含まれている 125 MiB/秒の一貫したベースラインスループットパフォーマンスを提供します。追加料金を支払うことで、プロビジョンド IOPS あたり 0.25 MiB/秒の割合で追加のスループット (最大 2,000 MiB/秒) をプロビジョニングできます。最大スループットは、8,000 IOPS 以上かつ 16 GiB 以上 (8,000 IOPS × IOPS あたり 0.25 MiB/秒 = 2,000 MiB/秒) でプロビジョニングできます。
**注記**
Outposts では、gp3 ボリュームは最大 16 TiB のサイズ、最大 16,000 の IOPS、最大 1,000 MiB/秒のスループットをサポートします。
### gp3 ボリュームサイズ
gp3 ボリュームのサイズは 1 GiB～64 TiB です。
### gp2 から gp3 に移行する
現在 gp2 ボリュームを使用している場合は、[Elastic Volumes オペレーションを使用して Amazon EBS ボリュームを変更する](ebs-modify-volume.md) オペレーションを使用してボリュームを gp3 に移行できます。Amazon EBS Elastic Volumes オペレーションを使用して、Amazon EC2 インスタンスを中断することなく、既存のボリュームのボリュームタイプ、IOPS、およびスループットを変更できます。コンソールを使用してボリュームを作成したり、スナップショットから AMI を作成したりする場合、ボリュームタイプには、汎用 SSD `gp3` がデフォルトで選択されます。それ以外の場合は、`gp2` がデフォルトで選択されます。このような場合、`gp2` を使用する代わりに、ボリュームタイプとして `gp3` を選択できます。
gp2 ボリュームを gp3 に移行することでどの程度のコストを削減できるかを調べるには、[Amazon EBS gp2 から gp3 への移行で削減できるコストの計算ツール](https://d1.awsstatic.com/product-marketing/Storage/EBS/gp2_gp3_CostOptimizer.dd5eac2187ef7678f4922fcc3d96982992964ba5.xlsx)を使用してください。
## 汎用 SSD (gp2) ボリューム
これらは、さまざまなトランザクションワークロードに対応できるコスト効率の高いストレージとして使用できます。`gp2` ボリュームを使用すると、ボリュームサイズに応じてパフォーマンスがスケールします。
**ヒント**
`gp3` ボリュームは、汎用 SSD ボリュームの最新世代です。このボリュームは、より予測可能なパフォーマンススケーリングと、`gp2` ボリュームよりも最大 20% 低い料金を提供します。詳細については、「[汎用 SSD (gp3) ボリューム](#gp3-ebs-volume-type)」を参照してください。
`gp2` ボリュームを `gp3` に移行することでどの程度のコストを削減できるかを調べるには、[Amazon EBS gp2 から gp3 への移行で削減できるコストの計算ツール](https://d1.awsstatic.com/product-marketing/Storage/EBS/gp2_gp3_CostOptimizer.dd5eac2187ef7678f4922fcc3d96982992964ba5.xlsx)を使用してください。
`gp2` ボリュームは、1 桁ミリ秒のレイテンシーと 99.8% から 99.9% のボリューム耐久性を提供し、年間障害率 (AFR) は 0.2% 以下です。これは、1 年間で実行中のボリューム 1,000 個あたり最大 2 つのボリューム障害に変換されます。 は、プロビジョニングされたパフォーマンスを 99% の割合で実現するように`gp2`ボリューム AWS を設計します。
**Topics**
+ [`gp2` ボリュームのパフォーマンス](#gp2-performance)
+ [`gp2` ボリュームサイズ](#gp2-size)
### `gp2` ボリュームのパフォーマンス
**IOPS パフォーマンス**
ベースライン IOPS パフォーマンスは、最小 100 から最大 16,000 の間で、ボリュームサイズの GiB あたり 3 IOPS のレートで直線的にスケールします。IOPS パフォーマンスは次のようにプロビジョニングされます。
+ 33.33 GiB 以下のボリュームは、最小 100 IOPS でプロビジョニングされます。
+ 33.33 GiB を超えるボリュームは、最大 16,000 IOPS (5,334 GiB (3 X 5,334) で到達) まで、ボリュームサイズの GiB あたり 3 IOPS でプロビジョニングされます。
+ 5,334 GiB 以上のボリュームは、16,000 IOPS でプロビジョニングされます。
1 TiB 未満の (および 3,000 IOPS 未満でプロビジョニングされた) `gp2` ボリュームは、長期間にわたって必要な場合に 3,000 IOPS に**バースト**できます。ボリュームのバースト機能は I/O クレジットによって制御されます。I/O の需要がベースラインパフォーマンスよりも大きい場合、ボリュームは **I/O クレジットを消費**して、必要なパフォーマンスレベル (最大 3,000 IOPS) までバーストします。バースト中は、I/O クレジットは累積されず、ベースライン IOPS を上回る IOPS (使用率 = バースト IOPS - ベースライン IOPS) を上回る IOPS の割合で消費されます。ボリュームが蓄積した I/O クレジットが多いほど、バーストパフォーマンスを維持できる時間が長くなります。次のように**バースト期間**を計算できます。
```
(I/O credit balance)
Burst duration = ------------------------------
(Burst IOPS) - (Baseline IOPS)
```
I/O の需要がベースラインパフォーマンスレベル以下に低下すると、ボリュームは、ボリュームサイズの GiB あたり 3 I/O クレジット/秒のレートで **I/O クレジットを獲得**し始めます。ボリュームには 540 万 I/O クレジットの **I/O クレジットの累積制限**があり、これは少なくとも 30 分間で 3,000 IOPS の最大バーストパフォーマンスを維持するのに十分です。
**注記**
各ボリュームは、540 万 I/O クレジットの初期 I/O クレジットバランスを受け取ります。これにより、ブートボリュームの高速な初期ブートサイクルと、他のアプリケーションの優れたブートストラップエクスペリエンスが提供されます。
ボリュームサイズとボリュームの関連するベースラインパフォーマンス、バースト期間 (540 万 I/O クレジットから開始)、および空の I/O クレジットバランスを再補充するのにかかる時間の例を次の表に示します。
| ボリュームサイズ (GiB) | ベースラインパフォーマンス (IOPS) | 3000 IOPS におけるバースト期間 (秒) | 空のクレジットバランスを補充する時間 (秒) |
| --- | --- | --- | --- |
| 1～33.33 | 100 | 1,862 | 54,000 |
| 100 | 300 | 2,000 | 18,000 |
| 334 (最大スループットの最小サイズ) | 1,002 | 2,703 | 5,389 |
| 750 | 2,250 | 7,200 | 2,400 |
| 1,000 | 3,000 | 該当なし\$1 | 該当なし\$1 |
| 5,334 (最大 IOPS の最小サイズ) 以上 | 16,000 | 該当なし\$1 | 該当なし\$1 |
\$1 ボリュームのベースラインパフォーマンスが最大バーストパフォーマンスを超えた場合。
Amazon CloudWatch の Amazon EBS `BurstBalance` メトリクスを使用して、ボリュームの I/O クレジットバランスをモニタリングできます。このメトリクスは、残りの `gp2` の I/O クレジットの割合を示します。詳細については、「[Amazon EBS I/O の特性およびモニタリング](ebs-io-characteristics.md)」を参照してください。`BurstBalance` の値が一定のレベルまで下がったときに通知するアラームを設定できます。詳細については、「[CloudWatch アラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)」を参照してください。
**スループットパフォーマンス**
`gp2` ボリュームは、ボリュームサイズに応じて、128 MiB/秒～250 MiB/秒のスループットを提供します。スループットパフォーマンスは次のようにプロビジョニングされます。
+ 170 GiB 以下のボリュームは、最大スループット 128 MiB/秒を提供します。
+ 170 GiB より大きく 334 GiB より小さいボリュームは、250 MiB/秒の最大スループットまでバーストできます。
+ 334 GiB 以上のボリュームは、250 MiB/秒を提供します。
`gp2` ボリュームのスループットは、250 MiB/秒のスループット制限まで、次の計算式を使用して計算できます。
```
Throughput in MiB/s = IOPS performance × I/O size in KiB / 1,024
```
### `gp2` ボリュームサイズ
`gp2` ボリュームのサイズ範囲は、1 GiB～16 TiB です。ボリュームのパフォーマンスはボリュームサイズに比例してスケールすることに注意してください。
# Amazon EBS プロビジョンド IOPS SSD ボリューム
プロビジョンド IOPS SSD ボリュームは、ソリッドステートドライブ (SSD) によってサポートされます。これらは、IOPS が高く、スループットが大量で、低レイテンシーを必要とする、重要なワークロード向けに設計された、最高パフォーマンスの Amazon EBS ストレージボリュームです。プロビジョンド IOPS SSD ボリュームは、期間の 99.9 パーセントにわたり、プロビジョニングされた IOPS パフォーマンスを実現します。
**Topics**
+ [プロビジョンド IOPS SSD (`io2`) Block Express ボリューム](#io2-block-express)
+ [Provisioned IOPS SSD (`io1`) ボリューム](#EBSVolumeTypes_piops)
## プロビジョンド IOPS SSD (`io2`) Block Express ボリューム
`io2` Block Express ボリュームは、次世代の Amazon EBS ストレージサーバーアーキテクチャにビルドされます。[Nitro System 上に構築されインスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)で実行される、最も要求の厳しい I/O 集約型アプリケーションのパフォーマンス要件を満たす目的として構築されています。最高級の耐久性と最小限のレイテンシーを備えた Block Express は、Oracle、SAP HANA、Microsoft SQL Server、SAS Analytics など、パフォーマンス重視のミッションクリティカルなワークロードの実行に最適です。
Block Express アーキテクチャにより、`io2` ボリュームのパフォーマンスとスケールが向上します。Block Express サーバーは、Scalable Reliable Datagram (SRD) ネットワークプロトコルを使用して、[Nitro ベースのインスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)と通信します。このインターフェイスは、インスタンスのホストハードウェア上の Amazon EBS I/O 機能専用の Nitro Card に実装されます。I/O 遅延とレイテンシーのバラツキ (ネットワークジッター) を最小限に抑え、より高速で安定したパフォーマンスをアプリケーションに提供します。
`io2` Block Express ボリュームは、年間故障率 (AFR) が 0.001% 以下で 99.999% のボリューム耐久性を提供するように設計されています。これは、1 年間で実行中のボリューム 100,000 個あたりにつき 1 つのボリュームの故障に相当します。`io2`Block Express ボリュームは、一貫してミリ秒未満のレイテンシーを実現する、単一ボリュームの恩恵を受けるワークロードに適しており、gp3 ボリュームより高い IOPS およびスループットをサポートします。
[Nitro ベースのインスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)にアタッチする場合、`io2` Block Express ボリュームは、16 KiB の I/O オペレーションで 500 マイクロ秒未満の平均レイテンシーを実現するように設計されています。`io2`Block Express ボリュームでは、汎用ボリュームと比較して外れ値のレイテンシーも改善され、800 マイクロ秒を超える I/O の頻度が 10 分の 1 以下に減少します。
**Topics**
+ [考慮事項](#io2-bx-considerations)
+ [パフォーマンス](#io2-bx-perf)
### 考慮事項
+ `io2` Block Express ボリュームは、 AWS リージョン AWS GovCloud (US) と中国リージョンを含むすべての リージョンで使用できます。
+ **2025 年 4 月 30 日**現在、新規および以前に作成されたすべての `io2` ボリュームは `io2` Block Express ボリュームです。
+ [Nitro ベースのインスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)は、最大 256,000 IOPS でプロビジョニングされたボリュームをサポートします。他のインスタンスタイプは、最大 64,000 IOPS まででプロビジョニングされたボリュームにアタッチできますが、最大 32,000 IOPS までプロビジョニングできます。
### パフォーマンス
`io2` Block Express ボリュームには、次の特性があります。
+ 16 KiB の I/O サイズで 500 マイクロ秒未満の平均レイテンシー。汎用ボリュームと比較して外れ値のレイテンシーが改善し、800 マイクロ秒を超える I/O の頻度が 10 分の 1 以下に減少します。
+ 最大 64 TiB (65,536 GiB) までのストレージ容量。
+ IOPS:GiB 比は 1,000:1 の、最大 256,000 のプロビジョンド IOPS。最大 IOPS は、256 GiB 以上でプロビジョニングできます (1,000 IOPS × 256 GiB = 256,000 IOPS)。
**注記**
[Nitro ベースのインスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)で最大 256,000 IOPS を実現できます。他のインスタンスでは、最大 32,000 IOPS を実現できます。
+ 最大 4,000 MiB/秒のボリュームスループット。スループットはプロビジョンド IOPS ごとに 0.256 MiB/秒の割合で比例してスケールします。16,000 IOPS 以上で最大スループットに達します。
![\[io2 Block Express ボリュームのスループット制限\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/io2_bx.png)
## Provisioned IOPS SSD (`io1`) ボリューム
プロビジョンド IOPS SSD (`io1`) ボリュームは、ランダムアクセス I/O スループットにおけるストレージパフォーマンスと整合性が重要な、I/O 集約型ワークロード (特にデータベースワークロード) のニーズを満たすように設計されています。プロビジョンド IOPS SSD ボリュームでは、ボリュームの作成時に指定した、一貫性のある IOPS レートを使用します。Amazon EBS では、プロビジョニングされたパフォーマンスを 99.9% 提供します。
`io1` ボリュームは、1 桁ミリ秒のレイテンシーと 99.8～99.9% のボリューム耐久性を提供し、年間故障率 (AFR) は 0.2% 以下です。これは、1 年間の期間において故障するボリュームの数が、実行中の 1,000 個のボリュームあたり最大 2 個であることを意味します。
`io1` ボリュームは、すべての Amazon EC2 インスタンスタイプで使用できます。
**パフォーマンス**
`io1` ボリュームのサイズは 4 GiB～16 TiB であり、ボリュームあたり 100 IOPS から最大 64,000 IOPS をプロビジョニングできます。リクエストされたボリュームサイズに対するプロビジョンド IOPS の最大割合 (GiB 単位) は 50:1 です。例えば、100 GiB の `io1` ボリュームは最大 5,000 IOPS でプロビジョニングできます。
1,280 GiB 以上のボリュームに対して、最大 IOPS をプロビジョニングできます (50 × 1,280 GiB = 64,000 IOPS)。
+ 最大 32,000 IOPS でプロビジョニングされた `io1` ボリュームは、最大 256 KiB の I/O サイズをサポートし、最大 500 MiB/秒のスループットを生み出します。最大の I/O サイズでは、ピークのスループットが 2,000 IOPS に達します。
+ 32,000 IOPS 超 (最大 64,000 IOPS) でプロビジョニングされた `io1` ボリュームでは、プロビジョンド IOPS あたり 16 KiB のレートでスループットが直線的に増加します。例えば、48,000 IOPS でプロビジョニングされたボリュームは、最大 750 MiB/秒のスループット (プロビジョンド IOPS あたり 16 KiB × 48,000 プロビジョンド IOPS = 750 MiB/秒) をサポートできます。
+ 1,000 MiB/秒の最大スループットを実現するには、ボリュームを 64,000 IOPS (プロビジョンド IOPS あたり 16 KiB × 64,000 プロビジョンド IOPS = 1,000 MiB/秒) でプロビジョニングする必要があります。
+ [Nitro ベースのインスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)でのみ最大 64,000 IOPS を実現できます。他のインスタンスでは、最大 32,000 IOPS を実現できます。
次のグラフは、これらのパフォーマンスの特長を示しています。
![\[io1 ボリュームのスループット制限\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/io1_throughput.png)
発生する I/O あたりのレイテンシーは、プロビジョニングされる IOPS とワークロードプロファイルによって異なります。最適な I/O レイテンシーのエクスペリエンスを得るには、ワークロードの I/O プロファイルを満たすように IOPS をプロビジョニングしてください。
# Amazon EBS スループット最適化 HDD ボリュームと Cold HDD ボリューム
Amazon EBS によって提供される HDD-Backed ボリュームは、次のカテゴリに分類されます。
+ スループット最適化 HDD: 高いスループットを必要とするアクセス頻度の高いワークロード向けの低コストの HDD
+ Cold HDD: アクセス頻度の低いワークロード向けの最も低コストの HDD。
**Topics**
+ [インスタンスごとのスループット制限](#throughput-limitations)
+ [スループット最適化 HDD ボリューム](#EBSVolumeTypes_st1)
+ [Cold HDD ボリューム](#EBSVolumeTypes_sc1)
+ [HDD ボリュームを使用するときのパフォーマンスに関する考慮事項](#EBSVolumeTypes_considerations)
+ [ボリュームのバーストバケットバランスのモニタリング](#monitoring_burstbucket-hdd)
## インスタンスごとのスループット制限
`st1` ボリュームと `sc1` ボリュームのスループットは常に、次のいずれか小さい方によって決定されます。
+ ボリュームのスループット制限
+ インスタンスのスループット制限
ネットワークボトルネックを回避するには、すべての Amazon EBS ボリュームで、EBS 最適化 EC2 インスタンスを選択することをお勧めします。
## スループット最適化 HDD ボリューム
スループット最適化 HDD (`st1`) ボリュームは、IOPS ではなくスループットでパフォーマンスを示す、低コストの磁気ストレージに使用できます。このボリュームタイプは、Amazon EMR、ETL、データウェアハウス、ログ処理など、サイズの大きなシーケンシャルワークロードに適しています。ブート可能な `st1` ボリュームはサポートされていません。
スループット最適化 HDD (`st1`) ボリュームは Cold HDD (`sc1`) ボリュームに類似していますが、アクセスが*頻繁な*データをサポートするように設計されています。
**注記**
このボリュームタイプは、サイズの大きなシーケンシャル I/O が含まれるワークロードに適しています。サイズの小さなランダム I/O を実行するワークロードのお客様には、[Amazon EBS 汎用 SSD ボリューム](general-purpose.md) または [Amazon EBS プロビジョンド IOPS SSD ボリューム](provisioned-iops.md) の使用をお勧めします。詳細については、「[HDD に対する読み取り/書き込みサイズが小さい場合の非効率性](#inefficiency)」を参照してください。
スループット最適化 HDD (`st1`) ボリュームを EBS 最適化インスタンスにアタッチすると、一貫したパフォーマンスが維持され、1 年で 99% の期間、想定されるスループットパフォーマンスの少なくとも 90% のボリュームが提供されます。
### スループットクレジットとバーストパフォーマンス
`gp2` と同様、`st1` でもパフォーマンスのためにバーストバケットモデルが使用されます。ボリュームのベースラインスループット (ボリュームのスループットクレジットが蓄積されるレート) は、ボリュームサイズによって決まります。ボリュームのバーストスループット (クレジットがある場合に可能な消費レート) もボリュームサイズによって決まります。ボリュームが大きいほど、ベースラインとバーストスループットの値も大きくなります。また、ボリュームのクレジットが多いほど、バーストレベルでドライブ I/O に使用できる時間が長くなります。
次の図は、`st1` のバーストバケット動作を示しています。
![\[st1 バーストバケット\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/st1-burst-bucket.png)
スループットとスループットクレジットの上限により、`st1` ボリュームで使用可能なスループットは、以下の計算式で示されます。
```
(Volume size) × (Credit accumulation rate per TiB) = Throughput
```
1 TiB の `st1` ボリュームの場合、バーストスループットは 250 MiB/秒に制限され、バケットのクレジットは 40 MiB/秒で最大 1 TiB 分まで累積されます。
容量が大きいほど、これらの制限はリニアにスケールされ、スループットは最大 500 MiB/秒に制限されます。バケットが枯渇した後は、スループットは TiB あたり 40 MiB/秒のベースラインレートに制限されます。
ボリュームサイズが 0.125～16 TiB の場合、ベースラインスループットの範囲は 5 MiB/秒 ～ 500 MiB/秒 (上限値) です。次に示すように、この最大値には 12.5 TiB で到達します。
```
40 MiB/s
12.5 TiB × ---------- = 500 MiB/s
1 TiB
```
バーストスループットの範囲は、31 MiB/秒～500 MiB/秒 (上限) です。次に示すように、この上限には 2 TiB で到達します。
```
250 MiB/s
2 TiB × ---------- = 500 MiB/s
1 TiB
```
次の表は、`st1` のベーススループット値およびバーストスループット値の範囲を示します。
| ボリュームサイズ (TiB) | ST1 ベーススループット (MiB/秒) | ST1 バーストスループット (MiB/秒) |
| --- | --- | --- |
| 0.125 | 5 | 31 |
| 0.5 | 20 | 125 |
| 1 | 40 | 250 |
| 2 | 80 | 500 |
| 3 | 120 | 500 |
| 4 | 160 | 500 |
| 5 | 200 | 500 |
| 6 | 240 | 500 |
| 7 | 280 | 500 |
| 8 | 320 | 500 |
| 9 | 360 | 500 |
| 10 | 400 | 500 |
| 11 | 440 | 500 |
| 12 | 480 | 500 |
| 12.5 | 500 | 500 |
| 13 | 500 | 500 |
| 14 | 500 | 500 |
| 15 | 500 | 500 |
| 16 | 500 | 500 |
次の図は、テーブルの値をグラフで示したものです。
![\[st1 のベーススループットとバーストスループットの比較\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/st1_base_v_burst.png)
**注記**
スループット最適化 HDD (`st1`) ボリュームのスナップショットを作成すると、スナップショットの進行中はボリュームのベースライン値までパフォーマンスが低下します。
CloudWatch メトリクスとアラームを使用してバーストバケットバランスをモニタリングする方法については、[ボリュームのバーストバケットバランスのモニタリング](#monitoring_burstbucket-hdd)を参照してください。
## Cold HDD ボリューム
Cold HDD (`sc1`) ボリュームは、IOPS ではなくスループットでパフォーマンスを示す、低コストの磁気ストレージに使用できます。`st1` は、`sc1` よりスループット制限が低く、サイズの大きなコールドデータのシーケンシャルワークロードに適しています。データへのアクセス頻度が低く、コストの削減が必要である場合は、低コストなブロックストレージとして `sc1` を使用できます。ブート可能な `sc1` ボリュームはサポートされていません。
Cold HDD (`sc1`) ボリュームは、スループット最適化 HDD (`st1`) ボリュームに類似していますが、アクセス*頻度が低い*データをサポートするように設計されています。
**注記**
このボリュームタイプは、サイズの大きなシーケンシャル I/O が含まれるワークロードに適しています。サイズの小さなランダム I/O を実行するワークロードのお客様には、[Amazon EBS 汎用 SSD ボリューム](general-purpose.md) または [Amazon EBS プロビジョンド IOPS SSD ボリューム](provisioned-iops.md) の使用をお勧めします。詳細については、「[HDD に対する読み取り/書き込みサイズが小さい場合の非効率性](#inefficiency)」を参照してください。
Cold HDD (`sc1`) ボリュームを EBS 最適化インスタンスにアタッチすると、一貫したパフォーマンスが維持され、1 年で 99% の期間、想定されるスループットパフォーマンスの少なくとも 90% のボリュームが提供されます。
### スループットクレジットとバーストパフォーマンス
`gp2` と同様、`sc1` でもパフォーマンスのためにバーストバケットモデルが使用されます。ボリュームのベースラインスループット (ボリュームのスループットクレジットが蓄積されるレート) は、ボリュームサイズによって決まります。ボリュームのバーストスループット (クレジットがある場合に可能な消費レート) もボリュームサイズによって決まります。ボリュームが大きいほど、ベースラインとバーストスループットの値も大きくなります。また、ボリュームのクレジットが多いほど、バーストレベルでドライブ I/O に使用できる時間が長くなります。
![\[sc1 バーストバケット\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/sc1-burst-bucket.png)
スループットとスループットクレジットの上限により、`sc1` ボリュームで使用可能なスループットは、以下の計算式で示されます。
```
(Volume size) × (Credit accumulation rate per TiB) = Throughput
```
1 TiB の `sc1` ボリュームの場合、バーストスループットは 80 MiB/秒に制限され、バケットのクレジットは 12 MiB/秒で最大 1 TiB 分まで累積されます。
容量が大きいほど、これらの制限はリニアにスケールされ、スループットは最大 250 MiB/秒に制限されます。バケットが枯渇した後は、スループットは TiB あたり 12 MiB/秒のベースラインレートに制限されます。
ボリュームサイズが 0.125～16 TiB の場合、ベースラインスループットの範囲は 1.5 MiB/秒～192 MiB/秒 (最大値) です。次に示すように、この最大値には 16 TiB で到達します。
```
12 MiB/s
16 TiB × ---------- = 192 MiB/s
1 TiB
```
バーストスループットの範囲は、10 MiB/秒～250 MiB/秒 (上限) です。次に示すように、この上限には 3.125 TiB で到達します。
```
80 MiB/s
3.125 TiB × ----------- = 250 MiB/s
1 TiB
```
次の表は、`sc1` のベーススループット値およびバーストスループット値の範囲を示します。
| ボリュームサイズ (TiB) | SC1 ベーススループット (MiB/秒) | SC1 バーストスループット (MiB/秒) |
| --- | --- | --- |
| 0.125 | 1.5 | 10 |
| 0.5 | 6 | 40 |
| 1 | 12 | 80 |
| 2 | 24 | 160 |
| 3 | 36 | 240 |
| 3.125 | 37.5 | 250 |
| 4 | 48 | 250 |
| 5 | 60 | 250 |
| 6 | 72 | 250 |
| 7 | 84 | 250 |
| 8 | 96 | 250 |
| 9 | 108 | 250 |
| 10 | 120 | 250 |
| 11 | 132 | 250 |
| 12 | 144 | 250 |
| 13 | 156 | 250 |
| 14 | 168 | 250 |
| 15 | 180 | 250 |
| 16 | 192 | 250 |
次の図は、テーブルの値をグラフで示したものです。
![\[sc1 のベーススループットとバーストスループットの比較\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/sc1_base_v_burst.png)
**注記**
Cold HDD (`sc1`) ボリュームのスナップショットを作成すると、スナップショットの進行中はボリュームのベースライン値までパフォーマンスが低下します。
CloudWatch メトリクスとアラームを使用してバーストバケットバランスをモニタリングする方法については、[ボリュームのバーストバケットバランスのモニタリング](#monitoring_burstbucket-hdd)を参照してください。
## HDD ボリュームを使用するときのパフォーマンスに関する考慮事項
HDD ボリュームを使用して最適なスループットを実現するには、次の考慮事項を念頭に置いてワークロードを計画してください。
### **スループット最適化 HDD と Cold HDD との比較**
`st1` と `sc1` のバケットサイズはボリュームサイズによって異なり、フルバケットにはフルボリュームスキャンのための十分なトークンが含まれています。ただし、`st1` ボリュームと `sc1` ボリュームの場合は、サイズが大きくなるほど、インスタンスごとおよびボリュームごとのスループット制限により、ボリュームスキャンの完了にかかる時間が長くなります。ボリュームが小さなインスタンスにアタッチされている場合は、`st1` または `sc1` のスループット制限よりインスタンスごとのスループットの方に制限されます。
`st1` と `sc1` のいずれも、全体のうち 99% の時間はバーストスループットの 90% のパフォーマンス安定性を実現できるよう設計されています。毎時間、予測合計スループットの 99% 達成を目標に、準拠しない期間はほぼ均一に分散されています。
スキャン時間は、一般的にこの式で示します。
```
Volume size
------------ = Scan time
Throughput
```
例えば、パフォーマンス安定性の保証と他の最適化を想定すると、5 TiB のボリュームを持つ `st1` のお客様は、フルボリュームスキャンが 2.91～3.27 時間で完了すると予測できます。
+ 最適なスキャン時間
```
5 TiB 5 TiB
----------- = ------------------ = 10,486 seconds = 2.91 hours
500 MiB/s 0.00047684 TiB/s
```
+ 最大スキャン時間
```
2.91 hours
-------------- = 3.27 hours
(0.90)(0.99) <-- From expected performance of 90% of burst 99% of the time
```
同様に、5 TiB のボリュームを持つ `sc1` のお客様は、フルボリュームスキャンが 5.83～6.54 時間で完了すると予測できます。
+ 最適なスキャン時間
```
5 TiB 5 TiB
----------- = ------------------- = 20972 seconds = 5.83 hours
250 MiB/s 0.000238418 TiB/s
```
+ 最大スキャン時間
```
5.83 hours
-------------- = 6.54 hours
(0.90)(0.99)
```
次の表は、フルバケットと十分なインスタンススループットを前提として、さまざまなサイズのボリュームに関する最も望ましいスキャン時間を示します。
| ボリュームサイズ (TiB) | ST1 のスキャン時間、バーストを含む (時間)\$1 | SC1 のスキャン時間、バーストを含む (時間)\$1 |
| --- | --- | --- |
| 1 | 1.17 | 3.64 |
| 2 | 1.17 | 3.64 |
| 3 | 1.75 | 3.64 |
| 4 | 2.33 | 4.66 |
| 5 | 2.91 | 5.83 |
| 6 | 3.50 | 6.99 |
| 7 | 4.08 | 8.16 |
| 8 | 4.66 | 9.32 |
| 9 | 5.24 | 10.49 |
| 10 | 5.83 | 11.65 |
| 11 | 6.41 | 12.82 |
| 12 | 6.99 | 13.98 |
| 13 | 7.57 | 15.15 |
| 14 | 8.16 | 16.31 |
| 15 | 8.74 | 17.48 |
| 16 | 9.32 | 18.64 |
\$1 これらのスキャン時間では、1 MiB のシーケンシャル I/O を実行する際のキューの平均深度 (整数に四捨五入) として 4 以上を前提としています。
したがって、スキャンを早く (最大 500 MiB/秒) 完了するために必要なスループット指向のワークロードがある場合や、または 1 日に複数のフルボリュームスキャンが必要な場合は、`st1` を使用してください。コストを最適化している場合、データのアクセス頻度が比較的低い場合、スキャンのパフォーマンスとして 250 MiB/秒を超える必要がない場合は、`sc1` を使用してください。
### HDD に対する読み取り/書き込みサイズが小さい場合の非効率性
`st1` ボリュームおよび `sc1` ボリュームのパフォーマンスモデルは、シーケンシャル I/O 用に最適化され、高スループットのワークロードに適しています。多様な IOPS およびスループットのワークロードに対して許容範囲のパフォーマンスを提供しますが、サイズの小さなランダム I/O のワークロードには向いていません。
例えば、1 MiB 以下の I/O リクエストは、1 MiB の I/O クレジットとしてカウントされます。ただし、I/O がシーケンシャルであれば、1 MiB の I/O ブロックにマージされ、1 MiB の I/O クレジットとしてのみカウントされます。
## ボリュームのバーストバケットバランスのモニタリング
`st1` および `sc1` ボリュームのバーストバケットレベルをモニタリングするには、Amazon CloudWatch の Amazon EBS `BurstBalance` メトリクスを使用します。このメトリクスは、バーストバケット内の残りの `st1` と `sc1` のスループットクレジットを示します。`BurstBalance` メトリクス、および I/O に関連するその他のメトリクスの詳細については、[Amazon EBS I/O の特性およびモニタリング](ebs-io-characteristics.md)を参照してください。CloudWatch では、`BurstBalance` 値があるレベルまで落ち込んだ時に通知するアラームを設定することもできます。詳細については、「[CloudWatch アラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)」を参照してください。
# Amazon EBS ボリュームの制約
Amazon EBS ボリュームのサイズは、ブロックデータストレージの物理学と算術、およびオペレーティングシステム (OS) とファイルシステムデザイナーの実装決定によって制約されます。 は、ボリュームサイズに追加の制限を AWS 課して、サービスの信頼性を保護します。
次のセクションでは、EBS ボリュームの使用可能サイズを制限する最も重要な要素と、EBS ボリュームを設定するための推奨事項について説明します。
**Topics**
+ [ストレージキャパシティ](#ebs-storage-capacity)
+ [サービスの制限](#aws_limits)
+ [パーティションスキーム](#partitioning)
+ [データブロックサイズ](#block_size)
## ストレージキャパシティ
次の表は、Amazon EBS で最も一般的に使用されているファイルシステムに実装された理論的なストレージ容量の概要を示しています (4,096 バイトのブロックサイズと仮定)。
| パーティションスキーム | アドレス可能な最大ブロック | 理論的な最大サイズ (ブロック x ブロックサイズ) | Ext4 に実装される最大サイズ\$1 | XFS に実装される最大サイズ\$1\$1 | NTFS に実装される最大サイズ | EBS による最大サポート数 |
| --- | --- | --- | --- | --- | --- | --- |
| MBR | 232 | 2 TiB | 2 TiB | 2 TiB | 2 TiB | 2 TiB |
| GPT | 264 | 64 ZiB | 1 EiB =1024 2TiB (RHEL7 で認証されている 50 TiB) | 500 TiB (RHEL7 で認証) | 256 TiB | 64 TiB† |
\$1「[Ext4 Howto](https://archive.kernel.org/oldwiki/ext4.wiki.kernel.org/index.php/Ext4_Howto.html)」および「[What are the file and file system size limitations for Red Hat Enterprise Linux?](https://access.redhat.com/solutions/1532)」
\$1\$1「[What are the file and file system size limitations for Red Hat Enterprise Linux?](https://access.redhat.com/solutions/1532)」
† `io2` Block Express ボリュームは、最大 64 TiB のGPT パーティションをサポートします。詳細については、[プロビジョンド IOPS SSD (`io2`) Block Express ボリューム](provisioned-iops.md#io2-block-express)を参照してください。
## サービスの制限
Amazon EBS では、データセンターの大規模な分散ストレージを仮想ハードディスクドライブに抽象化しています。EC2 インスタンスにインストールされたオペレーティングシステムにとって、アタッチされた EBS ボリュームは、512 バイトのディスクセクタを含む物理ハードディスクドライブのように見えます。OS は、ストレージ管理ユーティリティを使用して、データブロック (またはクラスター) をその仮想セクタに割り当てます。この割り当ては、マスターブートレコード (MBR) または GUID パーティションテーブル (GPT) などのボリュームパーティションスキームに準拠しており、インストールされているファイルシステム (ext4、NTFS など) の機能の範囲内で行うことができます。
EBS では、仮想ディスクセクタ内のデータは認識されません。セクタの整合性の保護のみ行われます。つまり、 AWS アクションと OS アクションは互いに独立しています。ボリュームサイズを選択する場合は、次のように機能と制限の両方に注意してください。
+ EBS では現在、最大 64 TiB のボリュームサイズがサポートされています。つまり、最大 64 TiB の EBS ボリュームを作成することはできますが、OS でその容量が認識されるかどうかは、そのOS自体の設計特性と、ボリュームのパーティションスキームによって異なります。
+ ブートボリュームは、MBR または GPT パーティションスキームのいずれかを使用する必要があります。インスタンスを起動する AMI はブートモードを決定し、その後はブートボリュームに使用するパーティションスキームを決定します。
**MBR** を使用すると、ブートボリュームのサイズは 2 TiB に制限されます。
**GPT** を使用すると、GRUB2 (Linux) または UEFI ブートモード (Windows) と使用した場合、ブートボリュームは最大 64 TiB のサイズにすることができます。
詳細については、「[Amazon EBS ボリュームを使用できるようにする](ebs-using-volumes.md)」を参照してください。
+ 2 TiB (2048 GiB) 以上の非ブートボリュームは、ボリューム全体にアクセスするには GPT パーティションテーブルを使用する必要があります。
## パーティションスキーム
他にも影響がある中で、このパーティションスキームは、単一ボリュームで一意にアドレス解決できる論理データブロックの数を決定します。詳細については、[データブロックサイズ](#block_size)を参照してください。使用中の一般的なパーティションスキームは、*マスターブートレコード* (MBR) と *GUID パーティションテーブル* (GPT) です。これらのパーティションスキームの重要な違いは次のようにまとめることができます。
### MBR
MBR では、32 ビットのデータ構造を使用して、ブロックアドレスを格納します。これは、各データブロックが、正の整数 232 のいずれかにマッピングされることを意味します。アドレス可能なボリュームの最大サイズは、次の式により得られます。
```
232 × Block size
```
MBR ボリュームのブロックサイズは、通常 512 バイトに制限されています。したがって、
```
232 × 512 bytes = 2 TiB
```
この MBR ボリュームの 2 TiB の制限を増やすための回避策は、一般的に広く普及していません。したがって、Linux と Windows は、 AWS がサイズを大きくしても、MBR ボリュームが 2 TiB より大きいことを検出しません。
### GPT
GPT では、64 ビットのデータ構造を使用して、ブロックアドレスを格納します。これは、各データブロックが、正の整数 264 のいずれかにマッピングされることを意味します。アドレス可能なボリュームの最大サイズは、次の式により得られます。
```
264 × Block size
```
GPT ボリュームのブロックサイズは、一般的に 4,096 バイトです。したがって、
```
264 × 4,096 bytes
= 264 × 212 bytes
= 270 × 26 bytes
= 64 ZiB
```
実際のコンピュータシステムでは、この理論上の最大値のような大きな値はサポートされていません。実装されたファイルシステムのサイズは現在、ext4 では 50 TiB、NTFS では 256 TiB に制限されています。
## データブロックサイズ
現代のハードドライブ上のデータストレージは、*論理ブロックアドレス*や、オペレーティングシステムで基礎となるハードウェアをほとんど把握することなく論理ブロック内のデータを読み書きできる抽象化レイヤーによって管理されています。オペレーティングシステムは、ストレージデバイスを使用してブロックを物理セクターにマッピングし、セクターサイズの倍数であるデータブロックを使用してデータをディスクに読み書きします。
Amazon EBS は、次の要素に応じて、512 バイトまたは 4,096 バイト (4 KiB) の物理セクターをオペレーティングシステムにアドバタイズします。
1. Amazon EC2 インスタンスタイプ
1. オペレーティングシステム
1. NVMe ドライバーのバージョン
Amazon EBS は、すべての要素でサポートされている場合にのみ、4-KiB の物理セクターをアドバタイズします。これらのいずれかで 4-KiB の物理セクターがサポートされていない場合、Amazon EBS は 512 バイトの物理セクターをアドバタイズします。
**Amazon EC2 インスタンスタイプのサポート**
次の表は、Amazon EBS がさまざまな Amazon EC2 インスタンスタイプに対してアドバタイズするセクターサイズを示しています。
| インスタンスタイプ | Linux | Server |
| --- | --- | --- |
| すべての Xen ベースのインスタンスタイプ | Amazon EBS は常に 512 バイトの物理セクターをアドバタイズします |
| A1 \$1 C5 \$1 C5a \$1 C5ad \$1 C5d \$1 C5n \$1 C6g \$1 C6gd \$1 DL1 \$1 D3 \$1 D3en \$1 G4ad \$1 G4dn \$1 G5 \$1 G5g \$1 I3 \$1 I3en \$1 Inf1 \$1 M5 \$1 M5a \$1 M5ad \$1 M5d \$1 M5dn \$1 M5n \$1 M5zn \$1 M6g \$1 M6gd \$1 P3dn \$1 P4d \$1 P4de \$1 R5 \$1 R5a \$1 R5ad \$1 R5d \$1 R5dn \$1 R5n \$1 R6g \$1 R6gd \$1 T3 \$1 T3a \$1 T4g \$1 U-12tb1 \$1 U-18tb1 \$1 U-24tb1 \$1 U-3tb1 \$1 U-6tb1 \$1 U-9tb1 \$1 X2gd \$1 X2iezn \$1 VT1 \$1 Z1d | Amazon EBS は常に 512 バイトの物理セクターをアドバタイズします | Amazon EBS は 512 バイトまたは 4-KiB の物理セクターをアドバタイズします 1 |
| その他すべての Nitro ベースのインスタンス | Amazon EBS は 512 バイトまたは 4-KiB の物理セクターをアドバタイズします 1 |
1 オペレーティングシステムのサポートによって異なります。次の「」セクションを参照してください。
**オペレーティングシステムのサポート**
次の表は、オペレーティングシステムの例と、Amazon EBS によってアドバタイズされる対応する物理セクターサイズを示しています。これは**網羅的なリストではありません**。オペレーティングシステムで Amazon EBS によってアドバタイズされた物理セクターのサイズを確認することをお勧めします。
| オペレーティングシステム | アドバタイズされた物理セクターサイズ |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/volume_constraints.html) | 512 バイト |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/volume_constraints.html) | 4 KiB |
1 Windows ワークロードの場合は、最新バージョンの [AWS NVMe ドライバー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/aws-nvme-drivers.html)を使用していることを確認してください。Amazon EBS は、 AWS NVMe ドライバーバージョン 1.4.1 以降の 4-KiB 物理セクターをアドバタイズします。
### デフォルト以外のブロックサイズ
論理データブロックの一般的なデフォルトサイズは、現在 4 KiB です。ワークロードによっては、ブロックサイズが小さいまたは大きい方がメリットを得られるため、ファイルシステムはデフォルト以外のブロックサイズをサポートしています。このサイズはフォーマット時に指定できます。デフォルト以外のブロックサイズを使用するシナリオ (最適化など) は、このトピックの対象外ですが、指定したブロックサイズによっては、ボリュームのストレージキャパシティに影響を及ぼす場合があります。次の表に、ブロックサイズの機能としての理論上のストレージキャパシティを示します。ただし、EBS で指定されているボリュームサイズ (io2 Block Express だと 64 TiB) の制限は、現在 16 KiB のデータブロックで使用できる最大サイズと同等であることに注意してください。
| ブロックサイズ | 最大ボリュームサイズ |
| --- | --- |
| 4 KiB (デフォルト) | 16 TiB |
| 8 KiB | 32 TiB |
| 16 KiB | 64 TiB |
| 32 KiB | 128 TiB |
| 64 KiB (最大) | 256 TiB |
# Amazon EBS ボリュームと NVMe
Amazon EBS ボリュームは NVMe ブロックデバイスとして、[AWS Nitro System](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) 上に構築された Amazon EC2 インスタンスで公開されます。NVMe ブロックデバイスとして公開される Amazon EBS ボリュームの機能とパフォーマンスを最大限に活用するには、EC2 インスタンスに AWS NVMe ドライバーがインストールされている必要があります。現行世代のすべての AWS Windows と Linux AMI には、デフォルトで NVMe ドライバーがインストールされています。AWS
AWS NVMe ドライバーを持たない AMI を使用する場合は、手動でインストールできます。詳細については、*Amazon EC2 ユーザーガイド*の [AWSNVMe ドライバー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/aws-nvme-drivers.html)を参照してください。
**Linux インスタンス**
デバイス名は、「`/dev/nvme0n1`」や「`/dev/nvme1n1`」などです。ブロックデバイスマッピングで指定したデバイス名は、NVMe デバイス名 (`/dev/nvme[0-26]n1`) を使用して名称変更されます。ブロックデバイスドライバーは、ブロックデバイスマッピングのボリュームに指定した順序とは異なる順序で NVMe デバイス名を割り当てることができます。
**Windows インスタンス**
インスタンスにボリュームをアタッチする場合はボリュームのデバイス名を含めます。このデバイス名は Amazon EC2 によって使用されます。インスタンスのブロックデバイスドライバーは、ボリュームのマウント時に実際のボリューム名を割り当て、この割り当てられた名前は Amazon EC2 が使用する名前とは異なる可能性があります。
**Topics**
+ [Amazon EBS ボリュームを NVMe デバイス名にマッピング](identify-nvme-ebs-device.md)
+ [Amazon EBS ボリュームの NVMe I/O オペレーションタイムアウト](timeout-nvme-ebs-volumes.md)
+ [Amazon EBS ボリュームの NVMe Abort コマンド](abort-command.md)
# Amazon EBS ボリュームを NVMe デバイス名にマッピング
EBS では、シングルルート I/O 仮想化 (SR-IOV) を使用して、NVMe 規格を使用して Nitro ベースのインスタンスにボリュームをアタッチします。これらのデバイスは、オペレーティングシステムの標準 NVMe ドライバーに依存しています。これらのドライバーは、通常、インスタンスのブート時にアタッチ済みのデバイスを検出し、そのデバイスがブロックデバイスマッピングでどのように指定されているかではなく、デバイスが応答する順序に基づいてデバイスノードを作成します。
## Linux インスタンス
Linux では、NVMe デバイス名は `/dev/nvmen` のパターンに従います。ただし、 は列挙順序で、EBS の場合の は 1 です。場合によっては、デバイスは後続のインスタンスの開始時に異なる順序で検出に応答することがあり、デバイス名が変更されます。また、ブロックデバイスドライバーによって割り当てられるデバイス名は、ブロックデバイスマッピングで指定される名前と異なる場合があります。
インスタンス内の EBS ボリュームには、次のいずれかのような安定した識別子を使用することをお勧めします。
+ Nitro ベースのインスタンスでは、ブロックデバイスマッピングは、EBS ボリュームをアタッチしているとき、または `AttachVolume` か `RunInstances` API コールが、NVMe コントローラー ID のベンダー固有のデータフィールドに取り込まれる際に Amazon EC2 コンソールで指定されます。バージョン 2017.09.01 以降の Amazon Linux AMI で、このデータを読み込んでブロックデバイスマッピングへのシンボリックリンクを作成する `udev` ルールを提供します。
+ EBS ボリューム ID とマウントポイントは、インスタンスの状態が変化しても安定しています。NVMe デバイス名は、インスタンスの起動時にデバイスが応答する順序に応じて変化します。一貫性のあるデバイスを識別するには、EBS ボリューム ID とマウントポイントを使用することをお勧めします。
+ NVMe EBS ボリュームには、EBS ボリューム ID がデバイス ID のシリアル番号として設定されています。シリアル番号を一覧表示するには、`lsblk -o +SERIAL` コマンドを使用します。
+ NVMe デバイス名の形式は、EBS ボリュームがインスタンスの起動中または起動後にアタッチされたかどうかによって異なります。インスタンスの起動後にアタッチされたボリュームの NVMe デバイス名には、`/dev/`プレフィクスが含まれますが、インスタンスの起動中にアタッチされたボリュームの NVMe デバイス名には`/dev/`プレフィクスが含まれません。
+ Amazon Linux または FreeBSD AMI の場合、`sudo ebsnvme-id /dev/nvme0n1 -u` コマンドを使用して、一貫した NVMe デバイス名を指定します。
+ その他のディストリビューションでは`sudo nvme id-ctrl -V /dev/nvme0n1`コマンドを使用して NVMe デバイス名を指定します。`--vendor-specific` コマンドオプションを含める必要がある場合があります。
+ デバイスがフォーマットされると、ファイルシステムの存続期間中、存続する UUID が生成されます。デバイスラベルは同時に指定することができます。詳細については、「[Amazon EBS ボリュームを使用できるようにする](ebs-using-volumes.md) および [間違ったボリュームからの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-booting-from-wrong-volume.html)」を参照してください。
**Amazon Linux AMI**
AMI Amazon Linux 2017.09.01 以降 (Amazon Linux 2 を含む) では､次のように **ebsnvme-id** コマンドを実行して、NVMe デバイス名をボリューム ID とデバイス名にマップすることができます。
次の例は、インスタンスの起動時にアタッチされたボリュームのコマンドと出力を示しています。NVMe デバイス名には、`/dev/`プレフィクスが含まれないことに注意してください。
```
[ec2-user ~]$ sudo /sbin/ebsnvme-id /dev/nvme0n1
Volume ID: vol-01324f611e2463981
sda
```
次の例は、インスタンスの起動後にアタッチされたボリュームのコマンドと出力を示しています。NVMe デバイス名に、`/dev/`プレフィクスが含まれることに注意してください。
```
[ec2-user ~]$ sudo /sbin/ebsnvme-id /dev/nvme1n1
Volume ID: vol-064784f1011136656
/dev/sdf
```
また、Amazon Linux はブロックデバイスマッピング (例えば、`/dev/sdf`) 内のデバイス名から NVMe デバイス名へのシンボリックリンクを作成します。
**FreeBSD AMI**
FreeBSD 12.2-RELEASE 以降では、上記のように **ebsnvme-id** コマンドを実行することができます。NVMe デバイスの名前 (`nvme0` など) またはディスクデバイス (`nvd0` または `nda0`) を渡します。FreeBSD は、ディスクデバイスへのシンボリックリンク (`/dev/aws/disk/ebs/`*volume\$1id* など) も作成します。
**その他の Linux AMI**
カーネルバージョン 4.2 以降では､次のように **nvme id-ctrl** コマンドを実行して、NVMe デバイスをボリューム ID にマップすることができます。最初に、Linux ディストリビューションのパッケージ管理ツールを使用して、NVMe コマンドラインのパッケージ `nvme-cli` をインストールします。他のディストリビューションのダウンロードおよびインストール手順については、ディストリビューションに固有のドキュメントを参照してください。
次の例では、インスタンスの起動時にアタッチされたボリュームのボリューム ID と NVMe デバイス名を取得します｡ NVMe デバイス名には、`/dev/`プレフィクスが含まれないことに注意してください。デバイス名は、NVMe コントローラベンダー固有の拡張子 (コントローラー ID のバイト 384:4095) を介して使用できます。
```
[ec2-user ~]$ sudo nvme id-ctrl -V /dev/nvme0n1
NVME Identify Controller:
vid : 0x1d0f
ssvid : 0x1d0f
sn : vol01234567890abcdef
mn : Amazon Elastic Block Store
...
0000: 2f 64 65 76 2f 73 64 6a 20 20 20 20 20 20 20 20 "sda..."
```
次の例では、インスタンスの起動後にアタッチされたボリュームのボリューム ID と NVMe デバイス名を取得します｡ NVMe デバイス名には、`/dev/`プレフィクスが含まれることに注意してください。
```
[ec2-user ~]$ sudo nvme id-ctrl -V /dev/nvme1n1
NVME Identify Controller:
vid : 0x1d0f
ssvid : 0x1d0f
sn : volabcdef01234567890
mn : Amazon Elastic Block Store
...
0000: 2f 64 65 76 2f 73 64 6a 20 20 20 20 20 20 20 20 "/dev/sdf..."
```
**lsblk** コマンドは、使用可能なデバイスとそのマウントポイント (該当する場合) をリストします。これは、使用する正しいデバイス名を決定するのに役立ちます。この例では、`/dev/nvme0n1p1` がルートデバイスとしてマウントされ、`/dev/nvme1n1` はアタッチされていますがマウントされていません。
```
[ec2-user ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1 259:3 0 100G 0 disk
nvme0n1 259:0 0 8G 0 disk
nvme0n1p1 259:1 0 8G 0 part /
nvme0n1p128 259:2 0 1M 0 part
```
## Windows インスタンス
**ebsnvme-id** コマンドを実行して、NVMe デバイスのディスク番号を EBS ボリューム ID およびデバイス名にマッピングできます。デフォルトでは、すべての EBS NVMe デバイスは列挙されません。特定のデバイスの情報を列挙するには、ディスク番号を渡します。`ebsnvme-id` ツールは、AWS で提供されている最新の Windows Server AMI の、`C:\ProgramData\Amazon\Tools` に含まれています。
AWS NVMe ドライバーパッケージの `1.5.0,` 以降では、`ebsnvme-id` ツールの最新バージョンがドライバーパッケージによってインストールされます。最新バージョンはドライバーパッケージでのみ入手可能です。`ebsnvme-id` ツールのスタンドアロンダウンロードリンクにはアップデートが送信されなくなります。スタンドアロンリンクから入手できる最後のバージョンは `1.1.0` です。このバージョンは [ebsnvme-id.zip](https://s3.amazonaws.com/ec2-windows-drivers-downloads/EBSNVMeID/Latest/ebsnvme-id.zip) リンクを使用してコンテンツを Amazon EC2 インスタンスに抽出することでダウンロード可能となり、`ebsnvme-id.exe` にアクセスできるようになります。
```
PS C:\ProgramData\Amazon\Tools> ebsnvme-id.exe
Disk Number: 0
Volume ID: vol-0d6d7ee9f6e471a7f
Device Name: sda1
Disk Number: 1
Volume ID: vol-03a26248ff39b57cf
Device Name: xvdd
Disk Number: 2
Volume ID: vol-038bd1c629aa125e6
Device Name: xvde
Disk Number: 3
Volume ID: vol-034f9d29ec0b64c89
Device Name: xvdb
Disk Number: 4
Volume ID: vol-03e2dbe464b66f0a1
Device Name: xvdc
```
```
PS C:\ProgramData\Amazon\Tools> ebsnvme-id.exe 4
Disk Number: 4
Volume ID: vol-03e2dbe464b66f0a1
Device Name: xvdc
```
# Amazon EBS ボリュームの NVMe I/O オペレーションタイムアウト
ほとんどのオペレーティングシステムは、NVMe デバイスに送信される I/O オペレーションのタイムアウトを指定します。
**Linux インスタンス**
Linux では、Nitro ベースのインスタンスにアタッチされた EBS ボリュームは、オペレーティングシステムが提供するデフォルトの NVMe ドライバーを使用します。ほとんどのオペレーティングシステムは、NVMe デバイスに送信される I/O オペレーションのタイムアウトを指定します。デフォルトのタイムアウトは 30 秒で、`nvme_core.io_timeout` ブートパラメータを使用して変更できます。バージョン 4.6 より前の Linux カーネルでは、このパラメータは `nvme.io_timeout` です。
I/O レイテンシーがこの timeout パラメータの値を超えると、Linux NVMe ドライバーは I/O に失敗し、ファイルシステムまたはアプリケーションにエラーを返します。I/O オペレーションに応じて、ファイルシステムまたはアプリケーションはエラーを再試行できます。場合によっては、ファイルシステムを読み取り専用として再マウントすることがあります。
Xen インスタンスに接続された EBS ボリュームに類似するエクスペリエンスのため、`nvme_core.io_timeout` を可能な限り最大値に設定することをお勧めします。現在のカーネルでは、最大値は 4294967295 ですが、以前のカーネルでは最大値は 255 です。Linux のバージョンに応じて、タイムアウトはすでにサポートされる最大値に設定されていることがあります。例えば、Amazon Linux AMI 2017.09.01 以降では、デフォルトでタイムアウトが 4294967295 に設定されています。
Linux ディストリビューションの最大値を確認するには、示されている最大値よりも高い値を `/sys/module/nvme_core/parameters/io_timeout` に書き込み、ファイルを保存する際に範囲外の数値結果エラーがないかどうかをチェックします。
**Windows インスタンス**
Windows では､デフォルトのタイムアウトは 60 秒で、最大は 255 秒です。`TimeoutValue` ディスククラスのレジストリ設定は、[SCSI ミニドライバーのレジストリエントリ](https://learn.microsoft.com/en-us/previous-versions/windows/drivers/storage/registry-entries-for-scsi-miniport-drivers)で説明されている手順を使用して変更できます。
# Amazon EBS ボリュームの NVMe Abort コマンド
`Abort` コマンドは、以前にコントローラーに送信された特定のコマンドを中止するために発行される NVMe Admin コマンドです。このコマンドは、通常、I/O オペレーションのタイムアウトしきい値を超えたストレージデバイスに対して、デバイスドライバーによって発行されます。
デフォルトで `Abort` コマンドをサポートする Amazon EC2 インスタンスタイプは、`Abort` コマンドが発行されアタッチされた Amazon EBS デバイスのコントローラーに以前に送信された特定のコマンドを中止します。`Abort` コマンドをサポートしていない Amazon EC2 インスタンスは、アタッチされた Amazon EBS ボリュームに `Abort` コマンドが発行されてもアクションを実行しません。
`Abort` コマンドは、以下でサポートされています。
+ NVMe デバイスバージョン 1.4 以降の Amazon EBS デバイス。
+ Xen ベースのインスタンスタイプと次の Nitro ベースのインスタンスタイプ**を除く**すべての Amazon EC2 インスタンス:
+ 汎用: A1 \$1 M5 \$1 M5a \$1 M5ad \$1 M5d \$1 M5dn \$1 M5n \$1 M5zn \$1 M6g \$1 M6gd \$1 Mac1 \$1 Mac2 \$1 T3 \$1 T3a \$1 T4g
+ コンピューティングの最適化: C5 \$1 c5a \$1 C5ad \$1 C5d \$1 C5n \$1 C6g \$1 C6gd
+ メモリ最適化: R5 \$1 R5a \$1 R5ad \$1 R5d \$1 R5dn \$1 R5n \$1 R6g \$1 R6gd \$1 U-12tb1 \$1 U-18tb1 \$1 U-24tb1 \$1 U-3tb1 \$1 U-6tb1 \$1 U-9tb1 \$1 X2gd \$1 X2iezn \$1 Z1d
+ ストレージ最適化: D3 \$1 D3en \$1 I3en
+ 高速コンピューティング: DL1 \$1 G4ad \$1 G4dn \$1 G5 \$1 G5g \$1 Inf1 \$1 P3dn \$1 P4d \$1 P4de \$1 VT1
詳細については、「[NVM Express の基本仕様](https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf)」のセクション「**5.1 Abort コマンド**」を参照してください。
# Amazon EBS ボリュームのライフサイクル
Amazon EBS ボリュームのライフサイクルは、作成プロセスから始まります。Amazon EBS スナップショットからボリュームを作成するか、空のボリュームを作成できます。ボリュームを使用する前に、ボリュームと同じアベイラビリティーゾーンにある 1 つ以上の Amazon EC2 インスタンスにボリュームをアタッチする必要があります。複数のボリュームを 1 つのインスタンスにアタッチできます。必要に応じて、1 つのインスタンスからボリュームをデタッチし、別のインスタンスにアタッチできます。ストレージ要件が変更された場合、いつでもボリュームのサイズまたはパフォーマンスを変更できます。Amazon EBS スナップショットを作成することにより、ボリュームのポイントインタイムバックアップを作成できます。ボリュームが不要になった場合、それを削除して関連するストレージコストの発生を中止できます。
次の図は、ボリュームライフサイクルの一環としてボリュームに実行できるアクションを示しています。インスタンスに接続してオペレーティングシステムのコマンドを実行することにより、実行するタスクもあります。例えば、ボリュームのフォーマット、ボリュームのマウント、パーティションの管理、空きディスク容量の表示などです。
![\[EBS ボリュームのライフサイクル。\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/volume-lifecycle.png)
**Topics**
+ [ボリュームの作成](ebs-creating-volume.md)
+ [ボリュームをコピーする](ebs-copying-volume.md)
+ [インスタンスへのボリュームのアタッチ](ebs-attaching-volume.md)
+ [複数のインスタンスへのボリュームのアタッチ](ebs-volumes-multi.md)
+ [ボリュームを使用できるようにする](ebs-using-volumes.md)
+ [ボリュームの詳細の表示](ebs-describing-volumes.md)
+ [ボリュームの変更](ebs-modify-volume.md)
+ [インスタンスからのボリュームのデタッチ](ebs-detaching-volume.md)
+ [ボリュームの削除](ebs-deleting-volume.md)
# Amazon EBS ボリュームの作成
Amazon EBS ボリュームを作成し、同じアベイラビリティーゾーン内の任意の EC2 インスタンスにアタッチできます。
**Amazon EBS スナップショットからボリュームを作成**するか、**空のボリュームを作成**できます。スナップショットに基づいて EBS ボリュームを作成した場合、ボリュームは、スナップショットの作成に使用されたボリュームの完全なレプリカとして開始されます。
**ボリュームの初期化**
スナップショットからボリュームを作成した場合、それにアクセスする前に、スナップショットのストレージブロックは Amazon S3 からダウンロードされてボリュームに書き込まれる必要があります。このプロセスはボリューム初期化と呼ばれます。この間、ボリュームの I/O レイテンシーは増加しています。すべてのストレージブロックがダウンロードされてボリュームに書き込まれた後にのみ、フルボリュームのパフォーマンスに達します。
デフォルトのボリューム初期化レートは初期化プロセス全体で変動するため、完了時間が予測できなくなる可能性があります。
ボリューム初期化に関連するパフォーマンスへの影響を最小限に抑えるには、ボリューム初期化のための Amazon EBS プロビジョンドレート (ボリューム初期化レート) または高速スナップショット復元を使用できます。詳細については、「[Amazon EBS ボリュームの初期化](initalize-volume.md)」を参照してください。
**ボリュームの暗号化**
ボリュームの暗号化状態は、アカウントが[デフォルトで暗号化が有効になっているかどうか](encryption-by-default.md)、そして使用を選択する場合はスナップショットの暗号化状態によって異なります。次の表は、考えられる暗号化の結果をまとめたものです。
| デフォルトでの暗号化 | スナップショット使用の有無 | ボリューム暗号化の結果 | メモ |
| --- | --- | --- | --- |
| Disabled | いいえ | オプションの暗号化 | 暗号化を有効にする場合、使用する KMS キーを指定できます。暗号化を有効にしても KMS キーを指定しない場合、 AWS マネージドキー (aws/ebs) が使用されます。 |
| Disabled | はい、暗号化されていません | オプションの暗号化 | 暗号化を有効にする場合、使用する KMS キーを指定できます。暗号化を有効にしても KMS キーを指定しない場合、 AWS マネージドキー (aws/ebs) が使用されます。 |
| Disabled | はい、暗号化されています | 自動暗号化 | 使用する KMS キーを指定できます。KMS キーを指定しない場合、ボリュームはソーススナップショットと同じ KMS キーを使用して暗号化されます。 |
| 有効 | いいえ | 自動暗号化 | 使用する KMS キーを指定できます。KMS キーを指定しない場合、暗号化用に指定されたキーがデフォルトで使用されます。 |
| 有効 | はい、暗号化されていません | 自動暗号化 | 使用する KMS キーを指定できます。KMS キーを指定しない場合、暗号化用に指定されたキーがデフォルトで使用されます。 |
| 有効 | はい、暗号化されています | 自動暗号化 | 使用する KMS キーを指定できます。KMS キーを指定しない場合、ボリュームはソーススナップショットと同じキー (コンソール) またはデフォルトで暗号化用に指定されたキー (CLI/API) を使用して暗号化されます。 |
**その他の考慮事項**
+ ボリュームは、インスタンスと同じアベイラビリティーゾーンにアタッチする必要があります。
+ ボリュームは、`available` 状態になった後にのみ使用できるようになります。
+ コンソールを使用してボリュームを作成する場合、デフォルトのボリュームタイプは `gp3` です。コマンドラインツール、API、および SDK では、デフォルトのボリュームタイプは `gp2` です。
+ Outpost で実行されているインスタンスでボリュームを使用するには、インスタンスと同じ Outpost にボリュームを作成する必要があります。
+ Windows インスタンス用のボリュームを作成し、そのボリュームが 2048 GiB を超える場合は、GPT パーティションテーブルを使用するようにボリュームを設定してください。詳細については、[Amazon EBS ボリュームの制約](volume_constraints.md) と「[2 TB を超えるハードディスクの Windows でのサポート](https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/support-for-hard-disks-exceeding-2-tb)」を参照してください。
+ また、ボリュームは Amazon EC2 インスタンスを起動することで間接的に作成されます。インスタンスの起動に使用した AMI、またはインスタンス起動リクエスト自体に Amazon EBS ボリュームのブロックデバイスマッピングを含めることができます。詳細については、「[ブロックデバイスマッピング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html)」を参照してください。
------
#### [ Console ]
**ボリュームを作成するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで **[ボリューム]** を選択して、**[ボリュームを作成]** を選択します。
1. (*Outpost のお客様のみ*) **Outpost ARN** の場合は、ボリュームを作成する AWS Outpost の ARN を入力します。
1. **[Volume type]** (ボリュームタイプ) に、作成するボリュームのタイプを選択します。使用できるボリュームタイプの詳細については、「[Amazon EBS ボリュームの種類](ebs-volume-types.md)」を参照してください。
1. [**サイズ**] に、ボリュームのサイズ (GiB) を入力します。詳細については、「[Amazon EBS ボリュームの制約](volume_constraints.md)」を参照してください。
1. (*`io1`、`io2`、`gp3` のみ*) **[IOPS]** に、ボリュームが提供する IOPS (1 秒あたりの入力/出力オペレーションの数) の最大数を入力します。
1. (*`gp3` のみ*) **[スループット]** に、ボリュームが提供すべきスループットを MiB/秒単位で入力します。
1. **[アベイラビリティーゾーン]** では、ボリュームを作成するアベイラビリティーゾーンを選択します。
1. **[スナップショット ID]** で、次のいずれかを実行します。
+ 空のボリュームを作成するには、デフォルト値のままにします (**[スナップショットからボリュームを作成しない]**)。
+ スナップショットからボリュームを作成するには、使用するスナップショットを選択します。
1. **[ボリューム初期化レート]** にスナップショットを選択した場合は、オプションでボリューム初期化レートを MiB/秒で指定できます。スナップショットブロックはこのレートで Amazon S3 から作成後のボリュームにダウンロードされます。詳細については、「[ボリューム初期化に Amazon EBS プロビジョンドレートを使用する](initalize-volume.md#volume-initialization-rate)」を参照してください。デフォルトの初期化レート、または高速スナップショット復元 (選択したスナップショットで有効化されている場合) を使用する場合は、レートを指定しないでください。
1. (*`io1` および `io2` のみ*) Amazon EBS マルチアタッチのボリュームを有効にするには、**[マルチアタッチを有効化]** を選択します。詳細については、[マルチアタッチを使用して EBS ボリュームを複数の EC2 インスタンスへアタッチ](ebs-volumes-multi.md)を参照してください。
1. ボリュームの暗号化ステータスを設定します。
+ アカウントにおいて[デフォルトでの暗号化](encryption-by-default.md)が有効になっている場合、暗号化は自動的に有効になり、無効にすることはできません。
+ 暗号化されたスナップショットを選択した場合、暗号化は自動的に行われ、無効にすることはできません。
+ アカウントにおいて[デフォルトでの暗号化](encryption-by-default.md)が有効になっていない、かつ選択したスナップショットが暗号化されていない、またはそもそも選択していない場合、暗号化はオプションです。
1. (*オプション*) ボリュームにカスタムタグを割り当てるには、**[タグ]** セクションで **[タグの追加]** を選択し、タグのキーと値のペアを入力します。
1. **[Create volume]** (ボリュームの作成) を選択します。
1. ボリュームを使用するには、ボリュームが `available` 状態になるまで待ってから、同じアベイラビリティーゾーンの Amazon EC2 インスタンスにアタッチします。詳細については、「[Amazon EBS ボリュームを Amazon EC2 インスタンスにアタッチ](ebs-attaching-volume.md)」を参照してください。
------
#### [ AWS CLI ]
**ボリュームを作成するには**
[create-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-volume.html) コマンドを使用します。次の例では、指定されたアベイラビリティーゾーンにサイズが 100 GiB の空の gp3 ボリュームを作成します。
```
aws ec2 create-volume \
--volume-type gp3 \
--size 100 \
--availability-zone us-east-1a
```
------
#### [ PowerShell ]
**ボリュームを作成するには**
[New-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Volume.html) コマンドレットを使用します。次の例では、指定されたアベイラビリティーゾーンにサイズが 100 GiB の空の gp3 ボリュームを作成します。
```
New-EC2Volume `
-VolumeType gp3 `
-Size 100 `
-AvailabilityZone us-east-1a
```
------
# Amazon EBS ボリュームをコピーする
同じアベイラビリティーゾーン内に Amazon EBS ボリュームのインスタントなポイントインタイムコピーを作成できます。ボリュームコピーは、ソースボリュームのクラッシュコンシステントなpoint-in-timeコピーとして始まります。これには、ボリュームコピーの初期化開始時にソースボリュームに書き込まれたすべてのデータブロックが含まれます。ボリュームコピーは、独自の一意のボリューム ID を取得します。ボリュームコピーはすぐに作成され、`available` 状態になると Amazon EC2 インスタンスにアタッチできます。ボリュームコピーを使用すると、テスト環境と開発環境のために本番データをすばやくコピーできます。
## 初期化
ボリュームコピーは作成後に初期化されます。初期化中、データブロックはソースボリュームからコピーされ、バックグラウンドでボリュームコピーに書き込まれます。初期化が完了するまで、ボリュームは `initializing` 状態のままです。
**初期化中のパフォーマンス**
コピーオペレーションは、ソースボリュームのパフォーマンスには影響しません。コピープロセス中は、ソースボリュームを通常どおり使用し続けることができます。コピーされたボリュームには、ソースボリュームからデータがコピーされるのを待たずにすぐにアクセスできます。ボリュームコピーは、1 桁ミリ秒のレイテンシーでデータへの即時アクセスを提供しますが、実際のレイテンシーはボリュームタイプによって異なることがあります。初期化中、ボリュームコピーは、次の 3 つの値のうち最も低い値に等しい**ベースラインパフォーマンス**を提供します。
+ 3,000 IOPS および 125 MiB/秒
+ **ソースボリューム**のプロビジョニングされたパフォーマンス
+ **ボリュームコピー**のプロビジョニングされたパフォーマンス
次の条件が満たされると、ボリュームコピーがベースラインパフォーマンスを超える場合があります。
1. ソースボリュームとボリュームコピーの両方が 3,000 IOPS および 125 MiB/秒以上でプロビジョニングされる。
1. ソースボリュームのパフォーマンスキャパシティが活用されていない (駆動パフォーマンスがプロビジョニングされたパフォーマンスよりも低い）。
例えば、ソースボリュームが 10,000 IOPS でプロビジョニングされていて、ワークロードが現在 5,000 IOPS しか駆動しておらず、ボリュームコピーが 10,000 IOPS でプロビジョニングされている場合、ボリュームコピーは、ソースボリュームの未使用の 5,000 IOPS を使用して、初期化中に 3,000 IOPS のベースラインパフォーマンスよりも高いパフォーマンスを達成できます。
**初期化期間**
ボリュームコピーの初期化にかかる時間は、ボリュームコピーの作成時にソースボリュームに書き込まれるブロックデータのサイズに依存します。ボリュームコピーはベストエフォートベースで初期化され、次の一般的なガイドラインが適用されます。データブロックの最初の 1 TiB については、ボリュームの初期化に最大 6 時間かかります。最大 16 TiB のデータブロックの後続の各 1 TiB については、初期化に TiB あたり 1.2 時間かかります。16 TiB を超える書き込みデータについては、初期化に 24 時間かかります。
**初期化の進行状況をモニタリングする**
[describe-volume-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volume-status.html) AWS CLI コマンドまたは Amazon EventBridge を使用して、初期化の進行状況をモニタリングできます。詳細については、「[Amazon EBS のボリューム初期化のステータスをモニタリングする](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-initialize-monitor.html)」を参照してください。
## 暗号化
暗号化されたボリュームのコピーは、ソースボリュームと同じ KMS キーで自動的に暗号化されます。暗号化されていないボリュームはコピーできません。
## 考慮事項
+ 暗号化されたソースボリュームからのみ、コピーを作成できます。暗号化されていないソースボリュームからはコピーを作成できません。
+ ソースボリュームから一度に作成できるボリュームコピーは 1 つのみです。同じソースボリュームの後続のコピーは、前のボリュームコピーが完全に初期化された後にのみ、作成できます。
+ 進行中のボリュームコピーは、リージョンごとに最大 5 つ持つことができます。このクォータを超えた場合、`CopyVolumesLimitExceeded` エラーが発生します。必要に応じて、[クォータの引き上げをリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)できます。
+ ソースボリュームと同じアベイラビリティーゾーンにボリュームコピーを作成する必要があります。
+ ボリュームコピーのサイズは、ソースボリュームのサイズ以上である必要があります。
+ ボリュームコピーを作成または初期化している間は、コピーできません。
+ ボリュームコピーを作成するには、ソースボリュームが `available` または `in-use` 状態にあり、ボリュームの変更が `completed` または `optimizing` 状態にある必要があります。
+ ボリュームコピーには、通常の Amazon EBS ボリュームと同じアカウント、リージョンストレージ、および IOPS クォータが適用されます。詳細については、[Amazon EBS クォータ](https://docs.aws.amazon.com/general/latest/gr/ebs-service.html#limits_ebs)を参照してください。
+ コピーオペレーションの進行中にソースボリュームを削除した場合にも、コピーオペレーションは完了します。
+ ソースボリュームに割り当てられたタグは、ボリュームコピーには割り当てられません。
+ Outposts または Wavelength ゾーンのボリュームからコピーを作成することはできません。
## 料金
ボリュームコピーオペレーションを開始すると、ボリュームコピーに書き込まれたデータブロックの GiB ごとに 1 回限りの料金が課金されます。ボリュームコピーの作成後は、アカウント内の他の Amazon EBS ボリュームと同じ方法で課金されます。詳細については、[Amazon EBS の料金表](https://aws.amazon.com/ebs/pricing/)を参照してください。
## ボリュームをコピーする
Amazon EBS ボリュームをコピーするには、次のいずれかの方法を使用します。
------
#### [ Console ]
**ボリュームをコピーするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. コピーするボリュームを選択し、**[アクション]**、**[ボリュームをコピー]** の順にクリックします。
1. **[ボリュームタイプ]** で、コピーのボリュームタイプを選択します。デフォルトのボリュームタイプは **gp3** です。
1. **[サイズ]** に、ボリュームコピーのサイズ (GiB) を入力します。サイズは、ソースボリュームのサイズ以上である必要があります。
1. (*`io1`、`io2`、および `gp3` のみ*) **[IOPS]** に、ボリュームコピーの 1 秒あたりの入出力オペレーション (IOPS) の最大数を入力します。
1. (*`gp3` のみ*) **[スループット]** に、ボリュームコピーのスループットを MiB/秒単位で入力します。
1. (*`io1` および `io2` のみ*) Amazon EBS マルチアタッチのボリュームコピーを有効にするには、**[マルチアタッチを有効化]** を選択します。
1. (*オプション*) ボリュームコピーにカスタムタグを割り当てるには、**[タグ]** セクションで **[タグの追加]** を選択し、タグのキーと値のペアを入力します。
1. **[ボリュームをコピー]** を選択します。
1. コピーされたボリュームは `creating` 状態になり、その後すぐに `available` に移行します。その後、同じアベイラビリティーゾーン内の Amazon EC2 インスタンスにアタッチできます。
------
#### [ AWS CLI ]
**ボリュームをコピーするには**
[copy-volumes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/copy-volumes.html) コマンドを使用します。
次の例では、ボリュームタイプが `gp3`、サイズが `100` GiB、スループットが `250` MiB/秒の `vol-01234567890abcdef` のボリュームコピーを作成します。
```
aws ec2 copy-volumes \
--source-volume-id vol-01234567890abcdef \
--volume-type gp3 \
--size 100 \
--throughput 250
```
------
#### [ PowerShell ]
**ボリュームをコピーするには**
[Copy-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Copy-EC2Volume.html) コマンドレットを使用します。
次の例では、ボリュームタイプが `gp3`、サイズが `100` GiB、スループットが `250` MiB/秒の `vol-01234567890abcdef` のボリュームコピーを作成します。
```
Copy-EC2Volume `
-SourceVolumeId vol-01234567890abcdef `
-VolumeType gp3 `
-Size 100 `
-Throughput 250
```
------
# Amazon EBS ボリュームを Amazon EC2 インスタンスにアタッチ
同じアベイラビリティーゾーンに 1 つ以上のインスタンスに、利用可能な EBS ボリュームをボリュームとしてアタッチできます。
起動時に EBS ボリュームをインスタンスに追加する方法については、「[インスタンスブロックデバイスマッピング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html#instance-block-device-mapping)」を参照してください。
**考慮事項**
+ インスタンスにアタッチできる Amazon EBS ボリュームの最大数はインスタンスタイプによって異なります。インスタンスタイプのボリュームアタッチメント制限を超えると、アタッチメントリクエストは `AttachmentLimitExceeded` エラーで失敗します。詳細については、「[インスタンスボリューム数の制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_limits.html)」を参照してください。
+ ボリュームは、インスタンスと同じアベイラビリティーゾーンに限りアタッチできます。
+ マルチアタッチが有効なボリュームは、最大で 16 個のインスタンスにアタッチできます。詳細については、「[マルチアタッチを使用して EBS ボリュームを複数の EC2 インスタンスへアタッチ](ebs-volumes-multi.md)」を参照してください。
+ ボリュームに AWS Marketplace 製品コードがある場合:
+ 停止されたインスタンスのみにアタッチできます。
+ ボリュームにある AWS Marketplace コードをサブスクライブする必要があります。
+ タイプやオペレーティングシステムなどのインスタンスの設定は、その特定の AWS Marketplace コードをサポートしている必要があります。例えば、Windows インスタンスからのボリュームを Linux インスタンスにアタッチすることはできません。
+ AWS Marketplace コードはボリュームからインスタンスにコピーされます。
+ 指定するこのデバイス名は Amazon EC2 によって使用されます。ブロックデバイスドライバーは、指定したデバイス名とは異なるデバイス名でデバイスをマウントすることがあります。詳細については、「[Amazon EC2 インスタンス上のボリュームのデバイス名](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/device_naming.html)」を参照してください。
+ 場合によっては、`/dev/xvda` または `/dev/sda` にアタッチしたボリューム以外のボリュームが、インスタンスのルートボリュームになることがあります。これは、別のインスタンスのルートボリュームや、ルートボリュームのスナップショットから作成されたボリュームを、既存のルートボリュームのインスタンスにアタッチした場合に起こります。詳細については、「[Linux インスタンスが間違ったボリュームから起動する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-booting-from-wrong-volume.html)」を参照してください。
+ 一部のインスタンスタイプは、複数の EBS カードをサポートしています。EBS カードインデックスを指定することで、アタッチするボリュームの EBS カードを選択できます。インスタンスが複数の EBS カードをサポートしている場合は、[「EBS カード](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs_cards.html)」を参照してください。
+ ルートボリュームは EBS カードインデックス にアタッチする必要があります`0`。
+ 複数の EBS カードをサポートするインスタンスの場合、EBS カードインデックスを指定しない場合、ボリュームは EBS カードインデックス にアタッチされます`0`。
+ 高性能ワークロード用に EC2 インスタンスを設定する場合、EBS カードのパフォーマンス制限に達しないように、パフォーマンス要件に基づいて EBS カード間で EBS ボリュームのバランスを取ることが重要です。
+ インスタンスタイプのボリュームアタッチメント制限は、各 EBS カードに均等に分散されます。たとえば、2 つの EBS カードを持つ`128`ボリュームアタッチメントをサポートする EC2 インスタンスでは、各 EBS カードは最大 個の`64`ボリュームアタッチメントをサポートできます。EBS カードのアタッチメント制限を超えると、リクエストは `CardAttachmentLimitExceeded` エラーで失敗します。
------
#### [ Console ]
**EBS ボリュームをインスタンスにアタッチするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. アタッチするボリュームを選択し、**[Actions]** (アクション)、**[Attach volume]** (ボリュームのアタッチ) の順にクリックします。
1. **[Instance]** (インスタンス) に、インスタンスの ID を入力するか、オプションのリストからインスタンスを選択します。
1. **[デバイス名]** で、以下のいずれかを行います。
+ ルートボリュームの場合は、リストの **[ルートボリューム用に予約済み]** セクションから必要なデバイス名を選択します。通常、AMI に応じて Linux インスタンスは `/dev/sda1` または `/dev/xvda` であり、Windows インスタンスは `/dev/sda1` です。
+ データボリュームの場合は、リストの **[データボリュームに推奨]** セクションから使用可能なデバイス名を選択します。
+ カスタムデバイス名を使用するには、**[カスタムデバイス名を指定]** を選択し、使用するデバイス名を入力します。
1. [**ボリュームのアタッチ**] を選択します。
1. インスタンスに接続し、ボリュームをマウントします。詳細については、「[Amazon EBS ボリュームを使用できるようにする](ebs-using-volumes.md)」を参照してください。
------
#### [ AWS CLI ]
**EBS ボリュームをインスタンスにアタッチするには**
[attach-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/attach-volume.html) コマンドを使用します。次の例では、指定されたデバイス名を使用して、指定されたボリュームを指定されたインスタンスにアタッチします。
```
aws ec2 attach-volume \
--volume-id vol-01234567890abcdef \
--instance-id i-1234567890abcdef0 \
--device /dev/sdf
```
------
#### [ PowerShell ]
**EBS ボリュームをインスタンスにアタッチするには**
[Add-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Add-EC2Volume.html) コマンドレットを使用します。次の例では、指定されたデバイス名を使用して、指定されたボリュームを指定されたインスタンスにアタッチします。
```
Add-EC2Volume `
-VolumeId vol-01234567890abcdef `
-InstanceId i-1234567890abcdef0 `
-Device /dev/sdf
```
------
# マルチアタッチを使用して EBS ボリュームを複数の EC2 インスタンスへアタッチ
Amazon EBS マルチアタッチを使用すると、1 つのプロビジョンド IOPS SSD (`io1` または `io2`) ボリュームを、同じアベイラビリティーゾーンにある複数のインスタンスにアタッチできます。複数のマルチアタッチが有効なボリュームを 1 つのインスタンスまたはインスタンスセットにアタッチできます。ボリュームがアタッチされている各インスタンスには、共有ボリュームに対する完全な読み取りおよび書き込みアクセス許可があります。マルチアタッチを使用すると、同時書き込みオペレーションを管理するアプリケーションで、アプリケーションの可用性を高めることが容易になります。
**料金と請求**
Amazon EBS マルチアタッチの使用に追加料金はかかりません。プロビジョンド IOPS SSD (`io1` および `io2`) ボリュームに適用される標準料金が請求されます。詳細については、[Amazon EBS の料金表](https://aws.amazon.com/ebs/pricing/)を参照してください。
**Topics**
+ [考慮事項と制限](#considerations)
+ [マルチアタッチボリュームのパフォーマンス](ebs-multi-attach-perf.md)
+ [マルチアタッチの有効化](working-with-multi-attach.md)
+ [マルチアタッチの無効化](disable-multi-attach.md)
+ [NVMe 予約](nvme-reservations.md)
## 考慮事項と制限
+ マルチアタッチが有効なボリュームは、同じアベイラビリティーゾーンにある「[Nitro System](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)」に構築された最大 16 のインスタンスにアタッチできます。
+ **Linux インスタンス**は、マルチアタッチが有効な `io1` および `io2` ボリュームをサポートします。**Windows インスタンス**は、マルチアタッチが有効な `io2` ボリュームのみをサポートします。
+ インスタンスにアタッチできる Amazon EBS ボリュームの最大数はインスタンスのタイプとサイズによって異なります。詳細については、「[インスタンスボリューム数の制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_limits.html)」を参照してください。
+ マルチアタッチは、[プロビジョンド IOPS SSD (`io1` および `io2`) ボリューム](provisioned-iops.md#EBSVolumeTypes_piops)でのみサポートされます。
+ `io1` ボリューム用マルチアタッチは次のリージョンでのみ利用できます: 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ソウル)。
`io2` 用のマルチアタッチは、`io2` をサポートするすべてのリージョンで使用できます。
**注記**
パフォーマンス、一貫性、耐久性を低コストで向上させるには、`io2` ボリュームを使用することをお勧めします。
+ マルチアタッチが有効になっている `io1` ボリュームは、Scalable Reliable Datagram (SRD) ネットワークプロトコルのみをサポートする [Nitro System 上に構築されたインスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)ではサポートされません。これらのインスタンスタイプでマルチアタッチを使用するには、`io2` を使用する必要があります。
+ XFS や EXT4 などの標準ファイルシステムは、EC2 インスタンスなどの複数のサーバーから同時にアクセスできるように設計されていません。本稼働ワークロードのデータに対し復元性と信頼性を確保するには、クラスター化されたファイルシステムを使用する必要があります。
+ マルチアタッチが有効な `io2` ボリュームは I/O フェンスをサポートしています。I/O フェンスプロトコルは、データの一貫性を維持するために、共有ストレージ環境での書き込みアクセスを制御します。アプリケーションは、データの整合性を維持するために、アタッチされたインスタンスの書き込み順序を提供する必要があります。詳細については、「[マルチアタッチが有効になっている Amazon EBS ボリュームで NVMe 予約を使用する](nvme-reservations.md)」を参照してください。
マルチアタッチが有効な `io1` ボリュームは I/O フェンスをサポートしていません。
+ マルチアタッチが有効なボリュームは、ブートボリュームとして作成できません。
+ マルチアタッチ対応のボリュームは、インスタンスあたり 1 つのブロックデバイスマッピングにアタッチできます。
+ マルチアタッチは、Amazon EC2 コンソールまたは RunInstances API を使用してインスタンスの起動時に有効にすることはできません。
+ Amazon EBS インフラストラクチャレイヤーに問題があるマルチアタッチが有効なボリュームは、アタッチされているすべてのインスタンスで使用できません。Amazon EC2 またはネットワークレイヤーでの問題は、一部のアタッチされたインスタンスにのみ影響する可能性があります。
+ 次の表は、作成後にマルチアタッチが有効な `io1` および `io2` ボリュームに対するボリューム変更サポートを示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-volumes-multi.html)
\$1 ボリュームがインスタンスにアタッチされている間は、マルチアタッチを有効または無効にすることはできません。
+ マルチアタッチが有効なボリュームは、最後にアタッチされたインスタンスが終了し、そのインスタンスが終了時にボリュームを削除するように設定されている場合、インスタンスの終了時に削除されます。ボリュームが複数のインスタンスにアタッチされ、ボリュームブロックデバイスマッピングで終了時の削除設定が異なる場合、最後にアタッチされたインスタンスのブロックデバイスマッピング設定によって、終了時の削除動作が決まります。
終了時の削除を予測できるようにするには、ボリュームがアタッチされているすべてのインスタンスについて、終了時の削除を有効または無効にします。詳細については、「[インスタンスの終了時にデータを保持する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/preserving-volumes-on-termination.html)」を参照してください。
+ Amazon EBS ボリュームの CloudWatch メトリクスを使用して、マルチアタッチが有効なボリュームをモニタリングできます。データは、アタッチされたすべてのインスタンスにわたって集約されます。アタッチされた個々のインスタンスのメトリクスをモニタリングすることはできません。詳細については、「[Amazon EBS の Amazon CloudWatch メトリクス](using_cloudwatch_ebs.md)」を参照してください。
# マルチアタッチ Amazon EBS ボリュームのパフォーマンス
アタッチされた各インスタンスは、ボリュームのプロビジョニングされた最大パフォーマンスまで IOPS の最大パフォーマンスを引き上げます。ただし、アタッチされたすべてのインスタンスの集計パフォーマンスは、ボリュームのプロビジョニングされた最大パフォーマンスを超えることはできません。アタッチされたインスタンスの IOPS に対する需要がボリュームのプロビジョンド IOPS よりも高い場合、ボリュームはプロビジョニングされたパフォーマンスを超えることはありません。
例えば、`80,000` プロビジョンド IOPSで `io2` マルチアタッチ対応のボリュームを作成し、それを `40,000` プロビジョンド IOPS をサポートする `m7g.large` インスタンスと、`60,000` プロビジョンド IOPS をサポートする ` r7g.12xlarge` インスタンスにアタッチするとします。各インスタンスは、ボリュームのプロビジョンド IOPS `80,000` を下回るため、最大 IOPS を駆動できます。ただし、両方のインスタンスがボリュームへの I/O を同時に駆動する場合、それらの合計 IOPS は、ボリュームのプロビジョニングされた `80,000` IOPS のパフォーマンスを超えることはできません。
整合性のあるパフォーマンスを実現するには、マルチアタッチが有効なボリュームのセクターにわたって、アタッチされたインスタンスから駆動される I/O のバランスを取ることがベストプラクティスです。
Amazon EC2 インスタンスの IOPS パフォーマンスの詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EBS 最適化インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)」を参照してください。
# Amazon EBS ボリュームのマルチアタッチを有効にする
マルチアタッチが有効なボリュームは、他の Amazon EBS ボリュームを管理する場合とほぼ同じ方法で管理できます。ただし、マルチアタッチ機能を使用するには、ボリュームに対してマルチアタッチ機能を有効にする必要があります。
新しいボリュームを作成する場合、マルチアタッチはデフォルトで無効になっています。ボリュームの作成時に、マルチアタッチを有効にできます。
また、作成後の `io2` ボリュームがどのインスタンスにもアタッチされていない場合に限り、マルチアタッチを有効にすることができます。作成後、`io1` ボリュームに対してマルチアタッチを有効にすることはできません。
ボリュームに対してマルチアタッチを有効にした後は、他の EBS ボリュームへアタッチするのと同じ方法でインスタンスにボリュームをアタッチできます。詳細については、「[Amazon EBS ボリュームを Amazon EC2 インスタンスにアタッチ](ebs-attaching-volume.md)」を参照してください。
------
#### [ Console ]
**ボリューム作成中にマルチアタッチを有効にするには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. **[Create volume]** (ボリュームの作成) を選択します。
1. **[ボリュームタイプ]** で、**[プロビジョンド IOPS SSD (`io1`)]** または **[プロビジョンド IOPS SSD (`io2`)]** を選択します。
1. [**Size (サイズ)**] と [**IOPS**] で、必要なボリュームサイズとプロビジョニングする IOPS 数を選択します。
1. **[アベイラビリティーゾーン]** で、インスタンスと同じアベイラビリティーゾーンを選択します。
1. **[Amazon EBS Multi-Attach]** (Amazon EBS マルチアタッチ) で、**[Enable Multi-Attach]** (マルチアタッチの有効化) を選択します。
1. (オプション) **[Snapshot ID]** (スナップショット ID) に、ボリュームの作成元となるスナップショットを選択します。
1. ボリュームの暗号化ステータスを設定します。
選択したスナップショットが暗号化されている場合、またはアカウントが[デフォルトで暗号化を有効にしている](encryption-by-default.md)場合は、暗号化が自動的に有効になり、無効にすることはできません。ボリュームの暗号化に使用する KMS キーを選択できます。
選択したスナップショットが暗号化されておらず、アカウントの暗号化がデフォルトで有効になっていない場合、暗号化はオプションです。ボリュームを暗号化するには、**[Encryption]** (暗号化) で、**[Encrypt this volume]** (このボリュームを暗号化する) を選択し、次にボリュームの暗号化に使用する KMS キーを選択します。
暗号化されたボリュームは、Amazon EBS の暗号化をサポートするインスタンスにのみアタッチすることができます。詳細については、「[Amazon EBS 暗号化](ebs-encryption.md)」を参照してください。
1. (オプション) ボリュームにカスタムタグを割り当てるには、**タグ**セクションで **[Add tag]** (タグの追加) を選択し、タグのキーと値のペアを入力します。
1. **[Create volume]** (ボリュームの作成) を選択します。
**作成後にマルチアタッチを有効にするには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. ボリュームを選択し、**[Actions]** (アクション)、**[Modify volume]** (ボリュームの変更) の順にクリックします。
1. **[Amazon EBS Multi-Attach]** (Amazon EBS マルチアタッチ) で、**[Enable Multi-Attach]** (マルチアタッチの有効化) を選択します。
1. **[Modify]** (変更) を選択します。
------
#### [ AWS CLI ]
**ボリューム作成中にマルチアタッチを有効にするには**
[create-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-volume.html) コマンドを使用して、`--multi-attach-enabled` オプションを指定します。
```
aws ec2 create-volume \
--volume-type io2 \
--multi-attach-enabled \
--size 100 \
--iops 2000 \
--region us-west-2 \
--availability-zone us-west-2b
```
**作成後にマルチアタッチを有効にするには**
[modify-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-volume.html) コマンドを使用して、`--multi-attach-enabled` オプションを指定します。
```
aws ec2 modify-volume \
--volume-id vol-01234567890abcdef \
--multi-attach-enabled
```
------
#### [ PowerShell ]
**ボリューム作成中にマルチアタッチを有効にするには**
`-MultiAttachEnabled` パラメータで [New-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Volume.html) コマンドレットを使用します。
```
New-EC2Volume `
-VolumeType io2 `
-MultiAttachEnabled $true `
-Size 100 `
-Iops 2000 `
-Region us-west-2 `
-AvailabilityZone us-west-2b
```
**作成後にマルチアタッチを有効にするには**
`-MultiAttachEnabled` パラメータで [Edit-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2Volume.html) コマンドレットを使用します。
```
Edit-EC2Volume `
-VolumeId vol-01234567890abcdef `
-MultiAttachEnabled $true
```
------
# Amazon EBS ボリュームのマルチアタッチを無効化
複数のインスタンスにアタッチされている場合にのみ、`io2` ボリュームに対してマルチアタッチを無効にできます。
`io1` ボリュームの作成後にマルチアタッチを無効にすることはできません。
------
#### [ Console ]
**マルチアタッチの作成後に無効にするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. ボリュームを選択し、**[Actions]** (アクション)、**[Modify volume]** (ボリュームの変更) の順にクリックします。
1. **[Amazon EBS Multi-Attach]** (Amazon EBS マルチアタッチ) で、**[Enable Multi-Attach]** (マルチアタッチを有効化) の選択を解除します。
1. **[Modify]** (変更) を選択します。
------
#### [ AWS CLI ]
**マルチアタッチの作成後に無効にするには**
[modify-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-volume.html) コマンドを使用して、`-no-multi-attach-enabled` オプションを指定します。
```
aws ec2 modify-volume \
--volume-id vol-01234567890abcdef \
--no-multi-attach-enabled
```
------
#### [ PowerShell ]
**マルチアタッチの作成後に無効にするには**
`-MultiAttachEnabled` パラメータで [Edit-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2Volume.html) コマンドレットを使用します。
```
Edit-EC2Volume `
-VolumeId vol-01234567890abcdef `
-MultiAttachEnabled $false
```
------
# マルチアタッチが有効になっている Amazon EBS ボリュームで NVMe 予約を使用する
マルチアタッチ対応の `io2` ボリュームは、業界標準のストレージフェンシングプロトコルのセットである NVMe 予約をサポートします。これらのプロトコルにより、複数のインスタンスから共有ボリュームへのアクセスを制御し、調整する予約を、作成および管理できます。共有ストレージアプリケーションが予約を使用して、データ整合性が確保されます。
**Topics**
+ [要件](#nvme-reservations-reqs)
+ [NVMe 予約のサポートを有効にする](#nvme-reservations-enable)
+ [サポートされている NVMe 予約コマンド](#nvme-reservations-commands)
+ [料金](#nvme-reservations-cost)
## 要件
NVMe 予約は、`io2` マルチアタッチ対応ボリュームでのみサポートされます。マルチアタッチが有効なボリュームは、Nitro システムで構築されたインスタンスにのみアタッチできます。
NVMe 予約は、次のオペレーティングシステムでサポートされています。
+ SUSE Linux Enterprise 12 SP3 以降
+ RHEL 8.3 以降
+ Amazon Linux 2 以降
+ Windows Server 2016 以降
**注記**
サポートされている、2023年 9 月 13 日以降の Windows Server AMI には、必要な NVMe ドライバーが含まれています。それ以前の AMI では、NVMe ドライバーバージョンを 1.5.0 以降に更新する必要があります。詳細については、「[AWS NVMe ドライバー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/aws-nvme-drivers.html)」を参照してください。
EC2Launch v2 を使用してディスクを初期化する場合は、バージョン **2.0.1521** 以降にアップグレードする必要があります。詳細については、「[EC2 Windows インスタンスの起動時に EC2Launch v2 エージェントを使用してタスクを実行する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2launch-v2.html)」を参照してください。
## NVMe 予約のサポートを有効にする
**2023 年 9 月 18 日** 以降に作成された、すべてのマルチアタッチ対応 `io2` ボリュームで、NVMe 予約のサポートがデフォルトで有効になっています。
2023 年 9 月 18 日より前に作成された既存の `io2` ボリュームで、NVMe 予約のサポートを有効にするには、ボリュームからすべてのインスタンスをデタッチし、必要なインスタンスをアタッチしなおす必要があります。すべてのインスタンスをデタッチした後にアタッチを行うと、NVMe 予約が有効になります。
## サポートされている NVMe 予約コマンド
Amazon EBS は、次の NVMe 予約コマンドをサポートしています。
**予約登録**
予約キーの登録と解除、または置き換えを行います。登録キーによりインスタンスを識別、または認証します。予約キーをボリュームに登録すると、インスタンスとボリュームが関連付けられます。インスタンスが予約を取得するには、インスタンスをボリュームに登録する必要があります。
**予約取得**
ボリュームの予約の取得、名前空間による先行予約の保持、ボリュームで保持している予約の中止を行います。次の予約タイプを取得できます。
+ 排他的書き込み予約
+ 排他的アクセス予約
+ 排他的書き込み - 登録者限定予約
+ 排他的アクセス - 登録者限定予約
+ 排他的書き込み - 全登録者用予約
+ 排他的アクセス - 全登録者用予約
**予約解除**
ボリュームに保持されている予約を、解除またはクリアします。
**予約レポート**
ボリュームの登録状況と予約状況について説明します。
## 料金
マルチアタッチを有効にする際、または使用する際に、追加料金はかかりません。
# Amazon EBS ボリュームを使用できるようにする
Amazon EBS ボリュームをインスタンスにアタッチすると、ブロックデバイスとして公開されます。任意のファイルシステムでボリュームをフォーマットし、マウントできます。EBS ボリュームを使用できるようにすると、他のボリュームと同じようにアクセスできます。このファイルシステムに書き込まれるデータはすべて EBS ボリュームに書き込まれますが、デバイスを使用するアプリケーションには透過的になります。
EBS ボリュームのスナップショットは、バックアップ目的で作成したり、別のボリュームを作成する際のベースラインとして使用したりできます。詳細については、「[Amazon EBS スナップショット](ebs-snapshots.md)」を参照してください。
使用準備中の EBS ボリュームが 2 TiB を超える場合は、GPT パーティショニングスキームを使用してボリューム全体にアクセスする必要があります。詳細については、「[Amazon EBS ボリュームの制約](volume_constraints.md)」を参照してください。
## Linux インスタンス
### アタッチ済みボリュームのフォーマットとマウント
ルートデバイス用の EBS ボリューム `/dev/xvda` を持つ EC2 インスタンスがあり、`/dev/sdf` を使用して空の EBS ボリュームをインスタンスにアタッチしたとします。新たなアタッチ済みボリュームを使用するには、次の手順を使用します。
**Linux で EBS ボリュームをフォーマットしてマウントするには**
1. SSH を使用してインスタンスに接続します。詳細については、「[Linux インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)」を参照してください。
1. ブロックデバイスマッピングで指定したものとは異なるデバイス名を使用して、デバイスをインスタンスにアタッチすることができます。詳細については、「[Linux インスタンスでのデバイス名](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/device_naming.html)」を参照してください。**lsblk** コマンドを使用して、使用可能なディスクデバイスとマウントポイント (該当する場合) を表示し、使用する正しいデバイス名を決定します。**lsblk** の出力は、フルデバイスパスから `/dev/` プレフィクスを削除します。
次の内容は、EBS ボリュームを NVMe ブロックデバイスとして公開する「[Nitro System](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)」で構築されたインスタンスの出力例を示します。ルートデバイス`/dev/nvme0n1`には、`nvme0n1p1`および`nvme0n1p128`という名前の 2 つのパーティションがあります。アタッチされているボリュームは `/dev/nvme1n1` パーティションがなく、まだマウントされていません。
```
[ec2-user ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1 259:0 0 10G 0 disk
nvme0n1 259:1 0 8G 0 disk
-nvme0n1p1 259:2 0 8G 0 part /
-nvme0n1p128 259:3 0 1M 0 part
```
以下は T2 インスタンスの出力例です。ルートデバイス`/dev/xvda`には、`xvda1`という名前のパーティションが 1 つあります。アタッチされているボリュームは `/dev/xvdf` パーティションがなく、まだマウントされていません。
```
[ec2-user ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
-xvda1 202:1 0 8G 0 part /
xvdf 202:80 0 10G 0 disk
```
1. ボリュームにファイルシステムがあるかどうかを確認します。新しいボリュームは未加工のブロックデバイスであるため、マウントして使用する前に、ボリュームにファイルシステムを作成する必要があります。スナップショットから作成されたボリュームは、多くの場合既にファイルシステムがあります。既存のファイルシステムの上に新しいファイルシステムを作成すると、データが上書きされます。
次の方法のいずれか (または両方) を使用して、ボリューム上にファイルシステムがあるかどうかを判断します。
+ **file -s** コマンドを使用して、ファイルシステムタイプなど、特定のデバイスに関する情報を取得します。次の例のように、出力に `data` だけが表示されている場合は、デバイスにはファイルシステムが存在していません。
```
[ec2-user ~]$ sudo file -s /dev/xvdf
/dev/xvdf: data
```
デバイスにファイルシステムがある場合は、ファイルシステムの種類に関する情報が表示されます。例えば、次の出力は XFS ファイルシステムを持つルートデバイスを示しています。
```
[ec2-user ~]$ sudo file -s /dev/xvda1
/dev/xvda1: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)
```
+ **lsblk -f** コマンドを使用して、インスタンスにアタッチされているすべてのデバイスに関する情報を取得します。
```
[ec2-user ~]$ sudo lsblk -f
```
例えば、次の出力例では、3 つのデバイス — `nvme1n1`、`nvme0n1`、および `nvme2n1` がインスタンスにアタッチされていることを示しています。最初の列には、デバイスとそのパーティションが一覧表示されています。`FSTYPE` 列には、各デバイスのファイルシステムタイプが表示されています。特定のデバイスについての列が空の場合は、そのデバイスにファイルシステムがないことを意味します。この場合、デバイス `nvme1n1` とデバイス `nvme0n1` 上のパーティション `nvme0n1p1` はともに XFS ファイルシステムを使用してフォーマットされていますが、デバイス `nvme2n1` とデバイス `nvme0n1` 上のパーティション `nvme0n1p128` にはファイルシステムがありません。
```
NAME FSTYPE LABEL UUID MOUNTPOINT
nvme1n1 xfs 7f939f28-6dcc-4315-8c42-6806080b94dd
nvme0n1
├─nvme0n1p1 xfs / 90e29211-2de8-4967-b0fb-16f51a6e464c /
└─nvme0n1p128
nvme2n1
```
これらのコマンドの出力で、デバイス上にファイルシステムがないことが示された場合は、ファイルシステムを作成する必要があります。
1. (条件付き) 前の手順でデバイスにファイルシステムがあることがわかった場合は、このステップをスキップしてください。ボリュームが空の場合は、**mkfs -t** コマンドを使用し、そのボリューム上にファイルシステムを作成します。
**警告**
すでにデータが入っているボリューム (例: スナップショットから作成されたボリューム) をマウントしている場合は、このコマンドを使用しないでください。そうでない場合、ボリュームがフォーマットされ、既存のデータが削除されます。
```
[ec2-user ~]$ sudo mkfs -t xfs /dev/xvdf
```
`mkfs.xfs` がないというエラーが表示された場合は、次のコマンドを使用して XFS ツールをインストールしてから、前述のコマンドを繰り返します。
```
[ec2-user ~]$ sudo yum install xfsprogs
```
1. **mkdir** コマンドを使用して、ボリュームのマウントポイントディレクトリを作成します。マウントポイントとは、ボリュームをマウントした後、ファイルシステムツリー内でボリュームが配置され、ファイルの読み書きが実行される場所です。次の例では、`/data` という名前のディレクトリが作成されます。
```
[ec2-user ~]$ sudo mkdir /data
```
1. 前のステップで作成したマウントポイントディレクトリにボリュームまたはパーティションをマウントします。
ボリュームにパーティションがない場合は、次のコマンドを実行してデバイス名を指定し、ボリューム全体をマウントします。
```
[ec2-user ~]$ sudo mount /dev/xvdf /data
```
ボリュームにパーティションがある場合は、次のコマンドを実行してパーティション名を指定し、パーティションをマウントします。
```
[ec2-user ~]$ sudo mount /dev/xvdf1 /data
```
1. 新しいボリュームマウントのファイルのアクセス許可をプレビューして、ユーザーとアプリケーションがボリュームに書き込みできることを確認します。ファイルのアクセス許可の詳細については、*Linux Documentation Project* の[ファイルセキュリティ](https://tldp.org/LDP/intro-linux/html/sect_03_04.html)を参照してください。
1. インスタンスを再起動した後にマウントポイントが自動的に保存されることはありません。再起動後にこの EBS ボリュームを自動的にマウントするには、次の手順を参照してください。
### 再起動後に接続ボリュームを自動的にマウントする
システムブート時に常に、このアタッチ済みの EBS ボリュームをマウントするには、`/etc/fstab` ファイルにデバイス用のエントリを追加します。
`/etc/fstab` でシステムの現在のデバイス名 (`/dev/xvdf` など) は使用できますが、代わりにデバイスの 128 ビット汎用一意識別子 (UUID) を使用することをお勧めします。デバイス名は変更される可能性がありますが、UUID はパーティションの存続期間を通じて持続します。UUID を使用することで、ハードウェアの再構成後にシステムが起動できなくなる可能性を減らすことができます。詳細については、[Amazon EBS ボリュームを NVMe デバイス名にマッピング](identify-nvme-ebs-device.md)を参照してください。
**再起動後に接続ボリュームを自動的にマウントするには**
1. (オプション) `/etc/fstab` ファイルのバックアップコピーを作成すると、編集中に誤って破壊/削除してしまった場合にこのコピーを使用できます。
```
[ec2-user ~]$ sudo cp /etc/fstab /etc/fstab.orig
```
1. **blkid** コマンドを使用してデバイスの UUID を見つけます。再起動後にマウントするデバイスの UUID を書き留めます。次の手順で必要になります。
例えば、次のコマンドは、インスタンスにマウントされている 2 つのデバイスがあることを示し、両方のデバイスの UUID を表示します。
```
[ec2-user ~]$ sudo blkid
/dev/xvda1: LABEL="/" UUID="ca774df7-756d-4261-a3f1-76038323e572" TYPE="xfs" PARTLABEL="Linux" PARTUUID="02dcd367-e87c-4f2e-9a72-a3cf8f299c10"
/dev/xvdf: UUID="aebf131c-6957-451e-8d34-ec978d9581ae" TYPE="xfs"
```
Ubuntu 18.04 では、lsblk コマンドを使用します。
```
[ec2-user ~]$ sudo lsblk -o +UUID
```
1. **nano** や **vim** などのテキストエディタを使用して、`/etc/fstab` ファイルを開きます。
```
[ec2-user ~]$ sudo vim /etc/fstab
```
1. 指定されたマウントポイントにデバイスをマウントするために、`/etc/fstab` に次のエントリを追加します。フィールドは、**blkid** (Ubuntu 18.04 の場合は **lsblk**) から返される UUID 値、マウントポイント、ファイルシステム、および推奨されるファイルシステムマウントオプションです。必須フィールドの詳細については、`man fstab` を実行して **fstab** マニュアルを開きます。
次の例では、UUID `aebf131c-6957-451e-8d34-ec978d9581ae` を使用してデバイスをマウントポイント `/data` にマウントし、`xfs` ファイルシステムを使用します。`defaults` フラグと `nofail` フラグも使用します。ファイルシステムがダンプされないように `0` を指定し、ルート以外のデバイスであることを示すように `2` を指定します。
```
UUID=aebf131c-6957-451e-8d34-ec978d9581ae /data xfs defaults,nofail 0 2
```
**注記**
このボリュームをアタッチしないでインスタンスを起動することを目的としている場合 (例えば、ボリュームを別のインスタンスに移動した後)、`nofail` マウントオプションを追加し、ボリュームのマウントでエラーが発生してもインスタンスが起動できるようにしてください。また、Debian から派生した OS (16.04 より前の Ubuntu バージョンなど) では、`nobootwait` マウントオプションを追加する必要があります。
1. 入力内容が正しいことを確認するには、次のコマンドを実行してデバイスをアンマウントし、すべてのファイルシステムを `/etc/fstab` にマウントします。エラーがなければ、`/etc/fstab` ファイルは問題ありません。ファイルシステムは再起動後に自動的にマウントされます。
```
[ec2-user ~]$ sudo umount /data
[ec2-user ~]$ sudo mount -a
```
エラーメッセージが表示されたら、ファイル内のエラーに対処してください。
**警告**
`/etc/fstab` ファイルにエラーがあると、システムがブート不能になる可能性があります。`/etc/fstab` ファイルにエラーがあるシステムをシャットダウンしないでください。
`/etc/fstab` のエラーを修正する方法がわからず、このステップの最初のステップでバックアップファイルを作成した場合は、次のコマンドを使用してバックアップファイルから復元できます。
```
[ec2-user ~]$ sudo mv /etc/fstab.orig /etc/fstab
```
## Windows インスタンス
次のいずれかの方法を使用し、Windows インスタンスでボリュームを使用できるようにします。
------
#### [ PowerShell ]
**raw パーティションを持つすべての EBS ボリュームを Windows PowerShell で使用できるようにするには**
1. リモートデスクトップを使用して Windows インスタンスにログインします。詳細については、「[Windows インスタンスに接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html)」を参照してください。
1. タスクバーで、[Start] (スタート) メニューを開き、**[Windows PowerShell]** を選択します。
1. 開いた PowerShell プロンプト内で、提供されている一連の Windows PowerShell コマンドを使用します。このスクリプトはデフォルトで次のアクションを実行します。
1. ShellHWDetection サービスを停止します。
1. パーティションスタイルが raw のディスクを列挙します。
1. ディスクとパーティションタイプがサポートする最大サイズにまたがる新しいパーティションを作成します。
1. 使用できるドライブ文字を割り当てます。
1. 指定されたファイルシステムラベルを使用して、ファイルシステムを NTFS としてフォーマットします。
1. ShellHWDetection サービスを再起動します。
```
Stop-Service -Name ShellHWDetection
Get-Disk | Where PartitionStyle -eq 'raw' | Initialize-Disk -PartitionStyle MBR -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS -NewFileSystemLabel "Volume Label" -Confirm:$false
Start-Service -Name ShellHWDetection
```
------
#### [ DiskPart command line tool ]
**DiskPart コマンドラインツールを使用して EBS ボリュームを使用可能にするには**
1. リモートデスクトップを使用して Windows インスタンスにログインします。詳細については、「[Windows インスタンスに接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html)」を参照してください。
1. 使用可能にするディスク番号を決定します。
1. [Start] (スタート) メニューを開き、[Windows PowerShell] を選択します。
1. `Get-Disk` コマンドレットを使用して、使用できるディスクのリストを取得します。
1. コマンドの出力で、使用可能にするディスクに対応する**[Number]** (番号) を書き留めます。
1. DiskPart コマンドを実行するスクリプトファイルを次のように作成します。
1. [Start] (スタート) メニューを開き、**[File Explorer]** (ファイルエクスプローラ) を選択します。
1. C:\$1 などのディレクトリに移動し、スクリプトファイルを保存します。
1. フォルダ内の空白領域を選択するか、右クリックしてダイアログボックスを開き、カーソルを **[New]** (新規) の上に置いてコンテキストメニューにアクセスし、**[Text Document]** (テキストドキュメント) を選択します。
1. テキストファイルの名前を `diskpart.txt` にします。
1. 次のコマンドをスクリプトファイルに追加します。ディスク番号、パーティションタイプ、ボリュームラベル、ドライブ文字の変更が必要になる場合があります。このスクリプトはデフォルトで次のアクションを実行します。
1. 修正するディスク 1 を選択します。
1. マスターブートレコード (MBR) パーティション構造を使用するようにボリュームを設定します。
1. ボリュームを NTFS ボリュームとしてフォーマットします。
1. ボリュームラベルを設定します。
1. ボリュームにドライブ文字を割り当てます。
**警告**
既存のデータがあるボリュームをマウントする場合は、ボリュームを再フォーマットしないでください。再フォーマットすると、既存のデータが削除されます。
```
select disk 1
attributes disk clear readonly
online disk noerr
convert mbr
create partition primary
format quick fs=ntfs label="volume_label"
assign letter="drive_letter"
```
詳細については、[DiskPart Syntax and Parameters](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc766465(v=ws.10)#diskpart-syntax-and-parameters)を参照してください。
1. コマンドプロンプトを開き、スクリプトがあるフォルダに移動し、次のコマンドを実行して、指定したディスクでボリュームを使用できるようにします。
```
C:\> diskpart /s diskpart.txt
```
------
#### [ Disk Management utility ]
**ディスク管理ユーティリティで EBS ボリュームを使用可能にするには**
1. リモートデスクトップを使用して Windows インスタンスにログインします。詳細については、「[Windows インスタンスに接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html)」を参照してください。
1. [Disk Management] ユーティリティを起動します。タスクバーで、Windows ロゴのコンテキスト (右クリック) メニューを開き、**[Disk Management]** (ディスクの管理) を選択します。
**注記**
Windows Server 2008 では、**[スタート]**、**[管理ツール]**、**[コンピュータの管理]**、**[ディスクの管理]** の順に選択します。
1. ボリュームをオンライン状態にします。下のペインで、EBS ボリューム用のディスクの左パネルのコンテキスト (右クリック) メニューを開きます。[**Online**] を選択します。
![\[ボリュームをオンライン状態にします。\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/windows-2016-volume-online.png)
1. (条件に応じて) ディスクが初期化されていない場合は、使用する前に初期化する必要があります。ディスクが既に初期化されている場合は、このステップをスキップします。
**警告**
すでにデータが含まれるボリューム (パブリックデータセット、またはスナップショットから作成したボリュームなど) をマウントする場合は、ボリュームを再フォーマットしないように注意してください。再フォーマットすると、既存のデータが削除されます。
ディスクが初期化されていない場合は、次のように初期化します。
1. ディスクの左側パネルのコンテキスト (右クリック) メニューを開き、**[Initialize Disk]** (ディスクの初期化) を選択します。
![\[ボリュームを初期化する\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/windows-2016-volume-initialize.png)
1. **[Initialize Disk]** (ディスクの初期化) ダイアログボックスで、パーティションスタイルを選択し、**[OK]** をクリックします。
![\[ボリューム設定を初期化します。\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/windows-2016-volume-initialize-settings.png)
1. ディスクの右パネルのコンテキスト (右クリック) メニューを開き、**[New Simple Volume]** (新しいシンプルボリューム) を選択します。
![\[シンプルボリュームをマウントします｡\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/windows-2016-new-simple-volume.png)
1. **[New Simple Volume Wizard]** (新しいシンプルボリュームウィザード) で、**[Next]** (次へ) をクリックします。
![\[[New Simple Volume Wizard] (新しいシンプルボリュームウィザード) を開始します。\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/windows-2016-new-simple-volume-wizard-welcome.png)
1. デフォルトの最大値を変更する場合は、**[Simple volume size in MB]** (シンプルボリュームサイズ (MB)) を選択してから、**[Next]** (次へ) をクリックします。
![\[ボリュームサイズを指定します。\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/windows-2016-new-simple-volume-wizard-size.png)
1. 必要に応じて、使用したいドライブ文字を **[Assign the following drive letter]** (次のドライブ文字を割り当る) ドロップダウンの中に指定し、**[Next]** (次へ) をクリックします。
![\[ドライブ文字を指定します。\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/windows-2016-new-simple-volume-wizard-letter.png)
1. **[Volume Label]** (ボリュームラベル) を指定し、必要に応じてデフォルト設定を調整し、**[Next]** (次へ) をクリックします。
![\[ボリュームをフォーマットするための設定を指定します。\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/windows-2016-new-simple-volume-wizard-format.png)
1. 設定を確認してから、**[Finish]** (終了) をクリックして変更を適用し、[New Simple Volume] (新しいシンプルボリューム) ウィザードを閉じます。
![\[設定を確認し、ウィザードを終了します。\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/windows-2016-new-simple-volume-wizard-finish.png)
------
# Amazon EBS ボリュームに関する情報の表示
EBS ボリュームに関する詳細情報を表示できます。例えば、特定のリージョンの全てのボリュームの情報を表示したり、単一ボリュームの詳細 (サイズ、ボリュームタイプ、ボリュームが暗号化されているかどうか、ボリュームを暗号化するために使用した KMS キー、ボリュームがアタッチされている特定のインスタンスなど) を表示することができます。
インスタンスのオペレーティングシステムから、どのくらいのディスク容量が使用可能かなどの EBS ボリュームの詳細情報を取得できます。
**Topics**
+ [ボリューム情報の表示](#ebs-view-information-console)
+ [ボリューム状態](#volume-state)
+ [ボリュームメトリクスの表示](#ebs-view-volume-metrics)
+ [空きディスク容量の表示](#ebs-view-free-disk-space-lin)
## ボリューム情報の表示
EBS ボリュームに関する情報を表示できます。
------
#### [ Console ]
**ボリュームに関する情報を表示するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. リストを減らすには、タグとボリューム属性を使用してボリュームをフィルターできます。フィルターフィールドを選択し、タグまたはボリューム属性を選択し、フィルタ値を選択します。
1. ボリュームの詳細情報を表示するには、そのボリュームを選択します。
**インスタンスにアタッチされている EBS ボリュームを表示するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. インスタンスを選択します。
1. **[Storage]** (ストレージ) タブの **[Block devices]** (ブロックデバイス) セクションでは、インスタンスにアタッチされているボリュームの一覧が表示されます。特定のボリュームに関する情報を表示するには、**[Volume ID]** (ボリューム ID) 列で該当する ID を選択します。
------
#### [ Amazon EC2 Global View ]
[Amazon EC2 Global View](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/global-view.html) を使用して、 AWS アカウントが有効になっているすべてのリージョンでボリュームを表示できます。
**すべてのリージョンの EBS ボリュームの概要を表示するには**
1. Amazon EC2 Global View コンソール ([https://console.aws.amazon.com/ec2globalview/home](https://console.aws.amazon.com/ec2globalview/home)) を開きます。
1. **[リージョンエクスプローラー]** タブの **[概要]** で、**[ボリューム]** のリソース数を確認します。これには、ボリューム数とリージョン数が含まれており、下線付きのテキストをクリックすると、ボリューム数がリージョン間でどのように分配されているかを確認できます。
1. **[グローバル検索]** タブで、クライアントフィルター **[リソースタイプ = ボリューム]** を選択します。リージョンまたはタグを指定することで、結果をさらにフィルタリングできます。
------
#### [ AWS CLI ]
**EBS ボリュームに関する情報を表示するには**
[describe-volumes](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volumes.html) コマンドを使用します。次の例では、現在のリージョンのボリュームをカウントします。
```
aws ec2 describe-volumes --query "length(Volumes[*])"
```
次の例では、指定されたインスタンスにアタッチされたボリュームを一覧表示します。
```
aws ec2 describe-volumes \
--filters "Name=attachment.instance-id,Values=i-1234567890abcdef0" \
--query Volumes[*].VolumeId \
--output text
```
次の例では、指定したボリュームについて説明します。
```
aws ec2 describe-volumes --volume-ids vol-01234567890abcdef
```
以下は出力の例です。
```
{
"Volumes": [
{
"Iops": 3000,
"VolumeType": "gp3",
"MultiAttachEnabled": false,
"Throughput": 125,
"Operator": {
"Managed": false
},
"VolumeId": "vol-01234567890abcdef",
"Size": 8,
"SnapshotId": "snap-0abcdef1234567890",
"AvailabilityZone": "us-west-2b",
"State": "in-use",
"CreateTime": "2024-05-17T23:23:00.400000+00:00",
"Attachments": [
{
"DeleteOnTermination": true,
"VolumeId": "vol-01234567890abcdef",
"InstanceId": "i-1234567890abcdef0",
"Device": "/dev/xvda",
"State": "attached",
"AttachTime": "2024-05-17T23:23:00+00:00"
}
],
"Encrypted": false
}
]
}
```
------
#### [ PowerShell ]
**EBS ボリュームに関する情報を表示するには**
[Get-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Volume.html) コマンドレットを使用します。次の例では、現在のリージョンのボリュームをカウントします。
```
(Get-EC2Volume).Count
```
次の例では、指定されたインスタンスにアタッチされたボリュームを一覧表示します。
```
(Get-EC2Volume `
-Filters @{Name="attachment.instance-id";Values="i-1234567890abcdef0"}).VolumeId
```
次の例では、指定したボリュームについて説明します。
```
Get-EC2Volume -VolumeId vol-01234567890abcdef
```
以下は出力の例です。
```
Attachments : {i-1234567890abcdef0}
AvailabilityZone : us-west-2b
CreateTime : 5/17/2024 11:23:00 PM
Encrypted : False
FastRestored : False
Iops : 3000
KmsKeyId :
MultiAttachEnabled : False
Operator : Amazon.EC2.Model.OperatorResponse
OutpostArn :
Size : 8
SnapshotId : snap-0abcdef1234567890
SseType :
State : in-use
Tags : {}
Throughput : 125
VolumeId : vol-01234567890abcdef
VolumeType : gp3
```
------
## ボリューム状態
ボリューム状態は、Amazon EBS ボリュームの可用性を示します。ボリュームの状態は、コンソールの**ボリューム**ページの**ステート**列で表示することも、[describe-volumes](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volumes.html) AWS CLI コマンドを使用して表示することもできます。
Amazon EBS ボリュームは、作成されてから削除されるまで、さまざまな状態に移行します。
次の図は、ボリュームの状態間の移行を示しています。Amazon EBS スナップショットからボリュームを作成するか、空のボリュームを作成できます。ボリュームを作成すると、`creating` 状態になります。ボリュームが使用可能になると、`available` 状態になります。ボリュームと同じアベイラビリティーゾーンにあるインスタンスに、利用可能なボリュームをアタッチできます。ボリュームを別のインスタンスにアタッチまたは削除する前に、ボリュームをデタッチする必要があります。不要になったボリュームは削除できます。
![\[EBS ボリュームのライフサイクル。\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/volume-states.png)
次の表はボリューム状態をまとめたものです。
| State | 説明 |
| --- | --- |
| creating | ボリュームは作成中です。 |
| available | ボリュームはインスタンスにアタッチされていません。 |
| in-use | ボリュームはインスタンスにアタッチされています。 |
| deleting | ボリュームは削除中です。 |
| deleted | ボリュームは削除されました。 |
| error | EBS ボリュームに関連する基となるハードウェアに障害が発生し、ボリュームに関連付けられているデータを回復できません。ボリュームを復元する方法またはボリューム上のデータを回復する方法については、「[EBS ボリュームのステータスが「エラー」になるのはなぜですか?](https://repost.aws/knowledge-center/ebs-error-status)」を参照してください。 |
## ボリュームメトリクスの表示
EBS ボリュームに関する詳細は、Amazon CloudWatch から入手できます。詳細については、[Amazon EBS の Amazon CloudWatch メトリクス](using_cloudwatch_ebs.md)を参照してください。
## 空きディスク容量の表示
インスタンスのオペレーティングシステムから、どのくらいのディスク容量が使用可能かなどの EBS ボリュームの詳細情報を取得できます。
### Linux インスタンス
**df -hT** コマンドを使用して、デバイス名を指定します。
```
[ec2-user ~]$ df -hT /dev/xvda1
Filesystem Type Size Used Avail Use% Mounted on
/dev/xvda1 xfs 8.0G 1.2G 6.9G 15% /
```
### Windows インスタンス
エクスプローラーを開き、**[この PC]** を選択して、空きディスク容量を表示します。
次の `dir` コマンドを使用して、出力の最後の行を確認することで空きディスク容量を表示することもできます。
```
C:\> dir C:
Volume in drive C has no label.
Volume Serial Number is 68C3-8081
Directory of C:\
03/25/2018 02:10 AM .
03/25/2018 02:10 AM ..
03/25/2018 03:47 AM Contacts
03/25/2018 03:47 AM Desktop
03/25/2018 03:47 AM Documents
03/25/2018 03:47 AM Downloads
03/25/2018 03:47 AM Favorites
03/25/2018 03:47 AM Links
03/25/2018 03:47 AM Music
03/25/2018 03:47 AM Pictures
03/25/2018 03:47 AM Saved Games
03/25/2018 03:47 AM Searches
03/25/2018 03:47 AM Videos
0 File(s) 0 bytes
13 Dir(s) 18,113,662,976 bytes free
```
次の `fsutil` コマンドを使用して、空きディスク容量を表示することもできます。
```
C:\> fsutil volume diskfree C:
Total # of free bytes : 18113204224
Total # of bytes : 32210153472
Total # of avail free bytes : 18113204224
```
**ヒント**
CloudWatch エージェントを使用して、インスタンスに接続せずに Amazon EC2 インスタンスからディスクスペース使用量のメトリクスを収集することもできます。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch エージェント設定ファイルを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file.html)」および「[CloudWatch エージェントのインストール](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)」を参照してください。複数のインスタンスのディスクスペース使用量をモニタリングする必要がある場合は、Systems Manager を使用してそれらのインスタンスに CloudWatch エージェントをインストールして設定できます。詳細については、「[Installing the CloudWatch agent using Systems Manager](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/installing-cloudwatch-agent-ssm.html)」(Systems Manager を使用した CloudWatch エージェントのインストール) を参照してください。
# Elastic Volumes オペレーションを使用して Amazon EBS ボリュームを変更する
Amazon EBS Elastic Volumes では、EBS ボリュームのボリュームサイズの増加、ボリュームタイプの変更、パフォーマンスの調整を行うことができます。インスタンスで Elastic Volumes をサポートしている場合は、ボリュームのデタッチやインスタンスの再起動を行うことなく、これらの操作を行うことができます。したがって、変更の適用中でも、アプリケーションを引き続き使用できます。
ボリュームの設定を変更するための料金は発生しません。ボリューム変更を開始すると、新しいボリューム設定料金が発生します。詳細については、[Amazon EBS 料金表](https://aws.amazon.com/ebs/pricing/)ページを参照してください。
**Topics**
+ [考慮事項](#elastic-volumes-considerations)
+ [制限事項](#elastic-volumes-limitations)
+ [Amazon EBS ボリューム変更の要件](modify-volume-requirements.md)
+ [Amazon EBS ボリュームの変更をリクエスト](requesting-ebs-volume-modifications.md)
+ [Amazon EBS ボリューム変更の進行状況のモニタリング](monitoring-volume-modifications.md)
+ [Amazon EBS ボリュームのサイズ変更後にファイルシステムを拡張](recognize-expanded-volume-linux.md)
## 考慮事項
+ ボリュームの変更を開始したら、その変更が `completed`状態になるまで待ってから、同じボリュームに対して別の変更を開始する必要があります。ボリュームが `in-use`または `available`状態であり、そのボリュームの以前のすべての変更が である限り、ローリング 24 時間以内に最大 4 回ボリュームを変更できます`completed`。この制限を超えると、次の変更を実行できるタイミングを示すエラーメッセージが表示されます。
+ ボリュームの変更はベストエフォートベースで実行され、リクエストされたボリューム設定によっては完了までに数分から数時間かかる場合があります。通常、1-TiB ボリュームの変更には最大 6 時間かかることがあります。ただし、時間は常にボリュームサイズに合わせて直線的にスケールされるとは限りません。ボリュームが大きいほど時間がかかり、ボリュームが小さいほど時間が長くなる可能性があります。
+ サイズの増加は、ボリュームの変更が `optimizing`状態になると有効になり、通常は数秒かかります。
+ 完全に初期化されていないボリュームでは、変更時間が長くなります。詳細については、「[作成後にボリュームを手動で初期化する](initalize-volume.md#ebs-initialize)」を参照してください。
+ ボリュームタイプを `gp2` から `gp3` に変更し、IOPS またはスループットパフォーマンスを指定しない場合、Amazon EBS はソース `gp2` ボリュームと同等のパフォーマンス、またはベースライン `gp3` パフォーマンスのいずれか高い方を自動的にプロビジョニングします。
例えば、IOPS またはスループットパフォーマンスを指定せずに、250 MiB/秒のスループットと 1,500 IOPS の 500 GiB `gp2` ボリュームを `gp3` に変更すると、Amazon EBS は 3,000 IOPS (ベースライン `gp3` IOPS) と 250 MiB/秒 (ソース `gp2` ボリュームスループットに一致するように) の `gp3` ボリュームを自動的にプロビジョニングします。
+ EBS ボリュームを変更する際にエラーメッセージが表示された場合や前世代のインスタンスタイプにアタッチされた EBS ボリュームを変更する場合は、以下のいずれかのステップを行ってください。
+ ルート以外のボリュームの場合は、ボリュームをインスタンスからデタッチして、変更を適用した後で、ボリュームを再アタッチします。
+ ルートボリュームの場合は、インスタンスを停止し、変更を適用した後で、インスタンスを再起動します。
## 制限事項
+ ボリューム変更リクエストの送信後は、キャンセルできません。
+ ボリュームサイズを増やす必要があります。ボリュームサイズを小さくすることはできません。ただし、より小さなボリュームを作成し、そのボリュームに対して **rsync** (Linux インスタンス) または **robocopy** (Windows インスタンス) などのアプリケーションレベルのツールを使用してデータを移行することができます。
+ ボリュームの変更でリクエストできる集計ストレージの最大数には制限があります。詳細については、「*Amazon Web Services 全般のリファレンス* 」の「[Amazon EBS service quotas](https://docs.aws.amazon.com/general/latest/gr/ebs-service.html#limits_ebs)」を参照してください。
+ 変更後のボリュームサイズは、そのファイルシステムとパーティション設定スキームでサポートされる容量を超えることはできません。詳細については、「[Amazon EBS ボリュームの制約](volume_constraints.md)」を参照してください。
+ ボリュームタイプを変更しない場合は、ボリュームサイズとパフォーマンスを、現在のボリュームタイプの制限内であれば変更できます。ボリュームタイプを変更する場合は、ターゲットとなるボリュームタイプの制限内であれば、ボリュームサイズとパフォーマンスを変更することが可能です。詳細については、[Amazon EBS ボリュームの種類](ebs-volume-types.md)を参照してください。
+ [Nitro ベースのインスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)は、最大 256,000 IOPS でプロビジョニングされたボリュームをサポートします。他のインスタンスタイプは、最大 64,000 IOPS まででプロビジョニングされたボリュームにアタッチできますが、最大 32,000 IOPS までプロビジョニングできます。
+ マルチアタッチが有効な `io2` ボリュームのボリュームタイプを変更することはできません。
+ マルチアタッチが有効な `io1` ボリュームのボリュームタイプ、サイズ、プロビジョンド IOPS を変更することはできません。
+ タイプ `io1`、`io2`、`gp2`、`gp3`、または `standard` のルート ボリュームは、インスタンスからデタッチされていても、`st1` または `sc1` ボリュームに変更できません。
+ ボリュームが 2016 年 11 月 3 日 23:40 (UTC) 以前にアタッチされていた場合は、Elastic Volumes サポートを初期化する必要があります。詳細については、[Elastic Volumes サポートの初期化](requesting-ebs-volume-modifications.md#initialize-modification-support)を参照してください。
+ `m3.medium` インスタンスはボリュームの変更を完全にサポートしていますが、`m3.large`、`m3.xlarge`、および `m3.2xlarge` インスタンスは、すべてのボリューム変更機能をサポートしていない場合があります。
# Amazon EBS ボリューム変更の要件
Amazon EBS ボリュームを変更すると、以下の要件と制限が適用されます。EBS ボリュームの一般的な要件についての詳細は、[Amazon EBS ボリュームの制約](volume_constraints.md)を参照してください。
**Topics**
+ [サポートされるインスタンスタイプ](#instance-support)
+ [オペレーティングシステム](#operating-system)
## サポートされるインスタンスタイプ
Elastic Volumes は、次のインスタンスでサポートされています。
+ すべての[現行世代のインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#current-gen-instances)
+ 旧世代のインスタンス: C1、C3、C4、G2、I2、M1、M3、M4、R3 および R4
インスタンスタイプが Elastic Volumes をサポートしていない場合は、[Elastic Volumes がサポートされていない場合の EBS ボリュームの変更](requesting-ebs-volume-modifications.md#modify-volume-stop-start)を参照してください。
## オペレーティングシステム
次のオペレーティングシステム要件が適用されます。
### Linux
Linux AMI では、2 TiB (2048 GiB) 以上のブートボリュームについて GUID パーティションテーブル (GPT) と GRUB 2 が必要です。現在の多くの Linux AMI は依然として MBR パーティションスキームを使用しており、2 TiB までのブートボリュームのみをサポートしています。インスタンスが 2 TiB を超えるブートボリュームで起動しない場合、使用中の AMI は、2 TiB のブートボリュームサイズに制限されている可能性があります。ブートボリューム以外のボリュームには、Linux インスタンスでこの制限はありません。
2 TiB より大きな値にブートボリュームのサイズを変更する前に、ボリュームが MBR と GPT のどちらのパーティション分割を使用しているのか確認します。それには、インスタンス上で、コマンドを実行します。
```
[ec2-user ~]$ sudo gdisk -l /dev/xvda
```
GPT パーティション分割を使用している Amazon Linux インスタンスでは、次の情報が返ります。
```
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
```
MBR パーティション分割を使用している SUSE インスタンスは、次の情報を返します。
```
GPT fdisk (gdisk) version 0.8.8
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
```
### Server
デフォルトでは、Windows はマスターブートレコード (MBR) パーティションテーブルを使用してボリュームを初期化します。MBR は 2 TiB (2048 GiB) 以下のボリュームのみをサポートするため、Windows はこのサイズ制限以上の MBR ボリュームのサイズ変更を阻止します。この場合、[**Extend Volume (ボリュームの拡張)**] のオプションは Windows の [**Disk Management (ディスクの管理)**] ユーティリティで無効になっています。 AWS マネジメントコンソール または を使用してサイズ制限を超える MBR パーティションボリューム AWS CLI を作成する場合、Windows は追加のスペースを検出または使用することはできません。
この制限を回避するには、GUID パーティションテーブル (GPT) でより大きな新しいボリュームを作成し、元の MBR ボリュームからデータをコピーします。
**GPT ボリュームを作成するには**
1. EC2 インスタンスのアベイラビリティーゾーンに必要な容量の新しい空のボリュームを作成し、インスタンスにアタッチします。
**注記**
新しいボリュームには、スナップショットから復元したボリュームは使用できません。
1. Windows システムにログインし、[**Disk Management** (ディスク管理)] (**diskmgmt.exe**) を開きます。
1. 新しいディスクのコンテキスト (右クリック) メニューを開き、[**Online**] を選択します。
1. [**Initialize Disk**] ウィンドウで、新規のディスクを選択し、続いて [**GPT (GUID Partition Table)**]、[**OK**] の順に選択します。
1. 初期化が完了したら、robocopy または teracopy などのツールを使用して元のボリュームから新しいボリュームにデータをコピーします。
1. [**Disk Management**] で、ドライブ文字を適切な値に変更し、古いボリュームをオフラインにします。
1. Amazon EC2 コンソールで、インスタンスから古いボリュームをデタッチ後、インスタンスを再起動して正常に稼働することを確認したら、古いボリュームを削除します。
# Amazon EBS ボリュームの変更をリクエスト
Amazon EBS の伸縮自在なボリュームでは、そのサイズを増やしたり、パフォーマンスを増減したり、ボリュームタイプを変更したりなどが、ボリュームをデタッチすることなく動的に行えます。
**プロセスの概要**
1. (オプション) 重要なデータを含むボリュームを変更する前に、変更をロールバックする必要がある場合に備えて、ボリュームのスナップショットを作成するのがベストプラクティスです。詳細については、[Amazon EBS スナップショットの作成](ebs-creating-snapshot.md)を参照してください。
1. ボリュームの変更をリクエストします。
1. ボリューム変更の進行状況をモニタリングします。詳細については、[Amazon EBS ボリューム変更の進行状況のモニタリング](monitoring-volume-modifications.md)を参照してください。
1. ボリュームのサイズが変更された場合、増加されたストレージ容量を利用するには、ボリュームのファイルシステムを拡張します。詳細については、「[Amazon EBS ボリュームのサイズ変更後にファイルシステムを拡張](recognize-expanded-volume-linux.md)」を参照してください。
**Topics**
+ [Elastic Volumes を使用して EBS ボリュームを変更する](#modify-ebs-volume)
+ [Elastic Volumes がサポートされていない場合の EBS ボリュームの変更](#modify-volume-stop-start)
+ [Elastic Volumes サポートの初期化 (必要な場合)](#initialize-modification-support)
## Elastic Volumes を使用して EBS ボリュームを変更する
開始する前に、以下を参照してください。
+ [考慮事項](ebs-modify-volume.md#elastic-volumes-considerations)
+ [制限事項](ebs-modify-volume.md#elastic-volumes-limitations)
+ [要件](modify-volume-requirements.md)
------
#### [ Console ]
**EBS ボリュームを変更するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. ボリュームを選択し、**[Actions]** (アクション)、**[Modify volume]** (ボリュームの編集) の順にクリックします。
1. **[Modify Volume]** (ボリュームの編集) 画面に、ボリューム ID とボリュームの現在の設定 (タイプ、サイズ、IOPS、スループットなど) が表示されます。新しい設定値を以下のように設定します。
+ タイプを変更するには、[**Volume Type**] (ボリュームタイプ) の値を選択します。
+ **サイズ**を変更するには、[Size] に新しい値を入力します。
+ (`gp3`,`io1`, および`io2`のみ) IOPS を変更するには、**IOPS** に新しい値を入力します。
+ (`gp3` のみ) スループットを変更するには、**[Throughput]** (スループット) に新しい値を入力します。
1. ボリューム設定を変更したら、[**変更**] を選択します。確認を求めるメッセージが表示されたら、**[Modify]** (変更) を選択します。
1. ボリュームのサイズを大きくした場合は、追加のストレージ容量を利用するために、ボリュームのパーティションも拡張する必要があります。詳細については、「[Amazon EBS ボリュームのサイズ変更後にファイルシステムを拡張](recognize-expanded-volume-linux.md)」を参照してください。
1. (*Windows インスタンスのみ*) NVMe ドライバーがないインスタンスで AWS NVMe ボリュームのサイズを増やす場合は、インスタンスを再起動して Windows が新しいボリュームサイズを表示できるようにする必要があります。 AWS NVMe ドライバーのインストールの詳細については、[AWS NVMe ドライバー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/aws-nvme-drivers.html)」を参照してください。
------
#### [ AWS CLI ]
**EBS ボリュームを変更するには**
[modify-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-volume.html) コマンドを使用します。例えば、サイズが 100 GiB で、タイプが `gp2` のボリュームがある場合は、次の例でこの設定を 10,000 IOPS、サイズが 200 GiB のタイプ `io1` のボリュームに変更します。
```
aws ec2 modify-volume \
--volume-id vol-01234567890abcdef \
--volume-type io1 \
--iops 10000 \
--size 200
```
以下は出力の例です。
```
{
"VolumeModification": {
"TargetSize": 200,
"TargetVolumeType": "io1",
"ModificationState": "modifying",
"VolumeId": "vol-01234567890abcdef",
"TargetIops": 10000,
"StartTime": "2022-01-19T22:21:02.959Z",
"Progress": 0,
"OriginalVolumeType": "gp2",
"OriginalIops": 300,
"OriginalSize": 100
}
}
```
ボリュームのサイズを大きくした場合は、追加のストレージ容量を利用するために、ボリュームのパーティションも拡張する必要があります。詳細については、「[Amazon EBS ボリュームのサイズ変更後にファイルシステムを拡張](recognize-expanded-volume-linux.md)」を参照してください。
------
#### [ PowerShell ]
**EBS ボリュームを変更するには**
[Edit-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2Volume.html) コマンドレットを使用します。例えば、サイズが 100 GiB で、タイプが `gp2` のボリュームがある場合は、次の例でこの設定を 10,000 IOPS、サイズが 200 GiB のタイプ `io1` のボリュームに変更します。
```
Edit-EC2Volume `
-VolumeId vol-01234567890abcdef `
-VolumeType io1 `
-Iops 10000 `
-Size 200
```
ボリュームのサイズを大きくした場合は、追加のストレージ容量を利用するために、ボリュームのパーティションも拡張する必要があります。詳細については、「[Amazon EBS ボリュームのサイズ変更後にファイルシステムを拡張](recognize-expanded-volume-linux.md)」を参照してください。
------
## Elastic Volumes がサポートされていない場合の EBS ボリュームの変更
サポートされているインスタンスタイプを使用している場合は、Elastic Volumes を使用して、Amazon EBS ボリュームのサイズ、パフォーマンス、およびボリュームのタイプを動的に変更することができます。それらをデタッチする必要はありません。
Elastic Volumes は使用できないが、ルート (ブート) ボリュームの変更が必要になった場合は、インスタンスを停止し、ボリュームを変更してから、インスタンスを再起動する必要があります。
インスタンスが起動したら、ファイルシステムのサイズを確認して、拡大したボリュームスペースをインスタンスが認識しているかどうか表示できます。Linux では、**df -h** コマンドを使用してファイルシステムのサイズを確認します。
```
[ec2-user ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.9G 943M 6.9G 12% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
```
新しく拡張したボリュームがサイズに反映されていない場合は、デバイスのファイルシステムを拡張して、インスタンスで新しいスペースを使えるようにします。詳細については、「[Amazon EBS ボリュームのサイズ変更後にファイルシステムを拡張](recognize-expanded-volume-linux.md)」を参照してください。
Windows インスタンスを使用すると、ボリュームを使用するためにオンラインにする必要がある場合があります。詳細については、「[Amazon EBS ボリュームを使用できるようにする](ebs-using-volumes.md)」を参照してください。ボリュームを再フォーマットする必要はありません。
## Elastic Volumes サポートの初期化 (必要な場合)
2016 年 11 月 3 日 23:40 (UTC) 以前にインスタンスにアタッチされたボリュームを変更する前に、次のいずれかのアクションを使用してボリュームのサポートを初期化する必要があります。
+ ボリュームをデタッチしてアタッチする
+ インスタンスの停止と起動
------
#### [ Console ]
**インスタンスの準備が完了していることを確認するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択します。
1. [**列の表示/非表示**] アイコン (歯車) を選択します。[**Launch time (起動時刻)**] 属性列を選択し、[**Confirm (確認)**] を選択します。
1. [**起動時刻**] 列でインスタンスの一覧をソートします。カットオフ日より前に開始されたインスタンスごとに、[**Storage (ストレージ)**] タブを選択し、[**Attachment time (アタッチ時刻)**] 列をチェックして、ボリュームがいつアタッチされたかを確認します。
------
#### [ AWS CLI ]
**インスタンスの準備が完了していることを確認するには**
ボリュームが 2016 年 11 月 3 日 23:40 (UTC) 以前にアタッチされたかどうかを確認するには、次の [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) コマンドを使用します。
```
aws ec2 describe-instances \
--query "Reservations[*].Instances[*].[InstanceId,LaunchTime<='2016-11-01',BlockDeviceMappings[*][Ebs.AttachTime<='2016-11-01']]" \
--output text
```
各インスタンスの出力の最初の行は、その ID と、カットオフ日前に開始されたかどうか (True または False) を示します。その最初の行の後に、各 EBS ボリュームがカットオフ日前にアタッチされたかどうかを示す 1 つ以上の行が続きます。次の出力例では、最初のインスタンスのボリューム変更を初期化する必要があります。これはカットオフ日よりも前に開始され、カットオフ日より前にそのルートボリュームがアタッチされていたためです。他のインスタンスはカットオフ日以降に開始されたため、準備は完了しています。
```
i-e905622e True
True
i-719f99a8 False
True
i-006b02c1b78381e57 False
False
False
i-e3d172ed False
True
```
------
#### [ PowerShell ]
**インスタンスの準備が完了していることを確認するには**
[Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html) コマンドレットを使用して、ボリュームが 2016 年 11 月 3 日 23:40 UTC より前にアタッチされたかどうかを確認します。
```
(Get-EC2Instance `
-InstanceId i-1234567890abcdef0).Instances.BlockDeviceMappings | `
Format-Table @{Name="VolumeId";Expression={$_.Ebs.VolumeId}}, `
@{Name="AttachTime";Expression={$_.Ebs.AttachTime}}
```
以下は出力の例です。
```
VolumeId AttachTime
-------- ----------
vol-0b243c8d927752d2b 3/23/2020 12:21:14 AM
vol-043eadbeb4a8387c3 9/5/2020 7:39:22 PM
vol-0c3f0c4e55c082753 4/23/2019 4:07:40 PM
```
------
# Amazon EBS ボリューム変更の進行状況のモニタリング
EBS ボリュームを変更すると、次のステータスになります。ボリュームの状態は `modifying`、`optimizing`、`completed` の順に変わります。この時点で、ボリュームは追加の変更を適用できる状態になります。
ボリュームが `optimizing` 状態である場合、ボリュームのパフォーマンスはソースとターゲットの設定仕様の中間にあります。過渡的なボリュームのパフォーマンスは、ソースボリュームのパフォーマンスより劣ることはありません。IOPS をダウングレードする場合、過渡的なボリュームのパフォーマンスは、ターゲットボリュームと同程度のパフォーマンスになります。
ボリュームの変更による影響は次のとおりです。
+ サイズの増加は、ボリュームの変更が `optimizing`状態になると有効になり、通常は数秒かかります。
+ リクエストされたボリューム設定によっては、パフォーマンス (IOPS とスループット) の変更が完了するまでに数分から数時間かかる場合があります。通常、完全に使用された 1-TiB ボリュームは、新しいパフォーマンス設定に移行するまでに約 6 時間かかることがあります。場合によっては、ボリュームが完全に初期化されていない場合など、新しいパフォーマンス設定が有効になるまでに 24 時間以上かかることがあります。
ボリュームの状態には、`creating`、`available`、`in-use`、`deleting`、`deleted`、`error` があります。
修正の状態には、`modifying`、`optimizing`、`completed` があります。
------
#### [ Console ]
**変更の進行状況をモニタリングするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. ボリュームを選択します。
1. **[詳細]** タブの **[ボリュームのステータス]** 列と **[ボリュームステータス]** フィールドには、*volume-state* - *modification-state* — *Modification state* という形式の情報が含まれます。次の画像に、ボリュームとボリュームの変更状態を示します。
![\[ボリュームとボリュームの変更状態\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/volume_state.png)
変更が完了すると、ボリュームの状態のみが表示されます。変更の状態と進行状況は表示されなくなります。
または、Amazon EventBridge を使用して、ボリューム変更イベントの通知ルールを作成できます。詳細については、「[Getting started with Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)」を参照してください。
------
#### [ AWS CLI ]
**変更の進行状況をモニタリングするには**
1 つ以上のボリュームの変更の進行状況を表示するには、[describe-volumes-modifications](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volumes-modifications.html) コマンドを使用します。次の例では、2 つのボリュームのボリューム変更を示します。
```
aws ec2 describe-volumes-modifications \
--volume-ids vol-11111111111111111 vol-22222222222222222
```
次の出力例では、これらのボリュームの変更の状態は、引き続き `modifying` になっています。進捗状況は、パーセンテージで報告されます。
```
{
"VolumesModifications": [
{
"TargetSize": 200,
"TargetVolumeType": "io1",
"ModificationState": "modifying",
"VolumeId": "vol-11111111111111111",
"TargetIops": 10000,
"StartTime": "2017-01-19T22:21:02.959Z",
"Progress": 0,
"OriginalVolumeType": "gp2",
"OriginalIops": 300,
"OriginalSize": 100
},
{
"TargetSize": 2000,
"TargetVolumeType": "sc1",
"ModificationState": "modifying",
"VolumeId": "vol-22222222222222222",
"StartTime": "2017-01-19T22:23:22.158Z",
"Progress": 0,
"OriginalVolumeType": "gp2",
"OriginalIops": 300,
"OriginalSize": 1000
}
]
}
```
次の例では、変更の状態が `optimizing` または `completed` であるすべてのボリュームを示し、その結果をフィルタリングおよびフォーマットして 2017 年 2 月 1 日以降に開始された変更のみを表示します。
```
aws ec2 describe-volumes-modifications \
--filters Name=modification-state,Values="optimizing","completed" \
--query "VolumesModifications[?StartTime>='2017-02-01'].{ID:VolumeId,STATE:ModificationState}"
```
2 つのボリュームに関する情報を含む出力例を以下に示します。
```
[
{
"STATE": "optimizing",
"ID": "vol-06397e7a0eEXAMPLE"
},
{
"STATE": "completed",
"ID": "vol-ba74e18c2aEXAMPLE"
}
]
```
------
#### [ PowerShell ]
**変更の進行状況をモニタリングするには**
[Get-EC2VolumeModification](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2VolumeModification.html) コマンドレットを使用します。次の例では、2 つのボリュームのボリューム変更を示します。
```
Get-EC2VolumeModification `
-VolumeId vol-11111111111111111 vol-22222222222222222
```
------
**注記**
まれに、一時的な AWS 障害によって `failed`状態が発生することがあります。これは、ボリュームのヘルスステータスを示すものではなく、ボリュームの変更に失敗したことを単に示しています。この場合は、再度ボリュームの変更を行います。
# Amazon EBS ボリュームのサイズ変更後にファイルシステムを拡張
[EBS ボリュームのサイズを増やし](requesting-ebs-volume-modifications.md)たら、パーティションおよびファイルシステムを新しいより大きなサイズに拡張する必要があります。ボリュームが `optimizing` 状態に入るとすぐにこれを実行できます。
## [開始する前に]
+ 変更をロールバックする必要がある場合に備えて、ボリュームのスナップショットを作成します。詳細については、「[Amazon EBS スナップショットの作成](ebs-creating-snapshot.md)」を参照してください。
+ ボリュームの変更が成功し、`optimizing` または `completed` 状態になっていることを確認します。詳細については、「[Amazon EBS ボリューム変更の進行状況のモニタリング](monitoring-volume-modifications.md)」を参照してください。
+ ボリュームがインスタンスにアタッチされており、フォーマットおよびマウントされていることを確認します。詳細については、「[アタッチ済みボリュームのフォーマットとマウント](ebs-using-volumes.md#ebs-format-mount-volume)」を参照してください。
+ (*Linux インスタンスのみ*) Amazon EBS ボリュームで論理ボリュームを使用している場合、Logical Volume Manager (LVM) を使用して論理ボリュームを拡張する必要があります。これを行う方法については、「[LVM を使用して EBS ボリュームのパーティションに論理ボリュームを作成する方法を教えてください](https://repost.aws/knowledge-center/create-lv-on-ebs-partition)」の記事の「**LV を拡張する**」のセクションを参照してください。
## Linux インスタンス
**注記**
次の手順では、Linux の **XFS** および **Ext4** ファイルシステムを拡張するプロセスについて説明します。別のファイルシステムの拡張に関する詳細ついては、そのドキュメントを参照してください。
ボリュームにパーティションがある場合、Linux でファイルシステムを拡張する前にパーティションを拡張する必要があります。
### EBS ボリュームのファイルシステムを拡張する
サイズを変更したボリュームのファイルシステムを拡張するには、以下の手順を使用します。
Xen インスタンスおよび Nitro System 上に構築されたインスタンスでは、デバイスおよびパーティションの命名が異なることに注意してください。インスタンスが Xen ベースか Nitro ベースかを確認するには、「[ハイパーバイザーのタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#instance-hypervisor-type)」を参照してください。
**EBS ボリュームのファイルシステムを拡張するには**
1. [インスタンスに接続します](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)。
1. 必要に応じて、パーティションのサイズを変更します。そのためには、次の操作を行います。
1. ボリュームにパーティションがあるかどうかを確認します。**lsblk** コマンドを使用します。
------
#### [ Nitro instance example ]
次の出力例では、ルートボリューム (`nvme0n1`) には 2 つのパーティション (`nvme0n1p1` および `nvme0n1p128`) がありますが、追加のボリューム (`nvme1n1`) にはパーティションがありません。
```
[ec2-user ~]$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1 259:0 0 30G 0 disk /data
nvme0n1 259:1 0 16G 0 disk
└─nvme0n1p1 259:2 0 8G 0 part /
└─nvme0n1p128 259:3 0 1M 0 part
```
------
#### [ Xen instance example ]
次の出力例では、ルートボリューム (`xvda`) にはパーティション (`xvda1`) がありますが、追加のボリューム (`xvdf`) にはパーティションがありません。
```
[ec2-user ~]$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 8G 0 part /
xvdf 202:80 0 24G 0 disk
```
------
+ ボリュームにパーティションがある場合は、次のステップ (2b) に進みます。
+ ボリュームにパーティションがない場合は、ステップ 2b、2c、2d をスキップして、ステップ 3 に進みます。
**トラブルシューティングのヒント**
コマンド出力でボリュームが表示されない場合は、ボリュームが[インスタンスにアタッチ](ebs-attaching-volume.md)され、[フォーマットおよびマウントされている](ebs-using-volumes.md#ebs-format-mount-volume)ことを確認します。
1. パーティションを拡張する必要があるかどうかを確認します。前のステップの **lsblk** コマンド出力で、パーティションサイズとボリュームサイズを比較します。
+ パーティションサイズがボリュームサイズよりも小さい場合は、次のステップ (2c) に進みます。
+ パーティションサイズがボリュームサイズと等しい場合、パーティションを拡張する必要はありません。ステップ 2c および 2d をスキップし、ステップ 3 に進みます。
**トラブルシューティングのヒント**
ボリュームがまだ元のサイズを反映している場合は、[ボリュームの変更が成功したことを確認します](monitoring-volume-modifications.md)。
1. パーティションを拡張します。**growpart** コマンドを使用して、デバイス名とパーティション番号を指定します。
------
#### [ Nitro instance example ]
パーティション番号は、`p` の後の番号です。例えば、`nvme0n1p1` の場合、パーティション番号は `1` です。`nvme0n1p128` の場合、パーティション番号は `128` です。
例えば、`nvme0n1p1` という名前のパーティションを拡張するには、次のコマンドを使用します。
**重要**
デバイス名 (`nvme0n1`) とパーティション番号 (`1`) の間のスペースに注意してください。
```
[ec2-user ~]$ sudo growpart /dev/nvme0n1 1
```
------
#### [ Xen instance example ]
パーティション番号は、デバイス名の後の番号です。例えば、`xvda1` の場合、パーティション番号は `1` です。`xvda128` の場合、パーティション番号は `128` です。
例えば、`xvda1` という名前のパーティションを拡張するには、次のコマンドを使用します。
**重要**
デバイス名 (`xvda`) とパーティション番号 (`1`) の間のスペースに注意してください。
```
[ec2-user ~]$ sudo growpart /dev/xvda 1
```
------
**トラブルシューティングのヒント**
`mkdir: cannot create directory ‘/tmp/growpart.31171’: No space left on device FAILED: failed to make temp dir`: サイズ変更の実行に必要な一時ディレクトリを growpart が作成するのに十分な空きディスク容量がボリュームにないことを示します。ディスク容量を少し解放してから、もう一度お試しください。
`must supply partition-number`: 正しくないパーティションが指定されたことを示します。**lsblk** コマンドを使用してパーティション名を確認し、デバイス名とパーティション番号の間にスペースが入力されていることを確認します。
`NOCHANGE: partition 1 is size 16773087. it cannot be grown`: パーティションが既にボリューム全体を拡張しており、拡張できないことを示します。[ボリュームの変更が成功したことを確認します](monitoring-volume-modifications.md)。
1. パーティションが拡張されたことを確認します。**lsblk** コマンドを使用します。これで、パーティションのサイズはボリュームサイズと同じになります。
------
#### [ Nitro instance example ]
次の出力例は、両方のボリューム (`nvme0n1`) とパーティション (`nvme0n1p1`) が同じサイズ (`16 GB`) であることを示しています。
```
[ec2-user ~]$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1 259:0 0 30G 0 disk /data
nvme0n1 259:1 0 16G 0 disk
└─nvme0n1p1 259:2 0 16G 0 part /
└─nvme0n1p128 259:3 0 1M 0 part
```
------
#### [ Xen instance example ]
次の出力例は、両方のボリューム (`xvda`) とパーティション (`xvda1`) が同じサイズ (`16 GB`) であることを示しています。
```
[ec2-user ~]$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 16G 0 part /
xvdf 202:80 0 24G 0 disk
```
------
1. ファイルシステムを拡張します。
1. 拡張する必要があるファイルシステムの名前、サイズ、タイプ、およびマウントポイントを取得します。**df -hT** または **lsblk -f** コマンドを使用します。
------
#### [ Nitro instance example ]
**df -hT** コマンドの次の出力例では、`/dev/nvme0n1p1` ファイルシステムのサイズが 8 GB、タイプが `xfs`、マウントポイントが `/` であることを示しています。
```
[ec2-user ~]$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/nvme0n1p1 xfs 8.0G 1.6G 6.5G 20% /
/dev/nvme1n1 xfs 8.0G 33M 8.0G 1% /data
...
```
------
#### [ Xen instance example ]
**df -hT** コマンドの次の出力例では、`/dev/xvda1` ファイルシステムのサイズが 8 GB、タイプが `ext4`、マウントポイントが `/` であることを示しています。
```
[ec2-user ~]$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/xvda1 ext4 8.0G 1.9G 6.2G 24% /
/dev/xvdf1 xfs 24.0G 45M 8.0G 1% /data
...
```
------
+ ファイルシステムのサイズがボリュームサイズよりも小さい場合は、次のステップ (3b) に進みます。
+ ファイルシステムのサイズがボリュームサイズと等しい場合、拡張する必要はありません。この場合、残りのステップをスキップします。パーティションとファイルシステムは新しいボリュームサイズに拡張されています。
1. ファイルシステムを拡張するコマンドは、ファイルシステムのタイプによって異なります。前のステップで書き留めたファイルシステムのタイプに基づいて、次の正しいコマンドを選択します。
+ **[XFS ファイルシステム]** **xfs\$1growfs** コマンドを使用して、前のステップで書き留めたファイルシステムのマウントポイントを指定します。
------
#### [ Nitro and Xen instance example ]
例えば、`/` にマウントされているファイルシステムを拡張するには、次のコマンドを使用します。
```
[ec2-user ~]$ sudo xfs_growfs -d /
```
------
**トラブルシューティングのヒント**
`xfs_growfs: /data is not a mounted XFS filesystem`: 正しくないマウントポイントが指定されたか、ファイルシステムが XFS でないことを示します。マウントポイントとファイルシステムタイプを確認するには、**df -hT** コマンドを使用します。
`data size unchanged, skipping`: ファイルシステムが既にボリューム全体を拡張していることを示します。ボリュームにパーティションがない場合は、[ボリュームの変更が成功したことを確認します](monitoring-volume-modifications.md)。ボリュームにパーティションがある場合は、ステップ 2 で説明されているように、パーティションが拡張されていることを確認します。
+ **[Ext4 ファイルシステム]** **resize2fs** コマンドを使用して、前のステップで書き留めたファイルシステムの名前を指定します。
------
#### [ Nitro instance example ]
例えば、マウントされた `/dev/nvme0n1p1` という名前のファイルシステムを拡張するには、次のコマンドを使用します。
```
[ec2-user ~]$ sudo resize2fs /dev/nvme0n1p1
```
------
#### [ Xen instance example ]
例えば、マウントされた `/dev/xvda1` という名前のファイルシステムを拡張するには、次のコマンドを使用します。
```
[ec2-user ~]$ sudo resize2fs /dev/xvda1
```
------
**トラブルシューティングのヒント**
`resize2fs: Bad magic number in super-block while trying to open /dev/xvda1`: ファイルシステムが Ext4 ではないことを示します。ファイルのシステムタイプを確認するには、**df -hT** コマンドを使用します。
`open: No such file or directory while opening /dev/xvdb1`: 正しくないパーティションが指定されたことを示します。パーティションを検証するには、**df -hT** コマンドを使用します。
`The filesystem is already 3932160 blocks long. Nothing to do!`: ファイルシステムが既にボリューム全体を拡張していることを示します。ボリュームにパーティションがない場合は、[ボリュームの変更が成功したことを確認します](monitoring-volume-modifications.md)。ボリュームにパーティションがある場合は、ステップ 2 で説明されているように、パーティションが拡張されていることを確認します。
+ **[その他のファイルシステム]** 手順については、ファイルシステムのドキュメントを参照してください。
1. ファイルシステムが拡張されたことを確認します。**df -hT** コマンドを使用して、ファイルシステムのサイズがボリュームサイズと等しいことを確認します。
## Windows インスタンス
次のいずれかの方法を使用して Windows インスタンスでファイルシステムを拡張します。
------
#### [ Disk Management utility ]
**ディスクの管理を使用してファイルシステムを拡張するには**
1. 重要なデータを含むファイルシステムを拡張する前に、変更をロールバックする必要がある場合に備えて、ファイルシステムを含むボリュームのスナップショットを作成するのがベストプラクティスです。詳細については、[Amazon EBS スナップショットの作成](ebs-creating-snapshot.md)を参照してください。
1. リモートデスクトップを使用して Windows インスタンスにログインします。
1. [**実行**] ダイアログボックスに**diskmgmt.msc**と入力し、Enter キーを押します。ディスクの管理ユーティリティが表示されます。
![\[Windows Server ディスクの管理ユーティリティ\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/Expand-Volume-Win2008-before.png)
1. [**ディスクの管理**] メニューで、[**操作**]、[**ディスクの再スキャン**] の順に選択します。
1. 拡張したドライブのコンテキスト (右クリック) メニューを開き、[**Extend Volume (ボリュームの拡張)**] を選択します。
**注記**
次の場合には、[**ボリュームを拡張**] が無効化されている (グレー表示される) ことがあります。
未割り当ての領域が、ドライブに隣接していない。未割り当て領域は、拡張するドライブの右側に隣接している必要があります。
ボリュームが、マスターブートレコード (MBR) パーティションスタイルを使用しており、そのサイズが既に 2 TB に達している。MBR を使用するボリュームのサイズは 2 TB を超えることはできません。
![\[Windows Server ディスクの管理ユーティリティ\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/Expand-Volume-Win2008-before-menu.png)
1. [**Extend Volume (ボリュームの拡張)**] ウィザードで、[**Next (次へ)**] を選択します。[**Select the amount of space in MB**] で、ボリュームを拡張するメガバイト数を入力します。通常は、使用可能な最大領域を指定します。[**Selected**] のハイライト表示されたテキストは、ボリュームの最終的なサイズではなく、追加分の容量を表します。ウィザードを終了します。
![\[Windows Server ボリュームの拡張ウィザード\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/Extend-Volume-Wizard-Win2008.png)
1. AWS NVMe ドライバーがないインスタンスで NVMe ボリュームのサイズを増やす場合、インスタンスを再起動して Windows を有効にし、新規のボリュームサイズを表示する必要があります。 AWS NVMe ドライバーのインストールの詳細については、[AWS NVMe ドライバー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/aws-nvme-drivers.html)」を参照してください。
------
#### [ PowerShell ]
PowerShell を使用して Windows ファイルシステムを拡張するには、以下の手順に従います。
**PowerShell を使用してファイルシステムを拡張するには**
1. 重要なデータを含むファイルシステムを拡張する前に、変更をロールバックする必要がある場合に備えて、ファイルシステムを含むボリュームのスナップショットを作成するのがベストプラクティスです。詳細については、[Amazon EBS スナップショットの作成](ebs-creating-snapshot.md)を参照してください。
1. リモートデスクトップを使用して Windows インスタンスにログインします。
1. 管理者として PowerShell を実行します。
1. `Get-Partition` コマンドを実行します。PowerShell は、各パーティションに対応するパーティション番号、ドライブ文字、オフセット、サイズ、タイプを返します。拡張するパーティションのドライブ文字をメモします。
1. 以下のコマンドを実行して、ディスクを再スキャンします。
```
"rescan" | diskpart
```
1. **** の代わりに手順 4 でメモしたドライブ文字を使用して、以下のコマンドを実行します。PowerShell から、許可されているパーティションの最小サイズと最大サイズがバイト単位で返されます。
```
Get-PartitionSupportedSize -DriveLetter
```
1. 指定された規模にパーティションを拡張するには、**** の代わりにボリュームの新しいサイズを入力しながら、次のコマンドを実行します。サイズは、`KB`、`MB`、`GB` で入力できます (`50GB` など)。
```
Resize-Partition -DriveLetter -Size
```
使用可能な最大サイズにパーティションを拡張するには、次のコマンドを実行します。
```
Resize-Partition -DriveLetter -Size $(Get-PartitionSupportedSize -DriveLetter ).SizeMax
```
特定のサイズにファイルシステムを拡張するための、完全な PowerShell コマンドと、そのレスポンスフローを以下に示します。
![\[PowerShell を使用してパーティションを拡張する – 指定サイズの例\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/ebs-extend-powershell-v3-specific.png)
使用可能な最大サイズにファイルシステムを拡張するための、完全な PowerShell コマンドと、そのレスポンスフローを以下に示します。
![\[PowerShell を使用してパーティションを拡張する – 最大サイズ\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/ebs-extend-powershell-v3-max.png)
------
# Amazon EC2 インスタンスから Amazon EBS ボリュームをデタッチ
Amazon Elastic Block Store (Amazon EBS) ボリュームをインスタンスからデタッチしてから、別のインスタンスにアタッチまたは削除する必要があります。ボリュームをデタッチしても、ボリュームのデータには影響しません。
**Topics**
+ [考慮事項](#considerations)
+ [ボリュームのアンマウントとデタッチ](#umount-detach-volume)
+ [トラブルシューティング](#detach-troubleshoot)
## 考慮事項
+ インスタンスから Amazon EBS ボリュームをデタッチするには、明示的にデタッチするか、インスタンスを終了します。ただし、インスタンスが実行中の場合、最初にインスタンスからボリュームをアンマウントする必要があります。
+ EBS ボリュームがインスタンスのルートデバイスである場合、ボリュームをデタッチする前に、インスタンスを停止する必要があります。
+ (アンマウントせずに) 切り離したボリュームを再接続することはできますが、同じマウントポイントが得られない可能性があります。進行中のボリュームがデタッチされたときにそのボリュームへの書き込みがあった場合、ボリューム上のデータは同期していない可能性があります。
+ ボリュームをデタッチした後も、ストレージ量が AWS 無料利用枠の制限を超えている限り、ボリュームストレージに対して課金されます。不要な料金の発生を防ぐために、ボリュームを削除する必要があります。詳細については、[Amazon EBS ボリュームの削除](ebs-deleting-volume.md)を参照してください。
## ボリュームのアンマウントとデタッチ
ボリュームをインスタンスからアンマウントおよびデタッチするには、次の手順を使用します。これは、ボリュームを別のインスタンスにアタッチする必要がある場合や、ボリュームを削除する必要がある場合に便利です。
**Topics**
+ [手順 1: ボリュームをアンマウントする](#unmount)
+ [手順 2: ボリュームをインスタンスからデタッチする](#detach)
+ [ステップ 3: (*Windows インスタンスのみ*) オフラインデバイスのロケーションをアンインストールする](#uninstall)
### 手順 1: ボリュームをアンマウントする
#### Linux インスタンス
Linux インスタンスから、次のコマンドを使用して `/dev/sdh` デバイスのマウントを解除します。
```
[ec2-user ~]$ sudo umount -d /dev/sdh
```
#### Windows インスタンス
Windows インスタンスから、次のようにボリュームをマウント解除します。
1. [Disk Management] ユーティリティを起動します。
+ (Windows Server 2012 以降) タスクバーで、Windows ロゴを右クリックし、[**Disk Management**] を選択します。
+ (Windows Server 2008) [**Start**]、[**Administrative Tools**]、[**Computer Management**]、[**Disk Management**] の順に選択します。
1. ディスクを右クリック (例: [**Disk 1**] を右クリック) し、[**オフライン**] を選択します。ディスクのステータスが [**オフライン**] に変わるまで待ってから Amazon EC2 コンソールを開きます。
### 手順 2: ボリュームをインスタンスからデタッチする
インスタンスからボリュームをデタッチするには、次のいずれかの方法を使用します。
------
#### [ Console ]
**EBS ボリュームをデタッチするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. ボリュームを選択します。
1. **[アクション]**、**[ボリュームのデタッチ]** を選択します。
1. 確認を求められたら、[**デタッチ**] を選択してください。
------
#### [ AWS CLI ]
**EBS ボリュームをインスタンスからデタッチするには**
ボリュームをアンマウントしたら、[detach-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/detach-volume.html) コマンドを使用します。
```
aws ec2 detach-volume --volume-id vol-01234567890abcdef
```
------
#### [ PowerShell ]
**EBS ボリュームをインスタンスからデタッチするには**
ボリュームをアンマウントしたら、[Dismount-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Dismount-EC2Volume.html) コマンドレットを使用します。
```
Dismount-EC2Volume -VolumeId vol-01234567890abcdef
```
------
### ステップ 3: (*Windows インスタンスのみ*) オフラインデバイスのロケーションをアンインストールする
ボリュームをインスタンスからアンマウントおよびデタッチすると、Windows はデバイスの場所にオフラインのフラグを立てます。インスタンスの再起動と停止および再起動後、デバイスの場所はオフラインのままになります。インスタンスを再起動すると、Windows はオフラインのデバイスの場所に残りのボリュームの 1 つをマウントする可能性があります。これにより、ボリュームが Windows で使用できなくなります。これが起こらないようにし、次に Windows を起動したときにすべてのボリュームがオンラインデバイスの場所に接続されるようにするには、次の手順に従います。
1. インスタンスで、デバイスマネージャーを開きます。
1. デバイスマネージャーで、[**View**]、[**Show hidden devices**] の順に選択します。
1. デバイスのリストで、[**Storage controllers**] ノードを展開します。
デタッチされたボリュームがマウントされたデバイスの場所に `AWS NVMe Elastic Block Storage Adapter` という名前が付けられ、グレー表示されます。
1. グレー表示されている `AWS NVMe Elastic Block Storage Adapter` という名前の各デバイスの場所を右クリックし、**[Uninstall device]** (デバイスをアンインストール) を選択し、**[Uninstall]** (アンインストール) を選択します。
**重要**
[**Delete the driver software for this device**] チェックボックスはオンにしないでください。
## トラブルシューティング
ボリュームをデタッチする場合に発生する一般的な問題と、それらを解決する方法は、次のとおりです。
**注記**
データ損失の可能性に対する保護を許可するには、ボリュームのスナップショットを作成してからアンマウントを試みます。スタックしたボリュームの強制デタッチを行うと、インスタンスを再起動しない限り、ファイルシステムまたはファイルシステムに含まれるデータに損害を与えたり、同じデバイス名を使用して新しいボリュームをアタッチできなくなったりする可能性があります。
+ Amazon EC2 コンソールからボリュームを切り離しているときに問題が発生した場合は、**describe-volumes** CLI コマンドを使用して問題を診断すると便利なことがあります。詳細については、[describe-volumes](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volumes.html)を参照してください。
+ ボリュームの状態が`detaching`状態のまま変わらない場合は、[**Force Detach**] を選択して、強制的にアタッチ解除することもできます。障害が発生したインスタンスからボリュームをアタッチ解除するための最後の手段として、またはボリュームを削除するためにデタッチする場合のみ、このオプションを使用してください。インスタンスは、ファイルシステムキャッシュやファイルシステムメタデータをフラッシュする機会を失います。このオプションを使用する場合は、ファイルシステムのチェックと修復の手順を手動で実行する必要があります。
+ ボリュームを数分間何度も強制的に切断しようとしたが、`detaching` 状態のままになっている場合は、[AWS re:Post](https://repost.aws/) へのヘルプのリクエストを送信できます。迅速に解決できるようにするため、ボリューム ID と、これまでに実行した手順を記述してください。
+ まだマウントされたボリュームをデタッチしようとすると、ボリュームはデタッチを実行しようとして `busy` 状態でスタックする可能性があります。**describe-volumes** からの次の出力は、この状態の例を示しています。
```
"Volumes": [
{
"AvailabilityZone": "us-west-2b",
"Attachments": [
{
"AttachTime": "2022-07-21T23:44:52.000Z",
"InstanceId": "i-1234567890abcdef0",
"VolumeId": "vol-01234567890abcdef",
"State": "busy",
"DeleteOnTermination": false,
"Device": "/dev/sdf"
}
...
}
]
```
この状態が発生した場合、ボリュームのアンマウント、デタッチの強制、インスタンスの再起動、またはそれら 3 つをすべて行うまで、デタッチは無期限に遅れる可能性があります。
# Amazon EBS ボリュームの削除
Amazon EBS ボリュームが不要になったら、それを削除することができます。削除後、ボリュームに含まれるデータは消去され、ボリューム自体はどのインスタンスにもアタッチできなくなります。削除前にボリュームのスナップショットを保存できるので、それを使用すれば後でボリュームを再作成できます。
インスタンスにアタッチされているボリュームは削除できません。ボリュームを削除するには、まずボリュームをデタッチする必要があります。詳細については、「[Amazon EC2 インスタンスから Amazon EBS ボリュームをデタッチ](ebs-detaching-volume.md)」を参照してください。
ごみ箱の保持ルールに一致するボリュームを削除すると、そのボリュームはすぐに削除されるのではなく、ごみ箱に保持されます。詳細については、「[ごみ箱](recycle-bin.md)」を参照してください。
------
#### [ Console ]
**EBS ボリュームを削除するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. ボリュームを選択します。ボリュームが **[使用可能]** 状態であることを確認します。
1. **[アクション]**、**[ボリュームの削除]** を選択します。
このオプションが無効になっている場合、ボリュームはインスタンスにアタッチされ、削除できません。
1. 確認を求められたら、「**delete**」と入力してから、[**削除**] を選択します。
------
#### [ AWS CLI ]
**EBS ボリュームが使用中かどうかを確認するには**
[describe-volumes](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volumes.html) コマンドを使用します。ボリュームが使用中の場合、状態は `in-use` になります。それ以外の場合は、`available` です。
```
aws ec2 describe-volumes \
--volume-id vol-01234567890abcdef \
--query Volumes[*].State \
--output text
```
**EBS ボリュームを削除するには**
[delete-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-volume.html) コマンドを使用します。
```
aws ec2 delete-volume --volume-id vol-01234567890abcdef
```
------
#### [ PowerShell ]
**EBS ボリュームが使用中かどうかを確認するには**
[Get-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Volume.html) コマンドレットを使用します。ボリュームが使用中の場合、状態は `in-use` になります。それ以外の場合は、`available` です。
```
(Get-EC2Volume `
-VolumeId vol-01234567890abcdef).State.Value
```
**EBS ボリュームを削除するには**
[Remove-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2Volume.html) コマンドレットを使用します。
```
Remove-EC2Volume -VolumeId vol-01234567890abcdef
```
------
# スナップショットを使用した Amazon EBS ボリュームの置き換え
Amazon EBS スナップショットは、速度、利便性、コストに優れるため、Amazon EC2 で推奨されるバックアップツールです。スナップショットからボリュームを作成すると、すべてのデータをそのままの状態で、過去の特定時点の状態が再作成されます。スナップショットから作成されたボリュームをインスタンスにアタッチすることで、リージョン間でのデータの複製、テスト環境の作成、損傷または破損した本稼働ボリュームの完全な置換、特定のファイルとディレクトリの取得とアタッチされた別のボリュームへの転送を行うことができます。詳細については、「[Amazon EBS スナップショット](ebs-snapshots.md)」を参照してください。
Amazon EBS ボリュームを、そのボリュームの以前のスナップショットから作成された別のボリュームに置き換えるには、次の手順のいずれかを使用できます。
**要件**
インスタンスと同じアベイラビリティーゾーンに新しい EBS ボリュームを作成する必要があります。ボリュームは、インスタンスと同じアベイラビリティーゾーンにアタッチする必要があります。
------
#### [ Console ]
**ボリュームを置き換えるには**
1. スナップショットからボリュームを作成し、新しいボリュームの ID を書き留めます。詳細については、「[Amazon EBS ボリュームの作成](ebs-creating-volume.md)」を参照してください。
1. [インスタンス] ページで、ボリュームを置き換えるインスタンスを選択し、インスタンス ID を書き留めます。
インスタンスが選択された状態で、**[Storage]** (ストレージ) タブを選択します。**[Block devices]** (ブロックデバイス) セクションで、置き換えるボリュームを検索し、ボリュームのデバイス名を書き留めます (例: `/dev/sda1`)。
1. **[ストレージ]** タブで、ボリューム ID を選択し、[インスタンスからボリュームをアンマウントおよびデタッチします](ebs-detaching-volume.md#umount-detach-volume)。
1. ステップ 1 で作成した新しいボリュームを選択し、**[Actions]** (アクション)、**[Attach volume]** (ボリュームのアタッチ) を選択します。
**[Instance]** (インスタンス) および **[Device name]** (デバイス名) に、ステップ 2 で書き留めたインスタンス ID とデバイス名を入力し、**[Attach volume]** (ボリュームのアタッチ) を選択します。
1. インスタンスに接続し、ボリュームをマウントします。詳細については、「[Amazon EBS ボリュームを使用できるようにする](ebs-using-volumes.md)」を参照してください。
------
#### [ AWS CLI ]
**ボリュームを置き換えるには**
1. スナップショットから新しいボリュームを作成します。[create-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-volume.html) コマンドを使用して、`--snapshot-id` オプションを指定します。`--availability-zone` には、インスタンスと同じアベイラビリティーゾーンを指定します。出力で、新しいボリュームの ID を書き留めます。
```
aws ec2 create-volume \
--volume-type gp3 \
--snapshot-id snap-0abcdef1234567890 \
--availability-zone us-east-1a
```
1. 置き換えるボリュームのデバイス名を取得します。[describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) コマンドを使用します。`--instance-ids` には、ボリュームを置き換えるインスタンスの ID を指定します。置き換えるボリュームのデバイス名とボリューム ID を書き留めます。
```
aws ec2 describe-instances \
--instance-ids i-1234567890abcdef0 \
--query Reservations[].Instances[].BlockDeviceMappings
```
1. 交換するボリュームをインスタンスからデタッチします。[detach-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/detach-volume.html) コマンドを使用します。
```
aws ec2 detach-volume --volume-id vol-xxxxxxxxxxxxxxxxx
```
1. 置換ボリュームをインスタンスにアタッチします。[attach-volume](https://docs.aws.amazon.com/cli/latest/reference/ec2/attach-volume.html) コマンドを使用します。`--volume-id` には、置き換えるボリュームの ID を指定します。`--instance-id` には、ボリュームをアタッチするインスタンスの ID を指定します。`--device` には、先ほどメモしたものと同じデバイス名を指定します。
```
aws ec2 attach-volume \
--volume-id vol-01234567890abcdef \
--instance-id i-1234567890abcdef0 \
--device /dev/sdf
```
1. インスタンスに接続し、ボリュームをマウントします。詳細については、「[Amazon EBS ボリュームを使用できるようにする](ebs-using-volumes.md)」を参照してください。
------
#### [ PowerShell ]
**ボリュームを置き換えるには**
1. スナップショットから新しいボリュームを作成します。`-SnapshotId` オプションで [New-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Volume.html) コマンドレットを使用します。`-AvailabilityZone` には、インスタンスと同じアベイラビリティーゾーンを指定します。出力で、新しいボリュームの ID を書き留めます。
```
New-EC2Volume `
-VolumeType gp3 `
-SnapshotId snap-0abcdef1234567890 `
-AvailabilityZone us-east-1a
```
1. 置き換えるボリュームのデバイス名を取得します。[Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html) コマンドレットを使用します。`-InstanceId` には、ボリュームを置き換えるインスタンスの ID を指定します。置き換えるボリュームのデバイス名とボリューム ID を書き留めます。
```
(Get-EC2Instance `
-InstanceId i-1234567890abcdef0).Instances.BlockDeviceMappings | `
Format-Table DeviceName, @{Name="VolumeId";Expression={$_.Ebs.VolumeId}}
```
1. 交換するボリュームをインスタンスからデタッチします。[Dismount-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Dismount-EC2Volume.html) コマンドレットを使用します。
```
DismountEC2Volume -VolumeId vol-xxxxxxxxxxxxxxxxx
```
1. 置換ボリュームをインスタンスにアタッチします。[Add-EC2Volume](https://docs.aws.amazon.com/powershell/latest/reference/items/Add-EC2Volume.html) コマンドレットを使用します。`-VolumeId` には、置き換えるボリュームの ID を指定します。`-InstanceId` には、ボリュームをアタッチするインスタンスの ID を指定します。`-Device` には、先ほどメモしたものと同じデバイス名を指定します。
```
Add-EC2Volume`
-VolumeId vol-01234567890abcdef `
-InstanceId i-1234567890abcdef0 `
-Device /dev/sdf
```
1. インスタンスに接続し、ボリュームをマウントします。詳細については、「[Amazon EBS ボリュームを使用できるようにする](ebs-using-volumes.md)」を参照してください。
------
# Amazon EBS ボリュームステータスチェック
ボリュームステータスチェックを利用すると、Amazon EBS ボリュームのデータの潜在的な不整合を容易に理解、追跡、および管理できます。これらのチェックは、Amazon EBS ボリュームに障害が発生しているかどうかを判断するために必要な情報を提供し、潜在的に不整合なボリュームの処理方法を制御できるように設計されています。
ボリュームステータスチェックは 5 分ごとに自動的に試行され、成功または失敗のステータスを返します。すべてのチェックが成功した場合、ボリュームのステータスは `ok` です。チェックが失敗した場合、ボリュームのステータスは `impaired` です。ステータスが `insufficient-data` の場合、ボリュームのチェックがまだ実行中である可能性があります。ボリュームステータスチェックの結果を表示して、障害のあるボリュームを特定し、必要なアクションを行うことができます。
ボリュームのデータが潜在的に不整合であると Amazon EBS が判断した場合、デフォルトでは、アタッチされたすべての EC2 インスタンスからそのボリュームへの I/O が無効になります。これにより、データの破損を防ぐことができます。I/O が無効になると、次のボリュームステータスチェックが失敗し、ボリュームステータスは `impaired` になります。さらに、I/O が無効になったこと、およびボリュームへの I/O を有効にすることによってボリュームの障害ステータスを解決できることを伝えるイベントが表示されます。ユーザーが I/O を有効にするまでシステムは待機するため、インスタンスがボリュームの使用を継続するかどうかを決定するか、それを実行する前に **fsck** (Linux インスタンス) または **chkdsk** (Windows インスタンス) などコマンドを使用して整合性チェックを実行する判断をできる機会を与えます。
**注記**
ボリュームステータスはボリュームステータスチェックに基づいており、ボリューム状態を反映していません。従って、ボリュームステータスではボリュームが `error` 状態 (例えば、I/O を受け付けできない) であることは判りません。ボリュームの状態についての詳細は、[ボリューム状態](ebs-describing-volumes.md#volume-state)を参照してください。
あるボリュームの整合性について心配しているわけではなく、そのボリュームに障害が発生した際にそのボリュームをすぐに利用できるようにしたい場合は、デフォルトの動作を上書きして、I/O を自動的に有効にするようにボリュームを設定することができます。**Auto-Enable IO** 属性 (API の `autoEnableIO`) を有効にしている場合は、ボリューム状態のチェックは引き続きパスされます。また、ボリュームに潜在的な障害があると判断されたが、そのボリュームの I/O が自動的に有効になったことを伝えるイベントも表示されます。これにより、ボリュームの整合性を確認したり、後でボリュームを交換したりすることが可能になります。
I/O パフォーマンスステータスチェックは、実際のボリュームパフォーマンスと予想されるボリュームパフォーマンスを比較します。ボリュームパフォーマンスが想定未満である場合は、警告が表示されます。このステータスチェックは、インスタンスにアタッチされている、プロビジョンド IOPS SSD (`io1` および `io2`) ボリュームと、汎用 SSD (`gp3`) ボリュームに対してのみ使用できます。ステータスチェックは、汎用 SSD (`gp2`)、スループット最適化 HDD (`st1`)、Cold HDD (`sc1`)、または磁気 (`standard`) ボリュームでは使用できません。I/O パフォーマンスステータスチェックは 1 分ごとに 1 回実行され、CloudWatch は 5 分ごとにこのデータを収集します。`io1` または `io2` ボリュームをインスタンスにアタッチしてから、ステータスチェックが I/O パフォーマンスステータスを報告するまでに、最長で 5 分かかる場合があります。
**重要**
スナップショットから復元された Provisioned IOPS SSD ボリュームを初期化している間は、ボリュームのパフォーマンスが想定レベルの 50% を下回る場合があります。このため、ボリュームの [**I/O Performance (I/O パフォーマンス)**] ステータスチェックでは `warning` 状態が表示されます。これは想定の動作です。初期化中の Provisioned IOPS SSD ボリュームの `warning` 状態は無視してかまいません。詳細については、[作成後にボリュームを手動で初期化する](initalize-volume.md#ebs-initialize)を参照してください。
次の表に、Amazon EBS ボリュームのステータスを示します。
| ボリュームのステータス | I/O 有効ステータス | I/O パフォーマンスステータス (`io1`、`io2`、および `gp3` ボリュームのみ) |
| --- | --- | --- |
| `ok` | Enabled (I/O Enabled または I/O Auto-Enabled) | Normal (ボリュームパフォーマンスは想定どおり) |
| `warning` | Enabled (I/O Enabled または I/O Auto-Enabled) | Degraded (ボリュームのパフォーマンスが想定を下回っている) Severely Degraded (ボリュームのパフォーマンスが想定をかなり下回っている) |
| `impaired` | Enabled (I/O Enabled または I/O Auto-Enabled) Disabled (ボリュームがオフラインで復旧の保留中、またはユーザーによる I/O の有効化待ち) | Stalled (ボリュームのパフォーマンスは致命的な影響を受けている) Not Available (I/O が無効なため、I/O パフォーマンスの判定不能) |
| `insufficient-data` | Enabled (I/O Enabled または I/O Auto-Enabled) Insufficient Data | Insufficient Data |
------
#### [ Console ]
**ステータスチェックを表示するには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ボリューム**] を選択します。
**[Volume Status]** (ボリュームのステータス) 列に、各ボリュームの動作状況が表示されます。
1. 特定のボリュームのステータスの詳細を表示するには、グリッドからボリュームを選択して、**[Status Checks]**] (ステータスチェック) タブを選択します。
1. ステータスチェックが失敗したボリュームがある場合 (ステータスが `impaired` と示されている場合) は、[障害のある Amazon EBS ボリュームを操作する](work_volumes_impaired.md) を参照してください。
ナビゲータで [**Events (イベント)**] を選択して、インスタンスとボリュームのすべてのイベントを表示することもできます。詳細については、[Amazon EBS ボリュームイベント](monitoring-vol-events.md)を参照してください。
------
#### [ AWS CLI ]
**ボリュームステータス情報を表示するには**
[describe-volume-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volume-status.html) コマンドを使用します。
```
aws ec2 describe-volume-status --volume-ids vol-01234567890abcdef
```
次の例を使用して、障害のあるボリュームを特定します。
```
aws ec2 describe-volume-status --filters Name=volume-status.status,Values=impaired
```
------
#### [ PowerShell ]
**ボリュームステータス情報を表示するには**
[Get-EC2VolumeStatus](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2VolumeStatus.html) コマンドレットを使用します。
```
Get-EC2VolumeStatus -VolumeId vol-01234567890abcdef
```
次の例を使用して、障害のあるボリュームを特定します。
```
Get-EC2VolumeStatus -Filter @{Name="volume-status.status"; Values="impaired"}
```
------
# Amazon EBS ボリュームイベント
ボリュームのデータが潜在的に不整合であると Amazon EBS によって判断された場合、デフォルトでは、アタッチされているすべての EC2 インスタンスからそのボリュームへの I/O が無効になります。これにより、ボリュームステータスチェックが失敗し、障害の原因を示すボリュームステータスイベントが作成されます。
データが潜在的に不整合であるボリュームで I/O を自動的に有効にするには、**Auto-Enabled IO** ボリューム属性 (API の `autoEnableIO`) の設定を変更します。この属性の変更の詳細については、[障害のある Amazon EBS ボリュームを操作する](work_volumes_impaired.md)を参照してください。
各イベントには、イベントが発生した時刻を示す開始時刻と、そのボリュームに対する I/O が無効になった時間を示す継続時間が含まれています。ボリュームに対する I/O が有効になると、イベントに終了時刻が追加されます。ボリュームステータスイベント
`Awaiting Action: Enable IO`
ボリュームデータに整合性がない可能性があります。ボリュームに対する I/O は、ユーザーが明示的に有効にするまで無効になります。I/O を明示的に有効にすると、イベントの説明が **IO Enabled** に変更されます。
`IO Enabled`
このボリュームに対する I/O 操作が明示的に有効にされました。
`IO Auto-Enabled`
イベントの発生後に、このボリュームで I/O 操作が自動的に有効になりました。データを引き続き使用する前に、データの整合性を確認することをお勧めします。
`Normal`
`io1`、`io2`、および `gp3` ボリュームのみ。ボリュームのパフォーマンスは想定どおりです。
`Degraded`
`io1`、`io2`、および `gp3` ボリュームのみ。ボリュームのパフォーマンスは想定を下回っています。
`Severely Degraded`
`io1`、`io2`、および `gp3` ボリュームのみ。ボリュームのパフォーマンスは想定をはるかに下回っています。
`Stalled`
`io1`、`io2`、および `gp3` ボリュームのみ。ボリュームのパフォーマンスは致命的な影響を受けています。
I/O が無効になっているボリュームがある場合は、[障害のある Amazon EBS ボリュームを操作する](work_volumes_impaired.md)を参照してください。I/O パフォーマンスが通常の状態を下回っているボリュームがある場合、実行したアクションを原因とする一時的な状態である可能性があります (ピーク使用時にボリュームのスナップショットを作成した、必要な I/O 帯域幅をサポートできないインスタンスでボリュームを実行した、ボリュームのデータに初めてアクセスした、など)。
------
#### [ Console ]
**ボリュームイベントを表示するには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**Events**] を選択します。イベントを含むすべてのインスタンスおよびボリュームがリストされています。
1. ボリュームでフィルタリングして、ボリュームステータスのみを表示できます。特定のタイプのステータスでフィルタリングすることもできます。
1. ボリュームを選択して、その特定のイベントを表示します。
------
#### [ AWS CLI ]
**ボリュームイベントを表示するには**
[describe-volume-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volume-status.html) コマンドを使用します。
```
aws ec2 describe-volume-status --volume-ids vol-01234567890abcdef
```
------
#### [ PowerShell ]
**ボリュームイベントを表示するには**
[Get-EC2VolumeStatus](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2VolumeStatus.html) コマンドレットを使用します。
```
Get-EC2VolumeStatus -VolumeId vol-01234567890abcdef
```
------
# 障害のある Amazon EBS ボリュームを操作する
ボリュームのデータが整合していない可能性があるためにボリュームに障害がある場合は、以下のオプションを使用します。
**Topics**
+ [オプション 1: インスタンスにアタッチされたボリュームで整合性チェックを実行する](#work_volumes_impaired_option1)
+ [オプション 2: 別のインスタンスを使用してボリュームで整合性チェックを実行する](#work_volumes_impaired_option2)
+ [オプション 3: 不要なボリュームを削除する](#work_volumes_impaired_option3)
## オプション 1: インスタンスにアタッチされたボリュームで整合性チェックを実行する
もっとも単純なオプションは、ボリュームが Amazon EC2 にアタッチされているときに、I/O を有効にしてから、ボリュームでデータの整合性チェックを実行するオプションです。
**アタッチされたボリュームで整合性チェックを実行するには**
1. アプリケーションによるボリュームの使用を停止します。
1. ボリュームの I/O を有効にします。次のいずれかの方法を使用します。
------
#### [ Console ]
**ボリュームの I/O を有効にするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**Events**] を選択してください。
1. ボリュームを選択します。
1. **[Actions]** (アクション)、**[Enable I/O]** (I/Oを有効化) を選択します。
------
#### [ AWS CLI ]
**ボリュームの I/O を有効にするには**
[enable-volume-io](https://docs.aws.amazon.com/cli/latest/reference/ec2/enable-volume-io.html) コマンドを使用します。
```
aws ec2 enable-volume-io --volume-id vol-01234567890abcdef
```
------
#### [ PowerShell ]
**ボリュームの I/O を有効にするには**
[Enable-EC2VolumeIO](https://docs.aws.amazon.com/powershell/latest/reference/items/Enable-EC2VolumeIO.html) コマンドレットを使用します。
```
Enable-EC2VolumeIO -VolumeId vol-01234567890abcdef
```
------
1. ボリュームのデータを確認します。
1. **fsck** (Linux インスタンス) または **chkdsk** (Windows インスタンス) コマンドを実行します。
1. (オプション) 関連するエラーメッセージがないか、使用可能なアプリケーションログまたはシステムログを確認します。
1. ボリュームに 20 分以上障害が発生した場合は、 AWS サポートセンターにお問い合わせください。[**Troubleshoot (トラブルシューティング)**] をクリックしてから、[**Troubleshoot Status Checks (ステータスチェックのトラブルシューティング)**] ダイアログボックスの [**Contact Support (サポートに問い合わせる)**] を選択してサポートケースを送信します。
## オプション 2: 別のインスタンスを使用してボリュームで整合性チェックを実行する
実動環境外部のボリュームをチェックするには、次の手順に従います。
**重要**
この手順を実行すると、ボリューム I/O を無効にしたときに停止された書き込み I/O が失われる場合があります。
**分離されたボリュームで整合性チェックを実行するには**
1. アプリケーションによるボリュームの使用を停止します。
1. ボリュームをインスタンスからデタッチします。詳細については、[Amazon EC2 インスタンスから Amazon EBS ボリュームをデタッチ](ebs-detaching-volume.md)を参照してください。
1. ボリュームの I/O を有効にします。次のいずれかの方法を使用します。
------
#### [ Console ]
**ボリュームの I/O を有効にするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**Events**] を選択してください。
1. 前の手順でデタッチしたボリュームを選択します。
1. **[Actions]** (アクション)、**[Enable I/O]** (I/Oを有効化) を選択します。
------
#### [ AWS CLI ]
**ボリュームの I/O を有効にするには**
[enable-volume-io](https://docs.aws.amazon.com/cli/latest/reference/ec2/enable-volume-io.html) コマンドを使用します。
```
aws ec2 enable-volume-io --volume-id vol-01234567890abcdef
```
------
#### [ PowerShell ]
**ボリュームの I/O を有効にするには**
[Enable-EC2VolumeIO](https://docs.aws.amazon.com/powershell/latest/reference/items/Enable-EC2VolumeIO.html) コマンドレットを使用します。
```
Enable-EC2VolumeIO -VolumeId vol-01234567890abcdef
```
------
1. ボリュームを別のインスタンスにアタッチします。詳細については、「[インスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html)」および「[Amazon EBS ボリュームを Amazon EC2 インスタンスにアタッチ](ebs-attaching-volume.md)」を参照してください。
1. ボリュームのデータを確認します。
1. **fsck** (Linux インスタンス) または **chkdsk** (Windows インスタンス) コマンドを実行します。
1. (オプション) 関連するエラーメッセージがないか、使用可能なアプリケーションログまたはシステムログを確認します。
1. ボリュームに 20 分以上障害が発生した場合は、 AWS サポートセンターにお問い合わせください。[**Troubleshoot (トラブルシューティング)**] を選択し、トラブルシューティングのダイアログボックスで [**Contact Support (サポートに問い合わせる)**] を選択して、サポートケースを送信します。
## オプション 3: 不要なボリュームを削除する
環境からボリュームを削除するには、単にそれを削除します。ボリュームの削除の詳細については、[Amazon EBS ボリュームの削除](ebs-deleting-volume.md)を参照してください。
ボリュームのデータをバックアップするスナップショットを最近作成した場合、そのスナップショットから新しいボリュームを作成できます。詳細については、「[Amazon EBS ボリュームの作成](ebs-creating-volume.md)」を参照してください。
# 障害のある Amazon EBS ボリュームの I/O の自動有効化
ボリュームのデータが潜在的に不整合であると Amazon EBS によって判断された場合、デフォルトでは、アタッチされているすべての EC2 インスタンスからそのボリュームへの I/O が無効になります。これにより、ボリュームステータスチェックが失敗し、障害の原因を示すボリュームステータスイベントが作成されます。あるボリュームの整合性について心配しているわけではなく、そのボリュームに**障害が発生した**際にそのボリュームをすぐに利用できるようにしたい場合は、デフォルトの動作を上書きして、I/O を自動的に有効にするようにボリュームを設定することができます。**Auto-Enable IO** 属性 (API の `autoEnableIO`) を有効にしている場合は、ボリュームとインスタンスとの間の I/O が自動的に有効になり、ボリュームのステータスチェックはパスされます。また、ボリュームが潜在的に不整合な状態であること、ただしそのボリュームの I/O が自動的に有効になったことを伝えるイベントも表示されます。このイベントが発生した場合は、ボリュームの整合性をチェックし、必要に応じて置き換えます。詳細については、「[Amazon EBS ボリュームイベント](monitoring-vol-events.md)」を参照してください。
------
#### [ Console ]
**ボリュームの、 IO の自動有効化 属性を表示するには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. ボリュームを選択して、**[Status Checks]** (ステータスチェック) を選択します。
**[Auto-Enabled I/O]** (自動有効化された I/O) には、ボリュームの現在の設定 (**[Enabled]** (有効) または **[Disabled]** (無効)) が表示されます。
**ボリュームの、IO の自動有効化属性を変更するには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. ボリュームを選択し、**[Actions]** (アクション)、**[Manage auto-enabled I/O]** (自動有効化 I/O の管理) を選択します。
1. 障害のあるボリュームの I/O を自動的に有効にするには、**[Auto-Enable Volume I/O for impaired volumes]** (障害のあるボリューム I/O の自動有効化) チェックボックスをオンにします。この機能を無効にするには、チェックボックスをクリアします。
1. **[更新]** を選択します。
------
#### [ AWS CLI ]
**ボリュームの autoEnableIO 属性を表示するには**
[describe-volume-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-volume-attribute.html) コマンドを使用します。
```
aws ec2 describe-volume-attribute \
--attribute autoEnableIO \
--volume-id vol-01234567890abcdef
```
以下は出力の例です。
```
{
"AutoEnableIO": {
"Value": true
},
"VolumeId": "vol-01234567890abcdef"
}
```
**ボリュームの autoEnableIO 属性を変更するには**
[modify-volume-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-volume-attribute.html) コマンドを使用します。
```
aws ec2 modify-volume-attribute \
--auto-enable-io \
--volume-id vol-01234567890abcdef
```
------
#### [ PowerShell ]
**ボリュームの autoEnableIO 属性を表示するには**
[Get-EC2VolumeAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2VolumeAttribute.html) コマンドレットを使用します。
```
(Get-EC2VolumeAttribute `
-Attribute autoEnableIO `
-VolumeId vol-01234567890abcdef).AutoEnableIO
```
以下は出力の例です。
```
True
```
**ボリュームの autoEnableIO 属性を変更するには**
[Edit-EC2VolumeAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2VolumeAttribute.html) コマンドレットを使用します。
```
Edit-EC2VolumeAttribute `
-AutoEnableIO $true `
-VolumeId vol-01234567890abcdef
```
------
# Amazon EBS での障害テスト
AWS Fault Injection Service (AWS FIS) は、 AWS ワークロードでフォールトインジェクション実験を実行するのに役立つフルマネージドサービスです。EBS アクションを使用すると AWS FIS、アプリケーションが I/O の中断やボリュームのパフォーマンスの低下につながるストレージ障害にどのように応答するかをテストできます。この制御されたテスト環境により、アプリケーションが中断にどのように応答するかを観察できるため、アーキテクチャの弱点を特定し、アプリケーションの全体的な耐障害性を向上させることができます。I/O 一時停止アクションとレイテンシーインジェクションアクションを使用して、Amazon CloudWatch アラームとフェイルオーバーワークフローなどのモニタリングおよび復旧メカニズムをテストし、ミッションクリティカルなアプリケーションのストレージ障害に対する耐障害性を向上させることができます。詳細については AWS FIS、[AWS Fault Injection Service 「 ユーザーガイド](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)」を参照してください。
## 利用可能な実験
Amazon EBS は現在、2 つの AWS FIS フォールトインジェクションをサポートしています。
+ [I/O フォールトインジェクションを一時停止する](ebs-fis-pause-io.md)
+ [レイテンシーインジェクション](ebs-fis-latency-injection.md)
## 考慮事項
以下の考慮事項に注意してください。
+ すべての Amazon EBS ボリュームタイプがサポートされています。ルートボリュームとデータボリュームの両方がサポートされます。インスタンスストアボリュームはサポートされていません。
+ ボリュームは [Nitro ベースの EC2 インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#instance-hypervisor-type)にアタッチする必要があります。
+ 期間に基づいて実験が完了すると、ボリュームは元の I/O パフォーマンスを再開します。実行中の実験は、完了する前に停止することもできます。または、CloudWatch アラームで定義したしきい値に達した場合に実験を停止するように停止条件を作成することもできます。
+ マルチアタッチが有効なボリューム AWS FIS では、 を使用できます。アタッチされたインスタンスのすべてが影響を受けます。実験用に特定のボリュームとインスタンスのアタッチメントを選択することはできません。
+ FIS は現在、ローカルゾーン、Outposts、または Wavelength ゾーンでは使用できません。
+ コンソールでボリューム ARN を指定するとき、同じアベイラビリティーゾーンで最大 5 つのボリュームを同時にテストできます。
+ AWS FIS は、 、 AWS Wavelength ゾーンOutpost、またはローカルゾーンで作成されたボリュームでは使用できません。
# I/O フォールトインジェクションを一時停止する
AWS Fault Injection Service および I/O 一時停止アクションを使用して、Amazon EBS ボリュームとそれがアタッチされているインスタンス間の I/O を一時的に停止し、ワークロードが I/O 中断を処理する方法をテストします。
詳細については AWS FIS、[https://docs.aws.amazon.com/fis/latest/userguide/what-is.html](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)」を参照してください。
**考慮事項**
ボリュームの I/O を一時停止する場合は、以下の考慮事項に留意してください。
+ I/O の一時停止は、すべての [Nitro ベースのインスタンスタイプ](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)でサポートされています。
+ OS タイムアウト設定をテストするには、実験時間を `nvme_core.io_timeout` に指定された値以上に設定します。詳細については、「[Amazon EBS ボリュームの NVMe I/O オペレーションタイムアウト](timeout-nvme-ebs-volumes.md)」を参照してください。
+ I/O が一時停止しているボリュームに I/O を実行すると、次のことが起こります。
+ ボリュームのステータスが 120 秒以内で `impaired` に遷移します。詳細については、「[Amazon EBS ボリュームステータスチェック](monitoring-volume-checks.md)」を参照してください。
+ ボリューム I/O が 60 秒以上一時停止している場合、`VolumeStalledIOCheck` の CloudWatch メトリクスは `1` になります。詳細については、「[Amazon EBS ボリュームのメトリクス](using_cloudwatch_ebs.md#ebs-volume-metrics)」を参照してください。
+ キューの長さ (`VolumeQueueLength`) の CloudWatch メトリクスはゼロ以外になります。アラームやモニタリングでは、キューの深さがゼロでないかどうかを監視する必要があります。
+ `VolumeReadOps` または `VolumeWriteOps` の CloudWatch メトリクスは `0` になります。これは、ボリュームが I/O を処理していないことを示します。
Amazon EC2 コンソールから基本的な実験を実行することも、 AWS FIS コンソールを使用してより高度な実験を実行することもできます。 AWS FIS コンソールを使用して高度な実験を実行する方法の詳細については、「 *AWS Fault Injection Service ユーザーガイド*」の[「 のチュートリアル AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/fis-tutorials.html)」を参照してください。
**Amazon EC2 コンソールを使用して基本的な実験を行うには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. I/O を一時停止するボリュームを選択し、**[アクション]**、**[フォールトインジェクション]**、**[ボリューム I/O の一時停止]** の順に選択します。
1. **[所要時間]** には、ボリュームとインスタンス間の I/O を一時停止する期間を入力します。[所要時間] ドロップダウンリストの横のフィールドには、ISO 8601 形式の期間が表示されます。
1. **サービスアクセス**セクションで、実験を実行する AWS FIS ために が引き受ける IAM サービスロールを選択します。デフォルトのロールか、作成した既存のロールを使用できます。詳細については、「[AWS FIS 実験の IAM ロールを作成する](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-iam-service-role.html)」を参照してください。
1. **[ボリュームの I/O を一時停止]** を選択します。プロンプトが表示されたら、確認フィールドに `start` と入力し、**[実験を開始]** を選択します。
1. 実験の進行状況と影響をモニタリングします。詳細については、「*AWS FIS ユーザーガイド*」の「[Monitoring AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-experiments.html)」を参照してください。
# レイテンシーインジェクション
のレイテンシーインジェクションアクション (`aws:ebs:volume-io-latency`) を使用して AWS FIS 、Amazon EBS ボリュームの I/O レイテンシーの増加をシミュレートし、アプリケーションがストレージパフォーマンスの低下にどのように応答するかをテストします。このアクションでは、挿入するレイテンシーの値と、ターゲットボリュームに影響を与える I/O の割合を指定できます。を使用すると AWS FIS、事前設定されたレイテンシー実験テンプレートを使用して、ストレージの障害中に観察される可能性のあるさまざまな I/O レイテンシーパターンのテストを開始できます。これらのテンプレートは、アプリケーションに中断を発生させて障害耐性をテストするために使用できるシナリオの初期セットとして設計されています。これらは、アプリケーションが実際に経験する可能性があるすべてのタイプの影響を網羅するように設計されているわけではありません。アプリケーションのパフォーマンスニーズに基づいて、複数の異なるテストを実行するように調整することをお勧めします。利用可能なテンプレートをカスタマイズするか、新しい実験テンプレートを作成して、アプリケーション固有の要件をテストすることができます。
**事前設定済みのレイテンシー実験テンプレート**
Amazon EBS は、EBS コンソールと [AWS FIS シナリオライブラリ](https://docs.aws.amazon.com/fis/latest/userguide/scenario-library-scenarios.html)を通じて次のレイテンシー実験テンプレートを提供します。ターゲットボリュームでこれらのテンプレートを直接使用して、レイテンシーインジェクション実験を実行することができます。
+ **持続レイテンシー**: 一定のレイテンシーをシミュレートします。この実験は、1 つのレイテンシーインジェクションアクションを使用し、合計所要時間は 15 分です。この実験では、読み取り I/O の 50% と書き込み I/O の 100% に対し、永続的なレイテンシーをシミュレートします (15 分間で 500 ミリ秒)。
+ **レイテンシーの増加**: 徐々に増加するレイテンシーをシミュレートします。この実験は、5 つのレイテンシーインジェクションアクションを使用し、合計所要時間は 15 分です。この実験では、読み取り I/O の 10% と書き込み I/O の 25% に対し、レイテンシーの段階的な増加をシミュレートします (3 分間で 50 ミリ秒、3 分間で 200 ミリ秒、3 分間で 700 ミリ秒、3 分間で 1 秒、3 分間で 15 秒)。
+ **断続的なレイテンシー**: 断続的なレイテンシーの急激なスパイクと、その間の復旧期間をシミュレートします。この実験は、3 つのレイテンシーインジェクションアクションを使用し、合計所要時間は 15 分です。この実験では、読み取りおよび書き込み I/O の 0.1% に対し、3 つのレイテンシーのスパイクをシミュレートします (1 分間継続する 30 秒のスパイク、2 分間継続する 10 秒のスパイク、2 分間継続する 20 秒のスパイク)。レイテンシーの各スパイク間に 5 分間の復旧期間があります。
+ **レイテンシーの削減**: 徐々に減るレイテンシーをシミュレートします。この実験は、5 つのレイテンシーインジェクションアクションを使用し、合計所要時間は 15 分です。この実験では、読み取り I/O と書き込み I/O の 10% に対してレイテンシーの段階的な減少をシミュレートします (3 分間で 20 秒、3 分間で 5 秒、3 分間で 900 ミリ秒、3 分間で 300 ミリ秒、3 分間で 40 ミリ秒)。
**事前設定済みのシナリオをカスタマイズする**
上記の事前設定済みテンプレートをカスタマイズするか、次のカスタマイズ可能なパラメータを使用して独自の新しい実験テンプレートを作成します。
+ `readIOPercentage` — レイテンシーを挿入する読み取り I/O オペレーションの割合。これは、アクションの影響を受けるボリュームに対するすべての読み取り I/O オペレーションの割合です。
範囲: 最小 0.1%、最大 100%
+ `readIOLatencyMilliseconds` — 読み取り I/O オペレーションに挿入されるレイテンシーの量。これは、実験中に読み取り I/O の指定された割合で観測されるレイテンシーの値です。
範囲: 最小 1 ミリ秒 (io2) / 10 ミリ秒 (io2 以外)、最大 60 秒
+ `writeIOPercentage` — レイテンシーを挿入する書き込み I/O オペレーションの割合。これは、アクションの影響を受けるボリュームに対するすべての書き込み I/O オペレーションの割合です。
範囲: 最小 0.1%、最大 100%
+ `writeIOLatencyMilliseconds` — 書き込み I/O オペレーションに挿入されるレイテンシーの量。これは、実験中に書き込み I/O の指定された割合で観測されるレイテンシーの値です。
範囲: 最小 1 ミリ秒 (io2) / 10 ミリ秒 (io2 以外)、最大 60 秒
+ `duration` — 選択した I/O の割合にレイテンシーが挿入される期間。
範囲: 最小 1 秒、最大 12 時間
**レイテンシーインジェクションをモニタリングする**
ボリュームのパフォーマンスへの影響は、次の方法でモニタリングできます。
+ CloudWatch で平均レイテンシーメトリクスを使用して、1 分あたりの平均 I/O レイテンシーを取得します。詳細については、「[Monitor your EBS volumes using CloudWatch](https://docs.aws.amazon.com/ebs/latest/userguide/using_cloudwatch_ebs.html)」を参照してください。
+ NVMe-CLI、CloudWatch エージェント、および Prometheus で利用できる EBS の詳細なパフォーマンス統計を使用して、1 秒あたりの平均 I/O レイテンシーを取得します。詳細なメトリクスでは、ボリュームのレイテンシー分散を分析するために使用できる I/O レイテンシーヒストグラムも提供されます。詳細については、「[NVMe detailed performance statistics](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-detailed-performance-stats.html)」を参照してください。
+ [Amazon EBS ボリュームステータスチェック](monitoring-volume-checks.md) を使用します。I/O レイテンシーを挿入すると、ボリュームのステータスは `warning` 状態に移行します。
**考慮事項**
EBS レイテンシーインジェクションを使用する場合は、次の点を考慮します。
+ レイテンシーインジェクションは、P4d、P5、P5e、Trn2u、G6、G6f、Gr6、Gr6f、M8i、M8i-flex、C8i-flex、R8i、R8i-flex、I8ge、Mac-m4pro、Mac-m4 を除くすべての [Nitro ベースのインスタンスタイプ](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)でサポートされています。
+ 実験で指定されたレイテンシー値と観測結果のレイテンシーには最大 5% の差異が生じることがあります。
+ ごく少数の I/O オペレーションしか行わない場合、アクションパラメータで指定された I/O の割合が、アクションの影響を受ける I/O の実際の割合と一致しない可能性があります。
**Amazon EBS ボリュームでレイテンシーインジェクション実験を実行するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**ボリューム**] を選択します。
1. 実験を実行するボリュームを選択し、**[アクション]**、**[レジリエンステスト]**、**[挿入ボリューム I/O レイテンシー]** を選択します。
AWS Fault Injection Service コンソールが開きます。
1. **[実験を作成]** ウィンドウで、実行する実験のタイプを、**[断続的]**、**[増加中]**、**[持続]**、または **[減少中]** から選択します。
1. **IAM ロールを選択する**には、**新しいロールの作成**を選択して、ユーザーに代わって実験を実行するために AWS FIS が使用する新しいロールを作成します。または、必要なアクセス許可を持つ IAM ロールを以前に作成している場合は、**[既存の IAM ロールを使用]** を選択します。
1. **[料金の見積り]** セクションには、実験の実行コストの見積りが表示されます。では AWS FIS、実験のターゲットアカウントの数に基づいて、アクションが最初から最後まで実行される 1 分ごとに課金されます。
1. **[実験を開始する]** を選択します。