EC2インスタンスを拡大するのは簡単です（たとえば、AMIを作成し、そこからインスタンスを起動してから、ストレージサイズを変更するなど）。

しかし、それを減らすことはより困難になります。Amazon Web Services（AWS）EC2インスタンスのElastic Block Store（EBS）のルートボリュームサイズを縮小したいと思います。ネット上にはいくつかの古い高レベルの手順があります。私が見つけたより詳細なバージョンは、StackOverflowの質問に対する1年前の答えです：どのようにebsボリューム容量を減らすことができますか、ステップはかなり高いレベルです：

希望するサイズの新しいEBSボリュームを作成します（例/ dev / xvdg）

インスタンスを起動し、両方のEBSボリュームをそれに接続します

（元のルートボリュームの）ファイルシステムを確認します。（例）e2fsck -f / dev / xvda1

元のルートボリュームを最大に縮小します（例：ext2 / 3/4）resize2fs -M -p / dev / xvda1

ddを使用してデータをコピーします。

• チャンクサイズを選択します（16MBが好きです）

• チャンクの数を計算します（resize2fs出力のブロック数を使用）：blocks * 4 /（chunk_size_in_mb * 1024）-安全のためにビットを切り上げます

• データをコピーします：（例）dd if = / dev / xvda1 ibs = 16M of = / dev / xvdg obs = 16M count = 80

新しい（より小さい）EBSボリュームのファイルシステムのサイズを変更します：（例）resize2fs -p / dev / xvdg

（元のルートボリュームの）ファイルシステムを確認します。（例）e2fsck -f / dev / xvdg

新しいEBSルートボリュームを切断し、元のインスタンスに接続します

「ハウツー」ソリューションの詳細な手順を見つけることができません。

EBSルートボリュームは、HVM Ubuntuインスタンスに接続されています。

どんな助けも本当に感謝されます。

AWSコンソールで：

1. サイズを変更するインスタンスを停止します

2. アクティブボリュームのスナップショットを作成し、そのスナップショットから「汎用SSD」ボリュームを作成します。

3. 別の「汎用SSD」ボリュームを必要なサイズに作成します。

4. これら3つのボリュームを次のようにインスタンスに接続します。

   • アクティブなボリュームの/ dev / sda1。
   • ターゲットサイズであるボリュームの/ dev / xvdf。
   • アクティブなボリュームのスナップショットから作成されたボリュームの/ dev / xvdg。

5. インスタンスを開始します。

6. SSH経由で新しいインスタンスにログオンします。

7. これらの新しいディレクトリを作成します。

mkdir /source /target

8. 新しいボリュームにext4ファイルシステムを作成します。

mkfs.ext4 /dev/xvdf

9. このディレクトリにマウントします：

mount -t ext4 /dev/xvdf /target

10. これは非常に重要です。ファイルシステムはそれを認識して起動するためにLinuxのe2labelを必要とします。アクティブインスタンスで「e2label / dev / xvda1」を使用して、それがどうあるべきかを確認します。

e2label /dev/xvdf /

11. スナップショットから作成されたボリュームをマウントします。

mount -t ext4 /dev/xvdg /source

12. 内容をコピーします。

rsync -ax /source/ /target

^{注：「/ target」の後に「/」はありません。また、シンボリックリンクと属性に関するいくつかのエラーがあるかもしれませんが、サイズ変更はまだ成功しました}

13. ファイルシステムをアンマウントします。

umount /target
umount /source

14. AWSコンソールに戻ります。インスタンスを停止し、すべてのボリュームをデタッチします。

15. 新しいサイズのボリュームをインスタンスに「/ dev / sda1」としてアタッチします

16. インスタンスを起動すると、起動します。

手順10が重要です。上記のように新しいボリュームに「e2label」というラベルを付けます。そうしないと、インスタンスはawsで起動しているように見えますが、接続チェックに合格しません。

ボリュームがルート（ブート可能）デバイスとして使用されている場合、他のソリューションは機能しません。

新しく作成されたディスクにはブートパーティションがないため、インスタンスがルートボリュームとして使用する前にGRUBをインストールし、いくつかのフラグを正しく設定する必要があります。

ルートボリュームを縮小するための（今日の時点で）私のソリューションは次のとおりです。

背景：ルートボリュームを縮小するインスタンスAがあります。このボリュームをVAと呼びましょう。VAを30GBから10GBとするために縮小したい

1. インスタンスAと同じOSで新しいec2インスタンスBを作成します。ストレージとして、VAと同じタイプのボリュームを選択しますが、サイズは10GBです。（またはターゲットサイズは何でも）。これで、この新しいボリューム（VBと呼びます）をルートボリュームとして使用するインスタンスBができました。
2. 新しいインスタンス（B）が実行されたら。停止して、ルートボリューム（VB）をデタッチします。

注：次の手順は、主に@billのソリューションから取られています。

3. サイズを変更するインスタンスを停止します（A）。

4. ボリュームVAのスナップショットを作成し、そのスナップショットから「汎用SSD」ボリュームを作成します。このボリュームをVASNAPと呼びます。

5. Amazon Linuxで新しいインスタンスをスピンし、このインスタンスをCと呼びます。このインスタンスを使用して、VASNAPのコンテンツをVBにコピーします。インスタンスAを使用してこれらの手順を実行することもできますが、独立したマシンで実行することを好みます。

6. 次のボリュームをインスタンスCに接続します。VBの場合は/ dev / xvdf。VASNAPの場合は/ dev / xvdg。

