You can configure lifecycle rules for a bucket based on the last access time of the objects in the bucket. After you configure a lifecycle rule for a bucket, Object Storage Service (OSS) monitors the access patterns of the objects in the bucket, identifies cold data, and converts the storage class of cold data. This way, cold data is stored by using storage classes that are different from the storage classes of hot data, and storage costs are reduced.

Scenarios

  • Multimedia

    After you store the videos and images of your website in an OSS bucket, the data may become infrequently accessed over time. For data that becomes infrequently accessed, you may need to convert the storage class to Infrequent Access (IA). For data that has been uploaded for a long time but is still frequently accessed, you must retain the Standard storage class. You can configure a lifecycle rule for the bucket based on the last access time of the objects in the bucket. This way, cold and hot data is stored by using different storage classes and storage costs are reduced.

  • Albums or network disks

    You can configure a lifecycle rule for a bucket that is used to store albums or is used as a network disk based on the last access time of the objects in the bucket. After the lifecycle rule is triggered, the storage class of cold data is automatically converted to IA. You can access the data in real time.

  • Life science

    A large amount of data is generated in gene sequencing. Users need to determine whether the data is frequently accessed based on the last access time instead of the last modified time of the data. In the past, users must use methods such as log analysis to identify and manage cold and hot data. You can configure a lifecycle rule based on the last access time of the objects in the bucket. This way, OSS automatically identifies cold and hot data based on the last access time of the objects and stores the objects by using different storage classes. You can also specify policies based on the last access time and last modified time in the same lifecycle rule to manage data in a more flexible manner.

Limits

  • Match conditions

    Currently, lifecycle rules only support matching based on prefixes and tags. Wildcard matching, suffix matching, and regular expression matching are not supported.

  • Part lifecycle
    You cannot configure two or more lifecycle rules that contain a part lifecycle policy for objects whose names have overlapping prefixes. For example, you cannot configure lifecycle rules in the following scenarios:
    • Example 1

      If you configure a lifecycle rule that contains a part lifecycle policy for the entire bucket first, you cannot configure another lifecycle rule that contains a part lifecycle policy for objects whose names contain any prefix in the bucket.

    • Example 2

      If you configure a lifecycle rule that contains a part lifecycle policy for objects whose names contain the dir1 prefix in a bucket first, you cannot configure another lifecycle rule that contains a part lifecycle policy for objects whose names have overlapping prefixes, such as dir1/dir2.

Usage notes

Number of lifecycle rules

You can configure up to 100 lifecycle rules in the OSS console. You can also specify policies based on the last access time and last modified time in the same lifecycle rule. If you want to configure more than 100 lifecycle rules, use OSS SDKs or the command-line tool ossutil.

Configurations of lifecycle rules for a bucket for which OSS-HDFS is enabled

To configure or modify a lifecycle rule to match all objects in a bucket for which the OSS-HDFS service is enabled, use the NOT element to exclude the objects that are stored in the .dlsdata/ directory. This helps prevent object deletion operations or storage class conversion operations that are triggered by the lifecycle rule from affecting data read and write operations on OSS-HDFS data.

lifecycle

Policies based on the last access time

After you turn on Enable access tracking on the Lifecycle page, the last access time of all objects in the bucket is set to the time when you enabled access tracking and is updated based on the actual access time of the objects. If multiple GetObject requests are sent to access the same object in 24 hours, the last access time of the object is set to the time when the object is accessed by the first GetObject request.

If an object is accessed by using a symbolic link that points to the object, the last access time of the object is not updated.

Supported storage classes

  • You can specify policies in a lifecycle rule that is configured based on the last access time of objects to convert the storage class of the objects from Standard to IA. You can also specify whether to convert the storage class of the objects from IA to Standard when the objects are accessed.
  • You can specify policies in a lifecycle rule that is configured based on the last access time of objects to convert the storage class of the objects from Standard or IA to Archive or Cold Archive. You can also specify policies in the lifecycle rule to convert the storage class of the objects from Archive to Cold Archive. If you want to convert the storage class of objects from Standard or IA to Archive or Cold Archive, submit a ticket to apply for the required permissions. After the application is approved, you must specify the storage class for the conversion.
    Important After the application is approved, if you configure a lifecycle rule based on the last access time of objects for a bucket to convert the storage class of the objects in the bucket from Standard or IA to Archive or Cold Archive, the last access time of the Archive or Cold Archive objects in the bucket is the time when access tracking is enabled for the bucket.

