EC2 root EBSの容量アップ手順｜AWS側のサイズ変更とOS側のresize2fs

EC2でrootディスクが100%になり、ログの書き込みやファイル作成が軒並み失敗する、といった状態になることがあります。打ち手は「不要なファイルを消して容量を空ける」か「EBSを大きくする」かの2つです。EBSの拡張は一方向の操作で月額費用も増えるのに対し、不要ファイルの削除は追加コストなしでその場で効くため、まず削除から試します。

ただし、当たりを付けずに消すと、原因調査の手掛かりまで失いかねません。また、削除で足りずEBSを拡張する場合も、AWSコンソールで操作するだけでは df の表示は変わらず、空き容量も増えません。以降は、root の /dev/xvda1（ext4）が使用率 100% になったインスタンスを例に進めます。

01.結論：まず不要ファイルを削除し、足りなければ二段階で拡張する

ディスクが 100% になったときは、次の順序で対応します。

3 の拡張に進んだときに混乱しやすいのが、「AWSコンソールで広げれば、そのままサーバーで使える容量も増える」という思い込みです。実際は、AWSが触れるのはブロックデバイスの容量だけで、そのデバイスの上に置かれているパーティションやファイルシステムは OS の責任範囲です。AWS側でサイズを増やしても、OS から見ると「元のサイズのファイルシステムを使い切ったまま」の状態が続きます。そのため、拡張の作業は二段階に分かれます。

本記事の例の root は、xvda（ディスク）の配下に xvda1（パーティション）が紐づく、現行のEC2で最も一般的な構成です。AWS側で容量が増えたあと、growpart → resize2fs の順で実行します。パーティションテーブルを持たず、デバイスを直接マウントしている構成（後述のデータ用 /dev/xvdf など）では、growpart は不要です。

本記事の手順で使うコマンドの役割は、次の一覧のとおりです。

02.事象の例：rootだけ100%で、別マウントにはまだ余裕がある

ここでは、root 用とデータ用の 2 本の EBS をアタッチしたインスタンスを例にします。本記事のコマンド出力は、説明用に再構成した架空の例です。df -hT を実行すると（-T を付けるとファイルシステムの種別も一緒に確認できます）、root だけが完全に詰まり、データ用のディスクには余裕が残っている状態です。

$ df -hT
Filesystem      Type  Size  Used Avail Use% Mounted on
/dev/xvda1      ext4   97G   92G    0  100% /
/dev/xvdf       ext4   50G   20G   27G   43% /data

ここから読み取れる事実は3つです。

• root の /dev/xvda1（ext4）は使用率 100% で、空きがありません（Size と Used の差は ext4 が確保する予約領域です）。
• データ用の /dev/xvdf は ext4 / 50GB のうち 20GB 使用で、まだ余裕があります。
• ファイルシステムはどちらも ext4なので、拡張する場合に実行するコマンドは resize2fs に揃えられます。

この状態では root の対処が最優先です。ログ書き込みやパッケージ更新、一時ファイルの作成まで止まり、サービス側にも影響が出るためです。一方、データ用のディスクは緊急性が低いものの、後述する「EBS とファイルシステムのサイズが揃っていない」状態になっています。

03.まずやること：du で当たりを付けて、不要ファイルを削除する

拡張を判断する前に、何が容量を使っているかを調べます。進め方は次の3つです。

1. du で階層ごとに当たりを付ける：容量を使っているディレクトリを上から順に絞り込みます。
2. find で巨大ファイルを列挙する：当たりを付けた階層で、1GBを超えるような単一ファイルを探します。
3. 定番の肥大化ポイントを確認する：ログ・キャッシュ・Docker など、経験的に膨らみやすい場所を一覧で点検します。

du は読み取りだけの調査なので、使用率 100% の状態でも問題なく実行できます。-x（--one-file-system）を付けると、/data のような別マウントを跨がずに root のファイルシステムだけを集計できます。

sudo du -xh -d 1 / 2>/dev/null | sort -rh | head -15
# 容量の大きい階層が見つかったら、同じ要領で1段ずつ降りていく
sudo du -xh -d 1 /var 2>/dev/null | sort -rh | head -15

当たりを付けた階層では、サイズの大きい単一ファイルも確認しておきます。

sudo find / -xdev -type f -size +1G -exec ls -lh {} + 2>/dev/null

