Lifecycle configuration examples

Single filter condition

Each lifecycle rule contains at least one filter condition. A filter condition determines the objects in a bucket to which the rule applies. The following examples show how to specify filter conditions in a lifecycle rule.

Example 1: Transition and delete objects with a specific prefix after a specified number of days

In this lifecycle rule, the filter condition specifies the prefix doc/. This rule applies to objects with the prefix doc/, such as doc/test1.txt and doc/test2.jpg. The rule transitions the objects to the Infrequent Access (IA) storage class 180 days after their last modified time and deletes them 365 days after their last modified time.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix>doc/</Prefix>
      <Status>Enabled</Status>    
      <Transition>
        <Days>180</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
      <Expiration>
        <Days>365</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  Console configuration parameters for the lifecycle rule:

  • Status: Enabled

  • Policy: Match by prefix, prefix: doc/

  • File time policy: Number of days

  • Rule 1: Data is automatically transitioned to Infrequent Access (IA) 180 days after the last modified time

  • Rule 2: Data is deleted 365 days after the last modified time (deleted data cannot be recovered)

  • Fragment expiration policy: Disabled

Example 2: Delete all objects in a bucket after a specified number of days

This lifecycle rule applies to all objects in a bucket and expires them 300 days after their last modified time.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <Days>300</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  Key configuration items for the lifecycle rule in the console:

  • Status: Enabled

  • Policy: Applied to the entire bucket

  • File time policy: Number of days

  • Lifecycle management rule: Data is automatically deleted 300 days after the last modified time (deleted data cannot be recovered)

  • Fragment expiration policy: Disabled

Example 3: Delete all objects in a bucket after a specified date

This lifecycle rule applies to all objects in a bucket (the prefix is empty). The rule expires all objects that were last modified before December 30, 2023.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <CreatedBeforeDate>2023-12-30T00:00:00.000Z</CreatedBeforeDate>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  Specific configuration parameters for the lifecycle rule:

  • Status: Select Enabled

  • Policy: Select Applied to the entire bucket

  • File time policy: Select Specific date. Set the lifecycle management rule to apply to objects whose last modified time is before December 30, 2023

  • Data processing: Select Data deletion (deleted data cannot be recovered)

  • Fragment expiration policy: Select Disabled

Overlapping filter conditions

The following examples describe how conflicts between lifecycle actions are handled when filter conditions overlap.

Example 1: Lifecycle actions based on overlapping prefixes (no conflict)

Result: The rules do not conflict. The actions specified in both Rule 1 and Rule 2 take effect.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix>test/</Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>30</Days>
        <StorageClass>Archive</StorageClass>
      </Transition>
    </Rule>
   <Rule>
      <ID>test-rule2</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <Days>365</Days>
      </Expiration>
    </Rule>  
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  • Rule 1

    Lifecycle rule configuration for Rule 1:

    • Status: Enabled

    • Policy: Match by prefix, prefix: test/

    • File time policy: Number of days. Data is automatically transitioned to Archive storage class 30 days after the last modified time

    • Fragment expiration policy: Disabled

  • Rule 2

    • Status: Enabled

    • Policy: Applied to the entire bucket

    • File time policy: Number of days. Data is automatically deleted 365 days after the last modified time (deleted data cannot be recovered)

    • Fragment expiration policy: Disabled

Example 2: Lifecycle actions based on tag filtering (conflict)

Condition: An object has both tags, so both rules apply to the object.

Result: The object expires 10 days after its last modified time. Because the object is deleted, the storage class transition cannot be performed. Therefore, only the expiration action from Rule 2 takes effect.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix></Prefix>
      <Tag>
        <Key>tag1</Key>
        <Value>value1</Value>
      </Tag>
      <Status>Enabled</Status>
      <Transition>
        <Days>180</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
    <Rule>
      <ID>test-rule2</ID>
      <Prefix></Prefix>
      <Tag>
        <Key>tag2</Key>
        <Value>value2</Value>
      </Tag>
      <Status>Enabled</Status>
      <Expiration>
        <Days>10</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  • Rule 1

    Console configuration for Rule 1:

    • Status: Enabled

    • Policy: Applied to the entire bucket

    • Tag: tag1:value1

    • File time policy: Number of days. Data is automatically transitioned to Infrequent Access (IA) 180 days after the last modified time

  • Rule 2

    Lifecycle configuration for Rule 2:

    • Status: Enabled

    • Policy: Applied to the entire bucket

    • Tag: tag2:value2

    • File time policy: Number of days

    • Lifecycle management rule: Data deletion is executed 10 days after the last modified time (deleted data cannot be recovered)

Example 3: Lifecycle actions based on the same time period (conflict)

Execution result: The objects that match the rules are deleted after the objects are last modified for more than 365 days.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>rule1</ID>
      <Prefix></Prefix>    
      <Status>Enabled</Status>
      <Transition>
        <Days>365</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
    <Rule>
      <ID>rule2</ID>
      <Prefix></Prefix>    
      <Status>Enabled</Status>
      <Expiration>
        <Days>365</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  • Rule 1

    Configuration for Rule 1:

    • Policy: Select Applied to the entire bucket

    • File time policy: Select Number of days. Rule: Data is automatically transitioned to Infrequent Access (IA) 365 days after the last modified time

    • Fragment expiration policy: Select Disabled

  • Rule 2

    Lifecycle configuration for Rule 2:

    • Status: Enabled

    • Policy: Applied to the entire bucket

    • File time policy: Number of days

    • Lifecycle management rule: Data is automatically deleted 365 days after the last modified time (deleted data cannot be recovered)

    • Fragment expiration policy: Disabled

