OSS allows you to call PutBucketLifecycle to configure lifecycle rules to delete expired objects and parts or convert the storage class of expired objects to IA or to Archive. This way, storage costs are minimized.

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

Scenarios

You can configure lifecycle rules to manage OSS data, which minimizes human resource and storage costs. You can also configure a specific prefix in a lifecycle rule to convert the storage class of less frequently accessed data to IA or to Archive and delete data that will be no longer accessed in the future. 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 uploads.
  • 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 uploads.
  • You can also configure a lifecycle rule to delete multiple objects in a bucket at a time. 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 A user-friendly and intuitive web application
Java SDK SDK demos for various programming languages
Python SDK
PHP SDK
Go SDK
C SDK
.NET SDK
Node.js SDK
Ruby SDK

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 run 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. You cannot configure tagging for 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 specified conditions can be retained for the specified validity period after the objects are last modified. The specified operation can be 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 to IA or to Archive, 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 are last modified. The specified operation can be performed on these objects after they expire.
    Note You can convert the storage class of these objects to IA or to Archive, or delete these objects that match the conditions. For more information, see Configure lifecycle rules.
  • 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 indicates the expiration date of the object, and rule-id that indicates 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 are last modified
      rule2 abc a=1 Convert the storage class of the objects to Archive after 20 days since they are 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 are last modified. In this case, objects have been deleted and rule2 makes no sense.

      Rule Prefix Tag Action
      rule1 abc a=1 Convert the storage class of objects to IA after 365 days since they are last modified
      rule2 abc a=1 Convert the storage class of objects to Archive if they are 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 N/A a=1 Convert the storage class of the objects to IA after 20 days since they are last modified
      rule2 abc a=1 Delete objects after 120 days since they are 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 N/A 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 are 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.