AWS于8月10日为Elastic Disaster Recovery增加Linux UEFI启动模式保留能力。采用UEFI固件启动的Linux源服务器经过AWS DRS恢复后，新的EC2实例会继续使用相同启动模式。
此前DRS会把这类Linux服务器以传统BIOS模式启动，恢复后可能需要额外调整分区、引导程序或系统配置。现在启动方式能够与源环境保持一致，灾难恢复流程少了一项容易影响开机的差异。
UEFI与传统BIOS启动方式并不相同
UEFI是现代服务器普遍采用的固件启动方式，通常与GPT分区、EFI系统分区和特定引导文件配合。传统BIOS则依赖另一套启动过程，两者并不是简单修改一个名称就能完全互换。
一台原本使用UEFI的Linux服务器被改成传统BIOS启动时，磁盘布局、GRUB安装位置和系统固件设置都可能不匹配。恢复实例虽然已经复制了数据，仍可能停在启动阶段或进入修复环境。
对于灾备系统，这类差异会延长恢复时间。运维人员需要在故障窗口内判断是磁盘复制问题、系统配置问题，还是固件模式造成的启动失败。
过去恢复实例会切换到传统BIOS
AWS DRS通过持续复制源服务器数据，在测试或故障切换时启动恢复实例。过去Linux源服务器即使采用UEFI，DRS创建的恢复实例仍会使用传统BIOS模式。
部分系统能够经过调整正常启动，但依赖UEFI行为的应用环境可能需要额外处理。维护脚本、磁盘识别方式和安全启动相关配置也可能因为启动模式变化出现差异。
这种问题不一定在复制阶段暴露。数据同步可以一直保持健康，真正启动测试实例时才发现引导异常，因此定期恢复演练比只观察复制状态更重要。
恢复实例现在自动沿用UEFI
新能力上线后，AWS DRS会识别Linux源服务器的UEFI启动方式，并在恢复时为EC2实例保留相同模式。整个过程自动完成，用户不需要另外开启选项或修改恢复模板。
启动模式一致能让恢复实例更接近源环境，减少为了适配固件而重新安装引导程序或调整分区的步骤。对恢复时间目标较严格的系统，这意味着故障切换中少一个人工排查点。
自动保留UEFI并不代表所有硬件差异都会消失。网卡名称、磁盘设备、实例驱动、内核模块与应用许可仍可能因为运行环境变化而需要验证。
测试恢复仍然不能省略
灾难恢复计划需要用测试启动验证，而不能只确认数据复制正常。管理员应检查系统能否完成引导、文件系统是否挂载、网络是否连通，以及数据库和业务进程能否按顺序启动。
UEFI相关检查还包括EFI系统分区、GRUB配置和内核版本。源服务器经历系统升级或磁盘调整后，新的复制状态也应重新进行恢复测试，避免旧演练结果失去参考价值。
测试环境应与正式故障切换配置尽量一致，包括目标子网、安全组、实例类型和IAM角色。只在隔离环境确认能开机，仍不足以证明业务可以接管真实流量。
所有DRS可用区域自动生效
Linux UEFI启动模式保留能力已覆盖所有提供AWS DRS的区域，而且不会产生额外功能费用。现有灾备方案无需单独申请预览，也不需要为启动模式保留增加配置。
用户仍会按照DRS、复制存储、测试实例和正式恢复资源的使用量付费。功能本身免费，并不代表完整灾难恢复架构没有成本，测试频率和跨区域复制流量都应纳入预算。
这次更新改善的是Linux服务器恢复时的环境一致性。对已经使用UEFI的生产系统，下一次演练应重点确认恢复实例确实沿用源服务器启动模式，并把验证结果更新到现有故障切换流程。
