Lifecycle rules based on access Time (Atime) can automatically monitor data access patterns, automatically tier cold data that is not accessed or has low access frequency, thereby reducing storage costs.
Use Limits
The lifecycle feature based on access time is an allowlist feature. If you need to use it, please contact us.
Lifecycle rules based on Atime only support tiering to STANDARD_IA. They do not support deletion or other operations (such as fragment cleanup and deletion marker removal).
You must first enable access tracking for a bucket before you can add lifecycle rules based on Atime. The statistics of access frequency are related to the time when access tracking is enabled.
You must delete all rules based on Atime before you can disable access tracking.
After versioning is enabled:
Rule configuration requirement: In lifecycle rules based on Atime, for the same rule, the access frequency elements (the time element RecentDays and the access quantity element AccessCountLessThan) for both current version and non-current version transition operations must be identical.
Actual tiering behavior for non-current versions: The system starts recording the access time after an object becomes a non-current version and performs tiering based on this record.
MAZ buckets do not support enabling access tracking, which means they do not support the use of Atime lifecycle rules.
Lifecycle rules based on Atime only support prefix filtering (Prefix and PrefixNotEquals). They do not support Tag-based filtering or filtering by object size parameters.
Enabling Access Tracking
Note:
Enabling access tracking will incur Atime monitoring and management fees. However, COS does not currently charge these fees.
Before configuring lifecycle rules based on Atime, you must first enable access tracking for the bucket. The analysis of access logs and the statistics of access frequency are related to the time when access tracking is enabled. Access tracking can be disabled. However, before you disable access tracking, you must delete all rules based on Atime. You can enable access tracking via the console Lifecycle Configuration or via the API PUT Bucket Access Monitor.
Lifecycle Configuration Elements Based on Atime
Similar to lifecycle rules based on last modification time, lifecycle rules based on Atime support the following elements.
ID: A customizable description of the rule.
Status: Indicates whether the rule is enabled or disabled.
Filter: Identifies objects to which the rule applies.
Action: Specifies actions that need to be performed on objects that match the above description.
Access frequency: Consists of the RecentDays and AccessCountLessThan parameters. It indicates that if the number of accesses within the last N days is less than M, the lifecycle rule is executed.
Configuration Element Description
Filter Element
It supports filtering objects to which the rule applies based on prefixes or by excluding prefixes. However, it does not support Tag-based filtering or filtering by object size.
Action Element
It only supports the Transition operation, and only allows tiering to the STANDARD_IA storage class.
<Transition>
<StorageClass>STANDARD_IA</StorageClass>
<AccessFrequency>
<AccessCountLessThan></AccessCountLessThan>
<RecentDays></RecentDays>
</AccessFrequency>
</Transition>
If versioning is enabled for a bucket, you must also configure a NoncurrentVersionTransition operation for historical version objects. The transition days and access frequency conditions for both operations must be identical.
<NoncurrentVersionTransition>
<StorageClass>STANDARD_IA</StorageClass>
<AccessFrequency>
<AccessCountLessThan></AccessCountLessThan>
<RecentDays></RecentDays>
</AccessFrequency>
</NoncurrentVersionTransition>
Lifecycle rules based on Atime do not support configuring operations such as expiration deletion, cleanup of incomplete multipart uploads, or cleanup of deletion markers within the same rule.
Access Frequency Element
The AccessFrequency element contains the RecentDays and AccessCountLessThan elements. It indicates that if the number of accesses within the last N days is less than M, the lifecycle rule is executed. RecentDays supports a maximum of 3650 days, and the default value for AccessCountLessThan is 1.
<Transition>
<StorageClass>STANDARD_IA</StorageClass>
<AccessFrequency>
<AccessCountLessThan></AccessCountLessThan>
<RecentDays></RecentDays>
</AccessFrequency>
</Transition>
Time Description
Access Days Judgment and Tiering Rules
1. The Atime access day window is calculated based on calendar days. For example, if an object is uploaded at 14:00 on the 5th, it is considered to have reached one day by early morning on the 6th, not at 14:00 on the 6th.
2. The tiering operation is executed between 00:00 and 12:00 on the following day. Consequently, objects that meet the tiering criteria may remain as STANDARD for part of that day before being transitioned to STANDARD_IA later.
3. The decision on whether to tier objects is based on the logs from the previous day. If an access occurs on the day the tiering operation is scheduled to execute, the tiering will still be performed.
Tiering Example
For example, a user configures a rule to tier objects to STANDARD_IA if they are not accessed within one day. Object A is uploaded at 14:00 on July 2, 2024, is not accessed on July 2, and is downloaded once at 02:00 on July 3.
COS transitions the object to STANDARD_IA before 12:00 on July 3. The specific transition time is random. For example, if the transition is executed at 06:00, the object will appear as STANDARD from 00:00 to 06:00 and as STANDARD_IA after 06:00. The bill for the 6th is charged based on STANDARD_IA.
Note:
We recommend that you add an extra day as a buffer for tiering execution. For example, if your expectation is to tier objects after one day of no access, we recommend setting the rule to two days.
Usage Instructions
Using the COS Console
Configure the lifecycle via the CSP console. For more information, see Set lifecycle in Console Guide.
Using the REST API
You can directly use the REST API to configure and manage bucket access tracking and lifecycle rules. For details, see the following API documentation:
