メニュー
Amazon Simple Storage Service
開発者ガイド (API Version 2006-03-01)

ライフサイクル設定の例

このセクションでは、ライフサイクル設定の例を示します。それぞれの例では、各サンプルシナリオで XML をどのように指定するかを示します。

例 1: フィルタを指定する

各ライフサイクルルールには、ライフサイクルルール適用先バケット内のオブジェクトのサブセットを識別するのに使用できるフィルタが含まれます。次のライフサイクル設定は、フィルタを指定する方法の例です。

  • このライフサイクル設定ルールでは、フィルタはキープレフィックス (tax/) を指定しています。したがって、ルールは、キー名プレフィックス tax/ を持つオブジェクトに適用されます (tax/doc1.txttax/doc2.txt など)。

    このルールは、Amazon S3 に次のことを行うようリクエストする 2 つのアクションを指定します。

    • 作成から 365 日 (1 年) 後にオブジェクトを GLACIER ストレージクラスに移行する。

    • 作成から 3650 日(10 年後)にオブジェクトを削除する(Expiration アクション)。

    Copy
    <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>

    作成後の日数でオブジェクトの経過時間を指定する代わりに、各アクションの日付を指定できます。ただし、DateDays の両方を同じルールで使用することはできません。

  • バケット内のすべてのオブジェクトにライフサイクルルールを適用する場合は、空のプレフィックスを指定します。次の設定では、このルールは、作成後 0 日でオブジェクトを GLACIER ストレージクラスに移行することを Amazon S3 に指示する Transition アクションを指定します。この場合、オブジェクトは作成後の午前 0 時 (UTC) に Amazon Glacier へのアーカイブ対象となります。

    Copy
    <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 つのタグを含むオブジェクトに、ライフサイクルルールを適用しています。複数のフィルタを指定するときは、次に示すように AND を含める必要があることに注意してください (Amazon S3 は、論理 AND を適用して指定されたフィルタ条件を結合します)。

    Copy
    ... <Filter> <And> <Prefix>tax/</Prefix> <Tag> <Key>key1</Key> <Value>value1</Value> </Tag> <Tag> <Key>key2</Key> <Value>value2</Value> </Tag> </And> </Filter> ...
  • オブジェクトのフィルタはタグに基づいてのみ行うことができます。たとえば、次のライフサイクルルールは、指定した 2 つのタグを含むオブジェクトに適用されます (プレフィックスは指定されていません)。

    Copy
    ... <Filter> <And> <Tag> <Key>key1</Key> <Value>value1</Value> </Tag> <Tag> <Key>key2</Key> <Value>value2</Value> </Tag> </And> </Filter> ...

重要

ライフサイクル設定に複数のルールがある場合、1 つのオブジェクトが複数のライフサイクルアクションの対象になることがあります。そのような場合に Amazon S3 が従う一般的なルールは次のとおりです。

  • 完全な削除は、移行より優先されます。

  • 移行は、削除マーカーの作成より優先されます。

  • オブジェクトが GLACIER 移行と STANDARD_IA 移行の両方の対象になる場合、Amazon S3 は GLACIER 移行を選択します。

例については、「例 5: 重複するフィルタ、競合するライフサイクルアクション、Amazon S3 の動作 」を参照してください。

例 2: ライフサイクルルールを無効にする

ライフサイクルルールは、一時的に無効にできます。次のライフサイクル設定では、2 つのルールが指定されています。

  • ルール 1 は、logs/ プレフィックスを持つオブジェクトを作成直後に GLACIER ストレージクラスに移行するよう、Amazon S3 に指示します。

  • ルール 2 は、documents/ プレフィックスを持つオブジェクトを作成直後に GLACIER ストレージクラスに移行するよう、Amazon S3 に指示します。

ポリシーでは、ルール 1 は有効で、ルール 2 は無効です。Amazon S3 は、無効なルールに対してアクションを実行しません。

Copy
<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> <Prefix>documents/</Prefix> <Status>Disabled</Status> <Transition> <Days>0</Days> <StorageClass>GLACIER</StorageClass> </Transition> </Rule> </LifecycleConfiguration>

例 3: オブジェクトの有効期間全体にわたってストレージクラスの層を下げる

