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 are 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 enable access tracking for a bucket, 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 within 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 to convert the storage classes of objects from Standard to IA in a lifecycle rule that is configured based on the last access time of objects. You can also specify whether to convert the storage classes of the IA objects back to Standard when the objects are accessed.
  • You can specify policies to convert the storage classes of objects from Standard or IA to Archive or Cold Archive in a lifecycle rule that is configured based on the last access time of objects. You can also specify policies to convert the storage classes of the objects from Archive to Cold Archive in the lifecycle rule. If you want to convert the storage classes of objects from Standard or IA to Archive or Cold Archive,submit a ticket to apply for required permissions. After the application is approved, you must specify the storage class for the conversion.
    Notice 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 classes 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 rules

  • 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 for objects of all sizes. You are charged storage fees based on the sizes and storage classes of the objects.
    • Standard objects are charged based on their actual sizes.
    • IA, Archive, or Cold Archive objects that are smaller than 64 KB in size are charged as 64 KB. Objects of these storage classes that are larger than or equal to 64 KB in size are charged 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 charged 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 then converts the IA object to a Standard object after 5 days based on a 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 then deletes the IA object after 15 days based on a lifecycle rule. In this case, you are charged storage fees for the remaining 5 days.

    When you call the CopyObject operation to overwrite a Standard object with an IA object, note that the IA object also has a minimum storage duration. For example, if you call the CopyObject operation to convert a Standard object to an IA object 10 days after the Standard object is created, and then 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 pane, choose Basic Settings > Lifecycle. In the Lifecycle section, click Configure.
  4. If you want to create lifecycle rules based on the last access time of objects, turn on Enable access tracking on the Lifecycle page.
  5. On the page that appears, click Create Rule. 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 to which the lifecycle rule applies. Valid values: Files with Specified Prefix and Whole Bucket.

      Allow Overlapped Prefixes

      If you select Allow Overlapped Prefixes, you can configure lifecycle rules with the same or overlapping prefixes without specifying tags.

      Notice
      • If you want OSS to automatically detect whether rules with the same or overlapping prefixes are configured, do not select Allow Overlapped Prefixes.
      • If you want to use this parameter, contact technical support.
      Prefix
      Specify the prefix in the names of objects to which the lifecycle rule takes 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 applies only to objects that have 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 have the img prefix in their names and have the tag a=1. For more information about object tagging, see Object tagging.

      NOT

      The NOT parameter is used to specify that the lifecycle rule does not apply to objects that have the specified prefix and tags.

      Notice
      • If you enable NOT, each lifecycle rule must contain at least one of the prefix and tags of an object.
      • The key of the tag specified by the NOT syntax cannot be the same as the key specified by the Tagging parameter.
      • If you enable NOT, lifecycle rules that apply to parts cannot be configured.
      • If you want to use this parameter, contact technical support.
      Policy for Objects File Lifecycle

      Configure rules for objects to specify when the objects expire. Valid values: Validity Period (Days), Expiration Date, and 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 ends. 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 to objects that are larger than 64 KB in size or to 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.

      Notice Each lifecycle rule must contain at least one of 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 and Policy for Parts sections 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 they become previous versions. After they expire, the specified operations are performed on the previous versions the next day. For example, if you set Validity Period (Days) to 30, objects that become previous versions on September 1, 2021 are converted to the specified storage class or deleted on October 1, 2021.

      Notice 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 classes of the objects are converted to IA 30 days after the objects are last accessed, and the storage classes 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 classes of these objects have 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 enable 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.