2025-10 Amazon DynamoDB 於 北維吉尼亞區域 (US-EAST-1) 服務中斷事件摘要

Published:
  Lastmod: 2025-11-02
隨手記
by Ernest Chiang

Post Title Image (圖說：AWS Health Dashboard 螢幕截圖 at 2025-10-20 12:51 PDT。圖片來源：Ernest。)

✳️ tl;dr

  • 以下內容來自 AWS 官方報告 1，由 AWS Community Hero Ernest 2 以開發者、技術管理者視角，切分段落、畫上重點，以求貼近事實，並基於事實進行推理與延伸學習。
  • 期待透過研讀報告，讓雙方（AWS 原廠、以及同樣身為 AWS 客戶的我們）不論是在雲端或是地端，一起累積經驗、一起持續進步。
  • 以下時間如果沒有特別描述，都是 AWS 西雅圖總部的美西太平洋夏令時間。
  • 這份筆記，會先以知識圖譜開場，然後接續拆解原始官方報告內容，總共分成四個段落：Amazon DynamoDB, Amazon EC2, Network Load Balancer (NLB), Other AWS Services
  • 如果時間不夠，建議可以先看第一個段落，了解本次服務中斷的 root cause 與解決方案。
  • 如果有預算想要調整自身架構成為跨區域高可用，但又沒有足夠時間大幅調整架構，推薦可以看一眼 AWS 各個服務中帶有 global 字樣的服務，例如這次同為 DynamoDB 家族的「Amazon DynamoDB Global Tables」幾乎沒有受到影響。
  • 我們想要提供您關於服務中斷的一些額外資訊,該事件發生於
    • 北維吉尼亞 (us-east-1) 區域 3
    • 2025 年 10 月 19 日和 20 日
    • 事件開始於美西太平洋夏令時間 10 月 19 日 晚上 11:48 (台北時間 UTC+8, 2025-10-20 14:48)
    • 並且結束於美西太平洋夏令時間 10 月 20 日 下午 2:20 (台北時間 UTC+8, 2025-10-21 05:20),
    • 對客戶應用有三個不同的影響時期：
      • 首先,在 10 月 19 日晚上 11:48 到 10 月 20 日凌晨 2:40 之間,Amazon DynamoDB 在北維吉尼亞 (us-east-1) 區域經歷了API 錯誤率增加的情況。
      • 其次,在 10 月 20 日上午 5:30 到下午 2:09 之間,網路負載平衡器 (NLB) 在北維吉尼亞 (us-east-1) 區域的部分負載平衡器經歷了連線錯誤增加的情況。
        • 這是由於 NLB 機群中的健康檢查失敗所造成,導致部分 NLB 的連線錯誤增加。
      • 第三,在 10 月 20 日凌晨 2:25 到上午 10:36 之間,新的 EC2 執行個體啟動失敗,而雖然執行個體啟動從上午 10:37 開始成功,但部分新啟動的執行個體遇到連線問題,這些問題在下午 1:50 得到解決。

✳️ 知識圖譜

(更多關於知識圖譜…)

%%{init: {'theme':'default'}}%%
graph TB
    DynamoDB[DynamoDB]:::instance
    DNS_System[DNS Management System]:::concept
    DNS_Planner[DNS Planner]:::instance
    DNS_Enactor[DNS Enactor]:::instance
    Route53[Route53]:::instance
    Endpoint[Service Endpoint]:::concept
    Race_Condition[Race Condition]:::concept
    
    EC2[EC2]:::instance
    DWFM[DWFM]:::instance
    Network_Manager[Network Manager]:::instance
    Lease[Lease Mechanism]:::concept
    
    NLB[Network Load Balancer]:::instance
    Health_Check[Health Check Subsystem]:::instance
    AZ[Availability Zone]:::concept
    Failover[Failover Mechanism]:::concept
    
    Lambda[Lambda]:::instance
    ECS[ECS]:::instance
    
    Congestion[Congestive Collapse]:::concept
    Propagation[Network State Propagation]:::concept
    Throttling[Throttling]:::concept
    Recovery[Recovery Process]:::concept
    
    DynamoDB -->|provides| DNS_System
    DNS_System -->|consists of| DNS_Planner
    DNS_System -->|consists of| DNS_Enactor
    DNS_Planner -->|generates| DNS_Plan[DNS Plan]:::concept
    DNS_Enactor -->|applies plan to| Route53
    DNS_Enactor -->|updates| Endpoint
    DNS_Enactor -->|triggers| Race_Condition
    Race_Condition -->|causes| DNS_Record_Deletion[DNS Record Deletion]:::concept
    DNS_Record_Deletion -->|blocks| Endpoint
    
    Endpoint -->|enables connection to| DynamoDB
    Endpoint -->|enables connection to| EC2
    Endpoint -->|enables connection to| Lambda
    
    EC2 -->|managed by| DWFM
    DWFM -->|maintains| Lease
    DWFM -->|depends on| DynamoDB
    Lease -->|times out without| DynamoDB
    Lease -->|causes| Congestion
    Congestion -->|delays| Recovery
    
    EC2 -->|network configured by| Network_Manager
    Network_Manager -->|performs| Propagation
    Propagation -->|delays cause| Health_Check_Failure[Health Check Failure]:::concept
    
    NLB -->|uses| Health_Check
    Health_Check -->|monitors| EC2
    Health_Check_Failure -->|triggers| Failover
    Failover -->|operates across| AZ
    Failover -->|causes| Connection_Error[Connection Error]:::concept
    
    EC2 -->|hosts| Lambda
    EC2 -->|hosts| ECS
    Lambda -->|depends on| DynamoDB
    ECS -->|depends on| EC2
    
    Recovery -->|requires| Manual_Intervention[Manual Intervention]:::concept
    Recovery -->|applies| Throttling
    Throttling -->|protects| DWFM
    Throttling -->|protects| Network_Manager
    
    classDef concept fill:#FF8000,stroke:#CC6600,stroke-width:2px,color:#000
    classDef instance fill:#0080FF,stroke:#0066CC,stroke-width:2px,color:#fff

