Configuring Lifecycle
Last updated: 2025-12-03 11:50:24
Scenarios
With lifecycle configuration, the predefined action can be automatically performed when a rule applies to objects. For example:
Transition storage class: After a specified period, objects can be automatically transitioned to different storage classes, such as Infrequent Access Storage (STANDARD_IA), Intelligent Tiering Storage (INTELLIGENT_TIERING), Archive Storage (ARCHIVE), and Deep Archive Storage (DEEP_ARCHIVE).
Expiration: Deletes objects after their specified expiration time.
How to Use
Using the COS Console
1. Log in to the COS Console.
2. In the left sidebar, click Bucket List to enter.
3. Find the bucket to enable the lifecycle function, click its bucket name, and enter the Bucket Details Page.
4.
Select
the basic configuration > lifecycle configuration item on the left. Configuration items are described below.
Access Tracking: If you wish to set a lifecycle rule based on "last access time", enable this option. When enabled, the activation time for access tracking will be the last access time for all objects in a bucket. You may configure the policy type as Last Access Time in Step 5.
Note:
Access Tracking is an allowlist feature and requires allowlisting before usage. Please contact your business representative or contact us. It will take effect on the same day after allowlisting.
Access Tracking feature usage restriction statement is as follows:
Currently only support enabling access tracking for buckets in Beijing, Shanghai, Guangzhou, Beijing Zone 1, Chongqing, Singapore, and Nanjing.
OFS integrated buckets do not support enabling access tracking.
5. Click Add Rule. Configuration items are described.
Basic information
Rule Name : Enter a name for your lifecycle rule.
Policy Type: Divided into last modification time and last access time. This configuration item is only applicable to users added to the access tracking allowlist.
Last Modification Time: Set rules based on the last modification time of objects.
Last Access Time: Set rules based on the last access time of objects. This configuration item requires allowlisting and enabling the access tracking feature (can be enabled in Step 4). Currently only supports downgrading to infrequent access storage.
Note:
After enabling access tracking, COS will start recording the access time of objects in the bucket. All access behaviors before enabling access tracking will not be included in access time analysis.For example, daily statistics on April 1 found that object a (standard storage) had not been accessed for 10 days. Access tracking was enabled that day, and a lifecycle rule was configured as "Tiering to low-frequency storage 5 days after the last access time of object a". Object a will be archived to low-frequency storage on April 6, not April 2.
Scope: This lifecycle rule can apply to the entire bucket or specific objects in the bucket.
When selecting the specified scope, configure at least one of the following:
Object Prefix: You can specify objects with the same object key prefix to execute the lifecycle rule. Regular expressions are not supported.
Object Tag: You can specify objects with the same tag to execute the lifecycle rule. Multiple tags are supported. Note that it is case-sensitive. If you choose the policy type based on last access time, this item cannot be configured.
Note:
You can specify both object prefix and object tag. The relationship between object prefix and object tag, or between object tags, is "AND" (all conditions must be satisfied simultaneously). For example, if you specify the object prefix as "doc" and the tag key-value pair as
group = IT in the lifecycle rule, the specified object range includes all objects in the current bucket with the object key prefix "doc" and the object tag group = IT.When selecting the entire bucket, you can choose whether to configure the exclusion range, which is off by default. Settings can be done based on the following configuration items:
Object Prefix: You can exclude objects with the same file prefix from executing the lifecycle rule. Currently, only one exclusion prefix can be configured. Note that the current exclusion range configuration does not support fusion buckets.
Rule configuration
Select and configure the following information based on the selected policy type.
Manage current version files: You can enable the option to manage current version files to transition or delete current version objects. Objects in the bucket can be transitioned from STANDARD storage (hot data) to STANDARD_IA storage (cold data), or deleted after expiration.
The storage types from hot to cold are: STANDARD > STANDARD_IA > INTELLIGENT_TIERING > ARCHIVE > DEEP_ARCHIVE. Storage type conversion can only be performed from hot to cold, not in reverse. For an introduction to storage types and region descriptions, see Storage Class Overview.The time is calculated based on the file's modification time in COS. Modifying an object is equivalent to re-uploading the object.
Note:
For buckets with multi-AZ configuration enabled, the lifecycle transition order only supports Standard Storage (Multi-AZ) > Infrequent Storage (Multi-AZ) > Intelligent Tiering Storage (Multi-AZ)/Archive Storage (Multi-AZ).
Manage Files of Historical Versions: You can enable this option to transition or delete historical version objects. If this option is not enabled, we will only process the latest version objects by default.
Note:
The transition and deletion of earlier versions are calculated based on the time when the object becomes an earlier version, not the upload time of the earlier version.
Clean up deletion markers without historical versions: To clean up deletion markers without historical versions, enable the following two items simultaneously.
Enable the "Manage Files of Historical Versions" option and set expiration and deletion for historical versions.
2.Enable the "Clean up deletion markers without historical versions" option.
Note:
This option takes effect depending on the rule for cleaning up historical versions. When you check this option, if the latest version of an object is a deletion marker and the last historical version object is deleted via lifecycle, the remaining multiple deletion markers will be automatically cleaned up on the second day. For example, after the historical version cleanup is completed on January 1, the deletion markers will be automatically cleaned up on January 2. For details, please refer to ExpiredObjectDeleteMarker.
This option cannot be used with expiration and deletion in Managing the current version files simultaneously.
Delete Incomplete Multipart Uploads: When uploading a file, the upload fails due to various reasons, and only a part of it is transmitted. For such damaged files, you can set periodic deletio
Manage Version Files: You can enable this option to determine whether to tier version objects by specifying the file's consecutive access days and access count below a certain threshold. Objects in the bucket can be tiered from the standard type (such as Standard Storage) to the infrequent type (such as Infrequent Storage). Once enabled, both current and earlier versions will be tiered.
6. After confirming the information is correct, click OK, and you will see the lifecycle rule.
Note:
After setting a lifecycle rule, repeated modifications may affect its execution. For details on rule effectiveness, see explanation of rule effective time.
7. If you need to stop a lifecycle rule, click Edit, change the status of the corresponding rule to Close or directly delete the lifecycle rule.
8. If you need to clear all lifecycle rules in the current bucket, click Clear All Rules.
Rule Execution Priority
Each bucket can add up to 1,000 lifecycle rules. If multiple rules are configured for the same group of objects and conflicts exist, COS will execute the lifecycle rules according to the following priorities based on different types of conflicts. For more detailed information, please refer to Lifecycle Overview - Configuration Elements - Operation.
Note:
Tencent Cloud COS strongly reminds you not to configure multiple lifecycle rules with conflicting conditions for the same set of objects, as conflicting executions may lead to different expense performances.
Different Operations of the Same Lifecycle Rule
If you configure a lifecycle rule and set different operations (such as transition and deletion) for the same group of objects in the rule, the execution rules and examples for these operations are as follows:
Execute the Rule | Example |
If both deletion and transition operations are applicable at the same time, the deletion operation takes precedence. | Rule R1: 1. The file test.txt will transition to infrequent access storage after being modified for 90 days. 2. The file test.txt will be deleted 90 days after modification. Expected outcome: Priority execution for 2, the file test.txt will be deleted after 90 days; execution of 1 failed. |
If multiple deletion operations are applicable at the same time, prioritize the shorter time deletion operation. | Rule R1: 1. The file with the specified prefix a will be deleted after 180 days. 2. Files with the specified prefix aa will be deleted after 90 days. Expected result: Assume that the bucket has the file aaa.png, specifying the prefix a and specifying the prefix aa both hit the same file aaa.png, prioritize 2, and the file aaa.png is deleted after 90 days; 1 fails to execute. |
If multiple transition operations are met at the same time, prioritize the transition operation with colder target storage type. | Rule R1: 1. The file test.txt will transition to infrequent access storage after being modified for 90 days. 2. The file test.txt will transition to archive storage 90 days after modification. Expected outcome: Priority execution for 2, the file test.txt will be transition to archive storage after 90 days of modification; execution of 1 failed. |
Different Operations For Different Lifecycle Rules
If you configure multiple lifecycle rules and set different operations (such as transition and deletion) for the same group of objects in different rules, the execution rules and examples for these operations are as follows:
Execute the Rule | Example |
If multiple different deletion and transition operations among rules are applicable at the same time, prioritize the shortest deletion time operation. | Rule R1: 1. The file test.txt will transition to infrequent access storage 50 days after modification. 2. The file test.txt will be deleted 10 days after modification. Rule R2: 1. The file test.txt will transition to infrequent access storage 10 days after modification. 2. The file test.txt will be deleted 30 days after modification. Expected outcome: Match rule R1, prioritize executing 2; the file test.txt is deleted 10 days after modification; if rule R2 execution fails, the execution of 1 in R1 also fails. |
If multiple deletion operations among different rules are applicable at the same time, prioritize the shorter time deletion operation. | Rule R1: Delete the file test.txt 10 days after modification. Rule R2: Delete the file test.txt 30 days after modification. Expected outcome: Match rule R1; the file test.txt is deleted 10 days after modification; rule R2 execution fails. Rule R3: Delete the file example.txt 10 days after modification. Rule R4: Delete the file example.txt 10 days after modification. Rule R5: Delete the file example.txt 50 days after modification. Expected outcome: Match rule R3 or R4; the file example.txt is deleted 10 days after modification; rule R5 execution fails. |
If multiple rules with different transition operations are satisfied simultaneously, prioritize the transition operation with the colder target storage type. | Rule R1: The file test.txt will be transition to infrequent access storage 10 days after modification. Rule R2: The file test.txt will be transition to archive storage 10 days after modification. Expected outcome: Match rule R2; the file test.txt is transition to archive storage 10 days after modification; rule R1 execution fails. Rule R3: The file example.txt will be transition to infrequent access storage 10 days after modification. Rule R4: The file example.txt will be transition to archive storage 10 days after modification. Rule R5: The file example.txt will be transition to archive storage 10 days after modification. Expected outcome: Match rule R4 or R5; the file example.txt is transition to archive storage 10 days after modification; rule R3 execution fails. |
Using the REST API
Configure and manage the lifecycle of objects in a bucket through the REST API as described in the following API documentation:
Using SDKs
Directly call the lifecycle method in the SDK. For more information, see the SDK documentation for the corresponding programming language below:
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback