AWS中断：经验教训 — API安全
我们可以从最近的AWS中断中学到什么？如何将这些经验应用到我们自己的基础设施中？
发生了什么？
2025年10月20日，AWS经历了一次重大中断，这次中断在整个互联网（和社交媒体）上产生了连锁反应，影响了Zoom、Microsoft Teams、Slack和Atlassian等广泛使用的服务。问题并非源于单个数据中心或客户工作负载，而是源于AWS控制平面——协调EC2实例、DynamoDB表和IAM角色等资源运行的管理层。
最初的触发因素似乎是US-EAST-1区域中DynamoDB API端点的DNS故障，加上监控网络负载均衡器的子系统出现故障。由于这些健康监控服务也在US-EAST-1中运行，AWS在恢复子系统时限制了新EC2实例的启动。
尽管AWS将其区域宣传为具有独立电源和冷却的数据中心隔离集群，但这次事件表明，核心控制平面功能仍然集中，创造了可能在全球范围内级联的隐藏依赖关系。
根本原因：单区域控制平面
分析师很快确定，US-EAST-1托管了支持大量全球服务的AWS通用控制平面。在欧洲或亚洲运行的工作负载实际上依赖于通过或路由到US-EAST-1的API调用，因此该区域的故障产生了全球性后果。
当该区域的DNS和健康检查子系统失效时，这些控制平面调用在全球范围内停滞。最终结果是EC2启动、配置更新和身份验证在全球范围内放缓，尽管其他区域在技术上是"健康"的。
AWS自己的设计指南鼓励客户跨可用区分布工作负载以实现弹性，但这些面向客户的弹性机制最终依赖于相同的集中式控制平面。换句话说，数据平面隔离按设计工作，但控制平面隔离没有。
这种模式以前就出现过，不仅仅是在AWS。Cloudflare、Microsoft和Google都曾遭受由控制平面或配置故障引发的全球性中断。这里的教训是，在现代分布式系统中，控制平面脆弱性可能成为单点故障。
更广泛的模式
AWS现在可能成为焦点，但纵观整个行业，几乎每个主要的云或CDN提供商（AWS、Cloudflare、Microsoft、Google）在过去五年中都经历过与控制平面相关的中断。这些很少由攻击引起；更多时候，它们源于常规操作变更、配置错误或集中式服务依赖。
2025年10月的AWS中断仅仅表明，没有云提供商能够免疫。最好的防御是架构性的：分散风险、解耦依赖关系，并设计优雅降级。
基础设施架构师的经验教训
理解和分析像AWS这样的大规模中断对于基础设施工程师至关重要。每个事件都揭示了设计假设与现实复杂性之间的差距，暴露了可能被忽视的弱点，并最终影响服务可用性。通过研究什么失败了、为什么失败以及恢复如何进行，架构师可以改进其基础设施和系统，使其更具容错性和弹性。这种持续学习的心态确保当下一次中断发生时，对用户和业务运营的影响最小化。那么，这里的关键教训是什么？
-
设计真正的多区域、主动-主动操作：如果控制流量无法到达，备用区域是不够的。以主动-主动配置运行，这样失去一个资源或区域不会禁用服务。
-
避免单区域控制平面：现在说起来似乎很明显，但配置和元数据服务应该完全本地化或全局复制。任何依赖单个区域的DNS、负载均衡器或其他系统进行协调的系统都会引入全局风险。
-
将控制平面与数据平面分离：AWS事件始于控制平面，但迅速级联到数据平面。构建系统，使运行时流量可以独立于配置或供应系统继续运行。
-
分布DNS和缓存层：具有长TTL的多提供商DNS可以减少与控制平面相关的解析故障的影响。当源站不可达时，缓存或区域读取副本保持应用程序部分功能。
-
实现断路器和隔离舱隔离：系统应该快速优雅地失败。断路器可以重新路由或降级功能，而不是反复攻击失败的端点。隔离舱隔离限制了故障在组件之间的传播。
-
持续测试故障场景：定期的"混沌"测试验证冗余、DNS故障转移和RTO/RPO目标在实践中有效。AWS自己的Resilience Hub鼓励这些测试，但这一教训适用于任何云或混合部署。查看Netflix在2011年推出的Chaos Monkey作为示例。
-
规划多云或混合弹性：多可用区冗余不能防止控制平面问题。跨多个云提供商部署或保持最小的本地足迹可以防止完全依赖一个提供商的管理系统。
-
将容量与故障转移逻辑解耦：AWS通过限制新实例启动来缓解中断，争取了时间，而不是弹性。提前在次要区域保留计算资源，但确保故障转移逻辑独立于控制平面工作。
我们自豪的是，Wallarm的安全边缘展示了如何主动应用这些经验教训。通过将API保护转移到多云、主动-主动的边缘结构中，组织不仅获得了针对攻击的弹性，还获得了针对即使最大提供商偶尔遭受的基础设施故障的弹性。
安全边缘：应用的经验教训
在设计安全边缘的架构时，我们希望解决这些具体挑战。今天，Wallarm的安全边缘在设计上体现了这些原则。它被有意构建以避免AWS中断暴露的单提供商脆弱性。安全边缘包括：
主动-主动、多云架构：安全边缘在AWS、Azure和其他提供商上以主动-主动配置运行执行节点。如果一个提供商经历性能下降，流量可以立即重新路由。这种多云分布消除了影响AWS的单区域或单提供商风险。
与客户基础设施解耦：安全边缘作为托管的云原生安全层运行，而不是嵌入客户环境的组件。其过滤和执行节点靠近API边缘定位，但与客户自己的数据平面隔离。换句话说，即使客户的云或提供商失败，Wallarm保护层仍然运行。
具有自动故障转移的始终可用性：Wallarm的架构提供独立于任何单一云提供商或CDN的自动全局故障转移和高可用性。即使底层基础设施中断，客户也能受益于安全连续性。
低延迟、边缘接近的执行：通过将过滤节点放置在客户的API端点附近，安全边缘在提供深度检查和遥测的同时保持低延迟。分布式足迹确保即使在提供商中断期间，合法流量也能继续有效流动。
API原生和协议感知：该平台支持REST、GraphQL、gRPC、Web Sockets和传统协议，确保弹性不以兼容性为代价。
安全设计：相互TLS（mTLS）在所有节点之间提供安全、经过身份验证的连接，对于受监管行业至关重要。
简化部署和管理：由于安全边缘通过DNS更改进行配置，团队不必管理控制平面依赖关系或基础设施更新。即使客户环境或特定区域经历停机，安全层也保持运行。