This page provides ready-to-use lifecycle configuration examples for common Object Storage Service (OSS) scenarios. Each example shows the XML configuration and the equivalent OSS console setup, so you can choose the approach that fits your workflow.
How OSS resolves rule conflicts
When multiple lifecycle rules apply to the same object, OSS uses the following precedence rules:
Expiration overrides transition. If one rule expires (deletes) an object and another transitions its storage class at the same time, the expiration runs and the object is deleted. The storage class transition does not occur.
The earliest action wins for same-type operations. If two rules apply the same action type (for example, both transition to Infrequent Access (IA)) to overlapping sets of objects, the rule with the shorter day count applies first.
Non-conflicting rules both run. If rules apply different actions on different time axes with no overlap, both rules execute as configured.
Filter by prefix or apply to all objects
Each lifecycle rule requires at least one filter condition to define which objects it targets. Use a prefix to target a specific set of objects, or leave the prefix empty to apply the rule to all objects in the bucket.
Transition and expire objects with a specific prefix
Objects prefixed with doc/ (for example, doc/test1.txt and doc/test2.jpg) are transitioned to IA 180 days after last modification and deleted 365 days after last modification.
XML configuration
<LifecycleConfiguration> <Rule> <ID>test-rule0</ID> <Prefix>doc/</Prefix> <!-- Apply to objects prefixed with doc/ --> <Status>Enabled</Status> <Transition> <Days>180</Days> <!-- Transition to IA after 180 days --> <StorageClass>IA</StorageClass> </Transition> <Expiration> <Days>365</Days> <!-- Delete after 365 days --> </Expiration> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
Expire all objects after a fixed number of days
All objects in the bucket are deleted 300 days after last modification.
XML configuration
<LifecycleConfiguration> <Rule> <ID>test-rule1</ID> <Prefix></Prefix> <!-- Empty prefix: apply to all objects --> <Status>Enabled</Status> <Expiration> <Days>300</Days> <!-- Delete all objects after 300 days --> </Expiration> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
Expire all objects modified before a specific date
All objects last modified before 2023-12-30T00:00:00.000Z are deleted.
XML configuration
<LifecycleConfiguration> <Rule> <ID>test-rule0</ID> <Prefix></Prefix> <!-- Empty prefix: apply to all objects --> <Status>Enabled</Status> <Expiration> <CreatedBeforeDate>2023-12-30T00:00:00.000Z</CreatedBeforeDate> </Expiration> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
Overlapping filter conditions
The following examples show how OSS handles lifecycle rules whose filter conditions overlap.
Two rules with overlapping prefixes, different actions (no conflict)
Rule 1 transitions objects prefixed with test/ to Archive 30 days after last modification. Rule 2 deletes all objects in the bucket 365 days after last modification. Because the two actions target different time points, both rules run.
XML configuration
<LifecycleConfiguration> <Rule> <ID>test-rule1</ID> <Prefix>test/</Prefix> <Status>Enabled</Status> <Transition> <Days>30</Days> <!-- test/ objects: Archive after 30 days --> <StorageClass>Archive</StorageClass> </Transition> </Rule> <Rule> <ID>test-rule2</ID> <Prefix></Prefix> <!-- All objects: delete after 365 days --> <Status>Enabled</Status> <Expiration> <Days>365</Days> </Expiration> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
Rule 1
Rule 2
Two tag-based rules applied to the same object (conflict)
Rule 1 filters on tag tag1/value1 and transitions matching objects to IA after 180 days. Rule 2 filters on tag tag2/value2 and expires matching objects after 10 days. An object with both tags matches both rules.
Result: The object is deleted 10 days after last modification. Because the object no longer exists, the storage class transition in Rule 1 cannot run. Only Rule 2 takes effect.
When expiration and transition conflict on the same object, expiration always wins.
XML configuration
<LifecycleConfiguration> <Rule> <ID>test-rule1</ID> <Prefix></Prefix> <Tag> <Key>tag1</Key> <!-- Filter: objects tagged tag1=value1 --> <Value>value1</Value> </Tag> <Status>Enabled</Status> <Transition> <Days>180</Days> <!-- Transition to IA after 180 days --> <StorageClass>IA</StorageClass> </Transition> </Rule> <Rule> <ID>test-rule2</ID> <Prefix></Prefix> <Tag> <Key>tag2</Key> <!-- Filter: objects tagged tag2=value2 --> <Value>value2</Value> </Tag> <Status>Enabled</Status> <Expiration> <Days>10</Days> <!-- Delete after 10 days — overrides Rule 1 --> </Expiration> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
Rule 1
Rule 2
Two rules that both act at 365 days (conflict)
Rule 1 transitions all objects to IA after 365 days. Rule 2 deletes all objects after 365 days. Both rules match the same objects at the same time.
Result: Objects are deleted after 365 days. Expiration takes precedence, so the transition in Rule 1 does not occur.
XML configuration
<LifecycleConfiguration> <Rule> <ID>rule1</ID> <Prefix></Prefix> <Status>Enabled</Status> <Transition> <Days>365</Days> <!-- Transition to IA — overridden by Rule 2 --> <StorageClass>IA</StorageClass> </Transition> </Rule> <Rule> <ID>rule2</ID> <Prefix></Prefix> <Status>Enabled</Status> <Expiration> <Days>365</Days> <!-- Delete after 365 days — takes precedence --> </Expiration> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
Rule 1
Rule 2
Broader rule overrides narrower rule (conflict)
Rule 1 transitions objects prefixed with logs/ to IA after 180 days. Rule 2 transitions all objects to IA after 30 days. Because Rule 2 applies to all objects (including logs/ objects) and triggers earlier, it overrides Rule 1 for those objects.
Result: All objects in the bucket, including those prefixed with logs/, are transitioned to IA after 30 days.
XML configuration
<LifecycleConfiguration> <Rule> <ID>rule1</ID> <Prefix>logs/</Prefix> <Status>Enabled</Status> <Transition> <Days>180</Days> <!-- Overridden by Rule 2 for logs/ objects --> <StorageClass>IA</StorageClass> </Transition> </Rule> <Rule> <ID>rule2</ID> <Prefix></Prefix> <!-- Applies to all objects, including logs/ --> <Status>Enabled</Status> <Transition> <Days>30</Days> <!-- Triggers earlier — takes effect --> <StorageClass>IA</StorageClass> </Transition> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
Rule 1
Rule 2
Disable a lifecycle rule
Only rules with Status set to Enabled run. Disabled rules are stored but have no effect.
In this example, Rule 1 (disabled) targets logs/ objects and Rule 2 (enabled) targets documents/ objects. Only Rule 2 runs.
XML configuration
<LifecycleConfiguration> <Rule> <ID>test-rule1</ID> <Prefix>logs/</Prefix> <Status>Disabled</Status> <!-- This rule is inactive --> <Transition> <Days>100</Days> <StorageClass>IA</StorageClass> </Transition> </Rule> <Rule> <ID>test-rule2</ID> <Prefix>documents/</Prefix> <Status>Enabled</Status> <!-- This rule is active --> <Transition> <Days>50</Days> <StorageClass>Archive</StorageClass> </Transition> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
Rule 1
Rule 2
Lifecycle rules for versioned buckets
In a versioned bucket, each object has a current version and may have one or more noncurrent versions. For more information about versioning, see Versioning.
Transition and expire noncurrent versions
This rule applies three actions across the object lifecycle:
Current versions are transitioned to IA 10 days after last modification.
Noncurrent versions are transitioned to Archive 60 days after becoming noncurrent.
Noncurrent versions are deleted 90 days after becoming noncurrent.
XML configuration
<LifecycleConfiguration> <Rule> <ID>test-rule0</ID> <Prefix></Prefix> <Status>Enabled</Status> <Transition> <Days>10</Days> <!-- Current version: IA after 10 days --> <StorageClass>IA</StorageClass> </Transition> <NoncurrentVersionTransition> <NoncurrentDays>60</NoncurrentDays> <!-- Noncurrent: Archive after 60 days --> <StorageClass>Archive</StorageClass> </NoncurrentVersionTransition> <NoncurrentVersionExpiration> <NoncurrentDays>90</NoncurrentDays> <!-- Noncurrent: delete after 90 days --> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
Clean up expired delete markers
A delete marker expires when it is the current version of an object and all other versions of that object have been deleted. Expired delete markers accumulate over time and consume storage. Use this rule to remove them automatically.
XML configuration
<LifecycleConfiguration> <Rule> <ID>test-rule0</ID> <Prefix></Prefix> <Status>Enabled</Status> <Expiration> <ExpiredObjectDeleteMarker>true</ExpiredObjectDeleteMarker> </Expiration> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
Clean up incomplete multipart uploads
If a multipart upload is initiated but CompleteMultipartUpload is never called, the uploaded parts remain in the bucket and incur storage charges. Use AbortMultipartUpload to automatically remove these incomplete parts.
In this example, parts prefixed with logs/ are deleted 5 days after the upload is initiated.
XML configuration
<LifecycleConfiguration> <Rule> <ID>lifecyclerule1</ID> <Prefix>logs/</Prefix> <!-- Apply to incomplete uploads prefixed with logs/ --> <Status>Enabled</Status> <AbortMultipartUpload> <Days>5</Days> <!-- Delete incomplete parts after 5 days --> </AbortMultipartUpload> </Rule> </LifecycleConfiguration>OSS console For more information about configuring rules in the console, see Configure lifecycle rules.
