【AWS解説 S3編 #3】ストレージクラスとライフサイクルの違いを整理

Posted at 2026-08-11

【AWS解説 S3編 #3】ストレージクラスとライフサイクルの違いを整理

S3編 #3（全7回予定）

前回のS3編 #2では、バージョニングを有効にして、上書き前や削除前のオブジェクトを残す仕組みを確認しました。

S3へ保存するデータが増えてくると、次は保存方法や料金について、次のような疑問が出てきます。

すべてのファイルを同じ保存方法で保管してよいのか
ほとんど使わなくなったファイルを、より低コストで保存できないか
古くなったログやバックアップを、自動的に移動・削除できないか

S3では、データの用途やアクセス頻度に応じて、複数のストレージクラスを選択できます。

さらに、一定期間が経過したオブジェクトを別のストレージクラスへ移行したり、不要になったオブジェクトを削除したりするライフサイクルルールも設定できます。

この記事では、主要なストレージクラスの違いを整理したうえで、AWSマネジメントコンソールから、30日後にS3 Standard-IAへ移行するライフサイクルルールを作成するところまで進めます。

今回は学習用の設定として、対象を特定のプレフィックスに限定します。確認後は、作成したルールと学習用リソースを削除します。

この記事で分かること

S3のストレージクラスとは何か
主要なストレージクラスの違い
ストレージクラスを選ぶときの考え方
S3ライフサイクルでできること
コンソールでの基本操作
- 学習用オブジェクトのアップロード
- ライフサイクルルールの作成
- ルールの対象範囲と設定内容の確認
- 作成したルールの削除
初学者がつまずきやすいポイント

S3のストレージクラスとは

S3のストレージクラスは、オブジェクトのアクセス頻度や取り出し速度、保存期間などに応じて選択する保存方法です。

例えば、同じS3に保存するデータでも、次のように使われ方が異なります。

Webサイトで頻繁に表示する画像
数か月に1回だけ確認するバックアップ
普段は使用しないが、数年間残しておきたい監査ログ
今後どの程度アクセスされるか分からないデータ

これらをすべて同じ条件で保存するのではなく、用途に合ったストレージクラスを選ぶことで、必要な取り出しやすさを維持しながら、ストレージ料金を調整できます。

身近なイメージでは、次のような違いに近いものです。

よく使うデータ
    ↓
すぐ取り出せる場所に保存する

たまに使うデータ
    ↓
取り出せるが、保管料金を抑えた場所に移す

長期間使わないデータ
    ↓
取り出しに時間がかかってもよい保管庫へ移す

ストレージクラスは、バケット全体で1つだけを選ぶものではありません。

同じバケットの中でも、オブジェクトごとに異なるストレージクラスを使用できます。

主要なストレージクラス

S3には複数のストレージクラスがあります。

この記事では、初学者が最初に押さえておきたいものを中心に整理します。

ストレージクラス	主な用途	データの取り出し	主な注意点
S3 Standard	頻繁に利用するデータ	ミリ秒単位	基本となるストレージクラス
S3 Intelligent-Tiering	アクセス頻度が分からない、または変化するデータ	通常の階層はミリ秒単位	オブジェクトの監視・自動階層化に関する料金がある
S3 Standard-IA	利用頻度は低いが、必要なときはすぐに取り出したいデータ	ミリ秒単位	取り出し料金と最低保存期間がある
S3 One Zone-IA	再作成可能で、利用頻度が低いデータ	ミリ秒単位	1つのアベイラビリティーゾーンに保存される
S3 Glacier Instant Retrieval	ほとんど利用しないが、すぐに取り出す可能性があるアーカイブ	ミリ秒単位	最低保存期間と取り出し料金がある
S3 Glacier Flexible Retrieval	長期保存するバックアップやアーカイブ	復元後に取得	復元に数分から数時間かかる場合がある
S3 Glacier Deep Archive	数年間保存する長期アーカイブ	復元後に取得	復元に長い時間がかかる場合がある

