AWS中断事件对API安全架构的深刻启示

事件概述

2025年10月20日，AWS经历了一次重大中断，影响了Zoom、Microsoft Teams、Slack和Atlassian等广泛使用的服务。问题并非源于单个数据中心或客户工作负载，而是出现在AWS控制平面——协调EC2实例、DynamoDB表和IAM角色等资源运行的管理层。

初始触发点似乎是US-EAST-1区域中DynamoDB API端点的DNS故障，加上监控网络负载均衡器的子系统故障。由于这些健康监控服务同样运行在US-EAST-1区域，AWS在恢复子系统时限制了新EC2实例的启动。

分析人员迅速识别出US-EAST-1承载着AWS支持众多全球服务的通用控制平面。在欧洲或亚洲运行的工作负载实际上依赖于路由回US-EAST-1的API调用，因此该区域的故障产生了全球性影响。

AWS目前备受关注，但纵观整个行业，几乎每个主要云或CDN提供商（AWS、Cloudflare、Microsoft、Google）在过去五年中都经历过与控制平面相关的中断。这些中断很少由攻击引起，更多源于常规运营变更、配置错误或集中式服务依赖。

备用区域不足，如果控制流量无法到达它。采用主动-主动配置，确保一个资源或区域的丢失不会使服务瘫痪。

配置和元数据服务应完全本地化或全局复制。任何依赖单个区域的DNS、负载均衡器或其他协调系统的系统都会引入全局风险。

AWS事件始于控制平面，但迅速级联到数据平面。架构系统时应确保运行时流量可以独立于配置或供应系统继续运行。

具有长TTL的多提供商DNS可以减少控制平面相关解析故障的影响。缓存或区域读取副本在原始源不可达时保持应用程序部分功能。

系统应快速优雅地失败。断路器可以重新路由或降级功能，而不是反复调用故障端点。隔离舱隔离限制了故障在组件间的传播。

定期的"混沌"测试验证冗余、DNS故障转移和RTO/RPO目标在实践中有效。AWS自身的Resilience Hub鼓励这些测试，但这个教训适用于任何云或混合部署。

多可用区冗余不能防止控制平面问题。跨多个云提供商部署或保持最小的本地足迹可以防止完全依赖一个提供商的管理系统。

AWS通过限制新实例启动来缓解中断，这赢得了时间而非弹性。提前在次要区域预留计算资源，但确保故障转移逻辑独立于控制平面工作。

Wallarm的Security Edge体现了这些原则：