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

Scenarios

  • Multimedia data storage

    If 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 of the data to Infrequent Access (IA). For data that has been uploaded for a long time but is still frequently accessed, you need to keep the storage class of the data as Standard. In this case, you can configure a lifecycle rule based on the last access time for the bucket to store cold and hot data by using different storage classes to reduce storage costs.

  • Albums or network disks

    You can configure a lifecycle rule based on the last access time for a bucket that is used to store albums or used as network disks. In this case, the storage class of cold data is automatically converted to IA after the lifecycle rule is triggered. In addition, the storage class of the cold data can be converted back to Standard when the data is accessed, which ensures real-time access to the data.

  • Life science data storage

    A large amount of data is generated in DNA sequencing. Users need to determine whether the data is frequently accessed based on the last access time but not last modified time of the data. In the past, users must manually analyze logs to identify cold and hot data and then use different methods to manage cold and hot data. In this case, you can configure a lifecycle rule based on the last access time. This way, OSS automatically identifies cold and hot objects based on the last access time of the objects and stores the objects by using different storage classes. In addition, you can specify policies based on the last access time and last modified time in the same lifecycle rule to flexibly manage data.

Implementation methods

To create a lifecycle rule based on the last access time for a bucket, you must enable access tracking for the bucket in the OSS console. For more information, see Configure lifecycle rules.

Usage notes

  • Supported regions

    You can configure lifecycle rules based on the last access time only for buckets in the China (Qingdao), China (Hohhot), Germany (Frankfurt), and Australia (Sydney) regions.

  • 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 access tracking is enabled 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 within the period.

    In addition, if a symbolic link is accessed, the last access time of the object that the symbolic link points to is not updated.

  • Supported storage classes

    In a lifecycle rule based on the last access time, you can specify policies to convert the storage class of objects from Standard to IA. In addition, you can specify whether to convert the storage class of the IA objects back to Standard after the objects are accessed. The storage classes of objects cannot be converted to Archive or Cold Archive based on lifecycle rules based on the last access time.

  • Billing
    • Storage fees

      You can configure lifecycle rules based on the last access time for objects of all sizes. You are charged storage fees for the objects based on the sizes and storage classes of the objects. If the storage class of the objects is Standard, you are charged storage fees based on the sizes of the objects and the unit price of Standard objects. If the storage class of the objects is IA, you are charged storage fees based on the sizes of the objects and the unit price of IA objects. Objects have a minimum billable size of 64 KB. Objects that are equal to or larger than 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. You are charged for the entire minimum storage duration of IA objects if the IA objects are stored for less than the minimum storage duration. The following examples show how IA objects are charged when lifecycle rules based on the last access time are configured:

      Example 1: A Standard object is converted to an IA object 10 days after the object is created, and then is converted back to a Standard object five days later based on a lifecycle rule. In this case, you are also charged for the remaining 15 days of the IA objects minimum storage duration of 30 days.

      Example 2: A Standard object is converted to an IA object 10 days after the object is created, and then is deleted 15 days later based on a lifecycle rule. In this case, you are also charged for the remaining five days of the IA objects minimum storage duration of 30 days.

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

    • 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.

FAQ

  • Why does a lifecycle rule not take effect immediately after it is created?

    After a lifecycle rule is configured, 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, it takes 48 hours at most for a lifecycle rule to take effect after it is created.

  • What will happen 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 at the same time. The first rule specifies that all objects 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 prefixed with doc in examplebucket is converted to IA 30 days after the objects are last accessed.

    If the first rule is implemented, no fees are incurred after the specified objects are deleted based on the rule. If the second rule is implemented, you are still charged storage fees and data retrieval fees after the storage class of the specified objects is converted based on the rule. In this case, only the first lifecycle rule takes effect because OSS implement lifecycle rules based on which fewer fees are incurred.

  • When does a lifecycle rule take effect after I modify the rule? What will happen 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 30 days later. In this case, if you change the prefix that you specify in the lifecycle rule from er to re 35 days after the objects 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 the lifecycle rule is modified, the last access time of the objects whose names contain the re prefix is tracked after access tracking is enabled for the bucket.

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

    In a versioned bucket, each object has a unique version ID. Objects with different version IDs are stored as different objects. Therefore, 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 that of a previous version of the same object.

  • Can I disable access tracking?

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