この例では、ライフサイクル設定を利用して、有効期間全体にわたってオブジェクトのストレージクラスの層を下げます。このように層を下げると、ストレージコストを削減できます。料金の詳細については、「Amazon S3 料金表」を参照してください。

次のライフサイクル設定では、キー名プレフィックス logs/ が付いたオブジェクトに適用されるルールを指定します。このルールは、次のアクションを指定します。

  • 2 つの移行アクション:

    • 作成されてから 30 日後にオブジェクトを STANDARD_IA ストレージクラスに移行します。

    • 作成されてから 90 日後にオブジェクトを GLACIER ストレージクラスに移行します。

  • 作成されてから 1 年後にオブジェクトを削除するよう Amazon S3 に指示する 1 つの有効期間アクション。

Copy
<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>

注記

すべてのアクションがオブジェクトの同じセットに適用される場合 (フィルタによって識別)、すべてのライフサイクルアクションを記述する 1 つのルールを使用できます。それ以外の場合、それぞれが異なるフィルタを指定する複数のルールを追加できます。

例 4: 複数のルールを指定する

オブジェクトごとに異なるライフサイクルアクションが必要な場合、複数のルールを指定できます。次のライフサイクル設定には 2 つのルールがあります。

  • ルール 1 は、キー名プレフィックス classA/ が付いたオブジェクトに適用されます。作成されてから 1 年後にオブジェクトを GLACIER ストレージクラスに移行し、作成されてから 10 年後にそれらのオブジェクトを期限切れにするよう、Amazon S3 に指示します。

  • ルール 2 は、キー名プレフィックス classB/ が付いたオブジェクトに適用されます。作成されてから 90 日後にオブジェクトを STANDARD_IA ストレージクラスに移行し、作成されてから 1 年後に削除するよう Amazon S3 に指示します。

Copy
<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>

例 5: 重複するフィルタ、競合するライフサイクルアクション、Amazon S3 の動作

重複するプレフィックスまたはアクションを指定するライフサイクル設定を指定する場合があります。次の例では、競合の可能性を解決するために Amazon S3 どのように選択するかを示します。

例 1: 重複するプレフィックス (競合なし)

以下の設定例には、次のように重複するプレフィックスを指定する 2 つのルールがあります。

  • 1 番目のルールは、空のフィルタを指定することで、バケット内のすべてのオブジェクトを示しています。

  • 2 番目のルールは、キー名プレフィックス logs/ を指定することで、オブジェクトのサブセットのみを示しています。

ルール 1 は、作成されてから 1 年後にすべてのオブジェクトを削除するよう、Amazon S3 にリクエストします。ルール 2 は、作成されてから 30 日後にオブジェクトのサブセットを STANDARD_IA ストレージクラスに移行するよう、Amazon S3 にリクエストします。

Copy
<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> </Filter> <Status>Enabled</Status> <Expiration> <Days>365</Days> </Expiration> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>30</Days> </Transition> </Rule> </LifecycleConfiguration>

例 2: 競合するライフサイクルアクション

この設定例には、オブジェクトの有効期間内の同じ時点で同じオブジェクトセットに対して 2 つの異なるアクションを実行するよう Amazon S3 に指示する 2 つのルールがあります。

  • 両方のルールで同じキー名プレフィックスが指定されているので、どちらのルールも同じオブジェクトのセットに適用されます。

  • どちらのルールでも、オブジェクトが作成されてから同じ 365 日後にルールを適用するように指定されています。

  • 1 つのルールは、オブジェクトを STANDARD_IA ストレージクラスに移行するよう Amazon S3 に指示しています。もう 1 つのルールは、同じタイミングでオブジェクトを有効期限切れにするよう Amazon S3 に指示しています。

Copy
<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Expiration> <Days>365</Days> </Expiration> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>365</Days> </Transition> </Rule> </LifecycleConfiguration>

この場合、ユーザーはオブジェクトを期限切れに (削除) するよう望んでおり、ストレージクラスを変更しても意味がないので、Amazon S3 は単純にこれらのオブジェクトに対して有効期限切れアクションを選択します。

例 3: ライフサイクルアクションが競合する重複したプレフィックス

