2025年10月20日，AWS最关键的 us-east-1 区域发生了一场持续 15 小时的重大故障，导致全球超过 1000 家企业服务中断。 而这场故障背后的根因，竟然仅仅是一条 AWS 内部 DNS 解析失效。
从凌晨的 DNS 解析失效开始，AWS DynamoDB、EC2、Lambda 等 142 项服务相继受到影响，进而导致全球互联网的大部分功能停转。 Snapchat、Roblox、Coinbase、Signal、Reddit、Robinhood 等热门应用离线，数十亿美元在半天内蒸发，这不啻于一场赛博世界的地震。
更令人警惕的是，因为 us-east-1 是所有 AWS 区域的公共控制平面所在地，即使工作负载部署在欧洲或亚洲的企业也未能幸免。 这场故障暴露了云计算时代最根本的脆弱性：一条损坏的 DNS 就能引发数十亿美元的经济损失。 这不是技术能力问题，而是架构哲学的失败 —— us-east-1 成了全球互联网依赖的中枢神经系统，而这个系统现在已经证明，它会定期失灵。

赛博地震：数十亿美元在半天内蒸发

这场持续15小时的故障，在全球数字经济中掀起了一场"赛博地震"。Catchpoint CEO 预估经济损失达"数十亿到数千亿美元"。
金融服务首当其冲。Robinhood 在美东交易时段完全离线，数百万散户投资者被锁在账户之外； Coinbase 的宕机让加密货币交易者在市场波动中束手无策； Venmo 收到8000份故障报告，用户的数字钱包瞬间"消失"。在现代无现金社会，这相当于所有人同时失去了钱包。
游戏行业损失同样惨重。上亿日活的 Roblox 用户被迫下线，虚拟经济瞬间停摆； Epic Games 的 Fortnite、任天堂的 Pokémon GO、育碧的彩虹六号集体失声。 对这些依赖用户粘性的平台而言，每小时的宕机都可能意味着永久的用户流失。
英国的政府网站，税务，海关，银行系统受到影响，多家航空公司内部系统受损导致部分航班运营混乱。 更讽刺的是，Amazon 自家产品全线翻车 —— 购物网站、Alexa、Ring 门铃、Prime Video，甚至 AWS 自己的工单系统都未能幸免。 这充分说明：即使是 AWS 的创造者，也无法避免对 us-east-1 的单点依赖。

故障根因：DNS失效引发的蝴蝶效应

太平洋夏令时2025年10月19日晚11:49，us-east-1 区域的多个服务错误率突然攀升。 直到22分钟后，AWS 才在健康仪表板发布第一条确认。截止到10月20日下午3:53分结束，整个故障持续了近 16 小时。

根据 AWS 发布的故障公告，根因看似简单：AWS 内部系统的一条 DNS 解析失败。但这个"小故障"却触发了惊人的级联效应。 DynamoDB 无法访问，而它恰恰是 AWS 控制平面的基石 —— IAM、EC2、Lambda、CloudWatch 等关键服务全部依赖它。

AWS 花了三个半小时修复 DNS，以为万事大吉，却没想到积压的请求产生了"重试风暴"，再次压垮了 DynamoDB。 EC2、负载均衡器、Lambda 与 DynamoDB 之间的循环依赖让系统陷入死局。 AWS 被迫采用手工限流的方式，通过限制启动 EC2 实例，限流 Lambda/SQS 轮询来缓解压力，直到下午才逐渐恢复。

级联放大：互联网的阿喀琉斯之踵

us-east-1 不是普通的数据中心，它是 AWS 全球基础设施的中枢神经系统。 除了独立运营的国区、美国政务云和欧盟主权云，其他所有 AWS 区域的全局性控制平面都在这个区域里。