肥大化しやすい場所はある程度決まっているので、確認方法と対処をセットで控えておくと二度目以降の調査が早くなります。対処の列にある logrotate の設定のような再発防止まで済ませれば、同じ詰まり方を繰り返さずに済みます。

削除したのに df の空きが増えないときは、プロセスが削除済みファイルを保持しているケースを疑います。開いたままのファイルを rm で消しても、プロセスが手放すまで領域は解放されません。

sudo lsof +L1

該当するプロセスを再起動するか、ログを開き直させると、その分の容量が解放されます。巨大なログを消したはずなのに使用率が 100% のまま、という現象はたいていこれが原因です。

削除で十分な空きを確保でき、増加の原因も断てたのであれば、対応はここで完了です。安全に消せるものがない、データの増加が正常なもので削除では一時しのぎにしかならない、という場合は、次章以降のEBS拡張に進みます。

04.AWS の /dev/sda1 と EC2 内の /dev/xvda1 を見分ける

AWSコンソールで EBS の一覧を開くと、root ボリュームは「アタッチ済みのデバイス」として /dev/sda1（または /dev/xvda）と表示されます。一方、SSH で入った EC2 内では、同じディスクが /dev/xvda1 として / にマウントされています。AWS側とOS側で名前が一致しないため、対応関係を一度押さえておくと、コンソール画面と OS の表示を行き来しても迷いません。

EBSを複数アタッチしている場合は、名前の思い込みで対象を選ばず、AWS側とOS側の情報を突き合わせてから作業します。突き合わせの起点は、インスタンス詳細の「ストレージ」タブです。

1. AWS側の情報を控える：「ストレージ」タブで、各ボリュームの「デバイス名」「ボリュームID（vol-…）」「サイズ」をメモします。
2. Xen系は名前の対応で同定する：上の表のとおり対応は機械的（/dev/sdf → /dev/xvdf）なので、lsblk の表示と突き合わせます。サイズも一致しているかを併せて確認すると、取り違えを防げます。
3. Nitro系はボリュームIDで同定する：名前の対応が成り立たないため、次の段落のとおりシリアル番号（vol-…）で突き合わせます。

Nitro 系のインスタンス（m5・c5・t3・m6i など現行世代の多く）は、上記の対応が成り立ちません。次の3点がポイントです。

• OS 内では NVMe デバイスとして見えるため、root は /dev/nvme0n1（パーティションは /dev/nvme0n1p1）、追加のディスクは /dev/nvme1n1 といった名前になります。
• コンソール側に /dev/sdf と書いてあっても、OS 側では /dev/nvme1n1 のような別の名前で見えます。
• lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,SERIAL でシリアル番号（vol-… で始まる EBS のボリューム ID）を確認すると、どの EBS がどの NVMe デバイスに対応しているかを確実に特定できます。

05.実作業：AWSコンソールでEBSを拡張し、OS側で resize2fs を実行する

ここから先は、削除では空けられない場合に、EBSを拡張して解消するまでの実作業です。前提は次のとおりです。

• 例として、root の EBS を 100GB から 150GB に拡張します。倍の容量へ一気に広げないのは、EBS が後から縮小できないためです。
• まず復旧に足りる分だけ控えめに広げ、恒久的なサイズは運用が落ち着いてから改めて決めます。
• Xen系インスタンス（OS 内で /dev/xvda として見える）を前提にしています。Nitro系では、前章の対応でデバイス名を読み替えます。

ステップ1：AWSコンソールでEBSのサイズを変更する

コンソールでの操作は次の4手順です。

1. EC2 コンソールから対象インスタンスを開きます。
2. 「ストレージ」タブで root ボリュームの /dev/sda1 をクリックします。
3. EBS のボリューム詳細から「ボリュームを変更」を選びます。
4. サイズを希望の値（この例では 100 GiB → 150 GiB）に変更して保存します。

CLI で行うなら aws ec2 modify-volume --volume-id vol-xxxxxxxx --size 150 で同じ操作ができます。

変更後しばらくは volume state が in-use - optimizing (n%) と表示されますが、サイズ自体は即座に反映されるため、OS 側の作業は optimizing の途中でも進められます。optimizing 中はパフォーマンスが揺れることがあるので、本番では負荷の谷の時間帯を選ぶのが無難です。

また、Elastic Volumes に関する AWS 公式ドキュメントによると、同じボリュームを再度変更するには、前回の変更から 6 時間以上待つ必要があります（クールダウン期間）。「少なめに広げて、足りなければすぐもう一度」という小刻みな運用はできません。