この例の設定には、次のように重複するプレフィックスを指定する 2 つのルールがあります。

  • ルール 1 では、空のプレフィックス (すべてのオブジェクトを示します) が指定されています。

  • ルール 2 では、すべてのオブジェクトのサブセットを識別するキー名プレフィックス (logs/) が指定されています。

キー名プレフィックス logs/ が付いたオブジェクトのサブセットには、両方のルールのライフサイクルアクションが適用されます。一方のルールは作成されてから 10 日後にオブジェクトを移行するよう Amazon S3 に指示しており、もう一方のルールは作成されてから 365 日後にオブジェクトを移行するよう Amazon S3 に指示しています。

Copy
<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix></Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>10</Days> </Transition> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>365</Days> </Transition> </Rule> </LifecycleConfiguration>

この場合、Amazon S3 は作成後 10 日での移行を選択します。

例 4: タグベースのフィルタ処理の結果によるライフサイクルアクションの競合

それぞれがタグフィルタを指定する 2 つのルールを含む次のようなライフサイクルポリシーがあるものとします。

  • ルール 1 では、タグベースのフィルタ (tag1/value1) が指定されています。このルールは、作成されてから 365 日後にオブジェクトを GLACIER ストレージクラスに移行するよう Amazon S3 に指示します。

  • ルール 2 では、タグベースのフィルタ (tag2/value2) が指定されています。このルールは、作成されてから 14 日後にオブジェクトを期限切れにするよう Amazon S3 に指示します。

ライフサイクル設定は次のようになります。

Copy
<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Tag> <Key>tag1</Key> <Value>value1</Value> </Tag> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>GLACIER<StorageClass> <Days>365</Days> </Transition> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Tag> <Key>tag2</Key> <Value>value1</Value> </Tag> </Filter> <Status>Enabled</Status> <Expiration> <Days>14</Days> </Expiration> </Rule> </LifecycleConfiguration>

ポリシーに問題はありませんが、両方のタグを持つオブジェクトがある場合、S3 はどうするか決める必要があります。つまり、両方のルールが 1 つのオブジェクトに適用されると、事実上、競合するアクションを実行するよう Amazon S3 に指示することになります。この場合、Amazon S3 は作成されてから 14 日後にオブジェクトを期限切れにします。オブジェクトは削除されるため、移行アクションは行われません。

例 6: バージョニングが有効なバケットへのライフサイクルルールの指定

バージョニングが有効なバケットがあるとします。つまり、各オブジェクトに、最新のバージョンと以前のバージョンが 0 個以上あります。1 年に相当する期間保持した後、以前のバージョンを削除するとします。バージョニングの詳細については、「オブジェクトのバージョニング」を参照してください。

さらに、最新のバージョンでなくなってから 30 日後に以前のバージョンを GLACIER に移動することで、ストレージコストを作成しようとしています (リアルタイムアクセスが必要でないコールドデータを想定しています)。加えて、最新のバージョンへのアクセス頻度は作成されてから 90 日後に低下することが予想されるため、これらのオブジェクトを STANDARD_IA ストレージクラスに移動することも選択できます。

Copy
<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> <NoncurrentDays>365</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

例 7: 期限切れオブジェクト削除マーカーの削除

バージョニングが有効なバケットで、各オブジェクトに最新のバージョン 1 個と、最新でないバージョンが 1 個以上存在します。オブジェクトを削除するときは、次のことに注意してください。

  • 削除リクエストでバージョン ID を指定しない場合、Amazon S3 はオブジェクトを削除する代わりに削除マーカーを追加します。現在のオブジェクトバージョンが最新でなくなり、削除マーカーが現在のバージョンになります。

  • 削除リクエストでバージョン ID を指定した場合、Amazon S3 はそのオブジェクトバージョンを完全に削除します (削除マーカーは作成されません)。

  • 最新でないバージョンが 0 の削除マーカーは、期限切れオブジェクト削除マーカーと呼ばれます。

この例では、バケットに期限切れオブジェクト削除マーカーを作成できるシナリオと、ライフサイクル設定を使用して期限切れオブジェクト削除マーカーを削除するよう Amazon S3 に指示する方法を示します。

次に示すように、最新でないバージョンが最新でなくなってから 30 日後に削除する NoncurrentVersionExpiration アクションを指定するライフサイクルポリシーを記述するとします。

Copy
<LifecycleConfiguration> <Rule> ... <NoncurrentVersionExpiration> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

