任何一个公有云供应商，在发展的历史长河中，都遭遇了这样那样的宕机、故障。

或因人为因素、或因雷电太凶、或因机房停电、或因光缆被挖、或因代码错输……

这些问题的出现与解决，正好也是公有云服务不断优化与提升的过程。

不过，作为全球公有云的一哥，从可以查询记载的故障宕机等事件来看，几乎每年都会出现。

在此，阿明来回顾一下，特别整理编辑了：

2010年到2019年今日为止，全球公有云一哥十年宕机故障大全。

【2010年】

AWS云服务因UPS和人为错误中断，持续时间不详。

2010年5月4日Amazon云计算服务出现两次故障，原因则分别是一个UPS单元故障和人为操作失误。

AWS云服务因数据中心电路中断，持续时间长达7个小时。

2010年5月8日Amazon云计算服务故障，因数据中心配电屏电气接地和短路，曾导致部分用户失去服务长达7个小时，而且还导致极少量用户的数据丢失。

Amazon数据中心停电AWS云服务中断，持续时间1个小时。

2010年5月11日，Amazon云计算服务因停电事故出现故障，致使美国东部的少量用户失去服务长达一个小时。

这次事故的原因，是一辆汽车撞倒了Amazon数据中心附近的高压电线杆，而数据中心的配电开关又未能正常地从公用电网切换到内部的备用发电机（配电自动化系统错误地将停电原因理解为电气接地）。

值得注意的是，这是Amazon云计算服务一周内第四次因停电发生故障。

亚马逊欧洲网站宕机，持续时间超过一个半小时。

2010年12月13日，亚马逊旗下英国、法国、德国和西班牙网站周日晚间宕机超过一个半小时，但目前还没有迹象显示这与网络攻击有关。自从维基解密开始公布美国机密外交电文后，亚马逊是首批宣布与维基解密断绝业务的公司之一。随后一批支持维基解密的网络黑客对亚马逊网站发起了网络攻击。

亚马逊旗下英国、德国、法国以及西班牙网站均出现了时间超过30分钟的宕机，直至格林威治时间周日21：45逐步恢复正常。亚马逊美国网站此次并未遭受影响。

【2011年】

AWS云数据中心服务器大面积宕机，持续时间很长。

2011年4月22日，亚马逊AWS云数据中心服务器大面积宕机，这一事件被认为是亚马逊史上最为严重的云计算安全事件。

由于亚马逊在北弗吉尼亚州的云计算中心宕机，包括回答服务Quora、新闻服务Reddit、Hootsuite和位置跟踪服务FourSquare在内的一些网站受到了影响。

亚马逊官方报告中声称，此次事件是由于其EC2系统设计存在漏洞和设计缺陷，并且在不断修复这些已知的漏洞和缺陷来提高EC2，即亚马逊ElasticComputeCloud服务的竞争力。

AWS被雷击断网，故障持续了大约两天。

2011年8月，亚马逊在北弗吉尼亚州的EC2（弹性计算云）服务发生断网故障，使许多使用亚马逊Web服务云计算基础设施的网站和服务临时中断。这个数据中心是亚马逊在欧洲唯一的数据存储地，也就是说，EC2云计算平台客户在事故期间没有其他数据中心可供临时使用。

亚马逊称，在北爱尔兰都柏林出现的闪电，引起亚马逊在那里的数据中心停电故障，导致在那里的云服务断网。亚马逊证实美国东1区与互联网之间的连接问题么，但很快连接全面恢复。同时还发现在北弗吉尼亚州的关系数据库服务中的另一个连接问题。这个故障在11分钟内修复。不过，宕机事件使得采用亚马逊EC2云服务平台的多家网站长中断达两天时间之久。

【2012年】

亚马逊AWS的EC2服务故障，持续时间超过29个小时。

2012年6月14日，Amazon位于美国东部的数据中心出现故障，并影响了AWS多项云服务以及基于之上的Heroku、Quora等知名网站。16日，Amaozn公布了事故分析。事故是由公共电网故障引起，并引发了一系列连锁故障。

雷暴使得亚马逊在该地区的设施失去了动力，发电机不能正常运行，消耗应急电源的不间断电源(电源)系统，从而导致运行在Amazon RDS上的大概上千个MySQL数据库宕机。

同时EBS-related EC2 API的损失集中在20:57-22:40。具体来看，这段时间内，可变系统调用（如创建，删除）失败，进而直接影响到客户发布新的EBS-backed EC2实例。EC2和EBS APIs实施在多个可用复制数据存储区。EBS数据存储被用来存储元数据等资源的卷快照。

一般来看，为了保护数据存储，系统会自动翻转为只读模式，直到电力恢复可以启动可用区，进而尽快恢复到一致状态，并返回到数据存储读写模式，使得启用可变EBS调用成功。但这个事件中，这一保护方案没有起到作用。

AWS网络服务中断，持续时间不详。