%%{init: {'theme':'default'}}%%
sequenceDiagram
    participant DNS_Enactor_1
    participant DNS_Enactor_2
    participant Route53
    participant DynamoDB_Endpoint
    participant Customer
    
    Note over DNS_Enactor_1: Experiences delays
    DNS_Enactor_2->>Route53: Apply new DNS plan
    Route53-->>DNS_Enactor_2: Success
    DNS_Enactor_2->>DNS_Enactor_2: Trigger cleanup
    DNS_Enactor_1->>Route53: Apply old DNS plan
    Note over Route53: Old plan overwrites new
    DNS_Enactor_2->>Route53: Delete old plan
    Note over Route53: All IPs removed
    Customer->>DynamoDB_Endpoint: Connection attempt
    DynamoDB_Endpoint-->>Customer: DNS resolution failure
    Note over Customer: Service disruption begins

%%{init: {'theme':'default'}}%%
graph TD
    Customer[Customer Application]:::external
    
    subgraph AWS_Services[AWS Services Layer]
        Lambda[Lambda]:::service
        ECS[ECS]:::service
        Redshift[Redshift]:::service
        Connect[Connect]:::service
    end
    
    subgraph Core_Infrastructure[Core Infrastructure]
        DynamoDB[DynamoDB]:::core
        EC2[EC2]:::core
        NLB[NLB]:::core
    end
    
    subgraph Management_Layer[Management Systems]
        DNS_System[DNS Management]:::mgmt
        DWFM[DWFM]:::mgmt
        Network_Mgr[Network Manager]:::mgmt
        Health_Check[Health Check]:::mgmt
    end
    
    Customer -->|uses| Lambda
    Customer -->|uses| ECS
    Customer -->|uses| Redshift
    Customer -->|uses| Connect
    
    Lambda -->|depends on| DynamoDB
    Lambda -->|runs on| EC2
    ECS -->|runs on| EC2
    Redshift -->|depends on| DynamoDB
    Redshift -->|runs on| EC2
    Connect -->|uses| NLB
    Connect -->|depends on| Lambda
    
    DynamoDB -->|managed by| DNS_System
    EC2 -->|managed by| DWFM
    EC2 -->|configured by| Network_Mgr
    NLB -->|monitored by| Health_Check
    
    DNS_System -.->|failure propagates| DynamoDB
    DWFM -.->|depends on| DynamoDB
    Health_Check -.->|monitors| EC2
    
    classDef external fill:#FFE6E6,stroke:#CC0000,stroke-width:2px
    classDef service fill:#E6F3FF,stroke:#0066CC,stroke-width:2px
    classDef core fill:#FFE6CC,stroke:#FF8000,stroke-width:3px
    classDef mgmt fill:#E6FFE6,stroke:#00CC00,stroke-width:2px

