亚马逊云俄勒冈州实例启动故障持续两小时

一、俄勒冈区域新建实例大面积启动失败

北京时间11月7日清晨，亚马逊云服务（Amazon WebServices，AWS）美国西部俄勒冈区域出现大范围实例启动故障，大量新建云服务器的请求无法完成。AWS官方状态页面记录显示，故障始于协调世界时11月6日22时51分，即北京时间11月7日6时51分，覆盖该区域全部4个可用区，编号分别为usw2-az1、usw2-az2、usw2-az3和usw2-az4。故障期间，弹性计算云（AmazonElastic ComputeCloud，EC2）实例启动失败率明显升高，依赖新建实例的数据同步、备份、代码构建、代码流水线、云命令行、批量计算、设备农场、云监控等服务同步受到牵连，其中游戏流传输服务GameLiftStreams与远程桌面服务WorkSpaces Applications也出现异常。AWS在排查后确认，问题源于支撑弹性块存储（Amazon ElasticBlockStore，EBS）卷创建的一个子系统，团队于美国太平洋时间11月6日15时20分开始修复，并于16时21分全面恢复，故障总计持续2小时21分钟。AWS同时强调，已经运行的实例与已创建的存储卷没有受到影响，客户只需重试失败的启动请求即可。

二、存储子系统故障拖垮新建实例链条

从AWS公布的处置过程看，这次故障的传导链条相当清晰：新建EC2实例必须先创建并挂载EBS卷，而负责这一环节的子系统出现异常，导致启动请求在第一步就被卡住。已经运行的实例不需要重新创建存储卷，因此照常提供服务；但任何需要拉起新实例的动作都会失败，包括自动扩容、批量任务调度、持续集成构建以及跨区域数据迁移。状态页面列出的受影响服务超过10项，涵盖AWSBackup、AWS DataSync、AWS CodeBuild、AWS CodePipeline、AWS CloudShell、AWSBatch、AmazonCloudWatch等，说明一次底层存储故障可以沿着依赖关系扩散到整条工具链。故障还波及了AWS之上的第三方服务：数据分析厂商Starburst报告称，其Galaxy服务在同一区域部分实例无法启动，问题从协调世界时11月7日0时04分持续到1时20分，历时1小时16分钟，已运行的服务未受影响。两起事件的时间高度重合，印证了故障源头在AWS区域基础设施本身，而非某个单一应用的配置错误。值得注意的是，AWS在故障发生约40分钟后才定位到EBS子系统，修复又用了约1小时，整个过程的公开通报节奏较为克制，只在确认根因与恢复后才给出完整说明。

三、一次故障照见云上韧性的真实成色

对使用AWS俄勒冈区域的企业而言，这次故障的直接损失有限：正在运行的业务没有中断，受影响的主要是扩容、部署与备份等弹性操作。但它再次提醒人们，云计算的韧性不能只看运行中的实例是否稳定，还要看系统在压力下能否顺利长出新的容量。自动扩容、蓝绿部署、灾备切换这些关键动作，恰恰都依赖新建实例的能力，一旦这条链路中断，业务在故障期间就失去了弹性空间。对企业来说，更稳妥的做法是把关键服务分散到多个可用区乃至多个区域，并为部署流水线准备重试与降级方案，而不是默认新建实例随时可用。云厂商同样需要回答一个问题：当支撑存储卷创建的子系统出现故障时，能否更快地隔离影响、缩短定位时间。这次2小时21分钟的处置不算漫长，但在分秒必争的线上业务面前，任何一次新建实例的停摆都值得复盘。

信源跟踪： 亚马逊云服务官方状态页面 | 数据时间： 北京时间 2026年11月7日