An Old Dataset Version Can Have a New Lifecycle Age

Start with the version that changed state

In a versioning-enabled Amazon S3 general purpose bucket, a later write under the same key creates a new current version. The previous version remains stored and becomes noncurrent. Its contents have not acquired a new creation date; its relationship to the current version has changed.

That change selects a different lifecycle clock. Age-based current-version actions use the evaluated version's creation time. Noncurrent actions use the creation time of its successor to determine when it became noncurrent.

A dataset name can cover many keys and versions with different histories. Its project start date cannot supply those individual anchors. Before comparing a proposed day threshold, identify the version, its observed current or noncurrent state, and the event that starts the applicable interval. The named S3 behavior here follows AWS documentation checked on October 21, 2026.

References: [S3-VERSION][S3-AGE]

Observe a 20-day-old version that is one day noncurrent

LC244 is a fictional comparison involving one key in a versioning-enabled general purpose bucket. V1 and V2 are symbolic labels. V1 was created on October 1, 2026 at 10:30 UTC. Its successor, V2, was created under the same key on October 20 at 10:30 UTC, making V1 noncurrent.

At the observation time, October 21 at 10:30 UTC, V1 is 20 days old measured from creation and one day old measured from becoming noncurrent. V2 is current and one day old. Both descriptions of V1 are correct because they measure different intervals.

No lifecycle rule was active for these versions before this observation. The supplier is offering a hypothetical three-day noncurrent expiration condition. Three days is an invented comparison input, not a recommended retention interval. To isolate the age calculation, assume V1 matches the offered filter, with no version-count gate or competing restriction. Those assumptions must be checked separately in an actual proposal.

References: [S3-VERSION][S3-NONCURRENT]

Calculate V1's boundary from its successor

The noncurrent anchor for V1 is October 20 at 10:30 UTC, when V2 was created. Adding three days gives October 23 at 10:30 UTC. AWS's calculation then rounds upward to the next midnight UTC: October 24, 2026 at 00:00 UTC.

Under the stipulated proposal, October 24 at 00:00 UTC is V1's calculated age-eligibility boundary. At the October 21 observation, V1 has not reached it. The unrounded October 23 time is an intermediate arithmetic result, rather than the final boundary.

Starting instead from V1's October 1 creation would produce October 5 at 00:00 UTC after adding three days and rounding. That is the wrong anchor for V1's noncurrent condition. October 5 is a rejected calculation in this comparison, not a historical expiration event.

References: [S3-AGE]

The same date can select a different version

An Expiration action using Days addresses the current-version population. A NoncurrentVersionExpiration action using NoncurrentDays addresses noncurrent versions. A three-day current condition therefore cannot be read as expiring every version whose creation was more than three days ago.

V2 has its own creation time: October 20 at 10:30 UTC. If the comparison also considered a hypothetical three-day current-age condition for V2, its calculated boundary would likewise be October 24 at 00:00 UTC. That agreement is a consequence of the example's timestamps. One calculation concerns current V2; the other concerns noncurrent V1.

The action's effect also matters. For a versioning-enabled bucket whose current version contains data, current expiration adds a delete marker and makes that data version noncurrent. Older versions can remain stored. Permanent expiration of a noncurrent version is a separate action.

References: [S3-CURRENT][S3-NONCURRENT][S3-EXP]

Read the age boundary alongside the other conditions

In an actual offer, the filter and any NewerNoncurrentVersions condition still matter. Where that count condition is present, the age and version-count requirements must both be satisfied. A newer current V2 is not a newer noncurrent version merely because it is newer. The age calculation cannot stand in for the version-count assessment.

AWS also documents Object Lock and replication conditions that can prevent expiration actions. The teaching example excludes competing restrictions; a real supplier return must identify the applicable conditions rather than silently inherit that simplification.

Even when the complete rule is satisfied, processing is asynchronous. AWS distinguishes the time a rule is satisfied from completion of its action. October 24's calculated boundary consequently does not establish a removal timestamp or a guaranteed period of readable access. Nor does introducing a rule give existing versions a fresh creation date: lifecycle rules apply to existing as well as later objects.

References: [S3-NONCURRENT][S3-AGE][S3-EXP][S3-DELAY]

Return a version-specific calendar explanation

For LC244, the corrected return identifies V1 as noncurrent at the October 21 observation. Its noncurrent age starts with V2's creation on October 20 at 10:30 UTC. Adding the offered three days and rounding to the next midnight UTC gives October 24 at 00:00 UTC for V1, under the stated assumptions.

That explanation resolves the calendar disagreement for the supplied case. It gives the buyer a defined version, interval and boundary to compare with the offer. Actual rule applicability, completed removal and the data owner's retention authority require their own evidence.

Use the related Object Lock and Delete Marker guide when the question is which version remains stored or why its key appears deleted. Use the Minimum Storage Duration Billing guide when the question concerns a charge interval, and the Archive Restore guide when the question is whether archived contents are ready to read. None of those intervals replaces V1's successor-based lifecycle age.

Connect a separate physical project to the right service

If the wider project separately requires approved physical connections between compute and storage equipment, Leviathan's Structured Cabling & Fiber Installation service and project inquiry provide the relevant next step. Share the equipment, approved endpoints, requested cabling work and required connection records to discuss scope and availability. S3 administration and lifecycle decisions remain with the appointed storage and data owners.

References: [L1]