S3 ライフサイクル設定の例 - Amazon Simple Storage Service

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

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

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

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

  • この S3 ライフサイクル設定ルールでは、フィルターはキープレフィックス (tax/) を指定しています。したがって、ルールは、キー名プレフィックスが tax/ のオブジェクト (tax/doc1.txttax/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>

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

  • バケット内のすべてのオブジェクトに 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 移行を選択します。

例については、「例 5: 重複するフィルター、競合するライフサイクルアクション、Amazon S3 がバージョン管理されていないバケットに対して行うこと」を参照してください。

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

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>

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

この例では、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 移行を選択します。

例については、「例 5: 重複するフィルター、競合するライフサイクルアクション、Amazon S3 がバージョン管理されていないバケットに対して行うこと」を参照してください。

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

オブジェクトごとに異なる 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 移行を選択します。

例については、「例 5: 重複するフィルター、競合するライフサイクルアクション、Amazon S3 がバージョン管理されていないバケットに対して行うこと」を参照してください。

例 5: 重複するフィルター、競合するライフサイクルアクション、Amazon S3 がバージョン管理されていないバケットに対して行うこと

重複するプレフィックスまたはアクションを指定する S3 ライフサイクル設定を指定する場合があります。

一般的に、S3 ライフサイクルはコストに合わせて最適化されます。たとえば、2 つの有効期限ポリシーが重複している場合は、短い有効期限ポリシーが適用されるため、データが予想よりも長く保存されることはありません。同様に、2 つの移行ポリシーが重複している場合は、S3 ライフサイクルによってオブジェクトが低コストのストレージクラスに移行されます。

いずれの場合でも、S3 ライフサイクルによって、最も安価なパスが選択されます。この一般的なルールの例外として、S3 Intelligent-Tiering ストレージクラスの場合があります。S3 Intelligent-Tiering は、S3 Glacier Flexible Retrieval および S3 Glacier Deep Archive ストレージクラスを除くどのストレージクラスよりも S3 ライフサイクルで優先されます。

次の例では、競合の可能性を Amazon S3 でどのように解決するかを示します。

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

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

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

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

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

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

この場合、競合は発生しないため、Amazon S3 は作成から 30 日後に logs/ プレフィックスを持つオブジェクトを S3 標準 – IA ストレージクラスへ移行させます。オブジェクトの作成後 1 年に達すると、そのオブジェクトは削除されます。

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

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

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

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

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

<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/ のオブジェクトのサブセットには、両方のルールの S3 ライフサイクルアクションが適用されます。片方のルールは作成されてから 10 日後にオブジェクトを移行するよう Amazon S3 に指示しており、もう一方のルールは作成されてから 365 日後にオブジェクトを移行するよう Amazon S3 に指示しています。

<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 つのルールを含む次のような S3 ライフサイクル設定があるものとします。

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

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

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

<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>value2</Value> </Tag> </Filter> <Status>Enabled</Status> <Expiration> <Days>14</Days> </Expiration> </Rule> </LifecycleConfiguration>

オブジェクトに両方のタグがある場合、Amazon S3 はどのルールに従うかを決定する必要があります。この場合、Amazon S3 は作成されてから 14 日後にオブジェクトを期限切れにします。オブジェクトは削除されるため、移行アクションは行われません。

重要

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

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

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

  • オブジェクトが S3 Glacier Flexible Retrieval と S3 Standard-IA (または S3 One Zone-IA) 移行の両方の対象になる場合、Amazon S3 は S3 Glacier Flexible Retrieval 移行を選択します。

例については、「例 5: 重複するフィルター、競合するライフサイクルアクション、Amazon S3 がバージョン管理されていないバケットに対して行うこと」を参照してください。

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

バージョニングが有効なバケットがあるとします。つまり、各オブジェクトに、最新のバージョンと以前のバージョンが 0 個以上あります。(S3 バージョニングの詳細については、S3 バケットでのバージョニングの使用 を参照してください。) この例では、1 年に相当する期間保持した後、以前のバージョンを削除するとします。S3 ライフサイクルの設定では、任意のオブジェクトを 1~100 バージョンまで保持できます。

ストレージコストを節約するために、最新でないバージョンが最新でなくなってから 30 日後に、S3 Glacier Flexible Retrieval に移動する方法(これらの最新でないオブジェクトは、リアルタイムアクセスが必要ないコールドデータを想定しています)。最新のバージョンへのアクセス頻度は作成されてから 90 日後に低下することが予想されるため、これらのオブジェクトを S3 標準 – 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>

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

バージョニングが有効なバケットで、各オブジェクトに最新のバージョン 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 バケットでのバージョニングの使用」を参照してください。

    注記

    同じルールに DaysExpiredObjectDeleteMarker のタグの両方を指定することはできません。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 ライフサイクルアクションを指定するときは、ルールではタグベースのフィルターを指定できません。

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

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>

例 9: サイズベースのルールを使用したライフサイクル設定

オブジェクトのサイズのみに基づいてオブジェクトを移行するルールを作成できます。オブジェクトのサイズは、最小 (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>

ObjectSizeGreaterThanObjectSizeLessThan の両方の要素を使用して範囲を指定する場合、最大オブジェクトサイズは最小オブジェクトサイズより大きくなければなりません。複数のフィルターを使用する場合は、フィルターを <And> 要素で囲む必要があります。次の例は、500 バイトから 64000 バイトの範囲のオブジェクトを指定する方法を示しています。

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