ステップ2：OS側で lsblk と df を見比べる

AWS 側の変更後に OS 内で lsblk を実行すると、次のようになります。

$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  150G  0 disk
└─xvda1 202:1    0  100G  0 part /
xvdf    202:80   0  100G  0 disk /data

ここで見るポイントは2つあります。

• 増えたのはディスク（xvda：TYPE disk）の 150GB だけで、配下のパーティション（xvda1：TYPE part）は 100GB のままです。ファイルシステムの前に、パーティションも広げる必要があります。
• df -h で見える / のサイズも、ファイルシステムを広げるまで 97G のまま変わりません。「ディスク → パーティション → ファイルシステム」の3層のうち、AWS側の変更で増えるのは一番外側だけです。

ステップ3：growpart → resize2fs の順で広げる

パーティション（TYPE part）をマウントしている構成なので、先に growpart でパーティションをディスクの末尾まで広げ、続いて ext4 の resize2fs でファイルシステムを広げます。growpart の引数は /dev/xvda1 ではなく、/dev/xvda 1 のように親デバイスと番号を空白で分けます。

sudo growpart /dev/xvda 1
sudo resize2fs /dev/xvda1

デバイスがパーティションを持たず、TYPE disk のまま直接マウントされている構成なら、growpart は不要で resize2fs だけで完了します（後述の /dev/xvdf がこの形です）。

ここまで終えてからもう一度 df -h を実行すると、/dev/xvda1 のサイズが 150GB 相当（ファイルシステムのメタデータ分を引いた値）に増え、空き容量も正しく出るはずです。これでrootの拡張は完了です。

06.別マウントの /dev/xvdf：ボリュームを広げたのに ext4 が古いサイズのまま

rootと並んで、もう1つ確認しておきたいのがデータ用にアタッチしている /dev/xvdf です。先ほどの df -hT では「ext4 / 50GB のうち 20GB 使用」となっていましたが、lsblk で見るとデバイス側は 100GB あります。これは過去にEBSのサイズだけを拡張し、OS 側で resize2fs を実行し忘れていた、という典型的な状態です。

この状態では、せっかく広げたボリュームの容量にファイルシステムが追いついていません。OS 側で resize2fs を実行するだけで、使える容量がボリュームのサイズまで広がります。/dev/xvdf はパーティションテーブルのない直接フォーマットなので、growpart は不要です。

sudo resize2fs /dev/xvdf

実行後に df -h /data を見ると、サイズが 100GB 側に揃います。緊急度は root より低いものの、サイズの不一致は運用の落とし穴になるため、root の復旧後に合わせて直しておきます。

07.ext4 と xfs でコマンドが違う点と、失敗しやすい落とし穴

AWS 側の操作は ext4 でも xfs でも同じですが、OS 側のファイルシステム拡張コマンドは ext4 と xfs で別物です。Ubuntu の root は ext4 が既定ですが、Amazon Linux 2 / Amazon Linux 2023 の root は xfs が既定で、ディストリビューションと世代によって混在します。事前に df -T でファイルシステムタイプを確認してから進めます。

つまずきやすいのは xfs の引数です。sudo xfs_growfs / のようにマウントポイントを渡す決まりで、ext4 と同じ感覚で /dev/xvda1 を渡すと「該当のマウントポイントが見つからない」というエラーで止まります。

08.よくある質問（FAQ）

09.まとめ

本記事の要点は次のとおりです。

• まず du で容量を使っている場所に当たりを付け、安全に消せるものから削除します。削除で恒久的に足りるなら、拡張は不要です。
• 拡張する場合は、AWS が触るのはブロックデバイス、ファイルシステムは OS の責任という分担のとおり、AWS側のサイズ変更とOS側のファイルシステム拡張の二段階で初めて完結します。
• 本記事の例のようなパーティションあり（ext4）の構成なら growpart の後に resize2fs、パーティションのない直マウント構成なら resize2fs だけ、xfs なら xfs_growfs / で拡張を完了できます。
• 別マウントの EBS は「ボリュームサイズ」と「ファイルシステムサイズ」が揃っているかを lsblk と df で見比べ、ズレていれば resize2fs だけで直せます。
• 削除でも拡張でも、logrotate のような再発防止まで済ませて初めて根本解決になります。拡張のサイズは復旧に足りる分に留め、恒久的な値は運用が落ち着いてから決めます。