Overview
When you need to periodically convert the storage class of or delete specified objects to reduce costs, you can use the lifecycle management feature. Currently, lifecycle rules can be created based on policies using the last modified time and last access time. COS will automatically transition or delete specified objects within the set timeframe according to your configured rules. Note:
Each bucket can have up to 1000 lifecycle rules.
Applicable Scenarios
Logging
If users use object storage to store log data, they can configure the lifecycle to automatically archive the log data after 30 days or delete it after 2 years.
Hot and Cold Tiering
Hot data often experiences a surge in access frequency shortly after upload, followed by a gradual decline in access frequency over time or no longer requires real-time access. You can configure lifecycle rules to transition data older than 30 days to STANDARD_IA storage, and further transition data older than 60 days to ARCHIVE storage. This process is called data transition.
Note:
COS now supports INTELLIGENT_TIERING, which automatically transitions data between storage tiers based on user access patterns to reduce storage costs. For details, see Introduction to INTELLIGENT_TIERING. Archive Management
When you use COS for file archiving management, it is often necessary to retain all historical versions of files for the long term according to compliance requirements such as financial and medical regulations. In such cases, you can use the lifecycle feature to transition historical versions of files to archival storage.
Configuration Element
To create a lifecycle rule, you need to configure the following elements.
Resource Scope
The resource scope for lifecycle rule execution can be customized, including the scope of application and the data types covered. When lifecycle rules are executed, the system scans the user-specified application scope and performs operations on the configured data types within that scope. The application scope can cover all objects in the bucket or specific objects filtered by the following rules:
Specify by object prefix: supports matching based on directory prefixes or filename prefixes.
Specify by object Tag: filter data by object Tag.
The supported configurable data types include:
Current version files: the latest version of objects in the bucket.
Historical version files: historical version objects stored after version control is enabled. For more information on version control, see version control overview. Delete markers: "markers indicating that an object has been deleted". The lifecycle feature supports automatically removing these markers after all historical versions are deleted. For more details about delete markers, see Delete Marker Documentation. Fragments: generated when a multipart upload task is incomplete.
Actions
When target objects are specified, perform the following operations: transition data and expiration deletion.
Transition Data
Transition objects to STANDARD_IA, INTELLIGENT_TIERING, ARCHIVE, or DEEP_ARCHIVE storage classes a specified number of days after their last modification date.
Supported regions
Supports public cloud regions. Financial cloud regions only support transitioning data to the STANDARD_IA storage class.
Unidirectional principle
Data transition is unidirectional, only allowing transitions from STANDARD > STANDARD_IA > INTELLIGENT_TIERING > ARCHIVE > DEEP_ARCHIVE. Jump-level transitions (such as STANDARD > ARCHIVE) are supported, but reverse transitions are not. To restore data from colder storage classes to hotter ones, you can only call PUT Object - Copy (for non-archive/deep archive storage types) or POST Object restore (only applicable to ARCHIVE/DEEP_ARCHIVE storage types). Final consistency
If multiple conflicting rules (excluding expiration deletion configurations) are configured for the same group of objects, COS prioritizes executing the rule that transitions to the coldest storage class.
For example, Rule A is configured to transition to STANDARD_IA 90 days after file modification, while Rule B is configured to transition to ARCHIVE 90 days after file modification. If both rules apply to the same object test.txt, Rule B takes precedence.
|
| | Transition to STANDARD_IA | 90 days after file modification | Conflicting rules, execution failed. |
| | | 90 days after file modification | |
Note:
Lifecycle does not perform transition operations for objects smaller than 64KB.
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 result in different cost behaviors.
Transitioned data does not alter the object's original upload or modification time.
Deletion upon Expiration
Setting the expiration time for the object so that it is automatically deleted upon expiration.
Processing logic
When an object matches the specified lifecycle expiration deletion rule, Tencent Cloud adds the object to the asynchronous deletion queue. The actual deletion time will have a certain delay compared to the creation time. You can obtain the current status of the object through GET or HEAD Object operations.
Final consistency
If multiple rules are configured for the same group of objects and there are conflicting situations, COS will execute based on the shortest expiration time, and the execution priority of expiration deletion is higher than that of storage class transition.
For example, Rule C is configured to transition to STANDARD_IA 180 days after file modification, while Rule D is configured to delete the object 180 days after file modification. If both rules apply to the same object test.txt, Rule D takes precedence.
|
| | Transition to STANDARD_IA | 180 days after file modification | Conflicting rules, execution failed. |
| | | 180 days after file modification | |
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 result in different cost behaviors.
Time Condition
Specify the time conditions for triggering the above operations. There are two cases:
For buckets without versioning enabled or the latest version of objects in versioning-enabled buckets, the corresponding operation is performed a specified number of days after the object's (Last-Modified) time.
For buckets with versioning enabled, the transition and deletion of previous versions are calculated based on when the object became a previous version, not based on the object's Last-Modified time.
Note:
Supports setting a maximum of 3650 days.
File Modification Time Notes
The lifecycle supports triggering rule execution based on the object's modification time. Some operations will change the file modification time, such as write operations to the file. PUT Object, PUT Object - Copy, POST Object, Complete Multipart Upload and other APIs will update the object's modification time, while transitioning objects through the lifecycle will not update the modification time. Execution Days Description
The number of days specified in the rule is based on 24-hour periods. Any period less than 24 hours does not count as one day.
For example, if you configure a lifecycle rule at 3 PM on the 1st to delete files one day after modification, the lifecycle task will start scanning at 00:00 on the 2nd for files whose last modification time exceeds one day prior to 00:00 on the 2nd, and perform deletion. Files uploaded on the 1st will not be deleted since their last modification time does not exceed one day. They will be scanned and deleted at 00:00 on the 3rd.
Usage Method
Rules Effective Time Description
Lifecycle rules take effect through two operations: daily scanning and execution.
Scanning: COS will pull lifecycle rules at 00:00 Beijing time (GMT+8) daily to scan all objects within the applicable scope.
Execution: If an object is scanned and reaches the date specified by the rule, transition or deletion operations are performed.
For example, a user configured Rule A on January 20, 2023, specifying that test.txt be deleted 10 days after its modification time. Then, starting from 00:00 on January 21, 2023, the modification time of test.txt is scanned daily at 00:00. Assuming the file's last modification time is January 15, 2023, the scan task at 00:00 on January 26, 2023 will determine that the file meets the deletion condition, and after scanning, the deletion operation will be executed.
Note:
Do not change the rule status during rule scanning and execution. Changes will cause the original rule to be terminated, and cannot ensure the correct execution of transition or deletion operations.
Fee Instructions
Request Fees
Performing deletion and transition operations in the lifecycle will incur request fees.
Each delete object operation performed by the lifecycle incurs a request fee.
Performing one transition operation in the lifecycle (for example, transitioning from STANDARD to STANDARD_IA storage class) incurs one request fee.
If two or more lifecycle rules apply to the same object and are scheduled to execute on the same day, the lifecycle prioritizes executing the rule with the coldest operation type (delete or transition) (see Final Consistency for details). Within the same day, only one transition/delete operation is performed, incurring only one request fee. For example: If one rule transitions objects to STANDARD_IA and another rule transitions them to ARCHIVE, the lifecycle only executes the rule transitioning objects to ARCHIVE, incurring one request fee.
If one rule transitions objects to DEEP_ARCHIVE and another rule deletes objects, the lifecycle only executes the delete rule, incurring one request fee.
If two or more lifecycle rules apply to the same object but execute on different days, the lifecycle will perform multiple operations, incurring multiple request fees accordingly.
Early Deletion Fee
Please note that STANDARD_IA must be stored for at least 30 days, ARCHIVE for at least 90 days, and DEEP_ARCHIVE for at least 180 days.If objects are deleted or transitioned prematurely via the lifecycle before the minimum storage duration, an early deletion fee will be charged.Tencent Cloud COS does not check whether the lifecycle contains rules with durations less than 30/90/180 days; all configurations will be executed as per your requirements.
|
Objects in STANDARD_IA storage class that have been stored for 20 days | Execute the delete operation in the lifecycle | An additional 10-day STANDARD_IA storage fee will be charged as an early deletion fee. |
STANDARD_IA objects stored for 10 days | The lifecycle performs a transition operation to ARCHIVE storage. | An additional 20-day STANDARD_IA storage fee will be charged as an early deletion fee. |
Execution Instructions
Currently, Tencent Cloud does not provide billing commitment for lifecycle execution effectiveness, meaning object billing will change upon completion of lifecycle execution.
When an accident occurs or there are too many objects in the bucket, lifecycle execution may fail. For failures due to other reasons, perform the GET or HEAD Object operation to get the current object status.
Size limitation. STANDARD_IA, ARCHIVE, and DEEP_ARCHIVE storage classes enforce minimum object size restrictions. For example, uploading a file smaller than 64KB to STANDARD_IA will be billed as 64KB. To reduce user costs, the lifecycle will not transition storage classes for objects smaller than 64KB.