AWS在2026年8月27日为Elastic Disaster Recovery推出Recovery Plans。多服务器应用可以预先定义恢复顺序，在事故或演练时通过一次操作依次启动数据库、应用服务和Web前端，不再要求运维人员逐台处理。
这项能力主要解决恢复流程中的依赖问题。单台云服务器能够启动，不代表整套业务已经可用；数据库尚未就绪时提前启动应用层，可能产生连接错误，而负载均衡过早接入Web服务器，也可能把用户流量送进未完成初始化的环境。
多层应用终于可以按依赖关系恢复
传统灾难恢复经常把服务器复制和业务恢复混在一起。DRS可以持续复制源服务器，但真正切换时，数据库、缓存、消息队列、应用服务和Web入口仍有各自的启动先后顺序。
Recovery Plans允许把源服务器放进有顺序的步骤中。例如第一步恢复数据库和目录服务，第二步启动应用层，最后再启动Web服务器与对外入口。
恢复计划编排的是服务器启动流程，而不是自动理解应用依赖。团队仍要根据真实架构决定哪些服务器属于同一步，以及服务达到什么状态后才能进入下一阶段。
同一步并行执行，步骤之间顺序推进
计划运行后，DRS会按照预设顺序执行每个步骤。同一步中的多台服务器可以并行恢复，系统会等待这些服务器全部进入终止状态后，再开始后续步骤。
这种方式能同时兼顾速度和依赖控制。数据库集群的多个成员可以一起启动，但应用层不会在数据库步骤尚未结束时提前执行。
用户还可以在步骤之间配置等待时间，为数据库重放日志、集群选主、缓存预热或服务注册保留窗口。等待时间应依据演练数据设置，不能只凭经验填写固定数值。
审批步骤保留人工确认入口
关键阶段可以加入审批步骤，让人员在流程中检查数据一致性、服务器健康状态和业务依赖，再决定是否继续。正式事故中，这能避免自动化在前置条件不满足时一路执行到底。
计划执行进度可以实时监控。遇到单台服务器失败或应用验证异常时，团队应根据预先制定的规则决定重试、跳过还是取消，而不是在事故现场临时讨论处理方式。
审批人员和权限需要提前确认。值班人员没有操作权限，或者所有审批都依赖同一个不可用账号，都会让自动恢复流程在最关键的环节停住。
同一套计划可以执行非破坏性演练
Recovery Plans支持drill模式，可以在不影响源服务器的情况下验证恢复步骤。团队可以使用与真实事故相同的计划，检查服务器能否按顺序启动，以及等待和审批设置是否合理。
演练不能只看EC2实例状态。数据库端口、应用健康检查、队列积压、DNS解析、证书、负载均衡后端和用户关键操作都需要纳入验证。
恢复脚本只有反复演练后才值得信任。每次应用架构、服务器分组、网络或启动脚本发生变化，都应重新运行演练并记录实际恢复时间。
恢复计划仍受账号和区域边界限制
AWS文档说明，一个恢复计划中的源服务器必须与计划位于同一AWS账号和区域。它不能直接把不同账号、不同区域的服务器塞进同一个计划统一编排。
该功能在所有提供AWS DRS的区域开放，除标准DRS使用费用外不额外收费。不过，演练和正式恢复创建的计算、存储、网络等资源仍会产生相应费用。
上线前应核对复制状态、启动设置、容量、子网、安全组、IAM和DNS切换流程。Recovery Plans减少的是手工启动顺序错误，完整灾难恢复仍需要数据保护、网络设计和业务验证共同配合。