%%{init: {'theme':'default'}}%%
stateDiagram-v2
    [*] --> Normal_Operation
    Normal_Operation --> DNS_Failure: Race condition triggered
    
    DNS_Failure --> DynamoDB_Unavailable: Endpoint resolution fails
    DNS_Failure --> Manual_Fix_Required: System inconsistent
    
    DynamoDB_Unavailable --> DWFM_Lease_Timeout: State checks fail
    DynamoDB_Unavailable --> Lambda_Errors: API calls fail
    DynamoDB_Unavailable --> Redshift_Errors: Query processing fails
    
    DWFM_Lease_Timeout --> EC2_Launch_Failure: No valid droplets
    DWFM_Lease_Timeout --> Congestive_Collapse: Queue buildup
    
    Congestive_Collapse --> Network_Propagation_Delay: Backlog processing
    Network_Propagation_Delay --> NLB_Health_Failures: New instances not ready
    NLB_Health_Failures --> Connection_Errors: Nodes removed from service
    
    Manual_Fix_Required --> DNS_Restored: Operator intervention
    DNS_Restored --> DynamoDB_Available: Endpoint accessible
    
    DynamoDB_Available --> DWFM_Recovery: Lease establishment
    DWFM_Recovery --> EC2_Throttled: Gradual recovery
    EC2_Throttled --> EC2_Normal: Throttles removed
    
    Connection_Errors --> NLB_Recovered: Auto-failover disabled
    Lambda_Errors --> Lambda_Recovered: DynamoDB restored
    Redshift_Errors --> Redshift_Recovered: EC2 launches succeed
    
    EC2_Normal --> Normal_Operation
    NLB_Recovered --> Normal_Operation
    Lambda_Recovered --> Normal_Operation
    Redshift_Recovered --> Normal_Operation

1️⃣ Amazon DynamoDB

  • 在 10 月 19 日晚上 11:48 到 10 月 20 日凌晨 2:40 之間，客戶在北維吉尼亞 (us-east-1) 區域經歷了 Amazon DynamoDB API 錯誤率增加的情況。
    • 在此期間，客戶和其他依賴 DynamoDB 的 AWS 服務無法建立與該服務的新連線。
    • 此事件是由服務的自動化 DNS 管理系統中的潛在缺陷所觸發，導致 DynamoDB 的端點 (endpoint) 解析失敗。
  • 許多大型 AWS 服務廣泛依賴 DNS 來提供無縫擴展、故障隔離與復原、低延遲和區域性。
    • 像 DynamoDB 這樣的服務維護數十萬筆 DNS 記錄，以在每個區域 (Region) 中運行非常大型的異構負載平衡器 (load balancer) 機群。
      • 自動化對於確保這些 DNS 記錄經常更新至關重要，以便在容量可用時增加額外容量，正確處理硬體故障，並有效地分配流量以優化客戶體驗。
      • 此自動化系統已針對韌性 (resilience) 進行設計，允許服務從各種運營問題中恢復。
      • 除了提供公開的區域端點外，此自動化系統還維護數個動態 DynamoDB 變體的額外 DNS 端點，包括符合 FIPS 標準的端點、IPv6 端點和帳戶特定端點。
    • 此問題的根本原因 (root cause)是 DynamoDB DNS 管理系統中的潛在競態條件 (race condition)，導致服務的區域端點 (dynamodb.us-east-1.amazonaws.com) 出現不正確的空白 DNS 記錄，而自動化系統無法修復。
      • 為了解釋此事件，我們需要分享一些關於 DynamoDB DNS 管理架構的細節。
      • 基於可用性原因，系統分為兩個獨立元件。
        • 第一個元件是DNS 規劃器 (DNS Planner)，它監控負載平衡器的健康狀況和容量，並定期為每個服務端點建立新的 DNS 規劃 (DNS plan)，其中包含一組負載平衡器和權重 (weight)。
          • 我們產生單一區域 DNS 規劃，因為當容量在多個端點之間共享時，這大大簡化了容量管理和故障緩解，就像最近推出的 IPv6 端點和公開區域端點的情況一樣。
        • 第二個元件是DNS 執行器 (DNS Enactor)，其設計為具有最小依賴關係以允許在任何情況下進行系統復原，透過在 Amazon Route53 服務中套用所需的變更來執行 DNS 規劃。
          • 為了韌性，DNS 執行器在三個不同的可用區域 (Availability Zone, AZ) 3 中冗餘且完全獨立地運作。
          • 這些 DNS 執行器的每個獨立實例 (instance) 都會尋找新的規劃，並嘗試使用 Route53 交易 (transaction) 將當前規劃替換為新規劃來更新 Route53，確保即使多個 DNS 執行器嘗試同時更新，每個端點也會使用一致的規劃進行更新。
        • 競態條件涉及兩個 DNS 執行器之間不太可能發生的互動。
          • 在正常操作下，DNS 執行器會取得最新規劃並開始逐一處理服務端點以套用此規劃。
          • 此過程通常會快速完成，並能有效地保持 DNS 狀態的即時更新。
          • 在開始套用新規劃之前，DNS 執行器會進行一次性檢查，確認其規劃比先前套用的規劃更新。
          • 當 DNS 執行器逐一處理端點清單時，它可能會在嘗試交易時遇到延遲，因為被另一個正在更新同一端點的 DNS 執行器阻擋。
          • 在這些情況下，DNS 執行器會重試每個端點，直到規劃成功套用到所有端點。
        • 就在此事件開始之前，一個 DNS 執行器在數個 DNS 端點上需要重試更新時，經歷了異常高的延遲。
          • 當它緩慢地處理端點時，其他幾件事情也同時發生。
          • 首先，DNS 規劃器持續運行並產生了許多更新版本的規劃。
          • 其次，另一個 DNS 執行器開始套用其中一個較新的規劃，並快速地完成所有端點的處理。
          • 這些事件的時序觸發了潛在的競態條件。
          • 當第二個執行器 (套用最新規劃) 完成其端點更新時，它接著啟動了規劃清理程序 (clean-up process)，該程序會識別出比它剛剛套用的規劃明顯更舊的規劃並刪除它們。
          • 在此清理程序被啟動的同時，第一個執行器 (已經異常延遲) 將其更舊的規劃套用到區域 DDB 端點，覆蓋了較新的規劃。
          • 在規劃套用過程開始時所進行的檢查 (確保規劃比先前套用的規劃更新) 此時已經過時，這是由於執行器處理中異常高的延遲所致。
          • 因此，這無法防止舊規劃覆蓋新規劃。
          • 第二個執行器的清理程序接著刪除了這個舊規劃，因為它比剛剛套用的規劃舊了許多代 (generation)。
          • 當此規劃被刪除時，區域端點的所有 IP 位址立即被移除。
          • 此外，由於活動規劃被刪除，系統處於不一致的狀態，阻止了任何 DNS 執行器後續套用規劃更新。
          • 這種情況最終需要人工操作員介入才能糾正。
  • 當此問題在晚上 11:48 發生時，所有需要透過公開端點連線到北維吉尼亞 (us-east-1) 區域 DynamoDB 服務的系統立即開始經歷 DNS 失敗，並無法連線到 DynamoDB。
    • 這包括客戶流量以及依賴 DynamoDB 的內部 AWS 服務的流量。
    • 擁有 DynamoDB 全域資料表 (global table) 的客戶能夠成功連線並對其他區域的副本資料表 (replica table) 發出請求，但經歷了與北維吉尼亞 (us-east-1) 區域副本資料表之間的複寫延遲 (replication lag) 延長。
    • 受影響 AWS 服務的工程團隊立即參與並開始調查。
    • 到 10 月 20 日凌晨 12:38，我們的工程師已經確認 DynamoDB 的 DNS 狀態是中斷的來源。
      • ℹ️ Ernest 補充：不到一個小時！（回頭想想自己的服務、可觀測工具、工作流程，有辦法在一個小時內定位問題、找出潛在 root cause 嗎？）
    • 到凌晨 1:15，套用的臨時緩解措施 (mitigation) 使一些內部服務能夠連線到 DynamoDB，並修復了關鍵的內部工具，解除了進一步復原的阻礙。
    • 到凌晨 2:25，所有 DNS 資訊都已恢復，所有全域資料表副本到凌晨 2:32 完全同步。
    • 客戶能夠解析 DynamoDB 端點，並在凌晨 2:25 到 2:40 之間，隨著快取 (cache) 的 DNS 記錄過期，建立成功的連線。
    • 這完成了主要服務中斷事件的復原。

