這個問題很古早，官方文檔告訴你：不行。
2026-02-06 請勿使用該方式縮容 – 這個方法有問題，在Amazon Linux 2023 升級kernel後將會無法啟動，會卡在grub 的環節，需要在每一次更新kernel 後，執行“grub2-mkconfig -o /boot/grub2/grub.cfg” 才能正常啟動。
但是，在特定的條件下是可以的。
特定的條件如下：
a）一台救援EC2。
b）一台和舊EC2 OS 版本完全一樣的系統，但root volume 是更小的size。
c）OS 版本必須完全一樣，並且都升級到最新的，相同的kernel版本，不一樣後果自負。
那麼場景如下：
一台救援EC2 ，使用Amazon Linux 2023，root volume 8G
一台新EC2 ，使用較小的EBS volume size，root volume 10G
一台舊EC2，使用較大的EBS volume size ，root volume 20G
步驟如下：
首先，將新舊兩台EC2 的root volume 都detach 然後attach 到救援EC2 上。
接下來，在救援EC2上查看UUID，可以看到新EC2 和救援EC2 的UUID 是一樣的，這是因為使用了相同的AMI 啟動。將新舊兩台EC2 的root volume EBS 作為data volume 分別mount 到一個位置，例如 /10G 和 /20G ，可以看到fstab 配置文件中的UUID 都是原來的，等一下我們要修改10G 那個。
sudo -i
mkdir /20G
mkdir /10G
lsblk -f
mount /dev/nvme1n1p1 /20G # 20G old root volume
mount -o nouuid /dev/nvme2n1p1 /10G # 10G new root volume
然後使用rsync 將 /20G 目錄中的文件使用rsync 完全同步到 /10G 目錄中，請注意：排除掉 /boot 目錄。
rsync -avH --progress --delete --exclude=/boot /20G/ /10G/在進行上述同步前，您當然需要先行確認 /20G 目錄中的實際總容量小於10G並且有足夠冗余，否則您走到這一步從一開始就是錯誤的決定。
同步完成後， 修改 vi /10G/etc/fstab 中的UUID 為新EBS volume 的UUID。
關閉救援EC2 ，把10G EBS volume 掛載到新的EC2 上啟動，完成。
