Study guide
Technical reference and lesson notes
S3 Lifecycle Rules: Storage Transitions, Expiration, and Cleanup
Purpose of This Lesson
This lesson explains how to create an Amazon S3 lifecycle rule that automates object transitions, expiration, version cleanup, and deletion of incomplete multipart uploads. The main objective is to select the correct lifecycle action based on whether an object is the current version, a non-current version, or an expired object artifact.
Key Concepts
- Lifecycle rule: A background automation policy that applies scheduled actions to objects in an S3 bucket.
- Current version: In a versioned bucket, the most recent version of an object—the version normally presented to users.
- Non-current version: An older version that was superseded when a newer version was uploaded.
- Storage class transition: Moving an object to another S3 storage class after a specified number of days.
- Expiration: Configuring current object versions to expire after a defined period.
- Permanent deletion: Removing non-current object versions after a defined period.
- Delete markers: Versioning-related markers that can be removed through lifecycle configuration when they are expired.
- Incomplete multipart uploads: Multipart uploads that were started but not completed; lifecycle rules can clean them up.
S3 Lifecycle Rule Configuration
Lifecycle rules are created from the bucket’s Management area. A rule can be applied to all objects in the bucket, or the configuration can be scoped when appropriate. In the demonstrated configuration, the rule was named demo rule and applied to all objects.
The lifecycle configuration presents five broad action categories:
- Transition current object versions between storage classes.
- Transition non-current object versions between storage classes.
- Expire current object versions.
- Permanently delete non-current object versions.
- Delete expired objects, delete markers, or incomplete multipart uploads.
Current-Version Transitions
A rule can transition the current version of an object through multiple storage classes over time. For example, a timeline could move an object to:
- Standard-IA after 30 days
- Intelligent-Tiering after 60 days
- Glacier Instant Retrieval after 90 days
- Glacier Flexible Retrieval after 180 days
- Glacier Deep Archive after 365 days
The exact schedule should reflect how frequently the data is expected to be accessed and how long it needs to remain available in each storage class.
Non-Current-Version Transitions
Versioned buckets retain older object versions when newer versions replace them. These older versions can follow a separate, often faster, transition schedule. For example, a non-current version could move to Glacier Flexible Retrieval after 90 days if it is unlikely to be retrieved after that point.
The important decision is whether the schedule applies to the object currently visible to users or to an older version that has been superseded.
Expiring Current Versions
A lifecycle rule can expire current object versions after a specified number of days. In the demonstrated example, current versions were configured to expire after 700 days.
Expiration is different from transitioning an object to a colder storage class: expiration removes the current object according to the lifecycle configuration rather than merely changing its storage class.
Deleting Non-Current Versions
Non-current versions can be permanently deleted after a specified retention period. The example configured deletion after 700 days. This is useful for limiting the accumulation of superseded versions, but the retention period should be selected carefully because deletion is permanent within the lifecycle behavior described.
Cleanup of Expired Artifacts and Incomplete Uploads
Lifecycle rules can also address expired objects, delete markers, and incomplete multipart uploads. These actions help prevent abandoned or no-longer-needed artifacts from remaining in the bucket indefinitely.
Exam- or Assessment-Relevant Takeaways
- Distinguish current versions from non-current versions before selecting a lifecycle action.
- A current-version transition changes the storage class of the version currently presented to users.
- A non-current-version transition applies to an older version superseded by a newer upload.
- Current-version expiration and non-current-version permanent deletion are separate actions.
- Lifecycle rules can contain multiple transitions at different time thresholds.
- A lifecycle rule runs in the background after it is created; it is an automation configuration rather than a one-time manual operation.
- Review the lifecycle timeline before creating the rule to verify that each current- and non-current-version action occurs at the intended time.
Tool / Feature Decision Guide
| Requirement | Appropriate lifecycle action | Decisive consideration |
|---|---|---|
| Reduce storage cost for the active version over time | Transition current versions | The object currently displayed to users is becoming less frequently accessed. |
| Reduce storage cost for superseded versions | Transition non-current versions | The target is an older version retained by bucket versioning. |
| Remove current objects after a retention period | Expire current versions | The object should no longer remain as the current version after the configured age. |
| Remove old versions after retention | Permanently delete non-current versions | Superseded versions are no longer required after the retention period. |
| Clean up abandoned or expired artifacts | Delete expired objects, delete markers, or incomplete multipart uploads | The target is a lifecycle artifact rather than an ordinary current object transition. |
Common Traps / Misconceptions
- Treating current and non-current versions as the same: They can have different transition and deletion schedules.
- Assuming expiration is a storage-class transition: Expiration removes the object according to the rule; it does not simply move it to a colder class.
- Forgetting versioning behavior: Replacing an object in a versioned bucket creates a newer current version while the previous version becomes non-current.
- Using one schedule for every object state: Current versions may still be actively accessed while non-current versions can often transition sooner.
- Ignoring permanent deletion: Non-current-version deletion should not be configured casually when older versions may be needed for recovery or historical access.
- Skipping the timeline review: Multiple transitions can be configured, so verify the complete sequence before creating the rule.
Real-World Engineer / Analyst Notes
- Design the lifecycle timeline around access patterns, retention needs, and the distinction between active and superseded data.
- Use separate schedules for current and non-current versions when version history has a different business value from active data.
- Treat expiration and permanent deletion as retention controls, not merely cost-optimization settings.
- Include incomplete multipart upload cleanup in lifecycle planning so unfinished uploads do not remain as unnecessary storage artifacts.
- After configuring the rule, inspect the displayed timeline and confirm that the intended storage classes and day thresholds are present before activating the policy.
Quick Reference Summary
- Create S3 lifecycle rules from the bucket’s Management section.
- A lifecycle rule can apply to all objects in the bucket.
- Current versions are the latest versions visible to users.
- Non-current versions are older versions replaced by newer versions.
- Current and non-current versions can use independent transition schedules.
- Current versions can expire; non-current versions can be permanently deleted.
- Lifecycle cleanup can include expired objects, delete markers, and incomplete multipart uploads.
- Multiple transitions can form a timeline, such as Standard-IA → Intelligent-Tiering → Glacier classes.
- Review the timeline before creating the rule because the configuration runs automatically in the background.
Flashcards
Q: A versioned S3 bucket contains an object that users currently access. Which lifecycle target represents that object?
A: It is the current version—the newest version of the object and the one normally displayed to users.
Q: A newer upload replaces an object in a versioned bucket. What happens to the previous version for lifecycle purposes?
A: The previous version becomes non-current and can follow a separate transition or deletion schedule.
Q: When should you choose a current-version transition instead of a non-current-version transition?
A: Choose a current-version transition when the object users currently see should move between storage classes. Choose a non-current transition for an older superseded version.
Q: Can one S3 lifecycle rule define several current-version storage transitions?
A: Yes. A current version can be scheduled to move through multiple storage classes at different age thresholds.
Q: What is the decisive difference between expiring a current version and deleting a non-current version?
A: Current-version expiration removes the current object after its configured age, while non-current-version deletion permanently removes an older superseded version after its retention period.
Q: A superseded version is unlikely to be retrieved after 90 days. Which lifecycle strategy fits this scenario?
A: Configure a non-current-version transition to an appropriate archival storage class after 90 days, such as Glacier Flexible Retrieval in the demonstrated example.
Q: What is the purpose of reviewing the lifecycle timeline before creating a rule?
A: It verifies the order and timing of transitions, expirations, and deletions for current and non-current versions.
Q: Which lifecycle action addresses a multipart upload that was started but never completed?
A: The cleanup action for incomplete multipart uploads.
Q: Why might current and non-current versions need different lifecycle schedules?
A: Current versions may still be actively accessed, while superseded versions may have much lower retrieval needs and can transition or be deleted sooner.
Q: What happens after an S3 lifecycle rule is created?
A: The rule operates in the background and performs its configured actions according to the specified timelines.
Q: A team wants to remove old versions but retain the active version. Which lifecycle action should it use?
A: Permanently delete non-current versions after the required retention period, rather than expiring current versions.
Q: Which storage-class sequence illustrates a multi-stage current-version lifecycle from the lesson?
A: Standard-IA, Intelligent-Tiering, Glacier Instant Retrieval, Glacier Flexible Retrieval, and Glacier Deep Archive at progressively later thresholds.
Q: What is a major operational risk of configuring non-current-version deletion too aggressively?
A: Older versions may be permanently removed before they are no longer needed for recovery, history, or retrieval.
Practice Questions
Question 1
A versioned bucket contains a current object that should move to Standard-IA after 30 days, then to Glacier Instant Retrieval after 90 days. Which configuration is appropriate?
A. A non-current-version deletion rule only
B. A current-version transition rule with multiple time-based transitions
C. A delete-marker cleanup rule only
D. An incomplete multipart upload cleanup rule only
Correct answer: B
The object is the current version, and the requirement specifies multiple storage-class transitions over time.
Question 2
An object has been replaced by a newer upload. The organization wants the older version moved to Glacier Flexible Retrieval after 90 days. Which action should be selected?
A. Transition current versions
B. Expire current versions
C. Transition non-current versions
D. Delete expired objects only
Correct answer: C
The older object version is non-current because it was superseded by a newer version.
Question 3
An organization wants current versions removed after 700 days and superseded versions permanently deleted after the same period. What should the lifecycle rule contain?
A. Only a current-version transition
B. Current-version expiration and non-current-version permanent deletion
C. Only incomplete multipart upload cleanup
D. Only a non-current-version transition
Correct answer: B
Expiration applies to current versions, while permanent deletion applies to non-current versions; these are distinct lifecycle actions.
Question 4
Before activating a rule with several transitions and deletion actions, what is the most important validation step described in the lesson?
A. Rename the bucket
B. Review the lifecycle timeline and confirm the configured thresholds
C. Convert every object to a current version
D. Remove bucket versioning
Correct answer: B
The timeline shows what will happen to current and non-current versions and helps verify that the rule will act at the intended times.
WordPress Metadata
Suggested Slug:
s3-lifecycle-rules-storage-transitions-expiration
Meta Description:
Learn how Amazon S3 lifecycle rules transition current and non-current object versions, expire data, delete old versions, and clean up incomplete uploads.
Tags:
AWS, Amazon S3, S3 Lifecycle Rules, S3 Versioning, Storage Classes, Glacier, Data Retention, Data Lifecycle Management, Incomplete Multipart Uploads