S3 Standard-IAとS3 One Zone-IAには30日、S3 Glacier Instant RetrievalとS3 Glacier Flexible Retrievalには90日、S3 Glacier Deep Archiveには180日の最低保存期間があります。期間を満たす前に削除や別クラスへの移行を行うと、残りの期間に相当する料金が発生することがあります。

S3 Standard

S3 Standardは、頻繁にアクセスするデータ向けの基本的なストレージクラスです。

特に理由がなく、今後のアクセス頻度もまだ分からない場合は、最初はS3 Standardを使用すると分かりやすいです。

例えば、次のようなデータに向いています。

Webサイトで表示する画像
アプリケーションが日常的に読み書きするファイル
頻繁に参照する設定ファイル
作成直後で、今後の利用頻度が分からないデータ

S3 Intelligent-Tiering

S3 Intelligent-Tieringは、オブジェクトのアクセス状況に応じて、S3内のアクセス階層を自動的に変更するストレージクラスです。

次のような場合に候補になります。

アクセス頻度を事前に予測しにくい
時期によってアクセス頻度が変わる
手作業でストレージクラスを見直したくない

ただし、オブジェクトごとの監視や自動階層化に関する料金があります。

小さなファイルを大量に保存する場合などは、保存料金だけでなく、オブジェクト数や監視料金も含めて検討します。

S3 Standard-IA

S3 Standard-IAは、アクセス頻度は低いものの、必要になったときはすぐに取り出したいデータ向けです。

IAは、Infrequent Accessの略です。

例えば、次のような用途が考えられます。

過去の成果物
ときどき確認するバックアップ
利用頻度が下がった画像やドキュメント
障害時に使用するデータ

データはミリ秒単位で取り出せますが、取り出し料金が発生します。

また、最低保存期間は30日です。短期間で削除するデータには、S3 Standardの方が適している場合があります。

S3 One Zone-IA

S3 One Zone-IAも、利用頻度が低いデータ向けのストレージクラスです。

S3 Standard-IAとの大きな違いは、データが1つのアベイラビリティーゾーンに保存されることです。

そのため、次のようなデータが候補になります。

失われても別の場所から再作成できるデータ
別の場所にも原本が保存されているデータ
一時的なバックアップの複製

失うことのできない唯一のデータを、料金だけを理由にS3 One Zone-IAへ保存するのは避けた方が安全です。S3 Standard-IAは複数のアベイラビリティーゾーンにまたがって保存されますが、S3 One Zone-IAは単一のアベイラビリティーゾーンを使用します。

S3 Glacier系のストレージクラス

S3 Glacier系のストレージクラスは、主に長期間保存するデータに使用します。

用途に応じて、主に次の3つがあります。

S3 Glacier Instant Retrieval
S3 Glacier Flexible Retrieval
S3 Glacier Deep Archive

S3 Glacier Instant Retrievalは、ほとんどアクセスしないデータを低コストで保存しつつ、必要なときはミリ秒単位で取り出したい場合に使用します。

一方、S3 Glacier Flexible RetrievalとS3 Glacier Deep Archiveでは、保存したオブジェクトを通常のS3 Standardと同じように、すぐに開くことはできません。

先に復元操作を行い、取り出せる状態になるまで待つ必要があります。

S3 Glacier Flexible Retrievalの標準的な復元には通常3〜5時間、S3 Glacier Deep Archiveでは通常12時間以内が目安とされています。

最初の段階では、次のように覚えておけば十分です。

頻繁に使う
    S3 Standard

利用頻度が低いが、すぐに取り出したい
    S3 Standard-IA

長期間保存し、取り出しに時間がかかってもよい
    S3 Glacier Flexible Retrieval
    S3 Glacier Deep Archive

どのストレージクラスを選べばよいか

ストレージクラスを選ぶときは、保存料金の安さだけでなく、次の点を確認します。

どの程度の頻度でアクセスするか
取り出すまでに待てる時間
どのくらいの期間保存するか
データを失った場合に再作成できるか
取り出し料金が発生しても問題ないか
オブジェクトのサイズや数

