What is OSS lifecycle management - Object Storage Service

Data access frequency decreases over time. Lifecycle management lets you create rules that automatically transition objects to lower-cost storage classes (such as Infrequent Access or Archive) or delete them after a specified period, reducing storage costs without manual intervention.

How it works

Lifecycle management uses user-defined rules to automate operations on objects in a bucket. OSS loads a new rule within 24 hours of creation. After loading, OSS executes matching rules at a fixed time daily, typically after 00:00 (UTC) the next day (08:00 UTC+8).

A lifecycle rule consists of three main parts:

Objects to manage: Filter target objects by object prefix (Prefix), object tag (Tag), or object size (ObjectSize).

Lifecycle rules do not support wildcard characters, suffix matching, or regular expressions.
Actions to perform: Define what to do with filtered objects:
- Storage class transition (Transition): Transition objects to lower-cost storage classes such as Infrequent Access, Archive, or Cold Archive.
- Expiration and deletion (Expiration): Delete objects after they reach a specified lifecycle period.
- Fragment cleanup (AbortMultipartUpload): Automatically delete parts from incomplete multipart uploads after a specified time.
Trigger policies: Define when actions trigger:
- Last modified time (Last-Modified-Time): Transition or delete objects based on last modified time. Suitable for data with a clear lifecycle, such as logs and backups.
- Last access time (Last-Access-Time): After enabling access tracking, transition objects based on last access time. Suitable for unpredictable access patterns (such as a material library). Cold data is downgraded automatically and restored on access.

All configurable parameters are documented in Lifecycle configuration elements.

Configuration scenarios

Automatically clean up expired log files

Servers upload logs daily to a designated directory. Use a last-modified-time rule to delete all objects in a bucket after a specified number of days, releasing storage and reducing costs.

Use automatic storage tiering for hot and cold data

For data with uncertain access frequency (website images, videos, documents), enable access tracking and use a lifecycle rule based on the last access time to implement intelligent data tiering. The system transitions cold data to lower-cost storage classes based on actual access patterns.

Automatically clean up previous versions

With versioning enabled, overwrites and deletes are saved as previous versions. When a bucket accumulates many previous versions or expired delete markers, use a lifecycle rule based on the last modified time together with versioning to reduce storage costs. This reduces costs and improves object listing performance.

Automatically clean up fragments from multipart uploads

Interrupted multipart uploads leave unmerged parts that continue incurring charges. Configure a lifecycle rule to clean up incomplete parts after a specified time.

In addition to the preceding scenarios, you can implement more fine-grained data management policies. For more information, see Lifecycle configuration examples. You can combine different rules to achieve fine-grained management of data in your bucket as needed.

Multiple lifecycle rules

Multiple lifecycle rules rely on two mechanisms: rule execution priority and the configuration overwrite mechanism.

Rule execution priority

A bucket can have multiple independent lifecycle rules. When an object matches multiple rules, the final action is determined by all matching results.

When multiple rules match the same object at the same time, they are executed in the following order of priority: Delete Object > Transition to Deep Cold Archive > Transition to Cold Archive > Transition to Archive > Transition to Infrequent Access > Transition to Standard.

Important

The delete action always has a higher priority than storage class transitions. Set the time for delete rules to be longer than the time for transition rules. This prevents objects from being deleted before the transition is complete.

Execution example

Assume you specify the following two lifecycle rules, and both rules match the same object.

Rule 1: Specifies that objects last modified more than 365 days ago are transitioned to the Infrequent Access storage class.
Rule 2: Specifies that objects last modified more than 365 days ago are deleted.

Result: The object that matches the rules will be deleted more than 365 days after its last modification time.

Configuration overwrite mechanism

The console handles merging automatically, preventing accidental overwrite. However, when using ossutil, SDKs, or the API, each PutBucketLifecycle call completely overwrites all existing lifecycle configurations. Submitting a new rule without including existing ones deletes those rules.

Example

If you want to add a new rule to your existing rules, perform the following steps:

Retrieve all currently effective lifecycle rules (for example, Rule 1).
Add the new rule (for example, Rule 2).
Resubmit the complete configuration that includes all rules (Rule 1 + Rule 2).

Note: If you submit only the configuration containing the new rule (Rule 2) without including the existing rule (Rule 1), Rule 1 will be deleted and will no longer be effective.

Going live

To deploy lifecycle management safely in production:

Test before you deploy: Create rules in a test bucket first. Verify behavior before applying them to production.
Use delete rules with caution: Set the prefix precisely to prevent accidental deletion of important data.
Enable versioning as a safeguard: For critical data, enable versioning so that objects accidentally deleted by a lifecycle rule can be recovered from a previous version.
Use tiered transitions to avoid extra fees: Ensure the trigger time for each subsequent stage exceeds the sum of the previous stage's trigger time and its minimum storage duration. This avoids fees from premature transitions.
- Incorrect example: Standard 30 days -> Infrequent Access 40 days -> Archive Storage. The object stays in IA for only 10 days (< 30 days) before transitioning again, incurring a fee.
- Correct example: Standard 30 days -> Infrequent Access 90 days -> Archive Storage. The object stays in IA for 60 days (meeting the 30-day minimum) before transitioning to Archive at day 90.

Billing

Configuring lifecycle rules is free. Fees apply when rules execute and change storage state.

Request fees: Each storage class transition, object deletion, or part deletion generates a Put-type request. Fees are charged per request. Billing details are in Lifecycle fee description.

For buckets with many small files, request fees can be significant. Evaluate before configuring rules.
Storage fees: After transition, objects are billed at the new storage class rate.

Important
Storage classes such as Infrequent Access, Archive, and Cold Archive have minimum storage duration requirements (for example, 30 days for Infrequent Access and 60 days for Archive). If a lifecycle rule deletes or transitions an object before the minimum storage duration is met, you must pay for the remaining storage duration. To avoid conditional capacity fees for storage shorter than the specified duration due to transitions or deletions, see How do I avoid capacity fees for storage shorter than the specified duration?. Ensure that the minimum storage duration is met before transitioning or deleting.
Data retrieval fees: Lifecycle rules themselves do not incur data retrieval fees. However, accessing objects in storage classes such as Infrequent Access or Archive incurs retrieval fees.
- Reading an IA object directly incurs data retrieval fees.
- Reading an Archive object incurs data retrieval capacity fees for real-time access.
- Restoring an Archive object incurs Put-type request fees and retrieval capacity fees.
- Restoring a Cold Archive or Deep Cold Archive object incurs retrieval request fees, retrieval capacity fees, and temporary restored capacity fees.
Important
For Cold Archive and Deep Cold Archive objects, the fee varies depending on the retrieval priority you choose. A higher priority results in a higher fee.

FAQ

What is the difference between lifecycle rules based on last modified time and last access time?

The key differences:

Policy	Based on last modified time	Based on last access time
Scenarios	Suitable for data scenarios with fixed or predictable access patterns.	Suitable for data scenarios with unfixed or unpredictable access patterns.
Supports Object Deletion	This is supported.	No.
Object Recovery After Deletion	If versioning is not enabled, deleted objects cannot be recovered. If versioning is enabled, when a lifecycle rule deletes a current version object, it becomes a previous version and can be recovered. However, when a lifecycle rule deletes a previous version object, it cannot be recovered.	A policy based on last access time does not involve object recovery after deletion.
Reversibility Of Storage Class Transition	Not reversible. After an object transitions from Standard to IA, it cannot automatically transition back. Details are in Transition storage class. Transitioning to IA, Archive, Cold Archive, or Deep Cold Archive involves minimum billable size, minimum storage duration, and data retrieval fees. Details are in Transition storage class.	Reversible. When an object is automatically transitioned from the Standard storage class to the Infrequent Access storage class, you can also choose to have it return to the Standard storage class when it is accessed. Important An object is considered "accessed" only when it is accessed through a GetObject API call. Other API calls are not included. This also involves minimum billable size, minimum storage duration, and data retrieval fees. Details are in Lifecycle rules based on last access time.

Why is my lifecycle rule not working?

Check the following items:

Effective time: Has the rule been created for more than 24 hours? New rules need time to load.
Prefix matching: Is the prefix in the rule set correctly? For example, a folder should be logs/ instead of logs.
Time condition: Does the last modified or last access time of the object actually meet the specified number of days?
Prerequisite feature: If you are using a rule based on last access time, have you enabled the access tracking feature for the bucket?

After enabling versioning, I deleted an object. Why did my storage usage not decrease?

With versioning enabled, a delete operation only creates a delete marker. The original object becomes a previous version and continues occupying space. Create a lifecycle rule to clean up previous versions.

Will converted objects be restored if I delete the lifecycle rule?

No. Deleting a rule does not reverse already-executed actions. Manually restore converted objects to their original storage class.

Why does a deleted object still occupy space after versioning is enabled?

With versioning enabled, a delete operation creates a delete marker. The original object becomes a previous version and continues occupying space. Configure a rule to delete previous versions.

What should I do if I receive the error Set bucket lifecycle error, InvalidArgument, Days in the Transition action for StorageClass Archive must be more than the Transition action for StorageClass IA?

This error occurs because the transition times for different storage classes do not meet the requirements. The transition period configured for the bucket must satisfy: Infrequent Access < Archive < Cold Archive < Deep Cold Archive.

