AWS（Amazon Web Services）美东US-EAST-1服务区域在太平洋标准时间（PST）周二（12/7）上午7:30（7日晚上11:30）出现故障，而且一直到PST当天下午2:22分（8日上午6:22分）才排除问题，延续了近7个小时，AWS在10日公布了详细的故障原因，指出是因为一个自动化的容量扩展程序导致网络设备重载而造成的意外事件。
根据AWS的说明，大多数的AWS服务与客户的应用都是在主要的AWS网络上运行，但AWS还运用一个内部网络来托管许多基本服务，像是监控、内部DNS、授权服务或是部分的EC2控制平面。由于在内部网络中执行的服务非常重要，因此AWS利用多个于地理上隔离的网络设备来连接内部网络，同时还会扩展该网络的容量来确保网络连接的高可用性。
这些网络设备用来提供额外的路由及网络地址的转换，以支持各种AWS服务在主要网络及内部网络之间的通信。
意外的发生始于PST时间上午7:30，AWS主要网络上的某个AWS服务进行自动化的容量扩展，触发了内部网络大量客户端的意外行为，造成主要网络与内部网络的连接活动激增，而让网络设备不堪负荷，导致这两个网络之间的通信延误。
延误的通信带来更多的延迟与错误，也造成系统不断重试，使得连接这两个网络的设备持续出现拥塞与性能问题。
事实上，AWS客户的负载并未直接受到该网络问题的影响，因为AWS的主要网络并未出现问题，但只要是必须连接到内部网络的服务几乎都受到波及。
举例来说，EC2实例并未受到影响，但要通过位于AWS内部网络的EC2控制平面来发布新实例的任务就会遇到错误；要访问Amazon S3及DynamoDB也是正常的，但若通过VPC Endpoints访问则会遭遇问题；既有的容器可正常运行，但使用Fargate、ECS与EKS等容器服务则会出错。
此外，由于内部网络托管了监控服务，使得该意外不仅波及AWS的CloudWatch监控服务，令用户无法访问服务健康仪表板，还让AWS在第一时间无法识别问题的所在。
AWS指出，因其内部团队无法访问即时的监控资料，只好依赖日志来识别与关注问题，并率先将内部的DNS流量移出，减少网络拥塞的状况，再陆续移除其它流量以减轻网络设备的负荷，同时添加其它的网络能力。
花了快7个小时的时间才解决，AWS提出了3个原因，一是网络拥塞同时也限制了内部团队寻找问题的能力，其次是内部系统也受到波及，第三则是主要网络上的服务是正常的，必须很谨慎才能在恢复服务时，不影响这些正常运行的任务。
这起意外除了让AWS暂时关闭并重新设计扩展活动外，也使得该平台决定于明年初发布全新的服务健康仪表板，以及全新的支持系统架构，以强化与客户之间的联系。