AWS Daily Intelligence #28 - A retention clock that starts when something happens

Executive summary

On 8 September AWS added variable retention to S3 Object Lock, letting you apply WORM protection to objects whose required retention period starts with a future event. It is available in every Region including China, at no additional charge.

The gap it fills is a familiar one to anyone who has tried to implement a records policy literally. Real policies are written as "seven years after the contract ends", "five years after the claim is resolved", "six years after the account closes". Object Lock had no way to say that. A retention period starts counting at write time, and a legal hold does not count at all — it simply holds until removed, and the moment it is removed the protection is gone.

So teams picked one of two bad options: compute the longest plausible retention and apply it from the day the object landed, over-retaining by years; or place a legal hold and rely on a human, later, to remember to replace it with a bounded retention at exactly the right moment. Variable retention makes the second option atomic. You place an event hold with a duration, and when you release it, S3 sets the retain-until-date to the release time plus that duration.

What changed

Object Lock still offers retention periods and legal holds. What is new is that a retention period now comes in two types rather than one, and the second type defers the date it is counting to.

Mechanism	Clock starts	On removal or release
Fixed retention	At write time. You supply the retain-until-date, or a bucket default duration is added to the creation timestamp.	Not applicable — it expires on its own.
Legal hold	Never. It has no expiration date and remains in effect until removed.	Protection ends immediately.
Variable retention (new)	On release of the event hold.	Protection begins. The retain-until-date is fixed at release time plus the duration.

That inversion in the third column is the feature. It also makes the two holds easy to confuse in a runbook, because the operator action is the same word — release — and the consequence is opposite.

Architecture

Releasing a legal hold ends protection. Releasing an event hold starts it. Same verb, opposite outcome.

The behaviour worth internalising is what the retain-until-date means before the hold is released. It is not a commitment; it is a projection. While the event hold is on, S3 computes the date as the current time plus the duration, so it moves forward as time passes. AWS's own example: with a one-year duration, reading the date on 2027-01-01 gives 2028-01-01, and reading it again on 2027-02-01 gives 2028-02-01.

Two guardrails sit on top of that. First, the date is a ratchet — if you decrease the duration, S3 does not move the retain-until-date to an earlier value than it already holds. Second, you may specify a retain-until-date alongside the event hold, and S3 treats it as a minimum: the effective date is the later of that floor and the release time plus the duration. So "at least until 2029, and in any case a year after closure" is expressible in one object.

Event holds work at every scale Object Lock does. They can be set on individual objects, turned on as a bucket default so every new version starts with variable retention rather than a fixed date, or applied across an existing estate with S3 Batch Operations.

Business value

The saving is storage that was never required. An organisation applying "seven years" from write time to records whose clock should have started at contract completion is holding every object for seven years plus the contract's entire life. On a multi-decade relationship that is not a rounding error, and it is paid for every month.

The second value is audit simplicity. A policy stated as "seven years after closure" and implemented as "seven years from creation" requires someone to explain the difference to an auditor and argue it is conservative. Implemented as an event hold with a seven-year duration, the control now matches the sentence in the policy.

Security considerations

AWS lists a use case that is not about records management at all: a configurable recovery window against ransomware or accidental deletion. That is worth reading twice. A bucket default that places an event hold on every incoming version gives you objects that cannot be deleted while the hold is on, and a bounded, pre-agreed survival period once it is released.

Two constraints keep this honest. Object Lock works only in versioning-enabled buckets, and holds protect the specific version — they do not stop new versions being written or delete markers being added on top. And in compliance mode, protection is genuinely absolute: no user can delete a protected version, including the account root, and AWS states the only way to delete before expiry is to delete the AWS account.

That absoluteness cuts both ways with a mechanism whose duration is set now and whose clock starts later. Authorisation matters more here than with a fixed date, which is why the announcement points at IAM and bucket policy condition keys for enforcing minimum and maximum durations, and why the existing s3:object-lock-remaining-retention-days key is the right place to bound what an operator can set.

Cost considerations

The feature itself is free in every Region, including China. The cost is entirely in what you retain, and for most estates adopting variable retention this is a reduction rather than an increase — that is the point of it.

One direction to watch: a bucket default that turns on an event hold means every object version arrives protected and stays protected until someone releases the hold. An unreleased hold is unbounded storage. This is the same operational hazard as a legal hold left in place, and it wants the same answer — a report that lists holds by age.

Operational considerations

Release is the only moment that matters, and it is irreversible in the direction that counts. Once released, the retain-until-date is fixed, and in compliance mode nothing shortens it. A hold released by mistake does not lose the object — it starts the clock early, which may still be a compliance failure if the event has not actually occurred.

So the event that triggers release should be the thing that calls the API, not a person reading a ticket. Contract completion, account closure and claim resolution all exist as states in some upstream system; the release belongs on that state transition. CloudTrail logs every hold operation, and S3 Inventory reports hold status across buckets, which together give you the before-and-after evidence an auditor will want.

Tradeoffs

Approach	Works well when	Breaks down when
Fixed retention from write	The policy genuinely counts from creation — most logs, most backups.	The policy counts from an event. You over-retain by the whole life of the relationship.
Legal hold	The duration is genuinely unknown, such as an open audit or live litigation.	A period must follow the hold. Removing it ends protection at once, and the conversion is manual.
Variable retention	The duration is known and the start date is not — the common shape of a records policy.	Nothing in your systems reliably signals the event. An unreleased hold retains forever.

Implementation guidance

Start by finding what you are currently over-retaining. Any bucket whose default retention was derived by adding a policy period to a worst-case relationship length is a candidate, and S3 Inventory will tell you the object counts behind that decision.

Then pilot in governance mode rather than compliance mode. AWS explicitly suggests governance mode to test retention settings before creating a compliance-mode period, and that advice is worth more here than usual: a mistake in a duration only becomes visible at release, which may be years after configuration. Governance mode leaves you a documented escape via the bypass permission and header; compliance mode leaves you deleting the AWS account.

Wire the release to the upstream state change, not to a runbook step, and bound what operators can choose with the retention-days condition key before you hand the capability out.

Best practices

Write the policy sentence first, then pick the mechanism that matches its grammar. "After X" means variable retention; "from creation" means fixed.
Use the minimum retain-until-date alongside the duration when the policy has both a floor and a relative period.
Report on holds by age. An event hold nobody releases is indistinguishable from indefinite retention on the invoice.
Trigger release from the system that owns the event, so the compliance record and the business record cannot diverge.
Pilot in governance mode. The error surfaces at release, which is much later than configuration.

Who should adopt this

Anyone whose retention policy contains the word "after". In practice that is financial services, insurance, healthcare and anyone under SEC 17a-4, CFTC or FINRA — Object Lock carries a Cohasset Associates assessment for exactly those environments, and variable retention extends it to the clause those policies most often use.

It is also worth a look from anyone running Object Lock purely as a ransomware control, because the bucket-default event hold is a cleaner expression of "protected now, and for a defined window after we say so" than a fixed period chosen by guesswork.

Key takeaways

Variable retention defers the retain-until-date: you set an event hold plus a duration, and S3 fixes the date at release time plus that duration.
Releasing a legal hold ends protection. Releasing an event hold begins it. Do not let a runbook conflate them.
While the hold is on, the retain-until-date is a moving projection, not a promise — and it ratchets, so shortening the duration never pulls it earlier.
A separately specified retain-until-date acts as a minimum floor, so "at least until this date, and a year after the event" is one configuration.
Free, every Region including China, and applicable to individual objects, bucket defaults, or an existing estate through S3 Batch Operations.