はじめに (対象読者・この記事でわかること)

この記事は、AWSでEC2インスタンスを運用しているエンジニアやシステム管理者を対象としています。ディスク容量が逼迫し、サービスが不安定になるケースに直面したことがある方、もしくは予防的に対策を立てたい方が対象です。この記事を読むことで、容量不足の原因特定方法、EBSボリュームのサイズ変更手順、ファイルシステムのリサイズ手順、そして CloudWatch を用いた自動アラート設定まで、実務で即活用できる具体的なフローが把握できます。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。
- AWS 基本概念（VPC、EC2、EBS の関係）
- Linux 系 OS の基本操作（df、lsblk、sudo など）
- 基本的なシェルコマンドやテキストエディタの使用経験

容量不足の現象と原因

EC2 インスタンスは起動時に設定した EBS ボリュームのサイズで動作しますが、ログの蓄積やデータの増加に伴いディスク使用率が 80 % を超えると、アプリケーションの書き込みエラーやシステム全体のパフォーマンス低下が顕在化します。主な原因は大きく分けて以下の三つです。

  1. ログファイルの肥大化 – アプリケーションや OS のログがローテーションされずに肥大化。
  2. データベースやキャッシュの容量増加 – EBS に直接格納している MySQL、Redis などがデータ量増大で容量を圧迫。
  3. 一時ファイル・スワップ領域の過剰使用 – ビルドやバックアップ処理で生成された一時ファイルが残り続け、予期せぬ容量消費を引き起こす。

これらを放置すると、インスタンスが “No space left on device” エラーで停止したり、最悪の場合はサービス全体がダウンする危険があります。したがって、早期発見と適切な対策が不可欠です。

容量不足対策の実践手順

以下では、実際に EC2 インスタンスで容量不足を解決するまでの一連の手順を具体的に解説します。手順は「原因の特定 → 余剰データの削除 → EBS の拡張 → ファイルシステムのリサイズ → 監視体制の強化」の流れで進めます。

ステップ1：現状のディスク使用状況を把握する

まずはインスタンスに SSH 接続し、df -h と lsblk を実行して現在のマウントポイントとボリュームサイズを確認します。

Bash

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       30G   27G  1.5G  95% /

$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   30G  0 disk 
└─xvda1 202:1    0   30G  0 part /

