S3 ライフサイクル設定の例
このセクションでは、S3 ライフサイクル設定の例を示します。それぞれの例では、各サンプルシナリオで XML をどのように指定するかを示します。
トピック
作成後 1 日以内にすべてのオブジェクトをアーカイブする
各 S3 ライフサイクルルールには、S3 ライフサイクルルール適用先バケット内のオブジェクトのサブセットを識別するのに使用できるフィルターが含まれます。以下の S3 ライフサイクル設定は、フィルタを指定する方法の例です。
-
この S3 ライフサイクル設定ルールでは、フィルターはキープレフィックス (
tax/
) を指定しています。したがって、ルールは、キー名プレフィックスがtax/
のオブジェクト (tax/doc1.txt
、tax/doc2.txt
など) に適用されます。このルールは、Amazon S3 に以下のことを命じる 2 つのアクションを指定します。
-
作成されてから 365 日後にオブジェクトを S3 Glacier Flexible Retrieval ストレージクラスに移行します。
-
作成から 3,650 日 (10 年) 後にオブジェクトを削除する (
Expiration
アクション)。
<LifecycleConfiguration> <Rule> <ID>Transition and Expiration Rule</ID> <Filter> <Prefix>tax/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>365</Days> <StorageClass>GLACIER</StorageClass> </Transition> <Expiration> <Days>3650</Days> </Expiration> </Rule> </LifecycleConfiguration>
オブジェクトの経過日数を作成後の日数で指定する代わりに、各アクションの日付を指定できます。ただし、
Date
とDays
の両方を同じルールで使用することはできません。 -
-
バケット内のすべてのオブジェクトに S3 ライフサイクルルールを適用する場合は、空のプレフィックスを指定します。以下の設定では、作成から 0 日後にオブジェクトを S3 Glacier Flexible Retrieval ストレージクラスに移行するよう Amazon S3 に指示する
Transition
アクションをルールとして指定しています。このルールは、オブジェクトが作成後の 午前 0 時 (UTC) に S3 Glacier Flexible Retrieval へのアーカイブ対象となることを意味します。ライフサイクルの制約の詳細については、「移行に関する制約と考慮事項」を参照してください。<LifecycleConfiguration> <Rule> <ID>Archive all object same-day upon creation</ID> <Filter> <Prefix></Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>0</Days> <StorageClass>GLACIER</StorageClass> </Transition> </Rule> </LifecycleConfiguration>
-
フィルタ内にゼロまたは 1 個のキー名のプレフィックスと 0 個以上のオブジェクトタグを指定できます。以下のコード例では、キープレフィックスが
tax/
のオブジェクトのサブセットと、指定したキーと値の 2 つのタグを含むオブジェクトに、S3 ライフサイクルルールを適用しています。複数のフィルターを指定するときは、次に示すように<And>
要素を含める必要があることに注意してください (Amazon S3 では論理AND
を適用して、指定されたフィルター条件を結合します)。... <Filter> <And> <Prefix>tax/</Prefix> <Tag> <Key>key1</Key> <Value>value1</Value> </Tag> <Tag> <Key>key2</Key> <Value>value2</Value> </Tag> </And> </Filter> ...
-
オブジェクトのフィルタはタグに基づいてのみ行うことができます。たとえば、以下の S3 ライフサイクルルールは、2 つのタグが指定されている (プレフィックスは指定されていない) オブジェクトに適用されます。
... <Filter> <And> <Tag> <Key>key1</Key> <Value>value1</Value> </Tag> <Tag> <Key>key2</Key> <Value>value2</Value> </Tag> </And> </Filter> ...
重要
S3 ライフサイクル設定に複数のルールがある場合、1 つのオブジェクトが同じ日に複数の S3 ライフサイクルアクションの対象になることがあります。このような場合、Amazon S3 は以下の一般的なルールに従います。
-
完全な削除は、移行より優先されます。
-
移行は、削除マーカーの作成より優先されます。
-
オブジェクトが S3 Glacier Flexible Retrieval と S3 Standard-IA (または S3 One Zone-IA) 移行の両方の対象になる場合、Amazon S3 は S3 Glacier Flexible Retrieval 移行を選択します。
例については、「重複するフィルタ、競合するライフサイクルアクションの例」を参照してください。
ライフサイクルルールの一時的な無効化
status
要素を使用して、S3 ライフサイクルルールを一時的に無効にできます。これは、既存のルールを上書きすることなく、新しいルールをテストしたり、設定に関する問題をトラブルシューティングしたりする場合に役立ちます。以下の S3 ライフサイクル設定では、2 つのルールを指定しています。
-
ルール 1 は、
logs/
プレフィックスを持つオブジェクトを作成直後に S3 Glacier Flexible Retrieval ストレージクラスに移行するよう、Amazon S3 に指示します。 -
ルール 2 は、
documents/
プレフィックスを持つオブジェクトを作成直後に S3 Glacier Flexible Retrieval ストレージクラスに移行するよう、Amazon S3 に指示します。
設定では、ルール 1 は有効で、ルール 2 は無効です。Amazon S3 は無効なルールを無視します。
<LifecycleConfiguration> <Rule> <ID>Rule1</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>0</Days> <StorageClass>GLACIER</StorageClass> </Transition> </Rule> <Rule> <ID>Rule2</ID> <Filter> <Prefix>documents/</Prefix> </Filter> <Status>Disabled</Status> <Transition> <Days>0</Days> <StorageClass>GLACIER</StorageClass> </Transition> </Rule> </LifecycleConfiguration>
オブジェクトの有効期間全体にわたってストレージクラスの層を下げる
この例では、S3 ライフサイクル設定を使用して、有効期間全体にわたってオブジェクトのストレージクラスの階層を下げます。層を下げると、ストレージコストを削減できます。料金に関する詳細については、「Amazon S3 の料金
次の S3 ライフサイクル設定では、キー名プレフィックス logs/
が付いたオブジェクトに適用されるルールを指定します。このルールは、次のアクションを指定します。
-
2 つの移行アクション:
-
作成されてから 30 日後にオブジェクトを S3 Standard – IA ストレージクラスに移行します。
-
作成されてから 90 日後にオブジェクトを S3 Glacier Flexible Retrieval ストレージクラスに移行します。
-
-
作成されてから 1 年後にオブジェクトを削除するよう Amazon S3 に指示する 1 つの失効アクション。
<LifecycleConfiguration> <Rule> <ID>example-id</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>30</Days> <StorageClass>STANDARD_IA</StorageClass> </Transition> <Transition> <Days>90</Days> <StorageClass>GLACIER</StorageClass> </Transition> <Expiration> <Days>365</Days> </Expiration> </Rule> </LifecycleConfiguration>
注記
すべてのアクションがオブジェクトの同じセットに適用される場合 (フィルターによって識別)、すべての S3 ライフサイクルアクションを記述する 1 つのルールを使用できます。それ以外の場合、それぞれが異なるフィルタを指定する複数のルールを追加できます。
重要
S3 ライフサイクル設定に複数のルールがある場合、1 つのオブジェクトが同じ日に複数の S3 ライフサイクルアクションの対象になることがあります。このような場合、Amazon S3 は以下の一般的なルールに従います。
-
完全な削除は、移行より優先されます。
-
移行は、削除マーカーの作成より優先されます。
-
オブジェクトが S3 Glacier Flexible Retrieval と S3 Standard-IA (または S3 One Zone-IA) 移行の両方の対象になる場合、Amazon S3 は S3 Glacier Flexible Retrieval 移行を選択します。
例については、「重複するフィルタ、競合するライフサイクルアクションの例」を参照してください。
複数のリソースの指定
オブジェクトごとに異なる S3 ライフサイクルアクションが必要な場合、複数のルールを指定できます。以下の S3 ライフサイクル設定には 2 つのルールがあります。
-
ルール 1 は、キー名プレフィックス
classA/
が付いたオブジェクトに適用されます。作成されてから 1 年後にオブジェクトを S3 Glacier Flexible Retrieval ストレージクラスに移行し、作成されてから 10 年後にそれらのオブジェクトを期限切れにするよう、Amazon S3 に指示します。 -
ルール 2 は、キー名プレフィックス
classB/
が付いたオブジェクトに適用されます。作成されてから 90 日後にオブジェクトを S3 Standard – IA ストレージクラスに移行し、作成されてから 1 年後に削除するよう Amazon S3 に指示します。
<LifecycleConfiguration> <Rule> <ID>ClassADocRule</ID> <Filter> <Prefix>classA/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>365</Days> <StorageClass>GLACIER</StorageClass> </Transition> <Expiration> <Days>3650</Days> </Expiration> </Rule> <Rule> <ID>ClassBDocRule</ID> <Filter> <Prefix>classB/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>90</Days> <StorageClass>STANDARD_IA</StorageClass> </Transition> <Expiration> <Days>365</Days> </Expiration> </Rule> </LifecycleConfiguration>
重要
S3 ライフサイクル設定に複数のルールがある場合、1 つのオブジェクトが同じ日に複数の S3 ライフサイクルアクションの対象になることがあります。このような場合、Amazon S3 は以下の一般的なルールに従います。
-
完全な削除は、移行より優先されます。
-
移行は、削除マーカーの作成より優先されます。
-
オブジェクトが S3 Glacier Flexible Retrieval と S3 Standard-IA (または S3 One Zone-IA) 移行の両方の対象になる場合、Amazon S3 は S3 Glacier Flexible Retrieval 移行を選択します。
例については、「重複するフィルタ、競合するライフサイクルアクションの例」を参照してください。
バージョニングが有効なバケットへのライフサイクルルールを指定する
バージョニングが有効なバケットがあるとします。つまり、各オブジェクトに、最新のバージョンと以前のバージョンが 0 個以上あります。(S3 バージョニングの詳細については、S3 バージョニングによる複数のバージョンのオブジェクトの保持 を参照してください。) この例では、1 年に相当する期間保持した後、以前のバージョンを削除するとします。S3 ライフサイクル設定では、任意のオブジェクトを 1~100 バージョンまで保持できます。
ストレージコストを節約するために、最新でないバージョンが最新でなくなってから 30 日後に、S3 Glacier Flexible Retrieval に移動する方法(これらの最新でないオブジェクトは、リアルタイムアクセスが必要ないコールドデータを想定しています)。また、最新のバージョンへのアクセス頻度は作成されてから 90 日後に低下すると予想されるため、これらのオブジェクトを S3 Standard-IA ストレージクラスに移動することもできます。
<LifecycleConfiguration> <Rule> <ID>sample-rule</ID> <Filter> <Prefix></Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>90</Days> <StorageClass>STANDARD_IA</StorageClass> </Transition> <NoncurrentVersionTransition> <NoncurrentDays>30</NoncurrentDays> <StorageClass>GLACIER</StorageClass> </NoncurrentVersionTransition> <NoncurrentVersionExpiration> <NewerNoncurrentVersions>5</NewerNoncurrentVersions> <NoncurrentDays>365</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>
バージョニングが有効なバケットで期限切れのオブジェクト削除マーカーを削除する
バージョニングが有効なバケットで、各オブジェクトに最新のバージョン 1 個と、最新でないバージョンが 0 個以上存在します。オブジェクトを削除するときは、次のことに注意してください。
-
削除リクエストでバージョン ID を指定しない場合、Amazon S3 はオブジェクトを削除する代わりに削除マーカーを追加します。現在のオブジェクトバージョンが最新でなくなり、削除マーカーが現在のバージョンになります。
-
削除リクエストでバージョン ID を指定した場合、Amazon S3 はそのオブジェクトバージョンを完全に削除します (削除マーカーは作成されません)。
-
最新でないバージョンが 0 の削除マーカーは、有効期限切れオブジェクト削除マーカー と呼ばれます。
この例では、バケットに期限切れオブジェクト削除マーカーを作成できるシナリオと、S3 ライフサイクル設定を使用して期限切れオブジェクト削除マーカーを削除するよう Amazon S3 に指示する方法を示します。
以下に示すように、最新でないバージョンがそのようになってから 30 日後に削除する NoncurrentVersionExpiration
アクションを使用し、最大 10 個を保持する S3 ライフサイクル設定を記述するとします。
<LifecycleConfiguration> <Rule> ... <NoncurrentVersionExpiration> <NewerNoncurrentVersions>10</NewerNoncurrentVersions> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>
NoncurrentVersionExpiration
アクションは、現在のオブジェクトバージョンには適用されません。最新以外のバージョンのみ削除されます。
現在のオブジェクトバージョンの場合、現在のオブジェクトバージョンが明確に定義されたライフサイクルに従うかどうかに応じて存続期間を管理する以下のオプションがあります。
-
現在のオブジェクトバージョンが明確に定義されたライフサイクルに従う。
この場合、次の例に示すように、現在のバージョンを削除するよう Amazon S3 に指示する
Expiration
アクションを含む S3 ライフサイクル設定を使用できます。<LifecycleConfiguration> <Rule> ... <Expiration> <Days>60</Days> </Expiration> <NoncurrentVersionExpiration> <NewerNoncurrentVersions>10</NewerNoncurrentVersions> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>
この例では、Amazon S3 は、現在の各オブジェクトバージョンに削除マーカーを追加することで、作成から 60 日後に現在のバージョンを削除します。このプロセスにより、現在のバージョンが最新でなくなり、削除マーカーが現在のバージョンになります。詳細については、「S3 バージョニングによる複数のバージョンのオブジェクトの保持」を参照してください。
注記
同じルールに
Days
とExpiredObjectDeleteMarker
のタグの両方を指定することはできません。Amazon S3は削除マーカーが経過機関の基準を満たすと、Days
タグを指定することで、自動的にExpiredObjectDeleteMarker
クリーンアップを実行します。削除マーカーが唯一のバージョンになったらすぐにクリーンアップできるよう、ExpiredObjectDeleteMarker
タグだけを含む別のルールを作成します。同じ S3 ライフサイクル設定の
NoncurrentVersionExpiration
アクションは、最新でないオブジェクトが最新でなくなってから 30 日後に削除します。したがって、この例では、すべてのオブジェクトバージョンがオブジェクトの作成から 90 日後に完全に削除されます。この過程で期限切れのオブジェクト削除マーカーが作成されますが、Amazon S3 が検知して削除します。 -
現在のオブジェクトバージョンに明確に定義されたライフサイクルがない。
この場合、必要でない場合はオブジェクトを削除できます。このとき、1 つ以上の最新でないバージョンとともに削除マーカーが作成されます。
NoncurrentVersionExpiration
アクションを含む S3 ライフサイクル設定が最新でないすべてのバージョンを削除した場合、期限切れオブジェクト削除マーカーが生成されます。特にこのシナリオのために、S3 ライフサイクル設定には、期限切れオブジェクト削除マーカーを削除するために使用できる
Expiration
アクションを提供します。<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Expiration> <ExpiredObjectDeleteMarker>true</ExpiredObjectDeleteMarker> </Expiration> <NoncurrentVersionExpiration> <NewerNoncurrentVersions>10</NewerNoncurrentVersions> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>
ExpiredObjectDeleteMarker
アクションで true
要素を Expiration
に設定することで、期限切れオブジェクト削除マーカーを削除するよう Amazon S3 に指示できます。
注記
ExpiredObjectDeleteMarker
S3 ライフサイクルアクションを指定するときは、ルールではタグベースのフィルターを指定できません。
マルチパートアップロードを中止するライフサイクル設定
Amazon S3 マルチパートアップロード REST API オペレーションを使用すると、大容量オブジェクトをいくつかに分けてアップロードできます。マルチパートアップロードの詳細については、「マルチパートアップロードを使用したオブジェクトのアップロードとコピー」を参照してください。
S3 ライフサイクル設定を使用すると、不完全なマルチパートアップロード (ルールで指定したキー名プレフィックスで特定) が開始後指定した日数以内に完了しない場合、アップロードを停止するように Amazon S3 に指示できます。Amazon S3 は、マルチパートアップロードを中止するとき、マルチパートアップロードに関連付けられているすべてのパートを削除します。このプロセスでは、Amazon S3 に保存されているパートを含む不完全なマルチパートアップロードがないことが保証されるので、ストレージコストを制御するのに役立ちます。
注記
AbortIncompleteMultipartUpload
S3 ライフサイクルアクションを指定するときは、ルールではタグベースのフィルターを指定できません。
AbortIncompleteMultipartUpload
アクションにルールを指定する S3 ライフサイクル設定の例を次に示します。このアクションは、開始されたから 7 日後に不完全なマルチパートアップロードを停止するように Amazon S3 に指示します。
<LifecycleConfiguration> <Rule> <ID>sample-rule</ID> <Filter> <Prefix>
SomeKeyPrefix
/</Prefix> </Filter> <Status>rule-status
</Status> <AbortIncompleteMultipartUpload> <DaysAfterInitiation>7</DaysAfterInitiation> </AbortIncompleteMultipartUpload> </Rule> </LifecycleConfiguration>
データがない旧オブジェクトの有効期限
オブジェクトのサイズのみに基づいてオブジェクトを移行するルールを作成できます。オブジェクトのサイズは、最小 (ObjectSizeGreaterThan
) または最大 (ObjectSizeLessThan
) を指定することも、バイト数で範囲を指定することもできます。プレフィックスとサイズの規則のように、複数のフィルターを使用する場合は、フィルターを <And>
要素で囲む必要があります。
<LifecycleConfiguration> <Rule> <ID>Transition with a prefix and based on size</ID> <Filter> <And> <Prefix>tax/</Prefix> <ObjectSizeGreaterThan>500</ObjectSizeGreaterThan> </And> </Filter> <Status>Enabled</Status> <Transition> <Days>365</Days> <StorageClass>GLACIER</StorageClass> </Transition> </Rule> </LifecycleConfiguration>
ObjectSizeGreaterThan
と ObjectSizeLessThan
の両方の要素を使用して範囲を指定する場合、最大オブジェクトサイズは最小オブジェクトサイズより大きくなければなりません。複数のフィルターを使用する場合は、フィルターを <And>
要素で囲む必要があります。次の例は、500 バイトから 64,000 バイトの範囲でオブジェクトを指定する方法を示しています。範囲を指定する場合、ObjectSizeGreaterThan
フィルターと ObjectSizeLessThan
フィルターは指定された値を除外します。詳細については、「Filter 要素」を参照してください。
<LifecycleConfiguration> <Rule> ... <And> <ObjectSizeGreaterThan>500</ObjectSizeGreaterThan> <ObjectSizeLessThan>64000</ObjectSizeLessThan> </And> </Rule> </LifecycleConfiguration>
バージョニングが有効になっているバケットで作成された最新でない削除マーカーオブジェクトなど、データがなく、最新でないオブジェクトに限り期限切れにするルールを作成することもできます。NoncurrentVersionExpiration
アクションを使用して、最新でないバージョンが最新のバージョンでなくなってから 30 日後に削除し、オブジェクトの最新でないバージョンの保持を最大 10 個にする例は、次のとおりです。また、ObjectSizeLessThan
エレメントを使用してデータのないオブジェクトのみをフィルタリングします。
<LifecycleConfiguration> <Rule> <ID>Expire noncurrent with size less than 1 byte</ID> <Filter> <ObjectSizeLessThan>1</ObjectSizeLessThan> </Filter> <Status>Enabled</Status> <NoncurrentVersionExpiration> <NewerNoncurrentVersions>10</NewerNoncurrentVersions> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>
例: 128 KB 未満のオブジェクトの移行を許可する
Amazon S3 はライフサイクル設定にデフォルトの動作を適用し、128 KB 未満のオブジェクトが任意のストレージクラスに移行されないようにします。最小サイズ (ObjectSizeGreaterThan
) または最大サイズ (ObjectSizeLessThan
) フィルターを追加して、小さいオブジェクトを移行することを許可できます。このフィルターでは、設定に小さいサイズを指定します。次の例では、128 KB 未満のオブジェクトを S3 Glacier Instant Retrieval ストレージクラスに移行します。
<LifecycleConfiguration> <Rule> <ID>Allow small object transitions</ID> <Filter> <ObjectSizeGreaterThan>1</ObjectSizeGreaterThan> </Filter> <Status>Enabled</Status> <Transition> <Days>365</Days> <StorageClass>GLACIER_IR</StorageClass> </Transition> </Rule> </LifecycleConfiguration>
注記
2024 年 9 月、Amazon S3 は小さなオブジェクトのデフォルトの移行動作を次のように更新しました。
デフォルトの移行動作の更新 — 2024 年 9 月以降、デフォルトの動作により、128 KB 未満のオブジェクトが任意のストレージクラスに移行されることを回避します。
以前のデフォルトの移行動作 — 2024 年 9 月以前は、デフォルトの動作により、128 KB 未満のオブジェクトは S3 Glacier および S3 Glacier Deep Archive ストレージクラスにのみ移行できました。
2024 年 9 月より前に作成された設定は、変更しない限り、以前の移行動作を保持します。つまり、ルールを作成、編集、または削除すると、設定のデフォルトの移行動作が更新された動作に変わります。ユースケースで必要な場合は、128KB 未満のオブジェクトが S3 Glacier および S3 Glacier Deep Archive に移行するように、デフォルトの移行動作を変更できます。これを行うには、PutBucketLifecycleConfiguration リクエストでオプションの x-amz-transition-object-size-minimum-default
ヘッダーを使用します。
次の例は、PutBucketLifecycleConfiguration リクエストで x-amz-transition-object-size-minimum-default
ヘッダーを使用して、varies_by_storage_class
デフォルトの移行動作をライフサイクル設定に適用する方法を示しています。この動作により、128 KB 未満のオブジェクトを S3 Glacier または S3 Glacier Deep Archive ストレージクラスに移行できます。デフォルトでは、他のすべてのストレージクラスは 128 KB 未満の移行を回避します。カスタムフィルターを使用して、任意のストレージクラスの最小移行サイズを変更できます。カスタムフィルターは常にデフォルトの移行動作よりも優先されます。
HTTP/1.1 200 x-amz-transition-object-size-minimum-default: varies_by_storage_class <?xml version="1.0" encoding="UTF-8"?> ...