摘要

  • AWS Backup Vault Lock 的合规模式在宽限期结束后约束删除操作，连 root 用户也不能随意撤锁；账户关闭后 90 天内未重开，AWS 仍会删除保险库内容。
  • 业务退役与历史记录退役是两项决定。跨账户副本、可用的重开身份和实际恢复结果，决定关户清单上的那一个勾会不会把企业的记忆一起勾掉。

保险柜很坚固，房契另有期限

公司终于买到了一把连自己人也打不开的锁。管理员不能因为账单难看就删掉备份，权限再高也得服从保留规则。安全团队可以松一口气。然后，另一张工单来了：这个业务已经结束，请关闭账户。

两张工单都可能办得完全正确，合在一起却把购买备份保护的目的办没了。

AWS Backup 的原始文档把边界写得很直接：关闭包含备份保险库的账户后，账户暂停 90 天，备份保持完整；期间没有重开，AWS 会删除保险库内容，即使已经使用 Vault Lock。

锁的确锁住了柜门。账户决定这座仓库还能不能继续存在。把前一个答案抄进后一个问题的验收表，企业就得到一种很昂贵的安心。

把删除权收走，是有价值的

Vault Lock 有不同模式。治理模式允许具备相应权限的用户改变保护；合规模式经过宽限期后，只要保险库仍有恢复点，客户、root 用户乃至 AWS 都无法修改或移除那把锁。选择后一种模式，就是主动放弃日后临时反悔的便利。

这种约束有实在的用途。公司可能希望一批历史记录撑过人员更替，也可能希望挡住持有高权限的破坏者。给最高管理员留一把万能钥匙，会把花钱购买的克制重新送回去。

关户规则划出的是这份克制的存续条件。若保留要求比产品寿命更长，承载备份的账户就必须有更长的经营安排。存储团队承诺了年限，撤销账户的团队便不能只看最后一台运行中的机器是否已经停下。

九十天里，存在与可用也分开了

AWS 的关户说明指出，关闭账户会构成终止该账户客户协议的通知。关户后的 90 天期间，要使用其中的内容与服务，必须先重开账户。永久关闭后，账户无法重开，原账户 ID 也不能重新使用。

于是，一份完整备份可以仍在那里，业务却拿不到它。企业购买恢复能力时，这段距离很要命。遇到需要翻查旧记录的争议，董事会通常不会接受“字节还没删”作为结案报告。

账户关停清单往往有一个漂亮的终点：应用退役、人员移交、成本中心清零。记录的任务可能还在继续。设想一个被撤销的产品线，团队已经散去，合同履行记录仍需要查询。若关户的人只接到消灭剩余开销的指令，完整完成自己的任务，就可能让别人的任务失去工具。这是一个管理情境，公开材料没有提供具体客户的关户清单或恢复测试；单家企业的风险要靠这两项证据判断。

重开的钥匙也有人保管

当前的AWS 重开账户文档已允许部分客户自助办理：账户由客户自行关闭，关闭时没有未付余额，使用该账户 root 身份，并在 90 天内提交重开请求。还需要有效的付款方式。普通 IAM 用户或角色不能代替 root 完成这项操作。

由 AWS 关闭的账户走另一条路：须在关闭之日起 30 天内支付未清余额，再联系支持。把所有情况概括成“反正有 90 天”会把付款与身份条件一起吞掉。

重开也要走到真正可用那一步。文档提醒，有些资源不会自动恢复运行，例如停止的 EC2 实例需要启动，RDS 数据库可能需要从关户时的快照恢复。账户重新亮灯，业务才能开始验收，不能直接宣布收工。

关户说明还列出一个近乎黑色幽默的依赖：root 邮箱使用同一账户内 Route 53 注册的域名，关闭账户可能让域名暂停，邮箱随之失效，恢复账户所需的通信渠道也就断了。负责保存钥匙的人，顺手把挂钥匙的墙拆了。AWS 明确要求先处理这个依赖。

另一个账户，必须真有另一份东西

AWS Backup 的跨账户复制方案提供了一条把历史留在别处的路径。源账户和目标账户需要属于同一个 AWS Organizations 组织；资源、区域、密钥和访问策略都有适用条件，冷存储层不支持这类跨账户复制。

普通流程是把备份复制到目标账户，再在那里恢复。只给另一个账户读取原账户的权限，记录仍住在原来的屋子里。目标副本会用目标保险库的密钥重新加密，但企业仍须验证副本已经完成、目标持有人可以使用它，恢复出来的内容确实有用。

同一组织里的两个账户也可能接受同一个关停决定。因此，第二份副本值得配上不同的存续理由：产品账户负责今天的服务，留存账户负责明天还必须回答的问题。多建一个名字，远不如明确谁有权结束它来得重要。

企业不必为每一段历史永久买单。它需要在最后一次关灯之前，把保留到哪天、由谁付钱、由谁恢复讲清楚。否则，安全团队守住了删除按钮，组织自己从账户层面把整张桌子撤走了。