2012年10月22日，亚马逊位于北维吉尼亚的网络服务AWS中断。

事故影响了包括Reddit、Pinterest等知名大网站。中断影响了弹性魔豆服务，其后是弹性魔豆服务的控制台，关系数据库服务，弹性缓存，弹性计算云EC2，以及云搜索。这次事故让很多人认为，亚马逊是应该升级其北维尼吉亚数据中心的基础设施了。

亚马逊AWS弹性负载均衡服务故障，持续时间不详。

2012年12月24日，刚刚过去的圣诞节平安夜，亚马逊并没有让他们的客户过得太平安。亚马逊AWS位于美国东部1区的数据中心发生故障，其弹性负载均衡服务(Elastic Load Balancing Service)中断，导致Netflix和Heroku等网站受到影响。

其中，Heroku在之前的AWS美国东部区域服务故障中也受到过影响。

不过，有些巧合的事情是Netflix的竞争对手，亚马逊自己的业务Amazon Prime Instant Video并未因为这个故障而受到影响。

【2013年】

亚马逊AWS负载均衡故障，持续时间2个小时。

2013年9月13日黑色星期五发生的这次故障是由负载均衡问题所导致的，部分地区客户受到影响。

Amaozn解决了复杂均衡的接入问题，并增加了配置时间以防止后续这种问题的出现。

虽然这次中断只持续了大约2个小时且只影响到弗吉尼亚州的一个可用区域，但对Amazon来说，却是一个要制定备份计划的重要提醒。

【2014年】

AWS CloudFront DNS服务中断，持续时间近2个小时。

2014年11月26日，Amazon Web Services的CloudFront DNS服务器从美国东部时间下午7：15开始持续了近2个小时。在下午9点之后DNS服务器开始恢复备份。

部分网站和云服务发生掉线，在这期间内容交付网络无法完成DNS请求。没有发生什么大事，但是值得列入该榜单，因为它涉及到全球最大的也是运行时间最长的云。

【2015年】

AWS大规模宕机，宕机持续时间超过40秒。

2015年7月1日 亚马逊Web服务（AWS）出现大规模宕机情况，宕机持续时间超过了40秒。Slack、Asana、Netflix、Pinterest等多款APP、以及多家使用AWS服务的网站出现无响应的情况。

对此不少网友笑称“都是闰秒惹的祸！”。也有网友怀疑是“苹果音乐服务”导致的。此外，还有用户在Hacker News网站上撰文称是由于亚马逊的一个EC2服务器引起的。

亚马逊AWS平台DynamoDB超时引发宕机，故障持续时间5小时。

2015年9月，亚马逊自动化基础设施过程中断，造成AWS平台宕机。从简单网络中断级联反应成大面积服务掉线，亚马逊经历了传统内部数据中心才会经历的那种断网——尽管它有非常先进和集成的云平台。

亚马逊的网络中断影响到其一部分DynamoDB云数据库的存储服务器。此事发生时，一些存储服务器还在请求其成员资格数据。于是，断线造成了检索和传输超时，这些服务器无法获得自己的成员资格数据，自动退出了服务。

当那些无法获得请求的服务器开始重新尝试请求的时候，DynamoDB超时问题便引发了更大面积的断网。如此，恶性循环产生，亚马逊客户有5个小时无法使用AWS。

数据中心停电AWS服务中断，停运超过5小时。

2015年9月20日亚马逊AWS一个数据中心遭遇停电事故，影响了Netflix，Tinder，Airbnb等应用程序的在线服务，以及Reddit和IMDB服务中断。

此次服务中断归咎于其在北弗吉尼亚的us-east-1数据中心软件的问题，而其受到影响的客户大多是本土的客户。20日早上3点停电后不久，一共24个应用和服务报告出现问题，其中有10个处于完全“服务中断”模式。

【2016年】

亚马逊AWS宕机，持续时间20分钟。

2016年3月11日，美国当地时间2点20分钟左右，电商巨头亚马逊官方网站发生宕机事故，时间长达20分钟，这次事故不仅导致亚马逊电子商务主网站无法访问，而且也波及到了亚马逊的其他服务，这其中就包括了全球最强的亚马逊云计算服务以及一些数字内容服务等。

这对于亚马逊来说是一个相当巨大的事故，并且这一事故将造成巨大的经济损失。作为实力及用户数量均为全球第一的亚马逊而言，云服务事故不仅是经济损失那么简单，也给追赶者带来了赶超的希望。

澳大利亚AWS因停电中断服务，持续近10个小时。

2016年6月悉尼遭遇风暴，AWS在该地区的设施停电，很多EC2实例以及为一些知名公司托管关键负载的EBS卷接连出现故障。

在那个周末，澳大利亚AWS可用区域的网站和在线服务中断了近10个小时，使得从银行服务到披萨送货都出现了问题。

【2017年】

亚马逊AWS S3宕机事件，宕机4个小时。

2017年2月28号，号称亚马逊AWS最稳定的云存储服务S3出现“超高错误率”的宕机事件。

