Lifecycle rules based on last modification time automatically transition objects to colder storage classes or delete them, reducing storage costs.
Use cases
A healthcare provider uploads medical records to OSS. Records are occasionally accessed in the first six months, then rarely. A lifecycle rule transitions them to Archive after 180 days.
A company uploads hotline recordings to OSS. Recordings are actively used for 2 months, occasionally accessed until 6 months, and unneeded after 2 years. A lifecycle rule transitions them to Infrequent Access after 60 days, Archive after 180 days, and deletes them after 730 days.
To delete all objects in a bucket, configure a lifecycle rule that applies to the entire bucket and deletes objects after one day.
These transitions use OSS storage classes.
Limitations
Matching conditions
Lifecycle rules support matching only based on prefixes and tags. Wildcard matching, suffix matching, and regular expression matching are not supported.
Part expiration limitations
You cannot configure two or more lifecycle rules that contain a part lifecycle policy for objects whose names have overlapping prefixes. Examples:
Example 1
If you configure a lifecycle rule that contains a part policy for a bucket, you cannot configure another lifecycle rule that contains a part policy for any objects in the bucket.
Example 2
If you configure a lifecycle rule that contains a part policy for objects whose names contain the dir1 prefix in a bucket, you cannot configure another lifecycle rule that contains a part policy for objects whose names contain overlapping prefixes, such as dir1/dir2.
Storage class transition limitations
Considerations
Rule limit
A bucket supports up to 1,000 lifecycle rules. A single rule can include policies based on both last modification time and last access time.
Overwrite semantics
The PutBucketLifecycle operation overwrites the existing configurations of a lifecycle rule of a bucket. For example, if a lifecycle rule named Rule1 is configured for a bucket and you want to configure another lifecycle rule named Rule2 for the bucket, perform the following operations:
Retrieve Rule1.
Combine Rule1 and Rule2.
Update the configuration with the combined rules (Rule1+Rule2).
Effective time
OSS loads a lifecycle rule within 24 hours after the rule is created. After the lifecycle rule is loaded, OSS runs the rule every day at 08:00:00 (UTC+8).
For day-based rules, ensure at least 24 hours between the object's last modification time and the rule's execution start time (08:00 UTC+8). For example, if a rule deletes objects one day after upload, OSS processes an object uploaded on July 20, 2020 as follows:
Objects uploaded before 08:00:00 (UTC+8) on July 20, 2020 are deleted from 08:00:00 (UTC+8) on July 21, 2020 to 08:00:00 (UTC+8) on July 22, 2020.
Objects uploaded after 08:00:00 (UTC+8) on July 20, 2020 are deleted from 08:00:00 (UTC+8) on July 22, 2020 to 08:00:00 (UTC+8) on July 23, 2020.
Updating a lifecycle rule may interrupt the current day's lifecycle task. Avoid frequent updates.
Execution completion time
-
After a rule takes effect, lifecycle operations such as object deletion, storage class transition, and expiration of multipart upload parts are typically completed within 24 hours for up to 1 billion objects in the China (Hangzhou), China (Shanghai), China (Beijing), China (Zhangjiakou), China (Ulanqab), China (Shenzhen), and Singapore regions. In other regions, these operations are typically completed within 24 hours for up to 100 million objects.
-
Execution may take longer than 24 hours, and in some cases several days or weeks, if there are many objects to scan, many objects to which the lifecycle rule applies, many tags, many versions for a single object, or a high volume of new objects being written while the lifecycle task is running.
NoteIf versioning is enabled for the bucket, an operation on each version of an object is counted as a separate operation.
Billing
Storage class transitions and deletions incur storage and request fees. Lifecycle Fees.
OSS-HDFS buckets
Lifecycle rules for OSS files
To configure or modify a lifecycle rule based on the last modified time to match all objects in a bucket for which OSS-HDFS is enabled, use the NOT element to exclude the objects that are stored in the
.dlsdata/directory. This prevents lifecycle rule-triggered object deletion or storage class conversion actions from applying to OSS-HDFS data and consequently affecting read and write operations on OSS-HDFS data.
Lifecycle rules for HDFS files
To tier frequently accessed data in Standard and less frequently accessed data in Infrequent Access, Archive, or Deep Archive, use the Use tiered storage feature, which is based on lifecycle rules.
Lifecycle rules with versioning
Lifecycle storage class transitions do not create previous versions.
Components
Filter conditions
Match by prefix: Matches objects and parts with a specified prefix. You can create multiple rules with different, non-overlapping prefixes. Prefix naming follows Object naming rules.
Match by tag: Matches objects by specified key-value tags. A single rule can have multiple tags; the rule applies only to objects that contain all specified tags.
Lifecycle rule tags
Object tags
Matched
a:1,b:2
a:1
No
a:1,b:3
No
a:1,b:2
Yes
a:1,b:2,c:3
Yes
NoteTag-based rules do not apply to parts.
Match by prefix and tags: Matches objects with the specified prefix and tag filters.
Apply to entire bucket: Matches all objects and parts in the bucket.
NOT element: Excludes specific objects from a lifecycle rule that would otherwise match a prefix and tags. Specify the prefixes and tags to exclude. NOT element examples.
ImportantLifecycle rules can include multiple NOT elements. This feature is in invitation-only preview. Contact technical support to request access.
A single bucket supports up to 1,000 NOT elements. A single rule supports up to 100 NOT elements. The total Prefix elements across all rules is limited to 2,000.
After you configure multiple NOT elements, use the console to manage your lifecycle rules.
If the multiple NOT elements feature is not enabled, do not create multiple rules that each exclude a different subdirectory. NOT elements in different rules operate independently. For example, if rule1 excludes only dir/p1/, dir/p2/ is still matched and deleted by rule1. If rule2 excludes only dir/p2/, dir/p1/ is still matched and deleted by rule2. This results in deleting all files under the dir/ prefix.
Object expiration and actions
Expiration in days: The specified action executes N days after the object's last modification time. Applies to all objects in a non-versioned bucket and to current versions in a versioned bucket.
Expiration on a date: All objects last modified before the specified date expire and the action executes. Applies to all objects in a non-versioned bucket and to current versions in a versioned bucket.
Days since becoming noncurrent: A noncurrent version expires N days after becoming noncurrent, and the action executes.
Transition or delete expired objects as specified in Lifecycle configuration elements.
Part expiration and actions
Expiration in days: A part is deleted a specified number of days (N) after its last modification time.
Expiration on a date: All parts last modified before a specified date are deleted.
How rules work
Different prefixes
For example, a bucket contains the following objects:
logs/programl/log1.txt
logs/program2/log2.txt
logs/program3/log3.txt
doc/readme.txtIf a lifecycle rule specifies the prefix logs/, it applies only to objects that start with logs/. If the prefix is doc/readme.txt, the rule applies only to the object doc/readme.txt.
You can specify a prefix containing Chinese characters for a lifecycle rule.
When you perform a GET or HEAD operation on an object that matches an expiration policy, OSS adds the x-oss-expiration response header. expiry-date indicates the object's expiration date, and rule-id indicates the ID of the matching rule.
Same prefix and tags
When multiple rules with the same prefix and tags apply to an object, deletion takes precedence over storage class transition. For example, if rule1 deletes objects with prefix abc and tag a=1 after 20 days, rule2's storage class transition does not take effect.
Rule | Prefix | Tag | Action |
rule1 | abc | a=1 | Delete after 20 days |
rule2 | abc | a=1 | Transition to Archive Storage after 20 days |
Overlapping prefixes
rule1 transitions all objects with the tag a=1 to Infrequent Access (IA) after 10 days. rule2 deletes objects with the prefix abc and the tag a=1 after 120 days.
Rule | Prefix | Tag | Action |
rule1 | - | a=1 | Transition to IA after 10 days |
rule2 | abc | a=1 | Delete after 120 days |
rule3 transitions all objects with tag a=1 to Archive after 20 days. Because objects in Archive cannot be transitioned to Infrequent Access (IA), rule4, which transitions objects with prefix abc and tag a=1 to IA after 30 days, does not take effect.
Rule | Prefix | Tag | Action |
rule3 | - | a=1 | Transition to Archive Storage after 20 days |
rule4 | abc | a=1 | Transition to IA after 30 days |
NOT element
If you configure multiple lifecycle rules for the same bucket and one includes a NOT element, the NOT logic applies only within that specific rule. Examples:
Example 1
Lifecycle rule 1 deletes objects with the prefix dir/ in examplebucket after 100 days.
Lifecycle rule 2 uses a NOT element to delete all objects in examplebucket except those with the prefix dir/ after 50 days.
Once these lifecycle rules are active, objects in examplebucket are deleted as follows:
Object
Deletion behavior
Objects with the prefix dir/
Delete after 100 days
Objects without the prefix dir/
Delete after 50 days
Example 2
Lifecycle rule 1 uses a NOT element to delete all objects in examplebucket except those with the tag (key1:value1) after 30 days.
Lifecycle rule 2 deletes all objects in examplebucket with the tag (key2:value2) after 50 days.
Once these lifecycle rules are active, objects in examplebucket are deleted as follows:
Object
Deletion behavior
Objects without the tags key1:value1 or key2:value2
Delete after 30 days
Objects with only the tag key1:value1
Not deleted
Objects with only the tag key2:value2
Delete after 30 days
Objects with both the key1:value1 and key2:value2 tags
Delete after 50 days
Procedure
OSS console
Alibaba Cloud SDK
ossutil
Related API
To configure lifecycle rules via REST API (requires signature calculation), use PutBucketLifecycle.
FAQ
FAQ
Error: Set bucket lifecycle error, InvalidArgument, Days in the Transition action for StorageClass Archive must be more than the Transition action for StorageClass IA
Lifecycle rules and existing objects
Modify lifecycle rules
Delete lifecycle rules
Logging for lifecycle operations
Clean up delete markers and current versions
Transition from Infrequent Access to Standard
Related documents
By default, OSS uses an object's upload time as its
LastModifiedtime. Lifecycle transitions do not updateLastModified. What are the operations that affect the LastModified attribute of OSS objects?If you transition or delete an
Infrequent Access,Archive,Cold Archive, orDeep Cold Archiveobject before its minimum storage duration, an early deletion fee applies. How am I charged for objects whose storage duration is less than the minimum storage duration?Lifecycle rules support batch transitions or deletions only for an entire bucket or objects matching a prefix. To batch delete objects with a specific suffix, use the ossutil rm command.
To have OSS automatically monitor access patterns and transition cold objects, configure Lifecycle rules based on the last access time.
To view the storage class of all objects in a bucket, use List objects.



