Build Glacier vault lock policy configurations for compliance with time-based retention and delete prevention.
Build Glacier vault lock policy configurations for compliance with time-based retention and delete prevention.
Required Fields
VaultNamePolicy.StatementOutput will appear here...The builder validates that VaultName and Policy.Statement resolve before accepting the JSON as a plausible Vault Lock policy document; it can't validate the policy against Glacier's actual InitiateVaultLock API (which would return a lock ID and start the 24-hour window), that only happens once you actually submit the policy to a real vault.
Build a Glacier Vault Lock policy, an IAM-policy-shaped document that, once locked, becomes immutable even to the account root user, enforcing compliance controls like a minimum retention period via a NumericLessThan condition on glacier:ArchiveAgeInDays. The InitiateVaultLock/CompleteVaultLock two-step process is deliberate: after InitiateVaultLock, the policy sits in an editable, testable state for 24 hours before CompleteVaultLock permanently locks it, and once truly locked, there is no path to loosen or delete the policy, only to let it continue enforcing exactly what's written, so any mistake in the policy (an overly broad Deny, a wrong retention number) becomes permanent.
Never call CompleteVaultLock without thoroughly testing the policy during the 24-hour InitiateVaultLock window, including verifying legitimate access (audit reads, expected deletions after the retention period) still works, a locked policy cannot be fixed, only lived with.
A retention-period Deny statement protects archives from deletion but doesn't protect against never being able to delete them even after the retention period passes, if that's not the intent, verify the NumericLessThan condition's threshold is exactly what's mandated, not overly conservative.
Vault Lock is specifically for Glacier vaults (not S3 Object Lock, which is the analogous but separate mechanism for S3 buckets), don't confuse the two when documenting compliance controls, they're different services with a similar immutability concept.
No, once CompleteVaultLock is called, the policy is permanently locked and cannot be edited, and there is no delete-the-lock operation, this is by design, since the entire point of Vault Lock is to create a compliance control that even the account owner can't weaken later. This is why the 24-hour InitiateVaultLock testing window matters so much, that's the only opportunity to catch a mistake before it becomes permanent.
The deletion is denied, a properly locked Vault Lock policy with a retention-based Deny statement applies even to the root user, that's the entire security property Vault Lock provides over a regular IAM or bucket policy (which the root user or an admin could otherwise modify or bypass). This makes it suitable for regulatory retention requirements that specifically need to survive even a compromised or malicious privileged account.
Deny statements alone control what's prohibited, but without any explicit Allow, access still depends on the requester's own IAM permissions elsewhere, Vault Lock policies commonly combine targeted Deny statements (for the compliance-mandated restrictions) with explicit Allow statements for legitimate operations (like audit read access), rather than relying solely on Deny and hoping IAM permissions elsewhere line up correctly.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.