7. インスタンスCを再起動します。

8. SSH経由でインスタンスCにログオンします。

9. 次の新しいディレクトリを作成します。

mkdir /source /target

10. VBのメインパーティションをext4ファイルシステムでフォーマットします。

mkfs.ext4 /dev/xvdf1

エラーが発生しない場合は、手順11に進みます。エラーがない場合は/dev/xvdf1、次のi-viiを実行してパーティションを作成する必要があります。

i）/dev/xvdf1何らかの理由で存在しない場合は、作成する必要があります。最初に入力してください：

sudo fdisk /dev/xvdf。

ii）次を入力してディスクをワイプします。 wipefs

iii）次を入力して、新しいパーティションを作成します。 n

iv）入力pしてプライマリパーティションを作成します

v）Enterを押し続けて、デフォルト設定を続行します。

vi）コマンドを再入力wするように求められたら、Enter を押して変更を書き込み、終了します。

vii）以下を実行して、/dev/xvdf1パーティションがあることを確認します。 lsblk

次のように表示されるはずです。

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  250G  0 disk
└─xvda1 202:1    0  250G  0 part
xvdf    202:80   0   80G  0 disk
└─xvdf1 202:81   0   80G  0 part 
xvdg    202:96   0  250G  0 disk
└─xvdg1 202:97   0  250G  0 part

次にステップ11に進みます。

11. このディレクトリにマウントします。

mount -t ext4 /dev/xvdf1 /target

12. これは非常に重要です。ファイルシステムは、Linuxがそれを認識して起動するためにe2labelを必要とします。アクティブインスタンスで "e2label / dev / xvda1"を使用して、それがどうあるべきかを確認します。

e2label /dev/xvdf1 /

13. / sourceにVASNAPをマウントします。

mount -t ext4 /dev/xvdg1 /source

14. 内容をコピーします。

rsync -vaxSHAX /source/ /target

注：「/ target」の後に「/」はありません。また、シンボリックリンクと属性に関するいくつかのエラーがあるかもしれませんが、サイズ変更はまだ成功しました

15. Umount VB：

umount /target

16. AWSコンソールに戻ります。インスタンスCからVettaをデタッチし、AからVAをデタッチします。

17. 新しいサイズのボリューム（VB）をインスタンスに「/ dev / xvda」としてアタッチします

18. インスタンスAを起動します。ルートデバイスは10GBです:)

19. インスタンスBとCの両方を削除し、VBを除くすべてのボリュームも削除します。VBはインスタンスAのルートボリュームです。

次の手順は私のために働いた

手順1.ルートebsボリュームのスナップショットを作成し、スナップショットから新しいボリュームを作成します（このボリュームコピーを呼び出しましょう）

手順2.希望するサイズのebsルートボリュームで新しいインスタンスを作成します。（このボリュームのサイズを変更してみましょう）このebsボリュームには、ブート用の正しいパーティションがあります。（ゼロから新しいebsボリュームを作成してもうまくいきませんでした）

手順3. volume-resizeとvolume-copyをインスタンスに接続します。

ステップ4. volume-resizeをフォーマットします。

sudo fdisk -l
    sudo mkfs -t ext4 /dev/xvdf1

注：パーティションボリュームが入力されて/dev/xvdf1いないことを確認してください/dev/xvdf

手順5. volume-resizeおよびvolume-copy mkdir / mnt / copy mkdir / mnt / resizeをマウントします

sudo mount /dev/xvdh1 /mnt/copy
sudo mount /dev/xvdf1 /mnt/resize

ステップ6.ファイルをコピーする

rsync -ax /mnt/copy/ /mnt/resize

手順7. e2labelがルートボリュームと同じであることを確認する

sudo E2label /dev/xvdh1 > cloudimg-rootfs
sudo E2label /dev/xvdf1 cloudimg-rootfs

ステップ8.新しいボリュームudidに一致するようにボリュームコピーのgrub.confを更新する

/boot/grub/grub.cfgでuudidを検索して置き換えます

ubuntu@server:~/mnt$ sudo blkid
/dev/xvdh1: LABEL="cloudimg-rootfs" UUID="1d61c588-f8fc-47c9-bdf5-07ae1a00e9a3" TYPE="ext4"
/dev/xvdf1: LABEL="cloudimg-rootfs" UUID="78786e15-f45d-46f9-8524-ae04402d1116" TYPE="ext4"

ステップ9.ボリュームのマウント解除

ステップ10.新しいサイズ変更されたebsボリュームをインスタンス/ dev / sda1に接続します

これは別のアプローチです。

実行中のEC2インスタンスに古いEBSボリュームを接続してマウントします。ブートボリュームをコピーする場合は、ライブシステムとして使用されているボリュームではなく、データとしてマウントされた古いボリュームを使用して、別のインスタンスで実行することをお勧めします。

目的のサイズの新しいEBSボリュームを作成します。

新しいボリュームをインスタンスに接続し、（慎重に）その上で新しいファイルシステムをフォーマットします（例：mkfsを使用）。マウントします。

古いファイルシステムのコンテンツを古いボリュームから新しいボリュームにコピーします。

rsync -vaxSHAX /oldvol/ /newvol/

新しいボリュームをアンマウントし、インスタンスからデタッチします。

ルートファイルシステムをコピーしていた場合：

新しいボリュームのEBSスナップショットを作成します。

スナップショットを新しいAMIとして登録します。