2️⃣ Amazon EC2

  • 在 10 月 19 日晚上 11:48 到 10 月 20 日下午 1:50 之間，
    • 客戶在北維吉尼亞 (us-east-1) 區域經歷了EC2 API 錯誤率、延遲和執行個體啟動失敗增加的情況。
    • 在事件開始之前已經啟動的現有 EC2 執行個體保持健康，在事件期間沒有經歷任何影響。
    • 在凌晨 2:25 解決 DynamoDB DNS 問題後，客戶繼續看到新執行個體啟動的錯誤增加。
    • 復原在中午 12:01 開始，完整的 EC2 復原發生在下午 1:50 。
    • 在此期間，新執行個體啟動失敗，並出現「超過請求限制 (request limit exceeded)」或「容量不足 (insufficient capacity)」錯誤。
  • 為了理解發生了什麼，
    • 我們需要分享一些關於幾個子系統 (subsystem)的資訊，這些子系統用於管理 EC2 執行個體啟動，
    • 以及為新啟動的 EC2 執行個體配置網路連線。
    • 第一個子系統是 DropletWorkflow Manager (DWFM)，負責管理 EC2 用於託管 EC2 執行個體的所有底層實體伺服器——我們稱這些伺服器為「droplet」。
    • 第二個子系統是網路管理器 (Network Manager)，負責管理和傳播網路狀態到所有 EC2 執行個體和網路設備。
    • 每個 DWFM 管理每個可用區域 (Availability Zone) 內的一組 droplet，並為目前管理的每個 droplet 維護一個 租約 (lease)。
    • 此租約允許 DWFM 追蹤 droplet 狀態，確保來自 EC2 API 或 EC2 執行個體本身的所有動作，例如源自 EC2 執行個體作業系統的關機或重新啟動操作，在更廣泛的 EC2 系統中產生正確的狀態變更。
    • 作為維護此租約的一部分，每個 DWFM 主機 (DWFM host)必須與其管理的每個 droplet 進行檢查並完成狀態檢查 (state check)，每隔幾分鐘一次。
  • 從 10 月 19 日晚上 11:48 開始，
    • 這些 DWFM 狀態檢查開始失敗，因為該過程依賴 DynamoDB 且無法完成。
    • 雖然這不影響任何運行中的 EC2 執行個體，但它確實導致 droplet 需要與 DWFM 建立新的租約，才能對其託管的 EC2 執行個體進行進一步的執行個體狀態變更。
    • 在 10 月 19 日晚上 11:48 到 10 月 20 日凌晨 2:24 之間，
    • EC2 機群中 DWFM 與 droplet 之間的租約開始慢慢逾時。
  • 在凌晨 2:25 ，
    • 隨著 DynamoDB API 的復原，
    • DWFM 開始重新與整個 EC2 機群中的 droplet 建立租約。
    • 由於任何沒有活動租約的 droplet 都不被視為新 EC2 啟動的候選者，
    • EC2 API 對新傳入的 EC2 啟動請求回傳「容量不足錯誤 (insufficient capacity error)」。
    • DWFM 開始與整個 EC2 機群中的 droplet 重新建立租約的過程；
    • 然而，由於 droplet 數量龐大，
    • 建立新 droplet 租約的工作耗時很長，以至於在逾時之前無法完成。
    • 額外的工作被排入佇列以重新嘗試建立 droplet 租約。
    • 此時，DWFM 已進入壅塞崩潰 (congestive collapse) 的狀態，無法在恢復 droplet 租約方面取得進展。
    • 由於這種情況沒有既定的操作復原程序，工程師在嘗試解決 DWFM 問題時謹慎行事，以避免造成進一步問題。
    • 在嘗試多個緩解步驟後，
    • 凌晨 4:14 工程師限流了傳入工作，並開始選擇性地重新啟動 DWFM 主機以從這種情況中恢復。
    • 重新啟動 DWFM 主機清空了 DWFM 佇列，
    • 減少了處理時間，
    • 並允許建立 droplet 租約。
    • 到上午 5:28，DWFM 已與北維吉尼亞 (us-east-1) 區域內的所有 droplet 建立了租約，新的啟動再次開始成功，
    • 儘管許多請求仍然看到「超過請求限制 (request limit exceeded)」錯誤，這是由於為減少整體請求負載而引入的請求限流 (throttle)。
  • 當啟動新的 EC2 執行個體時，
    • 一個稱為網路管理器 (Network Manager)的系統會傳播網路配置，使執行個體能夠與同一虛擬私有雲 (Virtual Private Cloud, VPC) 內的其他執行個體、其他 VPC 網路設備和網際網路通訊。
    • 在上午 5:28 ，DWFM 恢復後不久，
    • 網路管理器開始向新啟動的執行個體和在事件期間已終止的執行個體傳播更新的網路配置。
    • 由於這些網路傳播 (propagation) 事件因 DWFM 問題而延遲，
    • 北維吉尼亞 (us-east-1) 區域內的網路管理器需要處理大量積壓的網路狀態傳播。
    • 因此，在上午 6:21，網路管理器在處理積壓的網路狀態變更時，開始經歷網路傳播時間延遲增加。
    • 雖然新的 EC2 執行個體可以成功啟動，
    • 但由於網路狀態傳播的延遲，它們不會有必要的網路連線。
    • 工程師努力減少網路管理器的負載，以解決網路配置傳播時間問題，並採取行動加速復原。
    • 到上午 10:36，網路配置傳播時間已恢復到正常水平，
    • 新的 EC2 執行個體啟動再次正常運作。
  • EC2 復原的最後一步是完全移除為減少各種 EC2 子系統負載而設置的請求限流。
    • 隨著 API 呼叫和新 EC2 執行個體啟動請求穩定下來，
    • 在上午 11:23 ，我們的工程師開始放寬請求限流，朝著完全復原努力。
    • 在下午 1:50，所有 EC2 API 和新 EC2 執行個體啟動都正常運作。

