AWS公布上周大規模故障原因：自動化擴充容量造成網路設備過載

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暫時關閉並重新設計擴充活動外，也使得該平臺決定於明年初發表全新的服務健康儀表板，以及全新的支援系統架構，以強化與客戶之間的聯繫。