这意味着什么？即使你的应用部署在东京或法兰克福，当需要进行 IAM 认证、配置 S3、访问 DynamoDB 全局表、调用 Route 53 时，请求仍要路由到 us-east-1。 这次故障中，英国政府网站、Lloyds 银行、加拿大 Wealthsimple —— 这些看似与美东无关的服务，都因这种隐性依赖而瘫痪。
us-east-1 的特殊地位源于历史 —— 作为 AWS 的第一个区域，19年的演进让它积累了大量技术债务。 重构它？数百万行代码、数千个微服务、难以计数的客户依赖，任何改动都可能引发更大灾难。 于是 AWS 选择了维持现状，直到故障再次提醒我们这个选择的代价。

技术解剖：小故障如何演变为大灾难

从2017年到2025年，us-east-1 的每次重大故障都暴露了相同的架构反模式，而 AWS 似乎从未真正吸取教训。

循环依赖的死亡螺旋

AWS 各项基础服务深度耦合，各项基础服务（IAM，EC2管理，ELB）依赖 DynamoDB，DynamoDB 又依赖这些服务 —— 这种循环依赖会导致架构复杂度指数增长， 系统复杂度被隐藏在微服务的层层抽象之下，极大拉高故障分析定位，处理解决的难度与时长。平时岁月静好，故障时却成为死亡陷阱。 我们已经在 阿里云 ，OpenAI，滴滴 这些公司的翻车案例中见过太多类似的例子了。

中心化的单点故障

在2020年 Kinesis 故障后，AWS 大力推广蜂窝架构（Cell-Based），并公开称将自己的服务迁往这种新 Cell 架构。 但从目前来看，us-east-1 区域依然是整个 AWS 全球全局控制平面的单点，牵一发而动全身，故障爆炸半径巨大。 尽管 AWS 声称在 us-east-1 部署了六个可用区提供冗余，但遇到 DNS 这种全局基础服务故障时，依然形同虚设。 这揭示了一个残酷真相：再精妙的多区域设计，也敌不过一个单点依赖。

监控系统的自我失明

最荒谬的是，AWS 自己的监控工具也依赖被监控的服务。当故障发生时，监控系统也随之失明。这创造了一个悖论：最需要监控数据的时候，恰恰是监控系统最不可用的时候。 外部监控平台如 Datadog 同样托管在 AWS 上，形成了"自己监控自己"的闭环。 故障发生75分钟后，AWS 状态页面仍然是 “万里江山一片绿” —— 也许不是他们在撒谎，而是监控系统自己也瘫痪了。

断路器的集体缺席

尽管 AWS 发布了大量关于实施断路器的最佳实践指南，但这次故障显示出，AWS 自己的内部服务网格可能并没有实施这些机制。 断路器本应在检测到下游服务故障时自动"熔断"，停止发送请求，避免雪崩。但实际情况是，当 DynamoDB 出现问题，所有依赖服务继续疯狂重试，形成"重试风暴"。 AWS 最终被迫手动介入，通过人工限流来控制局面 —— 这种原始的应对方式，与其宣扬的"自动化一切"理念形成鲜明对比。

知识流失：组织功能障碍的技术表现

在运维圈里有句名言 —— “It’s always DNS” 。任何经验丰富的 SRE 遇到这种事都会优先检查 DNS。 但 AWS 团队却在黑暗中摸索了两个多小时，然后又在断路限流的路上挣扎了五个小时。精锐尽失的团队难堪大任，这无疑是草台班子理论的又一例证。
2022-2025年间，亚马逊裁员超过27000人。内部文件显示，各个级别 “不希望流失的人才” （Regretted Attrition）的流失率高达69-81%。 强制返回办公室政策进一步推动高级人才离职。Justin Garrison 在2023年离职时就预言会有更多大规模故障 —— 事实证明他还是太乐观。

Regretted Attrition：即企业本不希望他们离职、但他们仍主动离开的员工。 即在所有离职员工中，有 69–81% 属于公司不希望失去的人。