Example 4: Lifecycle actions based on overlapping prefixes that specify the same action (conflict)

Suppose you specify two lifecycle rules. The rule details are as follows:

• Rule 1: Specifies to transition objects with the prefix logs/ to the Infrequent Access storage class 180 days after their last modified time.

• Rule 2: Specifies to transition all objects in the current bucket to the Infrequent Access storage class 30 days after their last modified time.

Result: All objects in the bucket are transitioned to the Infrequent Access storage class 30 days after their last modified time.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>rule1</ID>
      <Prefix>logs/</Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>180</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
   <Rule>
      <ID>rule2</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>30</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>  
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  • Rule 1

    Console configuration for Rule 1:

    • Status: Enabled

    • Policy: Match by prefix, prefix: logs/

    • File time policy: Number of days. Data is automatically transitioned to Infrequent Access (IA) storage class 180 days after the last modified time

    • Fragment expiration policy: Disabled

  • Rule 2

    Rule 2 configuration: Status is Enabled. File time policy is Number of days. The lifecycle management rule specifies that data is automatically transitioned to Infrequent Access (IA) storage class 30 days after the last modified time. Fragment expiration policy is Disabled.

Disabling a lifecycle rule

Suppose you specify two lifecycle rules. The rule details are as follows:

• Rule 1 (Disabled): Specifies to transition objects with the prefix logs/ to the IA storage class 100 days after they are created.

• Rule 2 (Enabled): Specifies to transition objects with the prefix documents/ to the Archive storage class 50 days after they are created.

Result: Only the enabled rule takes effect.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix>logs/</Prefix>
      <Status>Disabled</Status>
      <Transition>
        <Days>100</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
    <Rule>
      <ID>test-rule2</ID>
      <Prefix>documents/</Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>50</Days>
        <StorageClass>Archive</StorageClass>
      </Transition>
    </Rule>
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  • Rule 1

    Lifecycle rule configuration for Rule 1:

    • Policy: Match by prefix, prefix: logs/

    • File time policy: Number of days. Data is automatically transitioned to Infrequent Access (IA) 100 days after the last modified time

    • Fragment expiration policy: Disabled

    • Status: Disabled

  • Rule 2

    Configuration for Rule 2: Policy is set to Match by prefix, prefix: documents/. File time policy is set to Number of days, with data automatically transitioned to Archive storage class 50 days after the last modified time. Fragment expiration policy is set to Disabled.

Lifecycle rules with versioning

When versioning is enabled, each object in the bucket has one current version and zero or more noncurrent versions. For more information about versioning, see Versioning.

Example 1: Transition and delete noncurrent object versions after a specified number of days

In this example, a lifecycle rule is configured for a bucket with versioning enabled. The rule transitions current object versions to the IA storage class 10 days after their last modified time. The rule also transitions noncurrent object versions to the Archive storage class 60 days after they become noncurrent, and then deletes them 90 days after they become noncurrent.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>10</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
      <NoncurrentVersionTransition>
        <NoncurrentDays>60</NoncurrentDays>
        <StorageClass>Archive</StorageClass>
      </NoncurrentVersionTransition>
      <NoncurrentVersionExpiration>
        <NoncurrentDays>90</NoncurrentDays>
      </NoncurrentVersionExpiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  Configuration details:

  • Status: Select Enabled. Policy: Select Match by prefix

  • Current version file execution policy: File time policy: Select Number of days. Set data to automatically transition to Infrequent Access (IA) 10 days after the last modified time

  • Noncurrent version file execution policy: File time policy: Select Number of days. Set to transition to Archive storage class 60 days after becoming noncurrent, and delete data 90 days after becoming noncurrent (deleted data cannot be recovered)

  • Fragment execution policy: Select Disabled

Example 2: Delete expired delete markers

If the only version of an object is a delete marker, it is referred to as an expired delete marker. The following example shows a lifecycle rule that removes expired delete markers.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <ExpiredObjectDeleteMarker>true</ExpiredObjectDeleteMarker>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  Lifecycle rule configuration:

  • Status: Select Enabled

  • Policy: Select Applied to the entire bucket

  • Current version file execution policy: File time policy: Select Remove expired delete markers

  • Noncurrent version file execution policy: File time policy: Select Disabled

  • Fragment execution policy: Fragment expiration policy: Select Disabled

Cleaning up expired fragments

This example shows a lifecycle rule that expires fragments with the prefix logs/ after 5 days. Fragments are parts from a multipart upload for which the CompleteMultipartUpload operation was not executed.

The following examples show the XML and console configurations for this lifecycle rule:

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>lifecyclerule1</ID>
      <Prefix>logs/</Prefix>
      <Status>Enabled</Status>
      <AbortMultipartUpload>
        <Days>5</Days>
      </AbortMultipartUpload>
    </Rule>
  </LifecycleConfiguration>

• Console

  Note

  You can also use the console to configure a lifecycle rule with these conditions. For more information, see Set lifecycle rules.

  Console lifecycle rule configuration:

  • Status: Enabled

  • Policy: Match by prefix, prefix: logs/

  • File time policy: Disabled

  • Fragment expiration policy: Number of days. Fragments generated more than 5 days ago are automatically deleted by the system (deleted data cannot be recovered)

References

• Lifecycle costs

• Billing examples: Automatically transition and clean up OSS data using lifecycle rules