Can the OSS lifecycle feature perform data tiering or deletion actions by matching file suffixes?

Lifecycle rules do not support suffix matching (such as .png). Use the following workarounds:

Method 1: Store objects by using a specific prefix

Store objects with a specific suffix (such as .png files) in a dedicated directory with a prefix like images/. Then configure a lifecycle rule matching the images/ prefix.

Method 2: Use object tags

Add a tag (such as image:png) to all .png files, then configure the lifecycle rule to match by tag. For more information, see Tag objects.

Do lifecycle rules apply to existing objects in a bucket?

A lifecycle rule applies to all objects, including those uploaded before the rule was configured. For example, if a rule configured on October 7 deletes objects after 30 days, an object uploaded on October 5 is deleted on November 6, and an object uploaded on October 8 is deleted on November 9.

How do I modify one or more lifecycle rule configurations?

Assume your bucket has two lifecycle rules (Rule1 and Rule2) and you want to modify Rule1:

Call GetBucketLifecycle to retrieve all current lifecycle rules (Rule1 and Rule2).
Modify the configuration item of the Rule1 lifecycle rule.
Call PutBucketLifecycle to submit the updated rules (Rule1 + Rule2).

Are there log records for type transitions and expiration deletions performed by lifecycle rules?

Yes. All successful type transitions and expiration deletions performed by lifecycle rules are logged. The log fields are as follows:

Operation
- CommitTransition: Transitions the storage class.
- ExpireObject: Deletes an expired object.
Sync Request

lifecycle: The transition and deletion operations that were triggered.

OSS log fields are documented in Log field details. Log query billing is covered in Billing.

Can I create a single lifecycle rule to clean up both object delete markers and current version objects at the same time?

No, you cannot. You must create one rule to clean up object delete markers and another rule to delete current version objects.

How to quickly clean up all files in a bucket using lifecycle rules

Bucket with versioning disabled

For a bucket with versioning disabled, you only need to configure one lifecycle rule to automatically and quickly clean up all files and parts from incomplete multipart uploads.

Log on to the OSS console, go to the Bucket List page, and find the target bucket.
In the navigation pane on the left, choose Data Security > Versioning, and confirm that versioning is disabled for the bucket.
In the navigation pane on the left, choose Data Management > Lifecycle. Set a lifecycle rule to automatically delete all files in the bucket 1 day after their last modification. Also, automatically clean up parts from incomplete multipart uploads that were created more than 1 day ago.

Bucket with versioning enabled

After versioning is enabled for a bucket, it generates current version objects, previous version objects, parts from incomplete multipart uploads, and delete markers. You only need to configure one lifecycle rule to automatically and quickly clean up all of these.

Log on to the OSS console, go to the Bucket List page, and find the target bucket.
In the navigation pane on the left, choose Data Security > Versioning, and confirm that versioning is enabled for the bucket.
In the navigation pane on the left, choose Data Management > Lifecycle. Set a lifecycle rule to automatically delete all current and previous version objects in the bucket 1 day after their last modification. Also, automatically clean up parts from incomplete multipart uploads that were created more than 1 day ago. This rule also cleans up delete markers.

If I create two lifecycle rules for objects with the same prefix, one based on the last modified time and the other based on the last access time, which rule is applied?

For example, you create two lifecycle rules for the target bucket `examplebucket`. Rule 1 specifies that all objects with the prefix `doc` in the bucket are deleted 30 days after their last modification time. Rule 2 specifies that all objects with the prefix `doc` in the bucket are transitioned to the Infrequent Access storage class 30 days after their last access time.

OSS executes lifecycle rules based on the principle of minimizing user costs. Therefore, only Rule 1 takes effect. This is because Rule 1 deletes the objects after 30 days, which stops all fees from being generated. In contrast, Rule 2, which transitions objects to the Infrequent Access storage class, would still incur related storage or data retrieval fees.

When does a change to a configured lifecycle rule take effect, and how is the data matched by the original rule handled?

For example, you configure a lifecycle rule for objects with the prefix er. This rule transitions the objects to the Infrequent Access storage class 30 days after their last access time, and then transitions them back to the Standard storage class if they are accessed again after an additional 30 days. However, 35 days after an object's last access time, you change the prefix in the lifecycle rule from er to re. As a result, the object is transitioned to the Infrequent Access storage class, but the action to transition it back to the Standard storage class does not take effect. For objects that match the updated rule, their last access time is calculated from the time when access tracking was enabled for the bucket.

In a bucket with versioning enabled, how does intelligent tiering affect the storage classes of different object versions?

In a bucket with versioning enabled, each object version has a unique version ID and is treated as an independent object. Therefore, a previous version of an object might be in the Infrequent Access storage class, while the current version of the same object is in the Standard storage class.