3️⃣ Network Load Balancer (NLB)

  • 新啟動的 EC2 執行個體的網路狀態傳播 (propagation) 延遲也對網路負載平衡器 (Network Load Balancer, NLB) 服務和使用 NLB 的 AWS 服務造成影響。
    • 在 10 月 20 日上午 5:30 到下午 2:09 之間，部分客戶在北維吉尼亞 (us-east-1) 區域的 NLB 上經歷了連線錯誤增加的情況。
    • NLB 建構於高度可擴展的多租戶 (multi-tenant) 架構之上，提供負載平衡端點並將流量路由到後端目標 (backend target)，這些目標通常是 EC2 執行個體。
    • 該架構還使用一個獨立的健康檢查子系統，定期對 NLB 架構內的所有節點 (node) 執行健康檢查 (health check)，並會將任何被視為不健康的節點從服務中移除。
  • 在事件期間，NLB 健康檢查子系統開始經歷健康檢查失敗增加的情況。
    • 這是由於健康檢查子系統將新的 EC2 執行個體帶入服務，而這些執行個體的網路狀態尚未完全傳播所致。
    • 這意味著在某些情況下，即使底層 NLB 節點和後端目標是健康的，健康檢查也會失敗。
    • 這導致健康檢查在失敗和健康之間交替。這導致 NLB 節點和後端目標從 DNS 中移除，
    • 只有在下一次健康檢查成功時才會恢復服務。
  • 我們的監控系統在上午 6:52 檢測到這個問題，
    • 工程師開始著手修復此問題。
    • 交替的健康檢查結果增加了健康檢查子系統的負載，
    • 導致其降級，
    • 造成健康檢查延遲並觸發自動可用區域 (AZ) DNS 故障轉移 (failover) 的發生。
    • 對於多可用區域負載平衡器，
    • 這導致容量被退出服務。
    • 在這種情況下，
    • 如果剩餘的健康容量不足以承載應用程式負載，應用程式會經歷連線錯誤增加。
    • 在上午 9:36，工程師停用了 NLB 的自動健康檢查故障轉移，
    • 允許所有可用的健康 NLB 節點和後端目標恢復服務。
    • 這解決了受影響負載平衡器的連線錯誤增加問題。
    • 在 EC2 恢復後不久，我們在下午 2:09 重新啟用了自動 DNS 健康檢查故障轉移。