例えば、数日後に削除するファイルをS3 Standard-IAへ保存しても、最低保存期間の料金によって、かえって割高になる可能性があります。

また、小さなファイルを大量に別クラスへ移行すると、ストレージ料金の削減額よりも、移行リクエストの料金が大きくなることがあります。

最初から最も安く見えるストレージクラスを選ぶのではなく、データをいつ、どのように使うかを基準に選ぶことが重要です。

S3ライフサイクルとは

S3ライフサイクルは、オブジェクトの作成から一定期間が経過したときに、S3が自動的に処理を行う仕組みです。

主に、次の2種類の処理を設定できます。

処理	内容
移行（Transition）	オブジェクトを別のストレージクラスへ移す
有効期限切れ（Expiration）	一定期間が経過したオブジェクトを削除する

例えば、ログファイルに次のようなルールを設定できます。

オブジェクトを作成
    ↓
最初の30日間はS3 Standard
    ↓
30日後にS3 Standard-IAへ移行
    ↓
365日後に削除

このように、時間の経過に応じて保存方法を自動的に変更するのがライフサイクルルールです。

S3 Lifecycleでは、オブジェクトの移行と有効期限切れをルールとして定義できます。ルールは、バケット内のすべてのオブジェクトだけでなく、プレフィックスやタグなどで対象を限定することもできます。

ストレージクラスとライフサイクルの違い

ストレージクラスとライフサイクルは、似た場面で使われますが、役割が異なります。

項目	役割
ストレージクラス	現在、そのオブジェクトをどの保存方法で保管するか
ライフサイクル	何日後に移行・削除するかという自動処理のルール

簡単に整理すると、次のようになります。

ストレージクラス
    = 保存場所の種類

ライフサイクル
    = 保存場所を変更・削除するタイミング

ライフサイクルを設定しなくても、アップロード時にストレージクラスを選択できます。

一方、作成直後はS3 Standardに保存し、時間が経過してから別のストレージクラスへ移したい場合は、ライフサイクルルールを使用します。

バージョニングを有効にしている場合

前回の記事で扱ったバージョニングを有効にしているバケットでは、現在のバージョンと過去のバージョンを分けて設定できます。

例えば、次のようなルールを作成できます。

現在のバージョンを、作成から30日後にS3 Standard-IAへ移行する
過去のバージョンを、現行ではなくなってから30日後に移行する
過去のバージョンを、現行ではなくなってから365日後に完全削除する
不要になった削除マーカーを削除する

今回のハンズオンでは仕組みを分かりやすくするため、バージョニングを有効にしていない学習用バケットを使用します。

バージョニング有効時の過去バージョンには、現在のバージョンとは別のライフサイクル設定が必要です。コンソールでも、現在のバージョンの移行・期限切れと、過去のバージョンの移行・完全削除は別の項目として設定します。

コンソールでライフサイクルルールを作ってみる

ここからは、AWSマネジメントコンソールを使って、ライフサイクルルールを作成します。

今回は、次のルールを作成します。

対象:
lifecycle-demo/ から始まるキーのオブジェクト

処理:
作成から30日後にS3 Standard-IAへ移行する

前提

AWSアカウントを持っていること
AWSマネジメントコンソールにログインできること
S3編 #1の基本操作を確認していること
本記事の操作は学習用として行うこと
検証後はライフサイクルルールと学習用リソースを削除すること
今回はバージョニングを有効にしていないバケットを使用すること

今回使用するリージョン

この記事では、次のリージョンにバケットを作成します。

アジアパシフィック（東京）ap-northeast-1

1. 学習用バケットを作成する

S3編 #1と同じ手順で、学習用バケットを作成します。

AWSマネジメントコンソールで S3 を開く
バケットを作成をクリックする
ほかの利用者と重複しないバケット名を入力する
AWSリージョンで、**アジアパシフィック（東京）ap-northeast-1**を選択する
そのほかの設定はデフォルトのまま進める
バケットを作成をクリックする

バケット名の例は次のとおりです。

s3-lifecycledemo-任意の数字

例えば、次のような名前にできます。

