You can call PutBucketLifecycle to configure lifecycle rules to minimize costs. This way, expired objects and parts can be automatically deleted. You can configure lifecycle rules to convert the storage class of expired objects to IA or Archive.

Note For more information about the PutBucketLifecycle operation, see PutBucketLifecycle.

Scenarios

You can configure a lifecycle rule to regularly convert the storage class of non-hot data to IA, Archive, or to Cold Archive, and delete data that will be no longer accessed in the future, which minimizes human resource and storage costs. Examples:
  • A medical institution stores their medical records in OSS. These objects are occasionally accessed within six months after they are uploaded, and almost never after that. A lifecycle rule can be used to convert the storage class of these objects to Archive after 180 days since they were uploaded.
  • A company stores the call records of their hotline service in OSS. These objects are frequently accessed within the first two months, occasionally after the two months, and almost never after six months. After two years, these objects no longer need to be stored. A lifecycle rule can be used to convert the storage class of these objects to IA after 60 days and to Archive after 180 days, and to delete them after 730 days since they were uploaded.
  • You can manually delete up to 1,000 objects each time. If a bucket contains more than 1,000 objects, you must perform multiple delete operations. You can configure a lifecycle rule that applies to the whole bucket to delete all objects in a bucket after one day.

Implementation modes

Implementation mode Description
Console User-friendly and intuitive web application
ossutil High-performance command-line tool
OSS SDK for Java SDK demos for various programming languages
OSS SDK for Python
OSS SDK for PHP
OSS SDK for Go
OSS SDK for C
OSS SDK for .NET
OSS SDK for Node.js
OSS SDK for Ruby

Precautions

  • Billing

    Requests that asynchronously trigger lifecycle rule actions are recorded in access logs and incur related request fees. Requests that fail to trigger lifecycle rule actions are not recorded or charged.

  • Maximum available rules

    You can configure up to 1,000 lifecycle rules for each bucket.

  • Effective time

    After a lifecycle rule is configured, it is loaded within 24 hours, and is implemented within 24 hours after it is loaded.

  • Prefix and tag
    • The naming conventions for prefixes are the same as those for objects.
    • If a rule does not specify any prefixes, the rule applies to all objects in a bucket.
    • The prefixes specified by different rules cannot overlap. If a bucket has two rules that specify prefixes logs/ and logs/program, OSS returns an error.
    • The tag key is required. The key and value of a tag can contain letters, digits, spaces, and special characters such as + - = . _ : /
    • Object name prefixes can overlap when you configure a combination of object name prefixes and tags in rules. Object name prefixes can overlap when you configure a combination of object name prefixes and tags in rules. Assume that a bucket has two rules configured: Rule 1 specifies the prefix for object names as logs/ and tags as K1=V1. Rule 2 specifies the prefix object names as logs/program and tags as K1=V2. OSS triggers operations on the objects whose names are prefixed with logs/program and for which tagging configurations are K1=V1 (Rule 1) or K1=V2 (Rule 2), and objects whose names are prefixed with logs/ and for which tagging configurations are K1=V1 (Rule 1).

Lifecycle rule configurations

Each lifecycle management rule contains the following information:
  • Policy: specifies the mode to match objects and parts.
    • Match by prefix: matches objects and parts by prefix. You can create multiple rules to configure different prefixes. Each prefix must be unique.
    • Match by tag: matches objects based on tag key and value configurations. You can configure multiple tags for a single rule. OSS runs lifecycle rules for all objects that have these tags. Tags cannot be configured to match parts.
      Note For more information, see Object tagging.
    • Match by prefix and tag: matches objects by specifying one prefix and one or more tags.
    • Match by bucket: matches all objects and parts contained in the bucket. You can create only one rule if you select this method.
  • Object lifecycle policy: specifies the validity period or expiration time and the operation to perform on these objects after they expire.
    • Validity period: specifies the number of days within which unversioned and current objects can be retained after they are last modified, and the operation to perform on these objects after they expire. Objects that meet the specified conditions are retained for the specified validity period after the objects are last modified. The specified operation is performed on these objects after they expire.
    • Expiration date: specifies the date before which objects that are last modified expire and the operation to perform on these objects after they expire. All objects that are last modified before this date expire and the specified operation is performed on these objects.
    • The validity period within which the previous versions can be retained. When the current versions expire, they become the previous versions. You can convert the storage class of the objects, or delete the previous versions after the validity period. Objects that meet specified conditions can be retained within the specified validity period after the objects become previous versions. The specified operation can be performed on these objects after they expire.
    Note You can convert the storage class of these objects to IA, Archive, or Cold Archive, or delete these objects that match the conditions. For more information, see Configuration elements.
  • Part lifecycle policy: specifies the validity period or expiration time and the delete operation to perform on these objects after they expire.
    • Validity period: specifies the number of days within which parts can be retained after they are last modified. After the validity period, expired parts are deleted.
    • Expiration date: specifies the date before which parts that are last modified expire. After the expiration date, expired parts are deleted.

Matching logic of lifecycle rules

  • Matching logic
    A rule applies to an object if the object name prefix matches the prefix specified in the rule. For example, a bucket contains the following objects:
    logs/program.log.1
    logs/program.log.2
    logs/program.log.3
    doc/readme.txt

    If the prefix specified in a rule is logs/, the rule applies to the first three objects whose names are prefixed with logs/. If the prefix specified in a rule is doc/readme.txt, the rule applies only to the doc/readme.txt object.

    You can also configure rules to delete expired objects. For example, you can configure a rule to delete objects whose names are prefixed with logs/ and that are last modified 30 days ago, or delete the doc/readme.txt object that will expire on a specific date.

    When an object matches such a rule, OSS includes the x-oss-expiration header in the response to the GetObject or HeadObject request. This header contains two parameters: expiry-date that specifies the expiration date of the object, and rule-id that specifies the ID of the matched rule.

  • Matching conflicts
    • Rules that have the same prefixing and tagging configurations
      Rule Prefix Tag Action
      rule1 abc a=1 Delete objects after 20 days since they were last modified
      rule2 abc a=1 Convert the storage class of the objects to Archive after 20 days since they were last modified

      Results: All objects whose names are prefixed with abc and for which tagging configurations are a=1 are deleted after 20 days since they were last modified. In this case, objects are deleted. Therefore, rule2 does not take effect.

      Rule Prefix Tag Action
      rule1 abc a=1 Convert the storage class of objects to IA after 365 days since they were last modified
      rule2 abc a=1 Convert the storage class of objects to Archive if they were last modified before March 1, 2018

      Results: The storage class of all objects whose names are prefixed with abc and for which tagging configurations are a=1 is converted to Archive if objects match the two rules at the same time. If objects match only one rule, OSS runs the specified rule.

    • Rules that have the overlapping prefixing and same tagging configurations
      Rule Prefix Tag Action
      rule1 - a=1 Convert the storage class of the objects to IA after 20 days since they were last modified
      rule2 abc a=1 Delete objects after 120 days since they were last modified

      Results: The storage class of all objects for which tagging configurations are a=1 is converted to IA after 20 days since they are last modified. Objects whose names are prefixed with abc and for which tagging configurations are a=1 are deleted after 120 days since they are last modified.

      Rule Prefix Tag Action
      rule1 - a=1 Convert the storage class of the objects to Archive after 10 days since they are last modified
      rule2 abc a=1 Convert the storage class of the objects to IA after 20 days since they were last modified

      Results: The storage class of all objects for which tagging configurations are a=1 is converted to Archive after 10 days since they are last modified. rule2 becomes invalid because the storage class cannot be converted from Archive to IA.