2026年8月17日

AWS S3のバージョニング機能の設定方法｜有効化・復元・古い版の自動削除まで

VPS・クラウド

S3 のバージョニングを有効にすると、同じキーへの上書きや削除が起きても以前の版が残り、誤操作から元に戻せるようになります。この記事では、有効化の手順と「一度有効にすると無効には戻せない」などの仕様、削除マーカーを使った復元方法、そして放置するとストレージ量が膨らむ古い版をライフサイクルルールで整理する方法までを説明します。WordPress のバックアップ保存先やメディアの保管先として S3 を使っている場合の注意点にも触れます。

この記事はコンソールの画面と AWS ドキュメントの内容（2026年10月現在）をもとに説明していますが、表記は更新で変わることがあります。ライフサイクルルールは条件を誤るとデータを削除する設定なので、まずは検証用バケットで試してから本番に適用してください。

バージョニングの3つの状態

S3 バケットのバージョニングには次の3つの状態があります。

未設定（既定）: 同じキーに上書きすると以前のデータは失われます。
有効: 書き込みのたびに新しいバージョン ID が付き、以前の版は「非現行バージョン」として残ります。
停止: 新しい書き込みにはバージョン ID が付かなくなりますが、すでに残っている版はそのまま保持されます。

重要なのは、一度「有効」にしたバケットは「未設定」に戻せず、「停止」にしかできない ことです。停止しても過去の版は消えず、保存料金の対象として残り続けます。「とりあえず有効にして、不要なら戻す」という使い方はできない点を理解したうえで設定してください。

なお、有効化する前から入っていたオブジェクトは、バージョン ID が null の版として扱われます。有効化した時点から新しい版の記録が始まり、さかのぼって過去の状態が保存されるわけではありません。

手順1：バージョニングを有効にする

コンソールでは、対象バケットを開いて「プロパティ」タブにあるバケットのバージョニングの項目から「編集」を選び、有効にして保存します。

AWS CLI では次のように設定と確認ができます。

# 有効化
aws s3api put-bucket-versioning \
  --bucket my-wp-backup-bucket \
  --versioning-configuration Status=Enabled

# 状態の確認（"Status": "Enabled" が返れば有効）
aws s3api get-bucket-versioning --bucket my-wp-backup-bucket

この操作には s3:PutBucketVersioning の権限が必要です。WordPress のプラグインに渡している IAM ユーザーには、この権限を付けないでください。バケットの設定変更は管理者だけが行えるようにしておくのが基本です。

手順2：上書き・削除からの復元方法

バージョニングが有効なバケットでは、「削除」の意味が変わります。キーを指定して普通に削除すると、データは消えずに 削除マーカー という目印が最新版として置かれ、オブジェクトが見えなくなるだけです。

一覧で版を確認する

aws s3api list-object-versions \
  --bucket my-wp-backup-bucket \
  --prefix backups/2026/db.sql.gz

結果の Versions に実データの各版、DeleteMarkers に削除マーカーが並びます。IsLatest が true のものが現在の版です。コンソールでは、オブジェクト一覧でバージョンを表示する切り替えをオンにすると同じ情報が見られます。

削除してしまったファイルを戻す

削除マーカーそのものをバージョン ID 指定で削除すると、その下にあった版が再び最新版になり、ファイルが元に戻ります。

# DeleteMarkers に出ていた VersionId を指定する
aws s3api delete-object \
  --bucket my-wp-backup-bucket \
  --key backups/2026/db.sql.gz \
  --version-id "削除マーカーのVersionId"

ここで注意したいのは、バージョン ID を指定した削除は取り消しができない ことです。削除マーカーではなく実データの版の ID を指定すると、その版は恒久的に消えます。ID は一覧から慎重にコピーしてください。

上書きしてしまったファイルを古い版に戻す

古い版を同じキーへコピーすると、その内容が新しい最新版になります。上書きされた版も非現行として残るので、やり直しがききます。

aws s3api copy-object \
  --bucket my-wp-backup-bucket \
  --key wp-content/uploads/2026/10/logo.png \
  --copy-source "my-wp-backup-bucket/wp-content/uploads/2026/10/logo.png?versionId=戻したい版のVersionId"

