S3ライフサイクルでStandard-IAへの即時移行が可能に—Days=0を試してみた

はじめに

2026年7月16日のアップデートで、S3ライフサイクルを使ってStandard-IA / One Zone-IAへ移行する際の「作成後30日以上経過していること」という移行開始日の制約が撤廃されました。これにより、Days=0 を指定した即日移行ルールが設定できるようになっています。なお、移行先ストレージクラスの最低30日間のストレージ期間課金は従来どおりです。

https://aws.amazon.com/jp/about-aws/whats-new/2026/07/s3-removes-30-day-transitions-standard-ia-one-zone-ia/

従来と現在の違いを整理します。

本記事では、Days=0 のライフサイクルルールをAWS CLIで設定し、実際にオブジェクトのStorageClassが STANDARD_IA へ変更されるまでを観測しました。あわせて、コスト面の現実も確認しています。

ライフサイクル移行の仕様は公式ドキュメントの Transitioning objects using Amazon S3 Lifecycle にまとまっています。ただし、2026年7月17日時点ではUser Guideの一部に今回撤廃された30日制約の記述が残っているため、最新の変更内容については上記What's Newもあわせて参照してください。

検証内容

検証環境

テストファイルの準備とアップロード

後述するデフォルトの移行対象サイズ閾値に合わせて、dd でちょうど128KBのランダムバイナリを作成しました。

dd if=/dev/urandom of=testfile.bin bs=1024 count=128

作成したファイルをテスト用バケットにアップロードします。

aws s3api put-object \
  --bucket <bucket-name> \
  --key testfile.bin \
  --body testfile.bin

アップロード直後の状態を head-object で確認しました。

aws s3api head-object --bucket <bucket-name> --key testfile.bin

レスポンスは次のとおりです。

{
    "AcceptRanges": "bytes",
    "LastModified": "2026-07-16T23:09:47+00:00",
    "ContentLength": 131072,
    "ETag": "\"24057b40bc8d24162b955833f8066523\"",
    "ContentType": "binary/octet-stream",
    "ServerSideEncryption": "AES256",
    "Metadata": {}
}

StorageClass フィールドが返っていません。head-object はストレージクラスが STANDARD の場合このフィールドを省略する仕様のため、オブジェクトが STANDARD に格納されていることが分かります。

Days=0 のライフサイクルルール設定

次に、Transitions の Days に 0 を指定したライフサイクル設定を投入します。従来はここで30以上の値が必須でしたが、今回のアップデートで 0 が受け付けられるようになりました。設定はJSONファイルに記述し、put-bucket-lifecycle-configuration で適用します。

aws s3api put-bucket-lifecycle-configuration \
  --bucket <bucket-name> \
  --lifecycle-configuration file://lifecycle.json

このコマンドは成功時に標準出力を返しません。エラーが出なければ設定は受理されています。

get-bucket-lifecycle-configuration で設定を取得すると、レスポンスに TransitionDefaultMinimumObjectSize が含まれます。値は all_storage_classes_128K で、デフォルトでは128KB未満のオブジェクトを移行対象にしないことを示しています。今回のルールではサイズフィルターを指定していないため、128KBちょうどのテストファイルを使用しました。

削除ルール（Expiration）の組み合わせ

移行と削除は同一ルール内に共存できます。ここでは Days=0 のStandard-IA移行と、Days=30 の削除（Expiration）を1つのルールにまとめました。get-bucket-lifecycle-configuration で取得した最終的な設定は次のとおりです。

{
    "TransitionDefaultMinimumObjectSize": "all_storage_classes_128K",
    "Rules": [
        {
            "Expiration": { "Days": 30 },
            "ID": "ImmediateTransitionToStandardIA",
            "Filter": { "Prefix": "" },
            "Status": "Enabled",
            "Transitions": [
                { "Days": 0, "StorageClass": "STANDARD_IA" }
            ]
        }
    ]
}

Days=0 の移行と Days=30 の削除が、同じルールの中で問題なく設定できています。"Filter": { "Prefix": "" } はバケット内の全オブジェクトを対象とする指定です。本番環境で利用する際は、必要に応じてPrefixやTagでフィルタリングしてください。

ストレージクラス変更の観測

ライフサイクルによる移行は非同期で実行されます。設定後、head-object を繰り返してStorageClassの変化を追跡しました。移行が確認できた時点のレスポンスです。

{
    "AcceptRanges": "bytes",
    "Expiration": "expiry-date=\"Sun, 16 Aug 2026 00:00:00 GMT\", rule-id=\"ImmediateTransitionToStandardIA\"",
    "LastModified": "2026-07-16T23:09:47+00:00",
    "ContentLength": 131072,
    "ETag": "\"24057b40bc8d24162b955833f8066523\"",
    "ContentType": "binary/octet-stream",
    "ServerSideEncryption": "AES256",
    "Metadata": {},
    "StorageClass": "STANDARD_IA"
}

StorageClass が STANDARD_IA に変わり、Expiration ヘッダーには30日後の削除予定日（2026年8月16日）とルールIDが表示されました。

Days=0 を指定しても即座には反映されず、本検証ではアップロードから移行を観測できるまで約10時間45分を要しました。実際に移行が実行された時刻は特定できておらず、移行処理そのものにこの時間がかかったわけではありません。移行までの経過は次のとおりです。

アップロードから移行の観測までは約10時間45分でした。日数指定のライフサイクルアクションでは、オブジェクトの作成時刻に指定日数を加え、その結果を次のUTC午前0時に切り上げてアクション日が算出されます。そのため、このオブジェクトは2026年7月17日00:00 UTCに移行対象となったと考えられます。なお、移行観測の約10分後にサーバーアクセスログを確認した時点では、このライフサイクル移行に対応するログはまだ確認できませんでした。サーバーアクセスログはベストエフォートで配信されるため、この時点で未配信であること自体は想定内です。Days=0 はあくまで「移行対象になる最短の経過日数が0日」という意味です。設定した瞬間に変換が走るわけではない点を押さえておくとよいでしょう。

コスト試算

Standard-IAはストレージ単価が安い一方、リクエストやデータ取り出しに追加コストがかかります。東京リージョンの料金をPricing APIで取得しました（effectiveDate 2026-07-14）。最新の料金は公式ページをご確認ください。

GET単価はAWS公式の表記単位が異なります（Standard: 1,000リクエストあたり、Standard-IA: 10,000リクエストあたり）。比較しやすいよう公式の表記をそのまま掲載しました。

1,000個のオブジェクトを30日保持する前提で、ファイルサイズ別に月額を比較しました。ここではデータ取り出しがない（GETなし）場合の保管コストを示しています。Standard-IA月額はストレージ + ライフサイクル移行リクエストの合計です。

※Standard-IA月額には、この1,000オブジェクトを移行する際に1回発生するライフサイクル移行リクエスト料金（$0.01）を含みます。同じオブジェクトの保管を翌月以降も継続する場合、その後の月額にはこの料金は含まれません。

GETアクセスがなければ、オブジェクトサイズが大きいほどストレージ単価の差が効いて削減率が伸びます。ただし実際にはデータを取り出す場面があり、その取り出し料金がStandard-IAの優位性を削ります。

次に、アクセス頻度による損益分岐点を10GBで確認しました。「月N回GET」は、1,000個すべて（10GB全体）を取得する操作をN回実行する前提です。Standard-IA月額はストレージ + GETリクエスト + データ取り出しの合計です（ライフサイクル移行リクエスト料金は初月のみ発生するため、ここでは除外しています）。

10GBのデータに月2回以上の全体GETが発生すると、取り出し料金と割高なGET単価が積み上がり、Standard-IAのほうがStandardより高くなります。

コスト面では、Standard-IAを選ぶ前に次の点を織り込む必要があります。30日未満で削除しても30日分のストレージ料金が課金されます。128KB未満のオブジェクトは実サイズにかかわらず128KB分として課金されます。Standard-IAからデータを取得すると、GETリクエスト料金に加えて、実際に取り出したデータ量に対して$0.01/GBのデータ取り出し料金がかかります。これはStandardにはない追加コストです。加えて、ライフサイクル移行そのものにも1,000オブジェクトあたり$0.01のリクエスト料金がかかります。Days=0で早期の移行が可能になったぶん、こうした最低課金や取り出しコストの影響を受ける期間も前倒しとなる点には注意が必要です。

まとめ

「作成後30日以上」という移行開始日の制約が撤廃され、作成当日を移行日とするStandard-IAへのライフサイクルルールを設定できるようになりました。本検証でも、Days=0の設定が受理され、非同期処理を経てSTANDARD_IAへ移行することを確認できました。

ただし、最低30日間のストレージ期間課金、128KBの最低課金サイズ、データ取り出し料金は従来どおりです。一定サイズに集約した監査ログや、作成後にほとんどアクセスしないバックアップなど、長期間保持しつつ取り出し頻度が低いデータでは、作成当日からの移行がコスト削減の選択肢になります。

参考リンク

• Amazon S3 storage classes
• Examples of S3 Lifecycle configuration