Amazon Web Services 的故障，始于美东时间周四晚 8:25 左右。
AWS 后续把原因限定在北弗吉尼亚 US-East-1 区域内一个可用区的 thermal issue，也就是散热或过热相关问题。受影响的是 EC2 实例。到美东时间周五下午，AWS 仍称完全恢复还需要数小时。
这不是 AWS 全球宕机，也不是 US-East-1 整个区域瘫痪。
但它已经足够刺眼：一个可用区里的冷却系统和硬件问题，传导到了 FanDuel、Coinbase 这类交易平台。对用户来说，感知不是“某个云资源异常”，而是无法访问、无法交易、无法及时退出。
我更在意的是这条链路：底层云的单点物理故障，怎样变成交易业务的可用性风险。
发生了什么：AWS 把故障限定在一个可用区
AWS 健康状态页最早在美东时间周四晚 8:25 左右称，正在调查 instance impairments。后续说法指向 US-East-1 区域一个可用区内的散热问题。
AWS 在周五上午 9:51 的更新中表示，团队正让更多冷却系统容量上线，以恢复受影响可用区中剩余的受损硬件。到周五下午 3:29，AWS 又称完全恢复仍预计需要数小时，进展慢于此前预期。
把时间线压成一张表，更容易看清这次事故的边界。
| 时间点（美东） | 事件 | 影响 | 该怎么理解 |
|---|---|---|---|
| 周四 8:25 p.m. 左右 | AWS 开始调查 EC2 instance impairments | 部分实例受损 | 问题从基础算力层暴露 |
| 周四 9:00 p.m. 左右 | FanDuel 称用户无法访问平台 | 用户无法使用服务 | 业务侧先感受到冲击 |
| 周四约 11:00 p.m. | FanDuel 将问题关联到更广泛的 AWS 故障 | 用户抱怨无法 cash out | 退出交易能力成为痛点 |
| 周五 | Coinbase 称核心交易服务曾长时间中断，主要问题已解决 | 加密交易受阻 | 恢复服务不等于韧性问题消失 |
| 周五 3:29 p.m. | AWS 称完全恢复仍需数小时 | 受影响硬件继续恢复 | 物理设施修复无法完全软件化 |
这里有几个边界必须说清。
目前材料不能支持“全区域宕机”的说法，也不能推出 AWS 全球性故障。没有受影响用户数，没有交易损失金额，也没有赔偿安排。
FanDuel、Coinbase 的问题也不应写成平台自身安全事故，更不是黑客攻击。能确认的，是 AWS 单个可用区的散热故障影响了部分 EC2 实例，并外溢到依赖这些基础设施的交易服务。
这类限定很重要。因为判断云韧性，最怕两种误读：一种是把事故夸成灾难，另一种是因为“只是一个可用区”就低估它。
谁被影响：交易平台最怕的不是打不开页面
FanDuel 在 X 上称，团队注意到技术困难导致用户无法访问平台。随后平台表示，问题与 AWS 故障有关。
用户抱怨的焦点之一，是无法 cash out。这个细节比“页面打不开”更关键。
博彩和交易业务里，退出本身就是交易的一部分。进不去、退不出、结算不了，都会改变用户承担风险的方式。
Coinbase 的表述更接近金融科技平台的核心问题。平台称，核心交易服务曾长时间中断，但主要问题已经解决。
对加密资产交易者来说，最敏感的不是首页能不能刷出来，而是订单能否提交、撤销，资产能否及时调仓，行情和风控链路是否同步。
两类平台的用户体验不同，但底层痛点相似。
| 受影响对象 | 用户最直接的感受 | 平台要补的能力 |
|---|---|---|
| FanDuel 这类投注平台 | 无法访问，无法 cash out | 关键操作降级、结算路径隔离、状态恢复说明 |
| Coinbase 这类交易平台 | 核心交易服务中断，调仓受阻 | 下单、撤单、账户、风控链路的跨区容灾 |
| 企业 IT 团队 | 云资源故障穿透业务 | 梳理单可用区依赖，补演练和切换预案 |
对云计算和企业 IT 决策者，这次事故至少该带来一个动作：回查核心系统到底是不是跨可用区运行。很多架构图画了多区，但认证、队列、监控、数据库副本或某个第三方组件，可能仍卡在单点上。
更现实的做法，是把新采购和扩容评审往后压一压，先做依赖清单。哪些服务只在一个可用区？哪些服务跨区部署，但故障切换没有演练？哪些业务能降级，哪些业务必须停写保护？这些问题比“云厂商 SLA 写了多少个 9”更有用。
对金融科技和交易平台从业者，动作更具体：把“退出交易”放进故障演练，而不是只测登录和页面可用。下单失败要有状态确认，撤单失败要有回执策略，cash out 或提现类操作要有清楚的用户提示。
这不便宜。交易系统多活会遇到数据一致性、订单状态同步、风控延迟、跨区成本和合规边界。也正因为贵，很多平台会在成本和韧性之间做取舍。
问题是，用户不会按你的架构成本来理解事故。用户只看一件事：关键时刻，我能不能操作。
为什么一个可用区会外溢：云的规模优势也会放大集中依赖
AWS 约占全球云基础设施市场三分之一，是大量企业的底层服务商。US-East-1 又是 AWS 最早、最繁忙、生态依赖很深的区域之一。
企业愿意把服务放在这里，不难理解。工具成熟，服务齐全，生态丰富，延迟和成本也常常更好看。
但集中依赖的风险，也藏在这些优势里。
云厂商用 Region 和 Availability Zone 分摊风险。按理说，一个可用区出问题，架构良好的业务应能切到其他可用区，甚至跨区域运行。
现实没这么轻巧。
真正做到交易级别多活，需要持续投入。数据库要同步，订单状态要一致，风控要跟得上，用户账户不能乱，跨区延迟还不能把体验拖垮。
所以这次事故更像一次提醒：买了云，不等于买好了韧性。云提供的是基础能力，韧性还要靠平台自己设计、付费、演练。
历史上，US-East-1 曾多次成为互联网服务中断的放大器。2021 年 AWS US-East-1 故障曾影响多类消费互联网和企业应用。此次范围被限定在单个可用区，但受影响对象包括投注和加密交易平台，敏感度更高。
停一小时视频服务，和停一小时交易服务，在工程词汇里都叫可用性问题。落到用户身上，不是一回事。
接下来最该看的，不是泛泛等一篇事故复盘。
更有价值的是三件事：AWS 是否说明冷却系统容量和硬件恢复的更细边界；FanDuel、Coinbase 是否披露关键交易链路的冗余调整；企业客户是否把单可用区依赖纳入下一轮架构审计。
目前看不出这次事故对相关公司财务造成多大冲击，材料也不足以支持这类判断。能看清的是另一件事：底层故障已经足够低，却仍能穿透到最高敏感度的交易场景。
这就是云时代的老问题。规模带来便利，也带来共振。平时看起来风平浪静，出事时才知道哪根绳子没有备份。