単にファイルを取り出して確認したいだけなら、aws s3api get-object に --version-id を付けてローカルへダウンロードする方法が安全です。

手順3：ライフサイクルルールで古い版を整理する

バージョニングを有効にしたまま放置すると、上書きのたびに非現行の版がたまり、ストレージ量が増え続けます。毎日同じファイル名で上書きするバックアップや、頻繁に再生成されるサムネイルなどでは特に増え方が大きくなります。そこで、ライフサイクルルールで古い版を自動的に削除します。

次の例は「非現行になってから30日を過ぎた版を削除する。ただし新しいほうから3版は残す」「中身の版がなくなった削除マーカーを掃除する」「途中で止まったマルチパートアップロードを7日で破棄する」という設定です。

{
  "Rules": [
    {
      "ID": "cleanup-noncurrent-versions",
      "Status": "Enabled",
      "Filter": { "Prefix": "" },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 30,
        "NewerNoncurrentVersions": 3
      },
      "Expiration": { "ExpiredObjectDeleteMarker": true },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

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

# 反映内容の確認
aws s3api get-bucket-lifecycle-configuration --bucket my-wp-backup-bucket

Filter の Prefix を空にするとバケット全体が対象になります。特定のフォルダーだけに適用したい場合は backups/ のように指定してください。ライフサイクルの処理は非同期で行われ、条件を満たした直後に消えるとは限りません。また、put-bucket-lifecycle-configuration はバケットの既存ルールを丸ごと置き換えるので、すでにルールがある場合は get で取得した内容に追記してから適用します。

何日・何版残すかは、「どれくらい前の状態まで戻したいか」と「保存量の許容範囲」で決めます。バックアップ用途なら、バックアッププラグイン側の保持世代数と合わせて考えると整理しやすくなります。

WordPressでS3を使うときの注意点

バックアップの保存先として使う場合

UpdraftPlus などのバックアッププラグインは、古いバックアップを世代管理で自動削除します。バージョニングが有効なバケットでは、この削除は削除マーカーになるだけで実データは残ります。誤削除への備えとしては有利ですが、ライフサイクルルールを設定しないと「プラグイン上は5世代なのに、S3 には何十世代も残っている」状態になります。

もう1つの利点は、プラグイン用の IAM ユーザーから s3:DeleteObjectVersion を外しておけることです。こうすると、WordPress が乗っ取られて認証情報が漏れても、攻撃者は削除マーカーを置けるだけで、過去の版そのものは消せません。プラグインに必要な権限（s3:PutObject、s3:GetObject、s3:ListBucket、通常の s3:DeleteObject など）はプラグインのドキュメントで確認し、最小限に絞ってください。

メディアの保管先として使う場合

WP Offload Media のようなプラグインでメディアを S3 に置いている場合、画像の再生成や編集で同じキーが上書きされることがあります。バージョニングは誤って消した画像を戻す手段になりますが、メディアライブラリ（データベース）側の情報は S3 の版とは別に管理されています。S3 で戻してもデータベースの記録とずれることがあるため、データベースのバックアップと組み合わせて復旧手順を考えておきましょう。

あわせて知っておきたい関連機能

MFA Delete: 版の恒久削除やバージョニング状態の変更に MFA を求める設定です。ルートアカウントの認証情報で CLI や API から設定する必要があり、ライフサイクルルールとは併用できないとされています。
オブジェクトロック: 一定期間、版の削除や上書きを防ぐ機能で、バージョニングが前提です。保持期間を設定すると管理者でも消せなくなるモードがあるため、検証してから使ってください。
レプリケーション: 別リージョンや別バケットへ自動複製する機能で、複製元と複製先の両方でバージョニングが有効になっている必要があります。

まとめ

バージョニングは一度有効にすると「停止」にしかできない。有効化前の内容はさかのぼって保存されない。
普通の削除は削除マーカーを置くだけ。マーカーを消せば復元でき、古い版のコピーで上書き前に戻せる。
バージョン ID を指定した削除は取り消せないので、ID の取り違えに注意する。
ライフサイクルルールで非現行バージョンの保持日数と世代数を決め、保存量の増え続けを防ぐ。
WordPress 用の IAM ユーザーには s3:DeleteObjectVersion や設定変更の権限を与えず、版を消せない構成にしておく。