du -sh /var/log/* でログディレクトリの容量も確認し、肥大化しているファイルを特定します。

Bash

$ sudo du -sh /var/log/*
4.2G    /var/log/apache2
5.8G    /var/log/mysql
0.1G    /var/log/syslog

ステップ2：不要ファイル・古いログの削除

logrotate が正しく設定されていない場合は手動でローテーションし、古いログを圧縮または削除します。

Bash

# ログを gzip 圧縮して保存
$ sudo find /var/log -type f -name "*.log" -mtime +7 -exec gzip {} \;

# 30 日以上前の圧縮ログを削除
$ sudo find /var/log -type f -name "*.log.gz" -mtime +30 -delete

また、不要なパッケージや一時ファイルもクリーンアップします。

Bash

$ sudo apt-get autoremove -y
$ sudo apt-get clean
$ sudo rm -rf /tmp/*

ステップ3：EBS ボリュームのサイズを拡張する

ログ削除だけでは十分でない場合は、EBS ボリュームそのものを拡張します。AWS コンソールまたは CLI で実行可能です。

3‑1. ボリューム ID の取得

Bash

$ aws ec2 describe-instances \
    --instance-ids i-0123456789abcdef0 \
    --query "Reservations[0].Instances[0].BlockDeviceMappings[0].Ebs.VolumeId" \
    --output text
vol-0abcd1234ef567890

3‑2. ボリュームサイズの増加（例：30 GB → 60 GB）

Bash

$ aws ec2 modify-volume \
    --volume-id vol-0abcd1234ef567890 \
    --size 60

実行後、ステータスが modifying になるので、完了まで待ちます。

Bash

$ aws ec2 describe-volumes-modifications \
    --volume-id vol-0abcd1234ef567890 \
    --query "VolumesModifications[0].ModificationState" \
    --output text
completed

ステップ4：インスタンス側でファイルシステムをリサイズ

ボリュームが拡張されたら、OS 側でパーティションとファイルシステムを拡張します。

4‑1. パーティションの再スキャン（XFS の場合）

Bash

# パーティションテーブルを再読み込み
$ sudo growpart /dev/xvda 1

4‑2. ファイルシステムのリサイズ

  • XFS（デフォルトの場合）
Bash

$ sudo xfs_growfs -d /
  • ext4 の場合
Bash

$ sudo resize2fs /dev/xvda1

リサイズ完了後、df -h で新しいサイズが反映されたことを確認します。

Bash

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       60G   27G   33G  45% /

ステップ5：容量不足を防ぐ自動監視・アラート設定

容量が再び逼迫しないよう、CloudWatch と SNS を組み合わせて監視アラートを構築します。

5‑1. カスタムメトリクスの設定（例：/ のディスク使用率）

Bash

$ cat <<'EOF' > /opt/cloudwatch/scripts/disk_usage.sh
#!/bin/bash
USED=$(df -h / | tail -1 | awk '{print $5}' | sed 's/%//')
aws cloudwatch put-metric-data --namespace "EC2/Disk" \
    --metric-name "RootVolumeUtilization" --value $USED --unit Percent
EOF
chmod +x /opt/cloudwatch/scripts/disk_usage.sh

5‑2. CloudWatch エージェントの設定

/etc/cloudwatch-agent/config.json に上記スクリプトを定期実行する設定を追加し、エージェントを再起動。

Bash

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
    -a fetch-config -m ec2 -c file:/etc/cloudwatch-agent/config.json -s

5‑3. アラーム作成

使用率が 80 % を超えたら SNS トピックへ通知。

Bash

$ aws cloudwatch put-metric-alarm \
    --alarm-name "RootDiskHighUtilization" \
    --metric-name "RootVolumeUtilization" \
    --namespace "EC2/Disk" \
    --statistic Average \
    --period 300 \
    --threshold 80 \
    --comparison-operator GreaterThanThreshold \
    --evaluation-periods 2 \
    --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:EC2-Alert \
    --unit Percent

ハマった点やエラー解決

  • growpart がインストールされていない
    sudo apt-get install cloud-guest-utils（Ubuntu）もしくは yum install cloud-utils（Amazon Linux）でインストールすると解決。

  • EBS 拡張後に xfs_growfs が「Filesystem is already the target size」エラー
    パーティションがまだ古いサイズのままになっているケースです。sudo growpart を実行してパーティションを正しく拡張してから再度 xfs_growfs を実行してください。

  • CloudWatch エージェントがメトリクス送信に失敗
    IAM ロールに cloudwatch:PutMetricData 権限が付与されていない場合があります。ポリシーに cloudwatch:PutMetricData を追加し、エージェントを再起動すると正常に送信されます。

解決策まとめ

  1. 原因特定：df, du, lsblk で現状把握。
  2. 不要データ削除：logrotate 設定・手動圧縮・古いログ削除。
  3. EBS 拡張：CLI で modify-volume → 変更完了待ち。
  4. ファイルシステム拡張：growpart + xfs_growfs / resize2fs。
  5. 監視自動化：CloudWatch カスタムメトリクス + SNS アラートで事前検知。

まとめ

本記事では、EC2 インスタンスにおけるディスク容量不足の原因分析から、実際の EBS ボリューム拡張手順、ファイルシステムリサイズ、さらに CloudWatch を用いた継続的監視までの一連のフローを解説しました。

  • 原因把握と不要データ削除で即時の圧迫解除が可能。
  • EBS 拡張 + リサイズにより、ダウンタイムなしで容量を増強。
  • 自動監視とアラートで再発リスクを低減し、運用の安定性を確保。

これらの手順を実践すれば、容量不足によるサービス停止リスクを大幅に軽減でき、安定したインフラ運用が実現します。今後は、スナップショット自動取得やコスト最適化の観点から、ボリュームタイプの見直しやライフサイクル管理についても検討していきます。

参考資料