はじめに
検証用のEC2（Amazon Linux 2023）で / 領域を 8GB → 9GB に拡張しました。
インスタンスの停止や再起動は不要で、作業は10分ほどで終わります。
以前オンプレミスで経験した「fdisk でパーティションを作り直す」方法と比べてかなり簡単だったので、違いも含めてまとめます。
前提環境
| 項目 | 内容 |
|---|---|
| OS | Amazon Linux 2023 |
| インスタンスタイプ | t3.micro |
| ボリューム | EBS gp3（8GB → 9GB） |
| パーティション形式 | GPT |
| ファイルシステム | XFS |
| LVM | なし |
全体像：3段階で広げる
/ 領域の拡張は、外側から順に3段階で広げていきます。
| 段階 | 何を広げるか | 操作 | 確認コマンド |
|---|---|---|---|
| ① 箱を広げる | ディスク（EBSボリューム） | AWSコンソール |
lsblk（nvme0n1） |
| ② 仕切りを広げる | パーティション | growpart |
lsblk（nvme0n1p1）、fdisk -l
|
| ③ 使える領域を広げる | ファイルシステム | xfs_growfs |
df -h |
段階ごとに確認コマンドが違うので、「今どこまで終わっているか」をコマンドで見分けられるのがポイントです。
手順0：現状確認
df -hT /
lsblk
fdisk -l /dev/nvme0n1
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
zram0 253:0 0 657M 0 disk [SWAP]
nvme0n1 259:0 0 8G 0 disk
├─nvme0n1p1 259:1 0 8G 0 part /
├─nvme0n1p127 259:2 0 1M 0 part
└─nvme0n1p128 259:3 0 10M 0 part /boot/efi
Device Start End Sectors Size Type
/dev/nvme0n1p1 24576 16777182 16752607 8G Linux filesystem
/dev/nvme0n1p127 22528 24575 2048 1M BIOS boot
/dev/nvme0n1p128 2048 22527 20480 10M EFI System
Partition table entries are not in disk order.
p127 と p128 は消さなくていい？
p127（BIOS boot）と p128（EFI System）は起動に必要なパーティションなので、絶対に消さないでください。
パーティションの番号とディスク上の並び順は関係ありません。Start（開始セクタ）を見ると、物理的な並びは次のとおりで、/（p1）が一番後ろにあります。
[p128（EFI）][p127（BIOS boot）][ p1（/） ][ 空き ]
↑ ここに伸ばす
p1 のすぐ後ろが空くので、他のパーティションに触らずに伸ばせます。
Partition table entries are not in disk order. は「番号順と並び順が一致していない」というお知らせで、エラーではありません。
lsblk の木構造の線（├─ └─）が tq mq のように文字化けすることがあります。端末の文字コード設定によるもので、デバイス名は nvme0n1p1 です。
手順1：EBSボリュームを広げる（AWSコンソール）
インスタンスは起動したままで大丈夫です。
- EC2 → インスタンス → 対象を選択 → 「ストレージ」タブ
- ボリュームID（
vol-xxxx）をクリック - ボリュームの詳細画面の右上にある 「変更」 ボタンをクリック
- 「サイズ（GiB）」を
8→9に変更（ボリュームタイプ・IOPS・スループットはそのまま） - 「変更」→ 確認画面で再度「変更」
- 「アクション」メニューの中には「ボリュームの変更」が見当たらないことがあります。詳細画面右上の「変更」ボタンから操作できます。
- EBSは縮小できません。
- 同じボリュームを再度変更できるのは、前回の変更から6時間後です。
状態は modifying → optimizing → completed と進みます。optimizing になればOS側の作業に進めます。
OS側で認識されたか確認
lsblk
nvme0n1 259:0 0 9G 0 disk
├─nvme0n1p1 259:1 0 8G 0 part /
ディスク（nvme0n1）は 9G、パーティション（nvme0n1p1）はまだ 8G です。
fdisk の警告は無視してOK
この時点で fdisk -l を実行すると、次の警告が出ます。
GPT PMBR size mismatch (16777215 != 18874367) will be corrected by write.
The backup GPT table is not on the end of the device.
GPTは、パーティション表をディスクの先頭と末尾の2か所に持っています。ディスクだけが大きくなったため、末尾の予備が元の8GBの位置に取り残されている、という意味です。
次の growpart が新しい末尾へ移動してくれるので、正常な途中経過です。
手順2：パーティションを広げる（growpart）
growpart /dev/nvme0n1 1
/dev/nvme0n1 と 1 の間にはスペースが入ります（「nvme0n1 の1番目のパーティション」という意味）。
CHANGED: partition=1 start=24576 old: size=16752607 end=16777183 new: size=18849759 end=18874335
start は変わらず、end だけが伸びているのがポイントです。
- 実際に変更せず結果だけ確認したい場合は
growpart -N /dev/nvme0n1 1（dry run） -
growpart: command not foundの場合はdnf install -y cloud-utils-growpart
確認
lsblk
fdisk -l /dev/nvme0n1
df -h /
nvme0n1 259:0 0 9G 0 disk
├─nvme0n1p1 259:1 0 9G 0 part /
/dev/nvme0n1p1 24576 18874334 18849759 9G Linux filesystem
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 8.0G 3.7G 4.3G 47% /
パーティションは 9G になり、fdisk の警告も消えました。
ただし df はまだ 8.0G のままです。パーティションが広がっても、ファイルシステム（XFS）が新しい領域をまだ知らないためです。
手順3：ファイルシステムを広げる（xfs_growfs）
xfs_growfs -d /
XFSでは、デバイス名ではなくマウントポイント（/）を指定します。
data blocks changed from 2094075 to 2356219
増えたブロック数は 262144 で、1ブロック4KiB（bsize=4096）なので、262144 × 4KiB = ちょうど1GiB です。
ext4 の場合は resize2fs /dev/nvme0n1p1 を使います。
確認
df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 9.0G 3.7G 5.3G 42% /
8.0G → 9.0G になりました。停止も再起動もなしで完了です。
補足1：fdisk でパーティションを作り直す方法との違い
/ 領域を広げる方法は growpart だけではありません。fdisk でパーティションを一度削除し、同じ開始位置から大きく作り直す方法もあります。growpart が使えない環境や、/ の後ろに別のパーティションがある構成では、この方法が使われてきました。
私もオンプレミスのRHEL系サーバー（/ の後ろに swap と dump 用のパーティションがある構成）で、次の手順で / を拡張したことがあります。
- kdump停止、swapoff、fstabのコメントアウト
- fdisk で / の後ろにある swap・拡張領域・dump用パーティションを削除して再起動
- fdisk で / のパーティションを削除して、同じ開始位置で大きく再作成
-
partx -uでカーネルに反映、xfs_growfsで拡張 - swap・dump用パーティションを作り直し、UUIDを fstab と kdump.conf に反映して再起動
やっていることの本質は同じで、「パーティションの終わりを伸ばして、ファイルシステムを伸ばす」です。大変だった理由は、ディスク構成にありました。
オンプレ（MBR）: [sda1][ sda2（/）][sda3 swap][sda4 拡張領域[sda5 dump]][ 空き ]
↑ / の後ろが邪魔
今回のEC2（GPT）: [p128][p127][ p1（/）][ 空き ]
| やること | fdisk で作り直す方法 | growpart（今回） |
|---|---|---|
| 邪魔なパーティションをどかす | 削除・再作成が必要 | 不要（/ が一番後ろ） |
| パーティションを伸ばす | fdiskで削除・再作成 | growpart |
| カーネルへの反映 |
partx -u、再起動 |
growpart が自動で実施 |
| ファイルシステムを伸ばす | xfs_growfs |
xfs_growfs |
fdiskでパーティションを削除しても、消えるのはパーティション表の記録だけで、データは残っています。そのため「開始位置を完全に同じにして、終わりだけ伸ばす」形で作り直せばデータは無事です。
ただし、開始位置を1セクタでも間違えたり、再作成時の「XFSの署名を消しますか？」に Yes と答えたりすると、データを失います。
growpart は、この「開始位置を変えずに終わりだけ書き換える」処理を安全に自動化したツールです。直後に空きがあるなら、growpart を使うのがおすすめです。AWSの公式ドキュメントでも、EBS拡張後の手順として紹介されています。
なお、growpart は直後の空き領域に伸ばすことしかできません。上のオンプレの構成のように / の後ろに別のパーティションがある場合は、どかす作業が別途必要です。
補足2：LVM構成の場合
LVM構成では、パーティションとファイルシステムの間にLVMの層が1段入ります。
growpart /dev/sda 2 # パーティション（PV）を伸ばす
pvresize /dev/sda2 # PVのサイズを更新
lvextend -r -l +100%FREE /dev/mapper/rhel-root # LV とファイルシステムを伸ばす
lvextend -r は、ファイルシステムの拡張まで一緒にやってくれます。
まとめ
- / 領域の拡張は「ディスク → パーティション → ファイルシステム」の3段階
- EC2（Amazon Linux 2023）は / が一番後ろにある構成なので、
growpart→xfs_growfsだけで、停止せずに拡張できる - 途中で出る fdisk の警告（GPTの予備が取り残されている）は正常な途中経過
-
lsblkが 9G でもdfが 8G のままなら、ファイルシステムの拡張がまだ