Planning Your Retention Period

The decision is one-directional from the moment of locking

Once a vault is locked, its retention period can move in exactly one direction: longer. Neither BYOVault nor either cloud provider accepts a shorter value than the period already in force — AWS Object Lock in Compliance mode and Azure’s locked immutability policy both reject it at the service level.

There is no operator override and no support escalation that reverses a lock or reduces a retention period once it has been set. Treat the number entered at provisioning as a real commitment, not a default to revisit casually later.

Why the two providers change the calculus

Extending a locked vault’s retention period later is supported on both providers. But what that extension actually reaches is not the same operation — and that asymmetry is exactly why the initial period deserves deliberate thought rather than a placeholder value.

• Azure Blob Storage computes every blob’s effective unlock date as its own creation time plus the container policy’s current interval. A single extension call automatically re-applies to every file already sitting in the vault, not only to files uploaded afterward — but that convenience is bounded: a container-level locked policy can be extended a maximum of five times over its entire life, a limit Azure enforces on the policy itself. BYOVault tracks how many of those five a given vault generation has used and refuses a sixth attempt outright, with an explicit error, once the count is exhausted.
• AWS S3 Object Lock has no such ceiling — the bucket’s default retention can be extended any number of times, with the only rule being that a new date can never be earlier than the one already in force. The tradeoff: extending the bucket default only changes what applies to uploads made after that change. It does not reach back and recalculate the retain-until-date already stamped onto files uploaded earlier — those keep whatever date they were given at the time, on their own individual object versions, regardless of what the bucket default later becomes.

See Extending a Retention Period for the full mechanics behind both of these, including exactly what BYOVault’s extend endpoint does and does not reach on each provider.

Practical guidance

• Choose the period deliberately, not provisionally. Because the direction can only be longer, a period set too long cannot later be reduced for data that turns out not to need it — that data simply stays locked for the full duration originally chosen, on whichever generation it was archived into.
• On Azure, treat each of the five extensions as a real decision, not a routine adjustment. A vault that has already used all five lifetime increases cannot be extended again under any circumstances; the only way to apply a longer period after that point is to start a new vault generation and let new files accumulate there under a fresh policy with its own five-extension allowance, while the original generation remains locked and capped exactly as it already was.
• If genuinely uncertain, starting shorter is the lower-risk direction on both providers — but for different reasons:
  • On AWS, there is no limit on how many times the period can be lengthened later, so a conservative starting value can be extended again and again as requirements become clearer, with no lifetime count to conserve.
  • On Azure, the same conservative instinct still applies, precisely because every extension spends one of only five the container will ever get. A shorter starting period that turns out to need lengthening once or twice is a far smaller commitment against that cap than repeatedly re-extending a period that was already set unnecessarily long from the start.
• A shorter starting period is not free on AWS, either. Because an AWS extension only changes the default applied to new uploads, lengthening protection for files already vaulted still requires addressing each object’s own retention individually. Choosing a period that is unlikely to need frequent revisiting reduces how often that individual, per-object work is necessary, even though AWS itself places no cap on attempting it.
• Decide before consent, not during provisioning. BYOVault requires explicit, recorded consent to the irreversibility of locking before provisioning can proceed at all. Treat that consent step as the last point to change course, not a formality to click through — the retention period entered in the same flow becomes exactly as permanent as the lock itself.

Side by side