组织记忆的流失是不可逆的。那些知道系统隐秘依赖关系的老工程师走了，留下的新人即使再努力，也缺乏诊断复杂级联故障的直觉。 这种隐性知识无法通过文档传承，只能通过多年的事故响应经验积累。当下一个"边缘案例"出现时，缺乏经验的团队只能眼睁睁看着系统崩溃，并花费老司机几十上百倍的时间去摸索定位与笨拙处理。

云经济学家 Corey Quinn 在《亚马逊人才流失终于导致 AWS 走向衰落》中辛辣评论道： “当你炒掉最优秀的工程师时，就别惊讶云厂商会忘记 DNS 是怎么工作的” —— “下一次大故障已经在酝酿中，只是哪个人手不足的团队率先被哪个边缘案例绊倒的问题而已。”

冷峻未来：应对云计算带来的脆弱性

在几个月前，Google IAM 故障带崩半个互联网；仅半年不到，AWS DNS 故障再次把全球互联网拉下水。 当一家云厂商内部的一条 DNS 记录损坏，就能让全球数千万用户的生活陷入混乱；当一个区域的数据中心网络故障，能让遍布五大洲的企业同时瘫痪， 我们必须承认：云计算在带来便利的同时，也创造了前所未有的系统性脆弱性。

更何况，当三家美国公司控制全球63%的云基础设施，这已经不仅是技术问题，更是地缘政治风险和数字主权挑战。单一供应商的便利性与全球性的脆弱性构成了一个危险的悖论。

在云服务商的营销话术中，“99.99% 可用性”、“全球多活冗余”、“企业级可靠性”是标配承诺。 但将 AWS、Azure、Google Cloud 近年的实际故障记录摆在一起，云可靠性的神话开始动摇。 Cherry Servers 在 2025 年发布的研究 揭示了残酷的数据： 过去一年 AWS 发生了 38 次故障，平均恢复时间 1.5 小时；Google Cloud 发生了 78 次，平均 5.8 小时；Azure 虽仅 9 次，但平均时长高达 14.6 小时

Headline Numbers: Incidents Summary

“下云” 正从异端想法变成现实选项。在此次 AWS 宕机中，马斯克旗下的社交平台 X（原推特）因独立运营而安然无恙。老马在 X 对 AWS 发出多次嘲讽与揶揄。 知名 SaaS 厂商 37signals 则早在 2022 年就决定将 Basecamp 和 HEY 邮件服务迁出公有云，预计五年内节省约超过千万万美元云开支。 Dropbox 更是在 2016 年便开始逐步减少对 AWS 的依赖，重返自建数据中心。这并不是技术倒退，而是对过度集中化风险的理性校正。

对于有能力的企业来说，混合部署——将核心系统自主可控部署，本地掌握底线，而将弹性扩展需求交给云端处理，可能是更明智的选择。 每一家依赖云的公司都需要认真思考：是否所有工作负载都必须上云？那些关键系统是否应该保留独立运行的能力，以在云崩溃时维持最基本的服务？
在脆弱性中构建韧性，在依赖与集中化中保持独立自主 —— 这不是技术选择，而是生存哲学。 us-east-1 还会再次故障 —— 不是是否，而是何时。所以真正的问题是：下一次故障发生时，你是否已经准备好了？
参考阅读
AWS: Update - AWS services operating normally
AWS: Service Health, Operational issue - Multiple services (N. Virginia)
HackerNews: AWS multiple services outage in us-east-1
CNN: Amazon says systems are back online after global internet outage
Register: Today is when the Amazon brain drain finally sent AWS down the spout
Converge: DNS Failure Triggers Multi-Service AWS Disruption in US-EAST-1

专栏：云计算泥石流

https://vonng.com/cloud

云故障

