This topic provides several common examples of lifecycle configurations so that you can better manage objects in your bucket.

Specify filter conditions

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

  • Example 1

    In the lifecycle rule configurations, the doc/ prefix is specified as a filter condition. This condition indicates that the lifecycle rule applies only to objects whose names are prefixed with doc/, such as doc/test1.txt and doc/test2.jpg. In addition, the rule specifies that the storage class of objects that match the rule is converted to Infrequent Access (IA) 180 days after the objects are last modified, and that the objects that match the rule are deleted 365 days after the objects are last modified.

    The following examples show the configurations of the lifecycle rule in the XML format and in the Object Storage Service (OSS) console:

    • Configurations in the XML format
      <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>
    • Configurations in the console
      Note The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.
      rule1
  • Example 2

    In the following lifecycle configuration example, the filter condition indicates that the lifecycle rule applies to all objects in the bucket. All objects in the bucket expire 300 days after the objects are last modified based on the lifecycle rule.

    The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

    • Configurations in the XML format
      <LifecycleConfiguration>
        <Rule>
          <ID>test-rule1</ID>
          <Prefix></Prefix>
          <Status>Enabled</Status>
          <Expiration>
            <Days>300</Days>
          </Expiration>
        </Rule>
      </LifecycleConfiguration>
    • Configurations in the console
      Note The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.
      rule2
  • Example 3

    In the following lifecycle configuration example, the Prefix parameter is not configured, which indicates that the lifecycle rule applies to all objects in the bucket. All objects that are modified before December 30, 2021 expire based on the lifecycle rule.

    The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

    • Configurations in the XML format
      <LifecycleConfiguration>
        <Rule>
          <ID>test-rule0</ID>
          <Prefix></Prefix>
          <Status>Enabled</Status>
          <Expiration>
            <CreatedBeforeDate>2021-12-30T00:00:00.000Z</CreatedBeforeDate>
          </Expiration>
        </Rule>
      </LifecycleConfiguration>
    • Configurations in the console
      Note The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.
      rule3

Overlapping filter conditions

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

  • Example 1

    This example shows how lifecycle rules are executed when the conditions specified in the lifecycle rules conflict. Assume that you specify the following lifecycle rules:
    • Rule 1 specifies a filter condition based on Tag A, and specifies that the storage class of objects with the tag is converted to IA 180 days after the objects are last modified.
    • Rule 2 specifies a filter condition based on Tag B, and specifies that objects with the tag expire 10 days after the objects are last modified.

    If an object has the two tags specified in the two lifecycle rules, both lifecycle rules apply to the object. In this case, the object expires 10 days after it is last modified. After the object is deleted, the storage class conversion operation specified in the first lifecycle rule cannot be performed. Therefore, only the expiration operation specified in the second lifecycle rule takes effect in this example.

    The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

    • Configurations in the XML format
      <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>
    • Configurations in the console
      Note The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.
      • Rule 1rule4
      • Rule 2rule5
  • Example 2

    This example shows how lifecycle rules are executed when the conditions specified in the lifecycle rules do not conflict. Assume that you specify the following lifecycle rules in which overlapped prefixes are configured:
    • Rule 1 applies to objects whose names contain the test/ prefix, and specifies that the storage class of these objects is converted to Archive 30 days after the objects are last modified.
    • Rule 2 applies to all objects in the bucket and specifies that objects are deleted 365 days after the objects are last modified.

    The two rules do not conflict. Therefore, the operations specified in the two lifecycle rules all take effect.

    The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

    • Configurations in the XML format
      <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>
    • Configurations in the console
      Note The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.
      • Rule 1rule7
      • Rule 2rule6

Disable lifecycle rules

In this example, two lifecycle rules are configured. The first rule specifies that the storage class of objects whose names contain the logs/ prefix is converted to IA 100 days after the objects are created. The second rule specifies that the storage class of objects whose names contain the documents/ prefix is converted to Archive 50 days after the objects are created. Then, disable the first rule and enable the second rule.

After the lifecycle configurations take effect, only the second lifecycle rule in which the <Status> value is Enabled takes effect. In this case, the storage class of objects whose names contain the documents/ prefix is converted to Archive 50 days after the objects are created.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

  • Configurations in the XML format
    <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>
  • Configurations in the console
    Note The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.
    • Rule 1rule8
    • Rule 2rule9

Configure lifecycle rules for versioned buckets

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

  • Example 1

    The lifecycle rule configured in this example specifies that the storage class of all objects in the bucket is converted to IA 10 days after they are last modified and to Archive 60 days after they become previous versions. In addition, objects are deleted 90 days after they become previous versions.

    The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

    • Configurations in the XML format
      <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>
    • Configurations in the console
      Note The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.
      rule9
  • Example 2

    If the current version of an object is a delete marker and other versions of the object are deleted, the delete marker expires. You can configure the following lifecycle rule to delete expired delete markers.

    The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

    • Configurations in the XML format
      <LifecycleConfiguration>
        <Rule>
          <ID>test-rule0</ID>
          <Prefix></Prefix>
          <Status>Enabled</Status>
          <Expiration>
            <ExpiredObjectDeleteMarker>true</ExpiredObjectDeleteMarker>
          </Expiration>
        </Rule>
      </LifecycleConfiguration>
    • Configurations in the console
      Note The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.
      rule10

Configure lifecycle rules to delete expired parts

Assume that you use multipart upload to upload an object and do not call the CompleteMultipartUpload operation to complete the multipart upload task. In this case, you can configure a lifecycle rule to specify that parts whose names contain the "logs" prefix expire 5 days after the parts are uploaded.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

  • Configurations in the XML format
    <LifecycleConfiguration>
      <Rule>
        <ID>lifecyclerule1</ID>
        <Prefix>logs/</Prefix>
        <Status>Enabled</Status>
        <AbortMultipartUpload>
          <Days>5</Days>
        </AbortMultipartUpload>
      </Rule>
    </LifecycleConfiguration>
  • Configurations in the console
    Note The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.
    rule11