Summary

  • AWS Backup Vault Lock’s compliance mode restricts even root from removing the lock after its grace period. Account closure follows a separate rule: without reopening within 90 days, AWS deletes the vault’s contents despite the lock.
  • Ending a product and ending its records need separate decisions. A completed copy, a tested restoration and a destination account with a continuing owner turn archival succession into something usable.

An excellent lock, a terminating lease

The security team bought a useful inconvenience: nobody should be able to tidy away the company’s history just because the storage bill looks untidy. The retirement team received an equally sensible instruction: this business is finished; close its accounts. Both teams can perform beautifully while the company loses what the first team was paid to preserve.

The join between those instructions appears in AWS Backup’s Vault Lock documentation. Closing an account containing a backup vault starts a 90-day suspension with backups intact. Unless the account is reopened during that period, AWS deletes the contents even with Vault Lock in place.

A lock governs actions inside a container. Closing the account ends the container’s continuing service relationship. The safe can have an excellent door while the office that houses it has a terminating lease.

Buying the right to bind your successor

Vault Lock makes a real distinction between its modes. Governance mode permits changes by appropriately authorised users. Once the grace period ends in compliance mode, the customer, root and AWS cannot change or remove the lock while recovery points remain in the vault.

That restraint can be worth buying. A hurried administrator should meet an obstacle before destroying history. A destructive actor holding powerful credentials should face another barrier. An effortless override for the next person in charge would reduce the protection the company chose.

The account still needs a life long enough to carry that restraint. A product may finish selling before its transaction records finish working. If the latter need a longer future, someone must fund and administer their address after the product budget has packed up.

Intact is a different milestone from available

AWS’s account-closure guidance says closure serves as notice terminating the customer agreement for that account. Access to content and services during the 90-day post-closure period requires reopening. After permanent closure, the account cannot be reopened and its ID cannot be reused.

The copies can therefore remain intact while the department needing them faces an administrative recovery job. Someone trying to explain an old transaction needs the records, with enough time to use them. An assurance that the bytes have not yet disappeared will make a poor answer to the next question.

Consider a hypothetical retired division. Its employees move, its budgets close and a cleanup team is rewarded for eliminating residual costs. The colleague who will later need its delivery history may be nowhere near the closure meeting. The gap is an allocation of responsibility before it becomes a storage failure. Public documents provide no particular customer’s account inventory or restoration tests; those two records are needed to judge that customer’s exposure.

The way back has an owner

The current reopening instructions permit self-service where the customer closed the account and it had no outstanding balance at closure. The request must come through the account’s root identity within 90 days, with a valid payment method. An IAM user or role cannot stand in for root.

Accounts closed by AWS follow a different route: pay the outstanding balance within 30 days of closure, then contact Support. A calendar reminder carrying only the number 90 would omit an earlier condition.

Reopening also leaves work for the operating team. AWS lists starting stopped EC2 instances and restoring RDS databases from snapshots made at closure among the possible tasks. An active account makes the tools available again; the recovery still needs checking.

Even the contact channel can depend on the retiring account. The closure guidance warns about a root email address using a Route 53 domain registered in that same account: suspending the domain can break mail delivery. The company can dismantle the office that holds its spare key. AWS tells customers to resolve that dependency before closing.

A successor needs an actual copy

AWS Backup’s cross-account copy process offers a route to a copy in a destination account, followed by restoration there. Source and destination must belong to the same AWS Organizations organisation. Supported resources and Regions, permissions and suitable keys are part of the conditions. Cross-account copies into cold storage tiers are unsupported.

The copy is re-encrypted using the destination vault’s key. Giving another account permission to consult the original leaves the original at its old address. A handover needs a completed copy and evidence that its recipient can restore the required contents and use them.

Two accounts in the same organisation can still be swept up by one retirement decision. The destination needs a separate purpose: keeping specified records until a chosen date, with a named custodian and funding. A second account number does not write that mandate.

There is nothing commercially mysterious about deciding when history has finished earning its keep. Some records will deserve continued expenditure; others can reach an intentional end. The decision belongs before the last cleanup instruction. Otherwise, a company may purchase formidable resistance to deletion and then remove the address at which that resistance works.