最终，AWS给出了确切的解释：一名程序员在调试系统的时候，运行了一条原本打算删除少量服务器的脚本，结果输错了一个字母，导致大量服务器被删。被错误移除的服务其中运行着两套S3的子系统，从而导致S3不能正常工作，S3 API处于不可用状态。

由于S3负责存储文件，为AWS体系中的核心组成部分，这导致北弗吉尼亚日（美国东一）服务区中，依赖于S3存储服务的其他AWS的S3 控制台、Amazon弹性计算云（简称EC2）新实例启动、Amazon弹性块存储（简称EBS）分卷（限于需要读取S3快照的数据）以及AWS Lambda均受到影响。

为了修复这个错误，亚马逊不得不重启整个系统，在此之前已经几年都没有重启过了，最终导致了震惊全球的Amazon S3宕机4个小时事件。

【2018年】

AWS网络故障，故障持续时间不详。

2018年3月，亚马逊Alexa智能家居出现了区域性失灵，用户在家中唤醒亚马逊Echo系列产品时，Alexa会让用户重试并报告找不到服务器。

Alexa这一故障源于亚马逊AWS的网络服务出现了问题，不仅是Alexa，其他依赖AWS作为骨干网的应用在当天也受到了影响，其中包括软件开发公司Atlassian，云通讯公司Twilio等。

亚马逊的一位发言人表示，这可能跟弗吉尼亚州AWS的一个冗余互联网连接点断电有关。在后续的故障确认中，AWS表示已经引起了美东1区的多个数据中心故障。同时，数据包的丢失导致美国东部地区的一些AWS Direct Connect客户服务受到影响。也影响到了来自弗吉尼亚州阿什本的Equinix DC1 - DC6 & DC10 - DC12和来自弗吉尼亚州雷斯顿的CoreSite VA1 & VA2的Direct Connect连接。

AWS数据中心硬件故障导致云服务影响，持续时间30分钟。

2018年5月31日，因北弗吉尼亚地区的数据中心出现硬件故障，AWS再次出现连接问题。在此事故中，AWS的核心EC2服务，Workspaces虚拟桌面服务以及Redshift数据仓库服务均受到影响。

AWS管理控制台故障，故障持续近6小时。

2018年7月18日消息，亚马逊盛大的购物促销活动Prime Day遭遇了史上最大的尴尬，亚马逊网站和应用出现了重大技术故障，威胁到了其持续36个小时的销售盛宴。

与此同时，亚马逊核心产品AWS云服务也出现了中断。客户登录AWS管理控制台时，将收到一条带有狗图片的错误消息，消费者Prime Day在亚马逊网站上看到带有狗的图片类似。

AWS故障在声明中表示：“客户使用帐户登录时遇到间歇性错误，无法访问AWS管理控制台。”管理控制台是客户控制他们从Web使用AWS资源的方式的入口，该功能出现故障，客户将无法实现AWS资源的调配。

该故障持续了将近6小时，AWS发言人表示，间歇性的AWS管理控制台问题，并未对亚马逊的消费者业务产生任何有意义的影响，AWS和Prime Day问题没有关联。

AWS韩国服务器中断，故障时间持续一个多小时。

2018年11月23日亚马逊网络服务（AWS）的核心服务器在韩国全国发生中断，导致两个主要的加密货币在线交易平台停止运作。AWS是全球广泛使用的云服务之一，受到内部核心服务器故障的影响，导致主要的数字资产交易平台Upbit和Coinone戛然而止。据外媒报道，几个主要的电子商务中心在大约一个小时内也无法访问。

AWS表示“在太平洋标准时间下午3点19分到4点43分之间，亚太服务器错误率上升，但问题已得到解决，服务器正常运作。”亚马逊的声明细节也证实了首尔网络受到中断影响最大。Upbit平台在停电后发布了几份声明，并为无法提前告知用户突然停机而道歉。 Coinone平台还宣布进入维护模式。

【2019年】

AWS北京区域因光纤被挖断中断新实例启用，故障时间持续不详。

2019年6月1日晚，AWS北京区域CN-NORTH-1地区的隔夜道路施工中有几处光缆被切断，导致可用区无法链接Internet，进而引发所有可用区中新的实例无法启动的故障，包括EC2 API启用故障。因而EC2 API在整个CN-North-1区域都不可用。目前维修团队已经找到了具体的断点所在，正在尽力恢复过程中。

业内人士指出，这是一个北京区域一个可用区的光纤被市政施工挖断，被挖断不止一处。EC2 API接口部分正好在被挖断的那个可用区，所以不能启动新的实例。遭遇这样的事情，也说明了市政的施工队总是那么猝不及防。

以上内容信息整理自：新浪、搜狐、腾讯新闻等相关网站、信息平台、公开新闻报道。

如有编辑统计疏漏之处，还望各位业内朋友补充补充。

声明：本文来自全球云观察，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。