4️⃣ Other AWS Services

  • 在 10 月 19 日晚上 11:51 到 10 月 20 日下午 2:15 之間，
    • 客戶在北維吉尼亞 (us-east-1) 區域經歷了 Lambda 函式 (function) 的 API 錯誤和延遲。
    • 最初，DynamoDB 端點問題阻止了函式的建立和更新，
    • 導致 SQS/Kinesis 事件來源 (event source) 的處理延遲和調用 (invocation) 錯誤。
    • 到凌晨 2:24，
    • 除了 SQS 佇列 (queue) 處理外，服務操作已恢復，
    • SQS 佇列處理仍然受到影響，因為負責輪詢 (polling) SQS 佇列的內部子系統失敗且未自動恢復。
    • 我們在凌晨 4:40 恢復了此子系統，並在上午 6:00 處理完所有訊息積壓 (backlog)。
    • 從上午 7:04 開始，
    • NLB 健康檢查失敗觸發了執行個體終止 (termination)，使 Lambda 內部系統的一部分容量不足。
    • 由於 EC2 啟動仍受損，
    • 我們限流了 Lambda 事件來源映射 (Event Source Mapping) 和非同步調用 (asynchronous invocation)，以優先處理對延遲敏感的同步調用 (synchronous invocation)。
    • 到上午 11:27，
    • 足夠的容量已恢復，錯誤減少。
    • 然後我們逐步減少限流，並在下午 2:15 處理完所有積壓，正常服務操作恢復。
  • 在 10 月 19 日晚上 11:45 到 10 月 20 日下午 2:20 之間，
    • 客戶在北維吉尼亞 (us-east-1) 區域的 Amazon Elastic Container Service (ECS)、Elastic Kubernetes Service (EKS) 和 Fargate 上經歷了容器 (container) 啟動失敗和叢集 (cluster) 擴展延遲。
    • 這些服務在下午 2:20 恢復。
  • 在 10 月 19 日晚上 11:56 到 10 月 20 日下午 1:20 之間，
    • Amazon Connect 客戶在北維吉尼亞 (us-east-1) 區域處理通話 (call)、聊天 (chat) 和案例 (case) 時經歷了錯誤增加。
    • 在 DynamoDB 端點恢復後，
    • 大多數 Connect 功能已恢復，但客戶在凌晨 5:00 之前持續經歷聊天的錯誤增加。
    • 從上午 7:04 開始，
    • 客戶再次經歷處理新通話、聊天、任務 (task)、電子郵件 (email) 和案例時的錯誤增加，這是由於 Connect 使用的 NLB 受到影響，以及 Lambda 函式調用的錯誤率和延遲增加所致。
    • 來電者經歷忙音 (busy tone)、錯誤訊息或連線失敗。
    • 座席發起 (agent-initiated) 和 API 發起 (API-initiated) 的外撥電話都失敗了。
    • 已接聽的通話經歷了提示播放 (prompt playback) 失敗、路由到座席 (agent) 失敗，或音訊死寂 (dead-air audio)。
    • 此外，座席在處理聯絡人 (contact) 時經歷了錯誤增加，部分座席無法登入。
    • 客戶在存取 API 和聯絡人搜尋 (Contact Search) 時也面臨錯誤增加。
    • 即時 (Real-time)、歷史儀表板 (Historical dashboard) 和資料湖 (Data Lake) 資料更新延遲，
    • 所有資料將在 10 月 28 日前回填 (backfill)。
    • 隨著 Lambda 函式調用錯誤恢復，服務可用性在下午 1:20 恢復。
  • 在 10 月 19 日晚上 11:51 到上午 9:59 之間，
    • 客戶在北維吉尼亞 (us-east-1) 區域經歷了 AWS Security Token Service (STS) API 錯誤和延遲。
    • STS 在內部 DynamoDB 端點恢復後於凌晨 1:19 恢復。
    • 在上午 8:31 到 9:59 之間，
    • 由於 NLB 健康檢查失敗，STS API 錯誤率和延遲再次增加。
    • 到上午 9:59，我們從 NLB 健康檢查失敗中恢復，服務開始正常運作。
  • 在 10 月 19 日晚上 11:51 到 10 月 20 日凌晨 1:25 之間，
    • 嘗試使用 IAM 使用者 (IAM user) 登入 AWS 管理主控台 (AWS Management Console) 的 AWS 客戶，由於北維吉尼亞 (us-east-1) 區域的底層 DynamoDB 問題，經歷了身份驗證 (authentication) 失敗增加。
    • 在北維吉尼亞 (us-east-1) 區域配置 IAM Identity Center 的客戶也無法使用 Identity Center 登入。
    • 使用其根憑證 (root credential) 的客戶，以及使用配置為使用 signin.aws.amazon.com 的身份聯合 (identity federation) 的客戶，在嘗試登入北維吉尼亞 (us-east-1) 區域以外的區域的 AWS 管理主控台時遇到錯誤。
    • 隨著 DynamoDB 端點在凌晨 1:25 變得可存取，服務開始正常運作。
  • 在 10 月 19 日晚上 11:47 到 10 月 20 日凌晨 2:21 之間，
    • 客戶在北維吉尼亞 (us-east-1) 區域建立和修改 Redshift 叢集或對現有叢集發出查詢 (query) 時經歷了 API 錯誤。
    • Redshift 查詢處理依賴 DynamoDB 端點從叢集讀取和寫入資料。
    • 隨著 DynamoDB 端點恢復，Redshift 查詢操作恢復，到凌晨 2:21，Redshift 客戶成功查詢叢集，以及建立和修改叢集配置。
    • 然而，在 DynamoDB 端點恢復正常運作後，部分 Redshift 運算叢集仍受損且無法進行查詢。
    • 當叢集節點的憑證過期而未被更新時，Redshift 自動化會觸發工作流程 (workflow) 以用新執行個體替換底層 EC2 主機。
    • 由於 EC2 啟動受損，這些工作流程被阻塞，使叢集處於「修改中 (modifying)」狀態，阻止了查詢處理並使叢集無法用於工作負載 (workload)。
    • 在上午 6:45，我們的工程師採取行動阻止工作流程積壓增長，當 Redshift 叢集在下午 2:46 開始啟動替換執行個體時，積壓的工作流程開始消耗。
    • 到 10 月 21 日凌晨 4:05，AWS 操作員完成了受替換工作流程影響的叢集可用性恢復。除了叢集可用性受損外，在 10 月 19 日晚上 11:47 到 10 月 20 日凌晨 1:20 之間，所有 AWS 區域的 Amazon Redshift 客戶由於 Redshift 缺陷而無法使用 IAM 使用者憑證執行查詢，該缺陷使用北維吉尼亞 (us-east-1) 區域的 IAM API 來解析使用者群組 (user group)。
    • 因此，IAM 在此期間的受損導致 Redshift 無法執行這些查詢。使用「本地 (local)」使用者連線到其 Redshift 叢集的 AWS 區域 Redshift 客戶未受影響。
  • 在 10 月 19 日晚上 11:48 到 10 月 20 日凌晨 2:40 之間，
    • 客戶無法透過 AWS 支援 (AWS Support) 主控台 (Console) 和 API 建立、檢視和更新支援案例。
    • 雖然支援中心 (Support Center) 如設計般成功故障轉移到另一個區域，但負責帳戶中繼資料 (metadata) 的子系統開始提供阻止合法使用者存取 AWS 支援中心的回應。雖然我們已經設計支援中心在回應不成功時繞過此系統，但在此事件中，此子系統回傳了無效回應。
    • 這些無效回應導致系統意外地阻止合法使用者存取支援案例功能。
    • 問題在凌晨 2:40 得到緩解，我們在凌晨 2:58 採取了額外行動以防止再次發生。
  • 其他依賴 DynamoDB、新 EC2 執行個體啟動、Lambda 調用和 Fargate 任務 (task) 啟動的 AWS 服務，
    • 例如 Managed Workflows for Apache Airflow 和 Outposts 生命週期 (lifecycle) 操作，在北維吉尼亞 (us-east-1) 區域也受到影響。
    • 請參閱事件歷史 (event history) 以獲取受影響服務的完整清單。
  • 我們正在因應此次營運事件進行多項變更。
    • 我們已在全球範圍內停用 DynamoDB DNS 規劃器 (DNS Planner) 和 DNS 執行器 (DNS Enactor) 自動化。
    • 在重新啟用此自動化之前，我們將修復競態條件 (race condition) 情境並添加額外保護措施以防止套用不正確的 DNS 規劃。
    • 對於 NLB，我們正在添加速度控制機制 (velocity control mechanism)，以限制當健康檢查失敗導致 AZ 故障轉移時，單一 NLB 可以移除的容量。
    • 對於 EC2，我們正在建構額外的測試套件 (test suite) 以增強我們現有的規模測試 (scale testing)，該套件將執行 DWFM 復原工作流程以識別任何未來的退化 (regression)。
    • 我們將改進 EC2 資料傳播系統中的限流機制 (throttling mechanism)，根據等待佇列的大小對傳入工作進行速率限制 (rate limit)，以在高負載期間保護服務。
    • 最後，隨著我們繼續研究所有 AWS 服務的此事件細節，我們將尋找更多方法來避免未來類似事件的影響，以及如何進一步縮短復原時間。
  • 結語
    • 我們為此事件對客戶造成的影響致歉。
    • 雖然我們在以最高可用性水準運營服務方面有著良好的記錄，但我們知道我們的服務對客戶、他們的應用程式和終端使用者，以及他們的業務有多麼重要。
    • 我們知道此事件以重大方式影響了許多客戶。
    • 我們將盡一切努力從此事件中學習，並利用它進一步提高我們的可用性。

