Extending a Retention Period
A locked vault's retention period can always be lengthened, never shortened. What that extension actually does to the files already sitting in the vault is not the same operation on Azure as it is on AWS — the two providers diverge in a way that changes what an operator should expect.
Lengthen only, enforced at every layer
Both providers use the same Extend control in the dashboard: open the vault, choose Extend, and enter the new retention period. By default this applies to the vault’s currently active generation.
You can also select a prior, already-locked generation from the vault’s history and extend it instead, even though it is frozen and no longer receiving new files. Extending a generation that has already been superseded by a newer one is a normal, fully supported operation, and it does not touch the generation that replaced it in any way.
The target generation must already be locked, and the new retention period must be strictly longer than the vault’s current retention period. This is enforced not only by BYOVault:
- Azure’s own management-plane call rejects a shorter interval outright.
- AWS Object Lock refuses to move a retain-until-date earlier than the value already set.
Shortening a locked vault’s retention is not possible through BYOVault, and not possible directly against either provider’s own API.
Azure: the extension reapplies to every file already in the vault
Azure’s retention lock is a single, container-level immutability policy, not a per-file setting. Extending it does not touch each blob individually — it changes the policy’s interval, and Azure computes every blob’s effective unlock date the same way going forward: the blob’s own creation time plus the policy’s current interval.
Because that calculation is re-derived from the current policy rather than fixed at the moment each file arrived, a single extension automatically re-applies to every file already sitting in the vault, not only to files uploaded after the change.
There is no separate step to “re-lock” older files; they are already governed by the one container-level policy, and lengthening it lengthens them all in the same call.
AWS: the extension only affects files uploaded after the change
AWS Object Lock retention works the opposite way. The vault bucket has a default retention setting in Compliance mode, and each object’s own individual retain-until-date is calculated once, at the moment that object is written, from whatever the bucket default was at that exact time.
Extending the bucket’s default retention changes what gets applied to new uploads from that point forward. It does not reach back and recalculate the retain-until-date already stamped onto files that were uploaded earlier — those keep the original date they were given, on their own individual object versions, regardless of what the bucket default later becomes.
A file already in the vault can still have its own retention lengthened — just not as a side effect of changing the bucket default. Extending an existing object’s retention is a separate, individual call against that exact object version.
BYOVault has no bucket-wide “reapply to everything already here” operation for AWS the way Azure has built into its own service. Lengthening retention for every file already vaulted on AWS means looping that individual call once per object (or per object version, since Object Lock requires S3 Versioning) rather than a single policy-level change.
The confirmation you see after extending reflects this asymmetry directly: alongside the new retention period, it states whether the change applies to files already in the vault or only to files uploaded from that point forward — “yes” for an Azure vault, “no” for an AWS vault.
Side by side
| Azure Blob Storage | AWS S3 | |
|---|---|---|
| What is extended | The container’s single locked immutability policy | The bucket’s default Object Lock retention |
| Effect on files already in the vault | Automatic — every existing blob’s unlock date is recalculated from creation time plus the new interval | None — each object keeps the retain-until-date it was given at upload time |
| Effect on files uploaded after the change | Governed by the same, single updated policy | Governed by the new bucket default at the moment they are written |
| Extending an already-vaulted file individually | Not applicable — already covered automatically by the container policy | Possible, one object (version) at a time, via a separate retention call |
| Maximum number of extensions | Five, for the life of the container | No limit |
What this means when planning ahead
On Azure, a single extension is enough to lengthen protection for an entire vault generation’s existing contents, but that convenience is bounded: five lifetime increases is a hard ceiling, and a vault that has already used all five cannot be extended again.
The only way to apply a longer period after that point is to provision a new vault generation and let new files accumulate there under a fresh policy with its own five-extension allowance, while the original generation stays exactly as locked, and exactly as capped, as it already was.
On AWS, there is no such ceiling, but there is also no shortcut: reaching every file already in the vault requires addressing each object’s retention individually. A bucket default change alone will not extend protection for anything uploaded before that change took effect. See Planning Your Retention Period for choosing an initial period deliberately, given how differently the two providers handle a later change of mind.