• AWS最大区域故障，带崩多项服务
• 知乎挂了：证书问题还是CDN翻车？
• 阿里云故障，CDN挂了，记得申请SLA赔付
• Apple,Google,FB,TG 160亿登录信息泄露
• 带瘫全球互联网，Google云/Cloudflare全球故障
• 大故障：阿里云核心域名被拖走了
• 深度分析：迪奥数据泄露事件，云配置失当的锅？
• 10万用户的软件，因腾讯云欠费2元灰飞烟灭？
• AWS 东京可用区故障：影响13项服务
• Shopify：愚人节真的翻车了
• Oracle云大翻车：6百万用户认证数据泄漏
• OpenAI全球宕机复盘：K8S循环依赖
• 支付宝崩了？双十一整活王又来了
• 草台回旋镖：Apple Music证书过期服务中断
• 阿里云：高可用容灾神话的破灭
• 阿里云故障预报：本次事故将持续至20年后？
• 阿里云盘灾难级BUG：能看别人照片？
• 阿里云新加坡可用区C故障，网传机房着火
• 这次轮到WPS崩了
• 草台班子唱大戏，阿里云RDS翻车记
• 我们能从网易云音乐故障中学到什么？
• GitHub全站故障，又是数据库上翻的车？
• 全球Windows蓝屏：甲乙双方都是草台班子
• 阿里云又挂了，这次是光缆被挖断了？
• 删库：Google云爆破了大基金的整个云账户
• 云上黑暗森林：打爆云账单，只需要S3桶名
• taobao.com证书过期
• 我们能从腾讯云故障复盘中学到什么？
• 云SLA是安慰剂还是厕纸合同？
• 腾讯云：颜面尽失的草台班子
• 【腾讯】云计算史诗级二翻车来了
• 互联网故障背后的草台班子们 马工
• 从降本增笑到真的降本增效
• 阿里云周爆：云数据库管控又挂了
• 我们能从阿里云史诗级故障中学到什么
• 【阿里】云计算史诗级大翻车来了

云资源

• 花钱买罪受的大冤种：逃离云计算妙瓦底
• 云数据库是不是智商税
• 云盘是不是杀猪盘？
• 剖析云上算力真实成本
• 扒皮对象存储：从降本到杀猪
• 垃圾腾讯云CDN：从入门到放弃
• 记一次阿里云 DCDN 加速仅 32 秒就欠了 1600 的问题处理 转
• 云SLA是安慰剂还是厕纸合同？
• FinOps终点是下云
• 本土云计算为啥还没挖沙子赚钱？
• 云SLA是不是安慰剂？
• 范式转移：从云到本地优先

下云记

• 花钱买罪受的大冤种：逃离云计算妙瓦底
• 草台班子唱大戏，阿里云RDS翻车记
• DHH下云：S3晚搬一天，就多花四万
• DHH：下云超预期，能省一个亿
• 先优化碳基BIO核，再优化硅基CPU核
• 单租户时代：SaaS范式转移
• 拒绝用复杂度自慰，下云也保稳定运行
• 半年下云省千万：DHH下云FAQ答疑
• 是时候放弃云计算了吗？
• 下云奥德赛

我是怎么知道的，今天早上第一节是我的，我们要用到docker，结果有一大半的学生在pull image的时候碰到了问题。

奇怪的是我自己试了试没问题，不过又试了一次发现自己也不行，去docker官网一查。

全红，我教学这门课好几年了，第一次碰到这种情况。

这个时候我才意识到，是docker背后的aws出问题了。

棘手的是这个世界上有非常多的应用都是基于AWS的，所以这两个多小时内，全世界小一半的软件都宕机了。

（侧面反映出其实整个互联网世界非常的脆弱）

这个图就非常形象了，最开始出问题的是US-EAST-1这个节点。

理论上一个节点出问题，甚至再多几个也问题不大，云服务就是靠redundancy活的，别的backup顶上就没问题。

Oct 20 12:11 AM PDT We are investigating increased error rates and latencies for multiple AWS services in the US-EAST-1 Region. We will provide another update in the next 30-45 minutes.