✳️ Bottom Line

事發當時正在處理一個靜態網站部署，在清空 CloudFront CDN 時看到一個沒看過的錯誤訊息，當時有覺得奇怪，不應該有這種錯誤訊息。然後陸續看到有一些網站服務都連得上、但是其中的某些功能失效或轉圈圈等很久，這才意識到可能是一次 AWS 服務中斷，趕緊切到 AWS Health Dashboard 追蹤。

當天的過程有追蹤紀錄 4 （但為了讓大家能充分討論與交換意見，僅限開放給有見過面的朋友們），雖然有點驚嚇，因為一開始只標示「Impacted」，然後突然將 DynamoDB 標示成「Distrpted」，心想這下不妙，DynamoDB 是許多服務的底層資料庫。但不到一個小時，AWS 工程師已經更新說有鎖定可能的問題與可能的原因，覺得佩服，想說這應該平常都有演練。

無獨有偶，2025-10-20 AWS 這次與 DNS 有關的服務中斷吿一段落之後，於 2025-10-29 Microsoft 也發生 DNS outage 5，曾經有一度連 Microsoft 官網都無法連上，也造成 Microsoft Azure、Microsoft 365 等服務受到影響。不禁讓我思考，會不會有什麼 DNS 相關的規格變更、或限制條件、或合規與這個時間點有關係，果然找到一條關於「美國聯邦政府 OMB Memorandum M-21-07」，於 2020-11 發布，規定到 2025 財年結束（2025/9/30）前，聯邦網路上至少 80% 的 IP 啟用資產必須在 IPv6-only 環境中運行。階段性目標：

  • 2023 財年底：至少 20% IPv6-only
  • 2024 財年底：至少 50% IPv6-only
  • 2025 財年底：至少 80% IPv6-only

這就說明為什麼 2025-10-09 有一則新聞是 Amazon DynamoDB now supports Internet Protocol version 6 (IPv6)。不確定是否與這次服務中斷直接或間接相關，但總是引人聯想。

接下來幾個月可能也是需要留意 DNS 或 IPv6 相關的服務中斷，但 AWS 加上 微軟 兩家雲端服務商有過半市佔率，其他有運行聯邦資產的美國服務商可能在這幾個月也可能出問題，但影響範圍可能也相對較小。

✳️ 延伸閱讀

  1. https://aws.amazon.com/message/101925/ ↩︎

  2. AWS Community Hero Ernest ↩︎

  3. Global Infrastructure Regions & AZs ↩︎ ↩︎

  4. https://www.facebook.com/ernestchiang/posts/pfbid02s6s46DAjNQXmyjahYgqKWMhBKMavXq8pq3Ugy4Kd12XTtrZ4fajJSZ6ZxM13tkfCl ↩︎

  5. https://www.bleepingcomputer.com/news/microsoft/microsoft-dns-outage-impacts-azure-and-microsoft-365-services/ ↩︎