s3-lifecycledemo-202607

この名前にする必要があるわけではありません。

ほかの利用者と重複せず、用途が分かる任意の名前を指定してください。

今回も、Block Public Accessは有効のまま進めます。

2. 学習用オブジェクトをアップロードする

次に、ライフサイクルルールの対象にするオブジェクトをアップロードします。

今回は、オブジェクトキーの先頭が次の文字列になるようにします。

lifecycle-demo/

作成したバケットを開く
フォルダの作成をクリックする
フォルダ名に lifecycle-demo と入力する
作成した lifecycle-demo フォルダを開く
アップロードをクリックする
画像やPDFなどのファイルを1つ選択する
アップロードを実行する

アップロード後のオブジェクトキーは、次のようになります。

lifecycle-demo/sample-image.png

今回のハンズオンでは、可能であれば128KBより大きいファイルを使用してください。

2024年9月以降に作成・更新された通常のライフサイクル設定では、128KB未満のオブジェクトは、デフォルトでは別のストレージクラスへ移行されません。小さなオブジェクトは移行リクエストの料金がストレージ料金の削減額を上回る可能性があるためです。

3. 現在のストレージクラスを確認する

アップロード直後のオブジェクトを確認します。

lifecycle-demo フォルダを開く
アップロードしたオブジェクトを選択する
オブジェクトの詳細画面を開く
ストレージクラスを確認する

アップロード時に変更していなければ、通常は次のストレージクラスになっています。

スタンダード

今回は、このオブジェクトを30日後にS3 Standard-IAへ移行するルールを作成します。

4. ライフサイクルルールを作成する

対象のバケットを開く
管理タブを開く
ライフサイクルルールの項目を確認する
ライフサイクルルールを作成するをクリックする

ライフサイクルルール名

ルール名には、設定内容が分かる名前を入力します。

今回は、次の名前を使用します。

move-lifecycle-demo-to-standard-ia

ルールの適用範囲

今回は、バケット内のすべてのオブジェクトではなく、lifecycle-demo/から始まるオブジェクトだけを対象にします。

ルールのスコープでは、フィルターを使用して対象を限定する設定を選択します。

プレフィックスには、次の値を入力します。

lifecycle-demo/

末尾の / も含めて入力します。

これにより、次のオブジェクトは対象になります。

lifecycle-demo/sample-image.png
lifecycle-demo/sample.pdf
lifecycle-demo/logs/sample.log

一方、次のオブジェクトは対象になりません。

sample-image.png
documents/sample.pdf

S3のライフサイクルルールでは、キーのプレフィックスやオブジェクトタグを使って、対象をバケット内の一部に限定できます。

ライフサイクルルールのアクション

アクションでは、次の項目を選択します。

オブジェクトの現行バージョンをストレージクラス間で移行

移行先のストレージクラスには、次を選択します。

S3 Standard-IA

オブジェクト作成後の日数には、次を入力します。

2026年7月16日のアップデート

S3 Standard-IAとS3 One Zone-IAには、オブジェクト作成当日（0日後）からライフサイクルで移行できるようになりました。

以前は、オブジェクトをS3 Standardに少なくとも30日間保存してから移行する必要がありましたが、この制限は撤廃されています。

ただし、S3 Standard-IAとS3 One Zone-IA自体の最低保存期間は30日のままです。移行後30日未満で削除・上書き・別のストレージクラスへ移行した場合は、残りの期間に相当する料金が発生します。

詳細は、AWS公式アップデートを確認してください。

今回は基本的なライフサイクル設定を確認するため、従来から一般的な例として使用されている「30日後にS3 Standard-IAへ移行する」ルールを作成します。

設定内容は次のとおりです。

ルール名:
move-lifecycle-demo-to-standard-ia

対象:
lifecycle-demo/ から始まるオブジェクト

アクション:
現行バージョンを移行する

移行先:
S3 Standard-IA

移行する時期:
オブジェクト作成から30日後

内容を確認し、ルールを作成をクリックします。

5. 作成したルールを確認する

ルールを作成したら、バケットの管理タブに戻ります。