NoncurrentVersionExpiration アクションは、現在のオブジェクトバージョンには適用されず、最新でないバージョンのみ削除する点に注意してください。

現在のオブジェクトバージョンの場合、現在のオブジェクトバージョンが明確に定義されたライフサイクルに従うかどうかに応じて存続期間を管理する次のオプションがあります。

  • 現在のオブジェクトバージョンが明確に定義されたライフサイクルに従う。

    この場合、次の例に示すように、現在のバージョンを削除するよう Amazon S3 に指示する Expiration アクションを含むライフサイクルポリシーを使用できます。

    Copy
    <LifecycleConfiguration> <Rule> ... <Expiration> <Days>60</Days> </Expiration> <NoncurrentVersionExpiration> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

    Amazon S3 は、現在の各オブジェクトバージョンに削除マーカーを追加することで、作成から 60 日後に現在のバージョンを削除します。これにより、現在のバージョンが最新でなくなり、削除マーカーが現在のバージョンになります。詳細については、「バージョニングの使用」を参照してください。

    同じライフサイクル設定の NoncurrentVersionExpiration アクションは、最新でないオブジェクトが最新でなくなってから 30 日後に削除します。したがって、すべてのオブジェクトバージョンが削除され、期限切れオブジェクト削除マーカーが生成されますが、Amazon S3 は期限切れオブジェクト削除マーカーを自動的に検出して削除します。

  • 現在のオブジェクトバージョンに明確に定義されたライフサイクルがない。

    この場合、必要でない場合はオブジェクトを削除できます。このとき、1 つ以上の最新でないバージョンとともに削除マーカーが作成されます。NoncurrentVersionExpiration アクションを含むライフサイクル設定が最新でないすべてのバージョンを削除した場合、期限切れオブジェクト削除マーカーが生成されます。

    特にこのシナリオでは、Amazon S3 のライフサイクル設定には Expiration アクションが含まれており、このアクションを使用すると、期限切れオブジェクト削除マーカーを削除するよう Amazon S3 にリクエストできます。

    Copy
    <LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Expiration> <ExpiredObjectDeleteMarker>true</ExpiredObjectDeleteMarker> </Expiration> <NoncurrentVersionExpiration> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

Expiration アクションで ExpiredObjectDeleteMarker 要素を true に設定することで、期限切れオブジェクト削除マーカーを削除するよう Amazon S3 に指示できます。Amazon S3 は、オブジェクトの失効後 48 時間経過するとすぐに、失効したオブジェクト削除マーカーを削除します。

注記

ExpiredObjectDeleteMarker ライフサイクルアクションを指定するときは、ルールではタグベースのフィルタを指定できません。

例 8: マルチパートアップロードを中止するライフサイクル設定

マルチパートアップロード API を使用すると、大容量オブジェクトをいくつかに分けてアップロードできます。マルチパートアップロードの詳細については、「マルチパートアップロードの概要」を参照してください。ライフサイクル設定を使用すると、開始してから指定されている日数以内に完了しなかった不完全なマルチパートアップロード (ルールで指定されているキー名プレフィックスによって識別されます) を中止するよう、Amazon S3 に指示できます。Amazon S3 は、マルチパートアップロードを中止するとき、マルチパートアップロードに関連付けられているすべてのパートを削除します。これにより、Amazon S3 に格納されているパートを含む不完全なマルチパートアップロードが存在しないことが保証されるので、そのようなパートのストレージコストを支払う必要はありません。AbortIncompleteMultipartUpload アクションにルールを指定するライフサイクル設定の例を次に示します。このアクションは、開始されてから 7 日後に不完全なマルチパートアップロードを中止するよう、Amazon S3 にリクエストします。

Copy
<LifecycleConfiguration> <Rule> <ID>sample-rule</ID> <Filter> <Prefix>SomeKeyPrefix/</Prefix> </Filter> <Status>rule-status</Status> <AbortIncompleteMultipartUpload> <DaysAfterInitiation>7</DaysAfterInitiation> </AbortIncompleteMultipartUpload> </Rule> </LifecycleConfiguration>

注記

AbortIncompleteMultipartUpload ライフサイクルアクションを指定するときは、ルールではタグベースのフィルタを指定できません。