When you need to periodically convert or delete specified objects for storage type to reduce costs, you can use the lifecycle management feature. Currently, lifecycle rules can be created based on the last modified time and the last accessed time. COS will automatically convert or delete the specified objects within the specified time according to the rules you set. For more information about this feature, see Lifecycle Overview document.
Notes:
The maximum number of days supported for the lifecycle setting is 3650 days.
The lifecycle does not perform conversion operations on objects smaller than 64 KB.
2. In the left sidebar, click Bucket List to enter the bucket list page.
3. Find the bucket for which you want to enable the lifecycle feature, click its bucket name, and enter the bucket details page.
4.
Click Basic Configuration > Lifecycle on the left side, and the configuration item description is as follows.
Access Tracking: If you want to set a lifecycle rule based on "last access time", enable this option. After enabling, the access tracking start time is the last access time of all objects in the bucket. You can configure the policy type as last access time in step 5.
Note:
The Access Tracking feature is an allowlist feature and needs to be added to the allowlist before use. Please contact your business representative or contact us. It will come into effect immediately after being added to the allowlist.
The usage limitations of the Access Tracking feature are as follows:
Currently, Access Tracking is only supported for buckets in Beijing, Shanghai, Guangzhou, Chongqing, and Singapore.
Multi-AZ buckets and OFS fusion buckets do not support enabling Access Tracking.
5. Click Add a Rule. Configuration items are as follows.
Information
Rule Name: Enter your lifecycle rule name.
Policy Type: You can choose last modification time or last access time.This configuration item is only visible to users who have been added to the allowlist for the Access Tracking feature.
Last Modification Time: Set rules based on the last modification time of the object.
Last Access Time: Set rules based on the object's last access time. This configuration item needs to be added to the allowlist and the Access Tracking feature needs to be enabled (can be enabled in Step 4) before it can be configured.Currently, it only supports data settlement to infrequent access storage.
Note:
The activation time of the Access Tracking feature is the last access time of all objects in the bucket, with the start calculation time being the activation time of the Access Tracking feature.
Applied to: This lifecycle rule can apply to the entire bucket or to specified objects.
When a specified range is selected, please configure at least one of the following:
Prefix : You can specify objects with the same object key prefix to execute lifecycle rules, such as prefix/. Regular expressions are not supported.
Object Tag: You can specify objects with the same tag to execute lifecycle rules. Multiple tags can be specified, and case sensitivity for English letters should be considered. If you choose a policy type based on the last access time, this item cannot be configured.
Note:
The object prefix and object tag can be specified at the same time. The relationships between object prefix and object tag and between object tags are "AND" (i.e., all conditions must be met simultaneously). For example, specifying an object prefix of "doc" and an object tag key-value pair of group = IT in a lifecycle rule means that the specified object range is all objects in the current bucket with an object key prefix of "doc" and an object tag of group = IT.
When the entire bucket is selected, you can choose whether to configure exclusion range, which is disabled by default. The following configuration items are supported for settings:
Prefix: You can specify to exclude objects with the same file prefix from executing lifecycle rules. Currently, only a single exclusion prefix is supported. Note that the current configuration exclusion range does not support fusion buckets.
Rule Configuration
Depending on the selected policy type, choose to configure the following information.
Last Modified Time
Last Access Time
Manage the current version: You can enable the option to manage current version files to settle or delete current version objects. Supports objects in the bucket to settle from hot data such as standard storage to cold data such as infrequent access storage, and supports deletion of objects after expiration.
The storage types range from hot to cold as follows: STANDARD > STANDARD_IA > INTELLIGENT TIERING > ARCHIVE > DEEP ARCHIVE. Storage type conversion can only be from hot to cold, not in the reverse direction. For an introduction to storage types and a description of applicable regions, please refer to Storage Type Overview. Time is calculated based on the modification time of the file in COS. Modifying an object is equivalent to re-uploading the object.
Notes:
For buckets with multi-AZ configuration enabled, the lifecycle transition order only supports MAZ_STANDARD > MAZ_STANDARD_IA > MAZ_INTELLIGENT TIERING.
Managing historical versions: You can settle or delete historical version objects by enabling the option to manage historical version objects. If this option is not enabled, we will default to processing only the latest version of objects.
Note:
Settlement and deletion of historical versions are calculated based on when the object becomes a historical version, not according to the upload time of the historical version.
Remove Delete Markers from objects with no noncurrent versions: To clean up delete markers without historical versions, the following two configurations need to be enabled at the same time.
Enable the "manage files of noncurrent version" option and set expiration and deletion for historical version files.
Enable the "Cleanup Delete Markers without Historical Versions" option.
Note:
The effectiveness of this option depends on the rule for cleaning up historical versions. After selecting this checkbox, if the latest version of an object is a deletion marker (Delete Marker), when the last historical version object is deleted through lifecycle, the remaining multiple deletion markers will be automatically cleaned up the next day. For example: After the cleanup of historical versions is completed on January 1st, the deletion markers will be automatically cleaned up on January 2nd. For details, see ExpiredObjectDeleteMarker.
This option cannot be enabled at the same time as expiration and deletion in manage the current version file.
Deleting incomplete multipart uploads: When a file is uploaded, various reasons may cause the upload to fail, resulting in only a part of it being transmitted. For such damaged files, periodic deletion can be set.
Manage version files: You can enable the option to manage version files and determine whether to settle version objects by specifying the number of consecutive days of access and the number of accesses below which the file is considered for settlement. Supports settling objects in the bucket from standard storage to infrequent access storage. Once enabled, both current and historical versions will be settled.
6. After confirming the information is correct, click OK, and you will be able to see the lifecycle rule.
Note:
After setting the lifecycle rule, repeated modifications may affect the execution of the lifecycle rule. For notes on rule effectiveness, please refer to Rule Effectiveness Time Explanation.
7. To stop a lifecycle rule, click Edit, change the status of the corresponding rule to Off, or directly delete the lifecycle rule.
8. If you need to clear all lifecycle rules of 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 settlement 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 settlement operations are applicable at the same time, the deletion operation takes precedence.
Rule R1:
1. The file test.txt will settle into 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 settlement operations are met at the same time, prioritize the settlement operation with colder target storage type.
Rule R1:
1. The file test.txt will settle into infrequent access storage after being modified for 90 days.
2. The file test.txt will settle into archive storage 90 days after modification.
Expected outcome:
Priority execution for 2, the file test.txt will be settled 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 settlement 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 settlement operations among rules are applicable at the same time, prioritize the shortest deletion time operation.
Rule R1:
1. The file test.txt will settle into 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 settle into 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 settlement operations are satisfied simultaneously, prioritize the settlement operation with the colder target storage type.
Rule R1: The file test.txt will be settled to infrequent access storage 10 days after modification.
Rule R2: The file test.txt will be settled to archive storage 10 days after modification.
Expected outcome:
Match rule R2; the file test.txt is settled to archive storage 10 days after modification; rule R1 execution fails.
Rule R3: The file example.txt will be settled to infrequent access storage 10 days after modification.
Rule R4: The file example.txt will be settled to archive storage 10 days after modification.
Rule R5: The file example.txt will be settled to archive storage 10 days after modification.
Expected outcome:
Match rule R4 or R5; the file example.txt is settled to archive storage 10 days after modification; rule R3 execution fails.