次の内容を確認します。

ルール名が表示されている
ステータスが有効になっている
対象のプレフィックスが lifecycle-demo/ になっている
30日後にS3 Standard-IAへ移行する設定になっている

ライフサイクルルールを作成しても、オブジェクトのストレージクラスがすぐに変更されるわけではありません。

今回の設定では、オブジェクトを作成してから30日が経過したあとに、移行の対象になります。

また、ライフサイクル処理は非同期で行われるため、設定した日数に達した瞬間に、必ず処理が完了するわけではありません。S3はオブジェクトの作成時刻をUTCで評価し、条件を満たしたオブジェクトを処理対象とします。

今回は30日間待つことを目的としていないため、ルールが正しく作成されたことの確認までをハンズオンのゴールとします。

ライフサイクルルールの設定例

実際の運用では、データの用途に応じて、移行と削除を組み合わせます。

例えば、アプリケーションログであれば、次のようなルールが考えられます。

作成から30日後
    S3 Standard-IAへ移行

作成から90日後
    S3 Glacier Flexible Retrievalへ移行

作成から365日後
    削除

ただし、この設定がすべてのログに適しているわけではありません。

次の点を確認してから日数を決めます。

法律や社内規則で必要な保存期間
障害調査で過去ログを確認する期間
データを取り出す頻度
復元に待てる時間
最低保存期間
取り出し料金
移行リクエスト料金

学習段階では、複数の処理を一度に設定するよりも、まず1つのルールを作成し、対象と動作を理解することをおすすめします。

料金を考えるときの注意点

ストレージクラスを変更するときは、保存料金だけを比較しないようにします。

S3では、主に次の内容によって料金が変わります。

保存しているデータ量
使用するストレージクラス
オブジェクトへのリクエスト数
別のストレージクラスへの移行リクエスト
データの取り出し量
最低保存期間
オブジェクトのサイズや数

例えば、S3 Standard-IAは、S3 Standardより保存料金を抑えられる場合があります。

一方で、次のようなデータには向いていない可能性があります。

頻繁に取り出すデータ
30日以内に削除するデータ
小さなオブジェクトを大量に保存する用途
短期間だけ使用する一時ファイル

S3 Standard-IAでは、128KB未満のオブジェクトも保存できますが、ストレージ料金は128KB分として計算されます。また、30日未満で削除・上書き・移行した場合は、最低保存期間の残りに相当する料金が発生します。

料金体系は変更される可能性があります。利用前に、AWS公式の料金ページを確認してください。

Amazon S3の料金

初学者がつまずきやすいポイント

ライフサイクルルールを作成しても、すぐに移行しない

ライフサイクルルールは、指定した日数が経過したオブジェクトを対象にします。

今回のルールでは、作成から30日が経過するまでは、オブジェクトはS3 Standardのままです。

また、条件を満たしたあとも処理は非同期で行われるため、指定日時と実際の処理完了時刻が完全に一致するとは限りません。

小さなファイルが移行されない

現在の標準的なライフサイクル設定では、128KB未満のオブジェクトは、デフォルトでは別のストレージクラスへ移行されません。

小さなオブジェクトは、1つずつ移行リクエストが発生するため、ストレージ料金の削減よりも移行料金の方が大きくなる可能性があります。

学習用に移行ルールを確認する場合は、128KBより大きい画像やPDFなどを使用すると分かりやすいです。

安いストレージクラスほど必ず得になると思っている

ストレージ料金が低く見えるクラスでも、次の料金や制約があります。

取り出し料金
最低保存期間
最低課金対象サイズ
移行リクエスト料金
復元リクエスト料金

頻繁に取り出すデータや短期間で削除するデータでは、S3 Standardの方が結果的に適している場合があります。

ルールをバケット全体へ適用してしまう

ライフサイクルルールは、バケット内のすべてのオブジェクトへ適用できます。

しかし、設定を間違えると、移行する予定のないファイルや、削除してはいけないファイルまで対象になる可能性があります。

最初は今回のように、次のプレフィックスへ対象を限定すると安全です。

lifecycle-demo/

ルールを作成するときは、対象範囲を必ず確認してください。

バージョニングの過去バージョンが削除されない

バージョニングを有効にしているバケットでは、現行バージョンと過去のバージョンが別に管理されます。

現行バージョンに対する有効期限だけを設定しても、過去のバージョンが残ることがあります。

過去のバージョンを自動的に整理する場合は、次の項目も設定します。

過去バージョンのストレージクラス移行
過去バージョンの完全削除
期限切れになった削除マーカーの削除

また、バージョニング有効バケットで現行バージョンを期限切れにすると、すべてのバージョンが直ちに完全削除されるのではなく、削除マーカーが追加される場合があります。

ライフサイクルルールを削除すれば元に戻ると思っている

ライフサイクルルールを削除すると、今後そのルールによる処理は行われなくなります。

ただし、すでに別のストレージクラスへ移行したオブジェクトが、自動的にS3 Standardへ戻るわけではありません。

今回のハンズオンでは30日が経過する前にルールを削除するため、移行処理は発生していません。

学習用リソースを削除する

確認が終わったら、作成したライフサイクルルール、オブジェクト、バケットを削除します。

1. ライフサイクルルールを削除する

対象のバケットを開く
管理タブを開く
作成したライフサイクルルールを選択する
削除をクリックする
確認画面の案内に従って削除する
ルール一覧から消えたことを確認する

削除するルール名は、今回作成した次のルールです。

move-lifecycle-demo-to-standard-ia

2. 学習用オブジェクトを削除する

オブジェクトタブを開く
lifecycle-demo フォルダを開く
アップロードしたオブジェクトを選択する
削除をクリックする
確認画面の案内に従って削除する

フォルダ表示が残っている場合は、lifecycle-demoも削除します。

3. バケットを削除する

S3のバケット一覧へ戻る
今回作成したバケットを選択する
削除をクリックする
確認画面の案内に従って削除する

バケット内にオブジェクトが残っている場合は削除できません。

削除できない場合は、バケット内にファイルやフォルダが残っていないかを確認してください。

まとめ

S3のストレージクラスは、データのアクセス頻度や保存期間、取り出しに必要な時間に応じて選択する保存方法です。

最初は、次のように整理すると分かりやすくなります。

頻繁に利用する
    S3 Standard

アクセス頻度が分からない
    S3 Intelligent-Tiering

利用頻度は低いが、すぐに取り出したい
    S3 Standard-IA

長期間保存する
    S3 Glacier Flexible Retrieval
    S3 Glacier Deep Archive

S3ライフサイクルを使用すると、時間の経過に応じて、オブジェクトを別のストレージクラスへ移行したり、不要なオブジェクトを削除したりできます。

この記事では、AWSマネジメントコンソールを使って、次の操作を行いました。

学習用バケットとオブジェクトを作成する
オブジェクトのストレージクラスを確認する
lifecycle-demo/を対象としたルールを作成する
30日後にS3 Standard-IAへ移行する設定を確認する
ライフサイクルルールと学習用リソースを削除する

ストレージクラスを選ぶときは、保存料金だけでなく、取り出し料金、最低保存期間、オブジェクトサイズなども含めて考えることが重要です。

次回

次回は、S3のBlock Public Accessとバケットポリシーを扱います。

S3のオブジェクトへアクセスできる人や操作を制御する仕組みと、意図しない一般公開を防ぐための考え方を整理します。

S3をCloudFormationで設定する場合

今回は、AWSマネジメントコンソールからS3のライフサイクルルールを作成しました。

CloudFormationでは、S3バケットの設定として、ストレージクラスの移行や有効期限などをYAML形式で定義できます。

個人開発しているIaCraftStudioでは、画面からS3のライフサイクル設定を選択し、その内容がCloudFormation YAMLへどのように反映されるか確認できます。

コンソールで設定する場合との違いや、ライフサイクルルールのYAML表現を確認したい場合は、次の画面から試せます。
是非とも試してみてください。

・以下から使用できます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up