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现在成为焦点，但纵观整个行业，几乎每个主要的云或CDN提供商（AWS、Cloudflare、Microsoft、Google）在过去五年中都经历过与控制平面相关的中断。这些很少由攻击引起；更多时候，它们源于常规操作变更、配置错误或集中式服务依赖。
2025年10月的AWS中断只是证明没有云提供商能够免疫。最佳防御是架构性的：分布风险、解耦依赖关系并设计优雅降级。
基础设施架构师的经验教训
-
设计真正的多区域主动-主动操作：如果控制流量无法到达，备用区域是不够的。以主动-主动配置运行，这样损失一个资源或区域不会禁用服务。
-
避免单区域控制平面：配置和元数据服务应完全本地化或全局复制。任何依赖单个区域的DNS、负载均衡器或其他系统进行协调的系统都会引入全局风险。
-
将控制平面与数据平面分离：AWS事件始于控制平面，但迅速级联到数据平面。构建系统，使运行时流量可以独立于配置或供应系统继续运行。
-
分布DNS和缓存层：具有长TTL的多提供商DNS可以减少与控制平面相关的解析故障的影响。当源站不可达时，缓存或区域读取副本保持应用程序部分功能。
-
实现断路器和舱壁隔离：系统应快速优雅地失败。断路器可以重新路由或降级功能，而不是反复调用失败的端点。舱壁隔离限制故障在组件之间的传播。
-
持续测试故障场景：定期的"混沌"测试验证冗余、DNS故障转移和RTO/RPO目标在实践中有效。AWS自身的Resilience Hub鼓励这些测试，但教训适用于任何云或混合部署。
-
规划多云或混合弹性：多可用区冗余不能防止控制平面问题。跨多个云提供商部署或保持最小的本地足迹防止完全依赖一个提供商的管理系统。
-
将容量与故障转移逻辑解耦：AWS通过限制新实例启动来缓解中断，争取时间而非弹性。提前在次要区域保留计算资源，但确保故障转移逻辑独立于控制平面工作。
安全边缘：应用的经验教训
在设计安全边缘架构时，我们希望解决这些具体挑战。今天，Wallarm的安全边缘通过设计体现了这些原则。它有意构建以避免AWS中断暴露的单提供商脆弱性。
主动-主动多云架构：安全边缘在AWS、Azure和其他提供商上以主动-主动配置运行执行节点。如果一个提供商经历性能下降，流量可以立即重新路由。这种多云分布消除了影响AWS的单区域或单提供商风险。
与客户基础设施解耦：安全边缘作为托管云原生安全层运行，而不是嵌入客户环境的组件。其过滤和执行节点靠近API边缘定位，但与客户自己的数据平面隔离。
具有自动故障转移的始终可用性：Wallarm架构提供独立于任何云提供商或CDN的自动全局故障转移和高可用性。即使底层基础设施中断，客户也能受益于安全连续性。
低延迟边缘邻近执行：通过将过滤节点靠近客户的API端点放置，安全边缘在提供深度检查和遥测的同时保持低延迟。分布式足迹确保即使在提供商中断期间，合法流量也能继续有效流动。
API原生和协议感知：平台支持REST、GraphQL、gRPC、Web Sockets和传统协议，确保弹性不以兼容性为代价。
安全设计：相互TLS（mTLS）在所有节点之间提供安全、认证的连接，对受监管行业至关重要。
简化部署和管理：由于安全边缘通过DNS更改配置，团队不必管理控制平面依赖关系或基础设施更新。即使客户环境或特定区域经历停机，安全层也保持运行。