公司，即使是大型公司，也没有像他们应该的那样定期考虑其主要云提供商拥有的基础设施之外的灾难恢复计划。今年 3 月，亚马逊网络服务 (AWS) 发生了大规模故障，直接影响了一些世界上最大的品牌，导致它们离线数小时。在这种情况下，这不是恶意攻击，但最终结果是一样的——中断。
当该组织的领导层向他们的 IT 部门询问这种中断是如何发生的时，大多数人都得到了一个可以接受的答案：是 AWS。亚马逊失败了，不是我们。但是，这个答案不应该被接受。
AWS 暗示它们是无懈可击的，但运行 IT 部门的人员运行它是有原因的。他们注定是怀疑者，他们的工作是建立冗余以保护系统免受任何一点故障的影响。其中一些公司使用 AWS 灾难恢复服务，但如果数据中心和所有需要在崩溃时启用故障保护的技术，那么你就失败了。这就是为什么我们需要使用与任何其他系统相同的逻辑来处理问题。如今，创建一个弹性的DoS抗性架构比以往任何时候都更加容易，该架构不仅考虑了传统的恶意活动，还考虑了关键的业务故障。该解决方案也不是纯技术性的，它需要基于使用现成技术的合理业务原则。
过去，企业灾难恢复架构围绕着拥有一个完全可操作的辅助位置。如果我们想要真正的弹性，那是唯一的选择。今天，尽管这仍然是您方法的基础支柱之一，但它不一定是唯一的答案。您需要更加谨慎地了解您的需求，并为每个环境/问题选择正确的解决方案。例如：
· A) 您仍然可以在自己的数据中心或云中构建它（将性能要求与业务价值等式相匹配）。
· B) 一些“备份即服务”将提供的不仅仅是云中的存储。他们提供出租资源（服务器在中断时运行您的公司环境）。如果您的企业能够维持足够长的时间以将其重新启动（几个小时），那么这可能是一个非常具有成本效益的解决方案。
· C) 对于非关键项目，依靠您当前使用的云提供商来提供近时故障保护。
底线****
无论您采用哪种方法，即使一切正常运行，您仍然需要解决“断电”现象或服务在主要位置或辅助位置恢复所需的时间。如果性能受损，自动将人员送到不同的位置更为重要。有几个人听说过 GSLB，虽然现在很多人都在使用它，但它并不是他们综合 DoS 方法的一部分。但它应该是。如果您的DDoS 缓解解决方案的目标是除了满足您批准的性能 SLA 之外，还确保提供不间断的服务；那么动态 GSLB 或基于基础设施的性能负载平衡必须成为任何设计的一个组成部分。
我们可以纯粹防御性地部署这项技术，就像我们传统上对所有 DoS 投资所做的那样，或者我们改变范式并部署技术来帮助我们超越预期。这使我们能够为每个单独的用户提供可能的最佳体验。Radware 基于动态性能的路由优化解决方案 (GSLB) 使我们能够为每一位用户提供独特的客户体验，无论他们来自哪里、如何访问环境或尝试做什么。同样的技术允许我们在发生 DoS 事件时重新路由用户，该事件导致整个站点因恶意行为、硬件故障或简单的人为错误而瘫痪。此功能可以作为产品或服务采购，因为它与环境/云无关并且部署相对简单。
我们可以得出的结论是，任何将未来站点故障归咎于云提供商的公司都应该被问到棘手的问题，因为今天解决这个问题比以往任何时候都容易。