但问题是这个节点非常的关键，它是 AWS 最早、依赖链最深的核心区域，承载着许多全局服务的控制平面（control plane），包括 IAM（身份与访问管理）、DynamoDB、CloudFormation、ECR（容器镜像库）等。

当 US-EAST-1 出现问题时，即使服务部署在其他区域（例如欧洲），仍可能受到波及，因为很多认证、API 调用、或全局功能会通过 US-EAST-1 的端点进行解析。

虽然在英国地区，但是照样受到了影响，不过好就好在Google这个大善人，我们还可以用Colab这个plan b来做事情。

有没有高人用aws这个事做个短线什么的。

AWS超级P0事故，幸灾乐祸的查了一下amzn的股票，没想到不降反涨。难道这次事故让投资者意识到AWS的潜力比想象中的更大？

DNS解析异常引起的！超级P0故障！亚马逊云AWS周一崩了！百万公司受严重影响！

最新进展： 太平洋夏令时间 10 月 20 日凌晨 2：01 我们已经确定了 US-EAST-1 区域中 DynamoDB API 错误率的潜在根本原因。根据我们的调查，该问题似乎与 US-EAST-1 中 DynamoDB API 端点的 DNS 解析有关。我们正在研究多条并行路径以加速恢复。此问题还会影响 US-EAST-1 区域中的其他 AWS 服务。依赖于 US-EAST-1 终端节点（例如 IAM 更新和 DynamoDB 全局表）的全局服务或功能也可能遇到问题。在此期间，客户可能无法创建或更新支持案例。建议客户继续重试任何失败的请求。我们将在有更多信息分享时或在凌晨 2：45 之前继续提供更新。

过程

2025 年 10 月 20 日，下午 3点11分， 美国东部 US-EAST-1 （弗吉尼亚北部），亚马逊云服务最大的核心机房确认出现重大故障！

马上到晚上高峰期了，我们的应用无法登陆注册，现有服务无法自动扩容，坑死人了！影响的服务每10分钟增加6个，非常恐怖！3点55时候是9个，目前41个！如图。

亚马逊在这个事故通告里，没有说清楚到底是什么原因造成了这次大范围的故障。

官方只是说他们正在积极抢修，并承诺会努力去“理解”到底是什么根本原因导致了问题。45分钟同步一次问题。

已确认的现象是：很多服务都出现了错误率和延迟增加的情况。
事故影响范围

这次出问题的区域是美国东部 US-EAST-1，这个地方是亚马逊云服务最大的核心机房。

受影响的服务数量非常多，开始9个，半小时后26个，目前41个！

其中，被称为“数据库基石”的 DynamoDB 被标记为红色，这是最严重的一个。

其他二十个受影响的关键服务包括：
EC2（租给用户的虚拟电脑，服务器）
IAM 和 STS（负责身份验证、授权和登录的“数字身份证系统”）
CloudFront（负责网站加速的全球分发网络）
CloudWatch（负责监控系统的眼睛）
Support API/Center（连用户向亚马逊提交“维修工单”的系统都受影响了）

这次核心服务的故障，会让数百万依赖这个区域的公司网站和App都出现了卡顿、报错、登录失败等问题。影响范围是全球性的，非常巨大。先守住业务看看能不能切到别的区域。再等亚马逊解释和赔钱，太坑了。

回复【aws】一起技术讨论，蹲问题原因。

第一时间看aws outage update 原因是dynamo db节点的DNS

到目前已经超过10小时 依旧没能修复。

aws对us east 1 region的依赖可见一斑。世界对aws的依赖也暴露出来

web3.0和crypto的去中心化恐成21世纪最大谎言

azure gcp aws互相依赖，ytb chatgpt cursor roblex robinhood zoom jira这个清单可以无限数下去

所有人都在过去刻意忽视了 原生问题,古早架构us east 1过于拥挤且一旦出问题没有fallback plan

在如今各种产品架构无限套娃到现在，问题已经无法忽视。

看着马一龙小人得志吹捧X和starlink 真的比杀了我还难受