翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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)
------