Billing rule

  • Object monitoring and management fees

    After you enable access tracking for a bucket, object monitoring and management fees are generated. However, you are not charged the fees.

  • Storage fees
    You can configure lifecycle rules based on the last access time of objects of all sizes. You are charged storage fees based on the sizes and storage classes of the objects.
    • For Standard objects, you are charged based on the actual sizes.
    • IA, Archive, or Cold Archive objects that are smaller than 64 KB in size are billed as 64 KB. Objects of these storage classes that are larger than or equal to 64 KB in size are billed based on their actual sizes.
  • Storage fees for IA objects that are stored for less than the minimum storage duration

    IA objects have a minimum storage duration of 30 days. If the IA objects are stored for less than 30 days, you are charged storage fees for 30 days. The following examples show how IA objects are billed when you configure lifecycle rules based on the last access time of objects:

    Example 1: OSS converts a Standard object to an IA object 10 days after the object is created and converts the IA object to a Standard object after 5 days based on the configured lifecycle rule. In this case, you are charged storage fees for the remaining 15 days.

    Example 2: OSS converts a Standard object to an IA object 10 days after the object is created and deletes the IA object after 15 days based on the configured lifecycle rule. In this case, you are charged storage fees for the remaining 5 days.

    If you call the CopyObject operation to overwrite a Standard object with an IA object, the IA object also has a minimum storage duration. For example, if you call the CopyObject operation to convert the storage class of an object from Standard to IA 10 days after the Standard object is created, and delete the IA object after 10 days, you are also charged storage fees for the remaining 20 days.

  • Retrieval fees for IA objects

    When you access IA objects, you are charged data retrieval fees based on the size of the retrieved IA objects.

Use the OSS console

  1. Log on to the OSS console.
  2. In the left-side navigation pane, click Buckets. On the Buckets page, click the name of the desired bucket.
  3. In the left-side navigation tree, choose Data Management > Lifecycle.
  4. On the Lifecycle page, turn on Enable access tracking and click Create Rule.
  5. In the Create Rule panel, configure the parameters. The following table describes the parameters.
    • Parameters for unversioned buckets
      Section Parameter Description
      Basic Settings Status

      Specify the status of the lifecycle rule. Valid values: Enabled and Disabled.

      Applied To

      Specify the objects on which you want the lifecycle rule to take effect. Valid values: Files with Specified Prefix and Whole Bucket.

      Allow Overlapped Prefixes
      By default, OSS checks whether the prefixes of each lifecycle rule overlap. For example, you configure the following lifecycle rules that contain overlapping prefixes:
      • Rule 1

        All objects whose names contain the dir1/ prefix in the bucket are deleted 180 days after the objects are last modified.

      • Rule 2

        All objects whose names contain the dir1/dir2/ prefix in the bucket are converted to IA objects 30 days after the objects are last modified, and deleted after 60 days.

      If you do not select this parameter, OSS determines that objects in the dir1/dir2/ directory match two deletion rules. Therefore, the two lifecycle rules are rejected and an error Overlap for same action type Expiration. is reported.

      If you select this parameter, the objects in the dir1/dir2/ directory are converted to IA objects after 30 days and deleted after 60 days. Other objects in the dir1/ directory are deleted after 180 days.

      Prefix
      Specify the prefix in the names of objects on which you want the lifecycle rule to take effect.
      • If you set the prefix to img, all objects whose names start with img, such as imgtest.png and img/example.jpg, match the lifecycle rule.
      • If you set the prefix to img/, all objects whose names start with img/, such as img/example.jpg and img/test.jpg, match the lifecycle rule.
      Tagging

      Specify tags. The rule takes effect only on objects that contain the specified tags. For example, if you select Files with Specified Prefix and set Prefix to img, Key to a, and Value to 1, the rule applies to all objects that contain the img prefix in their names and contain the a=1 tag. For more information about object tagging, see Object tagging.

      NOT

      The NOT parameter is used to specify that the lifecycle rule does not take effect on the objects that contain the specified prefix and tag.

      Important
      • If you turn on the NOT parameter, each lifecycle rule must contain at least one of the prefix and tag.
      • The key of the tag specified by the NOT syntax cannot be the same as the key specified by the Tagging parameter.
      • If you turn on the NOT parameter, lifecycle rules that take effect on parts cannot be configured.
      Policy for Objects File Lifecycle

      Configure rules for objects to specify when the objects expire. You can set File Lifecycle to Validity Period (Days), Expiration Date, or Disabled. If you select Disabled, the configurations of File Lifecycle do not take effect.

      Lifecycle-based Rules

      Configure the policy to convert the storage class of objects or delete expired objects.

      Example 1: If you select Access Time, set Validity Period (Days) to 30, and specify that the storage class of the objects is converted to IA (Not Converted After Access) after the validity period is elapsed. In this case, the storage class of objects that were last accessed on September 1, 2021 is converted to Infrequent Access (IA) on October 1, 2021.

      Note If you configure a lifecycle rule based on the last access time, you can specify that the rule takes effect only on objects that are larger than 64 KB in size or on all objects in the bucket.

      Example 2: If you select Modified Time, set Expiration Date to September 24, 2021, and specify that objects that are last modified before this date are deleted. In this case, objects that are last modified before September 24, 2021 are automatically deleted. The deleted objects cannot be recovered.

      Policy for Parts Part Lifecycle

      Specify the operations that you want to perform on expired parts. If you select Tagging, this parameter is unavailable. You can select Validity Period (Days), Expiration Date, or Disabled. If you select Disabled, the configurations of Part Lifecycle do not take effect.

      Important Each lifecycle rule must contain at least one of the object expiration policies and part expiration policies.
      Rules for Parts

      Specify when parts expire based on the value of Part Lifecycle. Expired parts are automatically deleted and cannot be recovered.

    • Parameters for versioned buckets

      Configure the parameters in the Basic Settings section and Policy for Parts section in the same way as the parameters configured for unversioned buckets. The following table describes only the parameters that are different from the parameters that you configure for unversioned buckets.

      Section Parameter Description
      Policy for Current Versions Clean Up Delete Marker

      If you enable versioning for the bucket, you can configure the Clean Up Delete Marker parameter. Other parameters are the same as those you can configure for unversioned buckets.

      If you select Clean Up Delete Marker, and an object has only one version which is a delete marker, OSS considers the delete marker expired and removes the delete marker. If an object has multiple versions and the current version of the object is a delete marker, OSS retains the delete marker. For more information about delete makers, see Delete marker.

      Policy for Previous Versions File Lifecycle

      Specify when previous versions expire. Valid values: Validity Period (Days) and Disabled. If you select Disabled, File Lifecycle does not take effect.

      Lifecycle-based Rules

      Specify the number of days within which objects can be retained after the objects become previous versions. After the objects expire, the specified operations are performed on the previous versions the next day. For example, if you set Validity Period (Days) to 30, the objects that become previous versions on September 1, 2021 are converted to the specified storage class or deleted on October 1, 2021.

      Important You can determine when an object becomes a previous version based on the time when the next version of the object is last modified.
  6. Click OK.
    After a lifecycle rule is saved, you can view the rule in the lifecycle rule list.

