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

ライフサイクル設定の例

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

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

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

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

    このルールは、Amazon S3 に以下のことを命じる 2 つのアクションを指定します。

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

    • 作成から 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>S3 Glacier</StorageClass> </Transition> <Expiration> <Days>3650</Days> </Expiration> </Rule> </LifecycleConfiguration>

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

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

    <LifecycleConfiguration> <Rule> <ID>Archive all object same-day upon creation</ID> <Filter> <Prefix></Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>0</Days> <StorageClass>S3 Glacier</StorageClass> </Transition> </Rule> </LifecycleConfiguration>
  • フィルタ内にゼロまたは 1 個のキー名のプレフィックスと 0 個以上のオブジェクトタグを指定できます。以下のコード例では、キープレフィックスが tax/ のオブジェクトのサブセットと、指定したキーと値の 2 つのタグを含むオブジェクトに、ライフサイクルルールを適用しています。複数のフィルターを指定するときは、次に示すように 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> ...

  • オブジェクトのフィルタはタグに基づいてのみ行うことができます。たとえば、以下のライフサイクルルールは、2 つのタグが指定されている (プレフィックスは指定されていない) オブジェクトに適用されます。

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

重要

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

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

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

  • オブジェクトが S3 Glacier 移行と S3 標準 – IA 移行 (または S3 1 ゾーン – IA 移行) の両方の対象になる場合、Amazon S3 は S3 Glacier の移行を選択します。

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

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

ライフサイクルルールは一時的に無効にできます。以下のライフサイクル設定では、2 つのルールを指定しています。

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

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

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

<LifecycleConfiguration> <Rule> <ID>Rule1</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>0</Days> <StorageClass>S3 Glacier</StorageClass> </Transition> </Rule> <Rule> <ID>Rule2</ID> <Prefix>documents/</Prefix> <Status>Disabled</Status> <Transition> <Days>0</Days> <StorageClass>S3 Glacier</StorageClass> </Transition> </Rule> </LifecycleConfiguration>

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

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

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

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

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

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

  • 作成されてから 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>
注記

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

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

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

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

  • ルール 2 は、キー名プレフィックス classB/ が付いたオブジェクトに適用されます。作成されてから 90 日後にオブジェクトを S3 標準 – 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>

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

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

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

同様に、2 つの移行ポリシーが重複している場合は、S3 ライフサイクルによってオブジェクトが低コストのストレージクラスに移行されます。いずれの場合でも、S3 ライフサイクルによって、最も安価なパスが選択されます。この一般的なルールの例外として、S3 Intelligent-Tiering ストレージクラスの場合があります。S3 Intelligent-Tiering は、S3 Glacier および S3 Glacier Deep Archive ストレージクラスを除くどのストレージクラスよりも S3 ライフサイクルで優先されます。

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

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

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

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

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

ルール 1 では、すべてのオブジェクトを作成後 1 年で削除するように Amazon S3 にリクエストします。ルール 2 では、オブジェクトのサブセットを作成後 30 日で S3 標準 – 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>

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

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

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

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

  • 1 つのルールは、オブジェクトを S3 標準 – 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/ のオブジェクトのサブセットには、両方のルールのライフサイクルアクションが適用されます。片方のルールは作成されてから 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 ストレージクラスに移行するよう Amazon S3 に指示します。

  • ルール 2 では、タグベースのフィルタ (tag2/value2) が指定されています。このルールは、作成されてから 14 日後にオブジェクトを期限切れにするよう Amazon 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>value1</Value> </Tag> </Filter> <Status>Enabled</Status> <Expiration> <Days>14</Days> </Expiration> </Rule> </LifecycleConfiguration>

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

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

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

さらに、最新のバージョンでなくなってから 30 日後に以前のバージョンを S3 Glacier に移動することで、ストレージコストを節約します (リアルタイムアクセスが必要でないコールドデータを想定しています)。加えて、最新のバージョンへのアクセス頻度は作成されてから 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>S3 Glacier</StorageClass> </NoncurrentVersionTransition> <NoncurrentVersionExpiration> <NoncurrentDays>365</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

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

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

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

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

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

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

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

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

NoncurrentVersionExpiration アクションは、現在のオブジェクトバージョンには適用されません。最新以外のバージョンのみ削除されます。

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

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

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

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

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

    注記

    同じルールに DaysExpiredObjectDeleteMarker のタグの両方を指定することはできません。削除マーカーが経過期間の基準を満たすと、Days タグを指定することで ExpiredObjectDeleteMarker クリーンアップが自動的に実行されます。削除マーカーが唯一のバージョンになったらすぐにクリーンアップできるよう、ExpiredObjectDeleteMarker タグのみを含む別のルールを作成できます。

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

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

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

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

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

ExpiredObjectDeleteMarker アクションで Expiration 要素を true に設定することで、期限切れオブジェクト削除マーカーを削除するよう Amazon S3 に指示できます。

注記

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

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

マルチパートアップロード API を使用すると、大容量オブジェクトをいくつかに分けてアップロードできます。マルチパートアップロードの詳細については、「マルチパートアップロードを使用したオブジェクトのアップロードとコピー」を参照してください。

S3 ライフサイクル設定を使用すると、開始してから指定の日数以内に完了しなかった不完全なマルチパートアップロード (ルールで指定されているキー名プレフィックスによって識別されます) を停止するよう、Amazon S3 に指示できます。Amazon S3 は、マルチパートアップロードを中止するとき、マルチパートアップロードに関連付けられているすべてのパートを削除します。これにより、Amazon S3 に格納されているパートを含む不完全なマルチパートアップロードが存在しないことが保証されるので、そのようなパートのストレージコストを支払う必要はありません。

注記

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

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>