【備忘録】EC2インスタンスのEBSボリューム拡張手順

Posted at 2026-04-12

こんにちは、最近ジムに行くたびに病気を持ち帰ってしまうokamuraです。

今まで全然風邪を引いてこなかっただけに少し動揺しておりますが、まぁ抗体を作れたと思ってポジティブに考えることにしますw

私の会社ではConfluenceを使用してドキュメントを管理しています。これまで忘れそうな手順などを自分用の備忘録として残していたのですが、この度サービスを移行することになりました。せっかくなので、埋もれさせてしまうよりは誰かの役に立てばと思い、技術記事として成仏させることにしました。

今回紹介するのは、毎回コマンドを忘れては調べている「EBSの容量拡張」についてです。

では、早速本題に入ります。

今回のゴールは、「EBSの物理容量を増やし、OSのパーティションとファイルシステムまでを拡張して、実際に容量が増えたことを確認する」 ことです。

※作業ミスでデータが消えるのを防ぐため、事前にスナップショット（バックアップ）を取っておくことをおすすめします！

AWSマネジメントコンソールでEBSボリュームのサイズを変更した後、OS側でその容量を認識させ、ファイルシステムを拡張するまでの一連の手順をまとめます。

ステップ1：AWSマネジメントコンソールでのボリューム変更

まずは「物理的なストレージ枠」を広げる作業です。OS側をいじる前に、AWSの管理画面からボリュームの設定を変更します。

これで「土地（ディスク）」自体は広がりました。しかし、この時点ではまだOS内の「部屋（パーティション）」は以前の狭いままです。次はこれを広げていきましょう。

AWSコンソールで「土地（ディスク）」を広げた後は、次に「部屋の境界線（パーティション）」を引き直す必要があります。ここからはEBSがアタッチされているEC2へログインして、ターミナルでの操作になります。

まずは lsblk コマンドで、今のディスクの状態を見てみましょう。

$ sudo lsblk

実行すると、以下のような結果が表示されるはずです。

「親のディスクは大きいのに、中のパーティション1（p1）が小さいまま」であることが確認できればOKです。

魔法のコマンド growpart を使います。

# sudo growpart <デバイス名> <パーティション番号>
$ sudo growpart /dev/nvme0n1 1

CHANGED という文字が出れば成功です！もう一度 lsblk を叩くと、パーティションサイズがディスクいっぱいの 40G に広がっているのが確認できるはずです。

実行結果の例:
CHANGED: partition=1 ... と表示されれば成功です。

再度 lsblk を実行し、パーティションサイズが 40G になっていることを確認してください。

さて、いよいよ大詰めです。境界線（パーティション）は広がりましたが、まだ「新しい床（ファイルシステム）」が敷かれていないため、OSは追加分を認識できていません。

df -Th を実行して、今のファイルシステムを確認しましょう。

$ df -Th

この時点では、まだファイルシステム上のサイズ（例: /dev/nvme0n1p1）は 30G のままです。

ここで、マウント位置が / の「タイプ（Type）」を確認してください。今回の手順は xfs という形式を想定しています。
xfs_growfs コマンドで、一気に床を敷き詰めます。

# マウントポイントを指定します
$ sudo xfs_growfs -d /

実行結果：

最後にもう一度 df -Th を叩いてみてください。

$ df -Th

「サイズ」が 40G になり、「残り（Avail）」が増えていれば、無事に拡張完了です！これでディスクフルに怯える日々とはおさらばです。
/ のサイズが 40G になり、利用可能な「残り」容量が増えていれば完了です。

この3ステップさえ覚えておけば、急な容量不足でも焦らず対応できます。
自分も次回はこの記事を見ながら作業しようと思いますw

備忘録ついでにどなたかの役に立てば幸いです。それでは！

参照元: