クラウドバックアップのコスト最適化方法（容量・保管クラス・世代管理の見直し）

クラウドバックアップの費用を下げる近道は、単価の安いサービスを探すことより先に、「何に課金されているか」を分解し、むだに保管している世代やファイルを減らすことです。費用の多くは、保管容量・リクエスト回数・取り出し（転送）の3つで決まり、保管クラスの選び方を誤ると、安いはずのクラスで逆に高くつくこともあります。この記事では、WordPressやサーバーのバックアップを Amazon S3 などのオブジェクトストレージに置いている人向けに、請求の内訳の読み方、容量を減らす方法、ライフサイクルルールでの自動整理、保管クラスの選び方、費用を監視する方法を説明します。料金の体系や金額はサービスごとに違い、改定もあるため、具体的な数字は各社の料金ページで確認してください（2026年10月現在の一般的な傾向として説明します）。

まず請求の内訳を分解する

オブジェクトストレージの費用は、おおむね次の要素の合計です。

• 保管容量：保存しているデータ量と保管期間に応じた費用。過去の世代やバージョンも含まれます。
• リクエスト：アップロード（PUT）や一覧取得（LIST）、ダウンロード（GET）の回数に応じた費用。小さなファイルを大量に送ると増えます。
• 取り出し・転送：インターネットへのデータ転送や、アーカイブ系クラスからの取り出しにかかる費用。復元のときに発生します。
• 最低保管期間・最小課金サイズ：低頻度アクセス向けやアーカイブ向けのクラスにある条件で、期間前に消したり、小さなファイルを置いたりすると、条件分の料金がかかります。

AWS なら Cost Explorer で、S3 の費用を使用タイプ別に分けて見られます。容量が原因なのか、リクエスト回数が原因なのか、転送が原因なのかで、打つ手がまったく変わるため、最初にここを確認します。バケットの中身の量は、次のように集計できます。

# バケット（またはプレフィックス）の合計サイズとオブジェクト数
aws s3 ls s3://your-backup-bucket/wp-backups/ --recursive --summarize --human-readable | tail -n 2

オブジェクト数が非常に多い場合は、この方法は時間がかかり、LIST リクエストの費用もかかります。大きなバケットでは、S3 Storage Lens や S3 インベントリのような集計機能を使うほうが向いています。

容量を減らす：送る前に小さくする

もっとも効果が大きいのは、クラウドに送るデータそのものを減らすことです。

不要なファイルを除外する。キャッシュ用プラグインのキャッシュディレクトリ、バックアップ用プラグインが作るローカルの保存先、更新作業の一時ディレクトリなどは、戻すときに必要ありません。特にバックアップ用プラグインの保存先を含めると、バックアップの中に過去のバックアップが入り、回を追うごとに膨らみます。

圧縮する。データベースのダンプはよく縮みます。一方、画像や動画はファイル形式の時点で圧縮されているため、圧縮してもほとんど小さくなりません。

毎回の全体バックアップをやめる。画像が多いサイトで、毎日すべてを1つのアーカイブに固めて送ると、変わっていない画像を毎日保存し直すことになります。restic や BorgBackup のような重複排除型のツールなら、2回目以降は変更分だけが増えます。restic はS3互換のストレージに直接書き込めます。

# restic で S3 互換ストレージへ（認証情報は環境変数やファイルで渡す）
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/your-backup-bucket/restic"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
restic backup --compression auto \
  --exclude /var/www/html/wp-content/cache \
  /var/www/html

小さなファイルを大量に送らない。数万個のファイルを1つずつアップロードすると、そのままリクエストの回数になります。tar でまとめてから送るか、内部でデータをまとめて保存する重複排除型のツールを使うと、回数を抑えられます。

世代を整理する：保持ルールを決める

容量が年々増えていく原因の多くは、古い世代が消えずに残っていることです。「毎日分を7日、毎週分を4週、毎月分を6か月」のように、保持する世代を先に決めておきます。restic なら次のように整理できます。

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

forget は世代の記録を消すだけで、--prune を付けて初めて不要になったデータが削除され、容量が減ります。prune はリポジトリの中身を読み書きするため、時間と、場合によってはリクエストの費用がかかります。毎日ではなく、週に1回程度にまとめる運用もよく見られます。

UpdraftPlus などのWordPress用バックアッププラグインでクラウドに保存している場合も、プラグイン側で保持する世代数を設定できます。設定画面の名前はバージョンによって変わるため、「保持する数」に当たる項目を探してください。プラグインで世代を消しても、バケット側でバージョニングが有効だと、消したつもりのデータが過去のバージョンとして残り続けます。次のライフサイクルルールと合わせて確認します。

ライフサイクルルールで自動的に整理する

S3 のライフサイクルルールを使うと、一定日数が過ぎたオブジェクトを安いクラスへ移したり、削除したりできます。手作業の整理に頼らないため、消し忘れによる費用の増加を防げます。

{
  "Rules": [
    {
      "ID": "wp-backup-tiering",
      "Filter": { "Prefix": "wp-backups/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" }
      ],
      "Expiration": { "Days": 365 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration \
  --bucket your-backup-bucket \
  --lifecycle-configuration file://lifecycle.json

この例では、wp-backups/ 以下のオブジェクトを30日後に低頻度アクセス向けのクラスへ、90日後にアーカイブ向けのクラスへ移し、365日後に削除します。見落とされやすいのが残りの2つです。

• NoncurrentVersionExpiration：バージョニングが有効なバケットでは、上書きや削除をしても古いバージョンが残ります。この指定がないと、過去のバージョンが課金され続けます。
• AbortIncompleteMultipartUpload：大きなファイルの分割アップロードが途中で失敗すると、目に見えない断片が残り、容量として課金されます。一定日数で自動的に片付けます。

既存のルールがある場合、この命令は設定を丸ごと置き換えます。先に aws s3api get-bucket-lifecycle-configuration で現在のルールを保存してから実行してください。

保管クラスの選び方と落とし穴

アーカイブ向けのクラスは保管単価が安い代わりに、取り出しに費用や時間がかかり、最低保管期間もあります。次の点を確認してから選びます。

• 最低保管期間：低頻度アクセス向けやアーカイブ向けのクラスには、30日・90日・180日といった最低保管期間があり、それより早く消すと残りの期間分が請求されます。7日で消す日次バックアップをアーカイブ向けに置くと、かえって高くなります。
• 最小課金サイズ：小さなオブジェクトは、実際より大きいサイズとして課金されるクラスがあります。S3 ではライフサイクルによる移行でも、小さなオブジェクトを既定では移さない動作があります。
• 重複排除型ツールとの相性：restic や BorgBackup は、prune や検査のときにリポジトリの中身を読みます。取り出しに復元の手続きが要るクラスに置くと、こうした処理が動かなくなったり、取り出しの費用がかさんだりします。重複排除型のリポジトリは、すぐに読めるクラスに置くのが無難です。
• 復元の時間：アーカイブ向けのクラスの中には、取り出しに数時間以上かかるものがあります。サイトが止まっているときに、すぐ戻せなくては困ります。直近の世代はすぐに読めるクラスに置き、長期保管分だけをアーカイブに回すのが基本です。

保管先サービスの選び方

S3互換の API を持つサービスは複数あり、転送料金がかからない、または安い料金体系のものもあります。ただし、最低保管期間や、保管量に対して取り出しの量に上限を設けるといった独自の条件を持つサービスもあるため、料金表の「保管単価」だけで比べるのは危険です。比べるときは、毎月の保管量、アップロードの回数、年に何回どれだけ復元するか、という自分の使い方を当てはめて試算します。

また、同じクラウドの同じリージョンに本番サーバーとバックアップを置くと、障害やアカウントの乗っ取りで両方を同時に失うおそれがあります。別のリージョン、別のサービスにも1つ持っておく考え方が、3-2-1ルールです。費用を下げるために冗長性まで削っていないかは、あわせて確認してください。

費用を監視する

設定を見直したあとも、データの増え方は変わります。費用の急な増加に早く気づけるよう、監視を入れておきます。

• 予算アラート：AWS Budgets などで、月の予算に近づいたらメールで通知されるようにします。
• 容量の推移：S3 Storage Lens などで、バケットごとの容量やオブジェクト数の推移を見ます。急に増えた場合は、除外設定が外れた、世代の整理が止まった、といった原因を疑います。
• ジョブの成否：prune や世代の整理が失敗していても、バックアップ自体は成功しているため気づきにくい点です。整理の処理も終了コードを記録し、失敗したら通知します。

復元の訓練も費用に含めて考える

費用を抑えることに集中すると、復元の訓練を後回しにしがちです。しかし、取り出しの費用や時間が想定外に大きいことは、実際に戻してみて初めて分かります。年に数回、最新の世代と古い世代をステージング環境に戻し、WordPressが表示できるか、どれだけ時間と費用がかかったかを記録しておくと、保管クラスや保持ルールの見直しの判断材料になります。

まとめ

• 請求を「保管容量・リクエスト・取り出し」に分けて、どこが費用の中心かを先に確認する
• 不要ファイルの除外、ダンプの圧縮、重複排除型ツールへの切り替えで、送るデータそのものを減らす
• 保持する世代数を決め、ライフサイクルルールで古いバージョンと分割アップロードの断片も片付ける
• アーカイブ向けのクラスは、最低保管期間・最小課金サイズ・取り出しの時間を確認してから使う
• 予算アラートと容量の推移で監視し、復元の訓練で実際の費用と時間を確かめる

• バックアップデータの圧縮と最適化方法
• S3のバージョニング設定と運用