AWS CloudFront流量包代充 AWS KMS 密钥被误删除或停用导致全站服务崩溃的紧急救援流程
这类事故我见过不少：RDS 起不来、EBS 挂载失败、Secrets Manager 读不到密钥、应用启动直接报解密错误。表面看像“全站挂了”，根因往往只有一个：KMS Key 被停用，或者已经进入删除流程。
先说结论：“停用”和“进入删除等待期”通常还能救；真正删除后，绝大多数已加密数据无法直接恢复。所以第一件事不是重启服务器，而是先判断密钥处于什么状态。
一、先判断现在还能不能救
| 密钥状态 | 常见表现 | 第一动作 | 成功率 |
|---|---|---|---|
| Disabled（已停用） | 服务报解密失败、启动失败、挂载失败 | 立刻启用密钥 | 高 |
| Pending deletion（待删除） | 部分服务开始报错，已有任务逐步失败 | 取消删除，马上恢复状态 | 高 |
| Deleted（已删除） | 历史数据、快照、密文无法解开 | 转向备份恢复、业务降级 | 低 |
二、10分钟内的救援顺序
- 先冻结变更：停止发布、停止自动化脚本、暂停 Terraform/CI/CD，避免把错误继续扩散。
- 确认受影响资源：重点查 RDS、EBS、S3 SSE-KMS、Lambda 环境变量、Secrets Manager、SSM Parameter Store、CloudWatch Logs 加密。
- 登录 KMS 控制台看状态：如果是 Disabled，直接启用；如果是待删除，立刻取消删除。
- 检查是否有替代密钥：有些团队做了别名切换、双写、跨 Region 复制，这时候能快速把读写流量切到备用资源。
- 开工单并标注紧急级别：AWS 基础支持可以提交账户/账单问题；如果你有付费支持计划，直接走技术支持，响应速度明显不同。
三、不同场景怎么处理
1）只是被停用
这种最好处理。很多事故是误操作、脚本误点、权限过大导致。启用后，部分服务会自动恢复，部分服务需要你手工重试，例如：
- RDS 恢复连接后，应用侧可能还要重启连接池
- AWS CloudFront流量包代充 Secrets Manager 读取恢复后，容器要重新拉取 secret
- Lambda 如果启动失败过，需要重新触发
2）进入删除等待期
这是第二抢救窗口。你要立刻取消删除，不要等“观察一下”。不少团队以为只是清理无用密钥，结果误删的是生产库主密钥。
如果你们有合规要求，建议把删除等待期拉长到 30 天，而不是默认只用短周期。短周期看起来更“干净”，但出事后没有缓冲时间。
3）已经删除
这个阶段别抱侥幸心理。AWS KMS 的密钥不是“回收站删除”。如果没有提前做备份策略，能做的通常只有：
- 从未加密前的快照、数据库备份恢复
- 从应用层导出的明文配置恢复
- AWS CloudFront流量包代充 用旧系统中残留的未失效副本重建
如果历史数据、快照、Secrets 全都依赖这个密钥，往往就是不可逆损失。此时重点不是“找回密钥”，而是尽快止损、恢复最近一次可用备份。
四、为什么很多团队会在“账号”这一步就埋雷
我遇到过一种典型情况：业务主账号是临时申请的，权限分散在几个人手里，支付卡也不是公司卡。平时没事，一出事就进不去控制台、收不到验证码、Support 也开不了。
如果你是准备新开 AWS 账号做容灾或备份账号，建议按这个顺序准备：
- 账号所有权：必须用公司邮箱和公司主体，别用个人账号“代管”生产环境
- 实名认证/资料一致：注册信息、账单地址、付款卡持有人尽量一致，减少风控抽查
- 支付方式：优先用企业信用卡；虚拟卡、频繁换卡、低额度卡更容易触发支付失败
- MFA：Root 账号和至少两位管理员必须开多因子认证
- 备用联系方式：电话、邮箱、工单联系人不要只留一个人
五、风控审核和支付问题，常常拖慢救援
很多人以为只要会登录就行，实际上 AWS 的风控会卡在几个地方：
- 新号刚开通就大额跑 KMS、RDS、EC2，容易被判定异常使用
- 付款卡账单地址和注册资料不一致，可能要求补充验证
- 频繁切换国家/IP/设备登录，会触发安全验证
- 余额不足或信用卡扣款失败时，部分服务会被限制，连支持工单都可能受影响
实操建议：如果你准备把 AWS 当生产环境用，不要等事故来了才补资料。该做的验证、税务信息、付款方式、联系人权限，最好提前一次性补齐。
六、成本怎么比，才知道要不要上付费支持
很多公司出事故后才发现，省下的支持费远小于宕机损失。简单算一笔：
| 方案 | 直接成本 | 适用场景 | 局限 |
|---|---|---|---|
| 基础支持 | 低 | 非紧急、常规账户问题 | 技术响应慢，电话支持受限 |
| 付费支持计划 | 月费/按比例计费 | 生产环境、关键业务 | 仍然不能“恢复已删除密钥” |
| 双账号/双 Region 备份 | 额外资源费 | 不能接受单点失效的业务 | 架构复杂，平时要维护 |
如果你们系统每小时损失几千到几万，付费支持和备用架构通常比事后抢修便宜得多。真正省钱的不是“少买服务”，而是把密钥误删的概率降下来。
七、最常见的 5 个失败原因
- 把生产密钥和测试密钥混在一起，删错对象
- 只盯着主密钥，忽略了数据库快照和 secrets 也在用同一把 KMS Key
- 没有备份恢复演练，以为有快照就一定能恢复
- 账号权限过大，任何人都能停用/删除密钥
- 没有设置删除审批和告警，误操作后没人及时发现
八、我给生产环境的实际建议
如果你的业务已经依赖 KMS，至少要做这四件事：
- 对生产密钥加审批和最小权限，删除操作单独授权
- 把删除等待期设长，给误操作留缓冲
- 建立备份恢复演练，确认“备份能用”而不是“看起来有备份”
- 准备一个经过验证的备用账号或备用 Region，不要临时注册临时用
FAQ：用户最关心的几个问题
Q1：密钥被停用后，服务会不会自动恢复？
A：启用后通常会恢复一部分，但很多应用还需要重启、重试、刷新缓存。
Q2：已经删除了还能找回吗？
A：如果已经真正删除，通常不能找回。别把希望放在“联系支持就能恢复”上。
Q3：为什么要提前准备账号和付款方式？
A：出事时再补资料，经常卡在验证、支付、权限交接上，黄金救援时间会被浪费掉。
Q4：第二个 AWS 账号能直接解开原账号的密文吗？
A：不能。KMS 密钥和加密资源是强绑定的，跨账号不是“复制一下就行”。
如果你现在正遇到这类事故，先做两件事：确认密钥状态，再停止所有变更。这比盲目重建环境更重要。多数团队真正失败，不是因为技术不会，而是因为判断顺序错了。