This topic describes several common examples of lifecycle configuration for you to better manage the objects in your bucket.

Specify filter condition

Each lifecycle rule contains at least one filter condition. The filter determines whether the lifecycle rule applies to some or all of the objects in a bucket. The following examples show how to specify a filter condition in lifecycle rule configurations.

  • Example 1

    In the following lifecycle rule configuration, a prefix doc/ is specified as the filter, which indicates that the lifecycle rule applies to only objects prefixed with doc/, such as doc/test1.txt and doc/test2.jpg. The lifecycle rule also specifies the following operations on these objects:

    • Transition operation: Convert the storage class of the object to IA 180 days after it is last modified.
    • Expiration operation: Delete the object 365 days after it is last modified.
    <LifecycleConfiguration>
      <Rule>
        <ID>test-rule0</ID>
        <Prefix>doc/</Prefix>
        <Status>Enabled</Status>
        <Expiration>
          <Days>365</Days>
        </Expiration>
        <Transition>
          <Days>180</Days>
          <StorageClass>IA</StorageClass>
        </Transition>
      </Rule>
    </LifecycleConfiguration>
  • Example 2

    In the following lifecycle rule configuration, the filter condition indicates that the lifecycle rule applies to all objects in the bucket. The lifecycle rule specifies that each object in the bucket expires 300 days after it is last modified.

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

    In the following lifecycle rule configuration, the value of prefix is null, which indicates that the lifecycle rule applies to all objects in the bucket. The lifecycle rule specifies that each object that is modified before December 30, 2019 expires.

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

Overlapping filter conditions

The following examples describe whether the operations specified in lifecycle rules conflict when the filter conditions overlap.

  • Example 1

    Two lifecycle rules are configured in the configuration and each of rule specifies a tag filter condition:

    • The first rule specifies a filter condition based on a tag that is a key-value pair of tag1 and value1. Based on this rule, OSS converts the storage class of objects to IA 180 days after the objects are last modified.
    • The second rule specifies a filter condition based on a tag that is a key-value pair of tag2 and value2. Based on this rule, objects expire 10 days after they are last modified.
    <LifecycleConfiguration>
      <Rule>
        <ID>test-rule0</ID>
        <Prefix></Prefix>
        <Tag>
          <Key>tag1</Key>
          <Value>value1</Value>
        </Tag>
        <Status>Enabled</Status>
        <Expiration>
          <Days>180</Days>
        </Expiration>
      </Rule>
      <Rule>
        <ID>test-rule1</ID>
        <Prefix></Prefix>
        <Tag>
          <Key>tag2</Key>
          <Value>value2 </Value>
        </Tag>
        <Status>Enabled</Status>
        <Transition>
          <Days>10</Days>
          <StorageClass>IA</StorageClass>
        </Transition>
      </Rule>
    </LifecycleConfiguration>
    Note If an object is configured with the two tags, both lifecycle rules apply to this object. Therefore, the first lifecycle rule does not take effect because the object has already been deleted. If the object is deleted, its storage class cannot be converted.
  • Example 2

    Two lifecycle rules are configured in the configuration and specify two overlapped prefixes as their filter conditions.

    • The first rule specifies an empty prefix as its filter conditions, which indicates that the rule applies to all objects in the bucket. This rule specifies that all objects in the bucket are deleted 365 days after they are last modified.
    • The second rule specifies the prefix test/ as its filter conditions, which indicates that this rule applies to only objects prefixed with test/. This rule specifies that the storage class of the objects is converted to Archive 30 days after the objects are last modified.
    <LifecycleConfiguration>
      <Rule>
        <ID>test-rule0</ID>
        <Prefix></Prefix>
        <Status>Enabled</Status>
        <Expiration>
          <Days>365</Days>
        </Expiration>
      </Rule>
      <Rule>
        <ID>test-rule1</ID>
        <Prefix>test/</Prefix>
        <Status>Enabled</Status>
        <Transition>
          <Days>30</Days>
          <StorageClass>Archive</StorageClass>
        </Transition>
      </Rule>
    </LifecycleConfiguration>

Disable lifecycle rules

You can temporarily disable lifecycle rules. In the following example, two lifecycle rules are configured in the configuration. The first rule is enabled and the second is disabled based on the policy.

  • The first rule specifies that the storage class of objects prefixed with logs/ is converted to Archive after the objects are created.
  • The second rule specifies that the storage class of objects prefixed with documents/ is converted to IA after the objects are created.
<LifecycleConfiguration>
  <Rule>
    <ID>test-rule1</ID>
    <Prefix>logs/</Prefix>
    <Status>Disabled</Status>
    <Transition>
      <Days>1</Days>
      <StorageClass>IA</StorageClass>
    </Transition>
  </Rule>
  <Rule>
    <ID>test-rule2</ID>
    <Prefix>documents/</Prefix>
    <Status>Enabled</Status>
    <Transition>
      <Days>1</Days>
      <StorageClass>Archive</StorageClass>
    </Transition>
  </Rule>
</LifecycleConfiguration>

Lifecycle rules for versioning-enabled buckets

In a versioning-enabled bucket, each object has a current version and may have historical versions. For more information about versioning, see Overview.

  • Example 1

    You can perform the following operations to reduce storage costs: 1. Convert the object to the Archive storage class 60 days after it becomes a historical version. 2. Delete the object 90 days after it becomes a historical version. 3. Convert the current version of the object to IA storage class 120 days after it is last modified to reduce access frequency. In this case, you can configure lifecycle rules as follows:

    <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>
  • Example 2

    If an object has only a delete marker as the current version and other versions of the object are deleted, the delete marker expires when the object expires based on lifecycle rules. You can configure a lifecycle rule as follows to delete an expired delete marker:

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