FAQ

Why is a lifecycle rule unable to immediately take effect after the rule is configured?

After a lifecycle rule is created, OSS loads the rule within 24 hours. After the lifecycle rule is loaded, OSS runs the rule every day at 08:00:00 (UTC+8) and completes the actions triggered by the rule within 24 hours. Therefore, a new lifecycle rule requires up to 48 hours to take effect.

What happens if I configure a lifecycle rule based on the last modified time and a lifecycle rule based on the last access time at the same time for objects that have the same prefix in the same bucket?

For example, you configure two lifecycle rules for a bucket named examplebucket. The first rule specifies that all objects whose names are prefixed with doc in examplebucket are deleted 30 days after the objects are last modified. The second rule specifies that the storage class of all objects whose names are prefixed with doc in examplebucket is converted to IA 30 days after the objects are last accessed.

In this case, only the first lifecycle rule takes effect because OSS implements the lifecycle rule that incurs lower fees. If the first rule is implemented, you are not charged after the specified objects are deleted based on the rule. If the second rule is implemented, you are charged storage fees or data retrieval fees after the storage class of the specified objects is converted based on the rule.

When does a lifecycle rule take effect after I modify the rule? What happens to the objects to which the original rule applies?

For example, you configure a lifecycle rule for objects whose names contain the er prefix. Based on the lifecycle rule, the storage class of the objects is converted to IA 30 days after the objects are last accessed, and the storage class of the objects can be converted back to Standard when the IA objects are accessed after 30 days. If you change the prefix that you specify in the lifecycle rule from er to re 35 days after the objects whose names are prefixed with er are last accessed, the storage class of these objects has already been converted to IA and cannot be converted back to Standard based on the original lifecycle rule. After you modify the lifecycle rule, the last access time of the objects whose names contain the re prefix is set to the time when you enabled access tracking for the bucket.

How are objects stored if I configure lifecycle rules based on the last access time for a versioned bucket?

Each object in a versioned bucket has a unique version ID. Objects with different version IDs are separately stored. After you configure lifecycle rules based on the last access time for a versioned bucket, the storage class of the current version of an object may be different from the storage class of a previous version of the same object.

Can I disable access tracking?

Yes, you can disable access tracking. Before you disable access tracking for a bucket, make sure that no lifecycle rules are configured based on the last access time for the bucket. After you disable access tracking for a bucket, OSS stops tracking the last access time of the objects in the bucket. If you enable access tracking for the bucket again, the last access time of the objects in the bucket is reset.