AWS國際帳號 AWS Aurora 自動擴展失效排查

前言：先判斷「失效」是哪一種

不少團隊遇到「Aurora 自動擴展失效」時，第一反應是檢查設定，最後卻發現問題其實出在監控口徑、資源容量、或是事件未被正確記錄。要把問題收斂得快，關鍵是先把「失效」定義清楚：你看到的是沒有觸發、觸發了沒擴、還是擴了但沒有改善？不同答案會導向完全不同的排查路徑。

本文以 Aurora（含 Serverless v2 或 Provisioned + Auto Scaling 的典型用法）為背景，給出一套可落地的排查流程。你不需要先看一堆概念，照著問題問下去、把時間線補齊，就能找到真正的卡點。

第一章：用時間線鎖定真正的問題

1. 先確定「該擴」的時間範圍

自動擴展是否失效，常常不是「一直不動」，而是只在某些峰值窗口失效。請你回到最近一次流量上升：例如 10:00–12:00 的尖峰。把這段時間記下來，後續所有查詢都圍繞這段窗口展開。

建議你同時記錄三個資訊：
(1) 當時的業務指標（請求量、延遲、錯誤率）。
(2) 你設定的伸縮目標或觸發指標（例如 Aurora Replica Lag、CPU、連線數等）。
(3) 期望的擴展結果（增加讀節點？擴大容量？）。

2. 列出「預期 vs 實際」差距

把觀察寫清楚：

• 預期是增加讀節點到 N，但實際一直在 M。
• 預期是容量擴大，但 Aurora 集群的容量沒有上去。
• 預期是觸發後幾分鐘完成，但實際卡在某個狀態。

這個差距是排查的方向盤。因為「沒觸發」與「觸發未完成」的根因很不一樣：前者多半是指標條件或策略設計；後者則可能是容量、網路、安全、配額或資源可用性。

3. 從事件日誌開始：找「伸縮決策」是否發生

不管你用的是 Application Auto Scaling、Aurora 自帶的伸縮能力，或是 Serverless 的容量自動變更，系統都會留下某種形式的事件記錄。你的目標不是立刻解讀，先把「是否有伸縮決策」查出來。

你可以用同一個思路檢查：在那段時間附近，是否出現伸縮活動（Scaling activity）、是否有錯誤（AccessDenied、ResourceLimit、Insufficient capacity 之類）、或是否有「因為不符合條件而跳過」的訊息。

AWS國際帳號 如果你找不到任何伸縮活動，通常意味著：根本沒有進入決策流程，或事件被分流到你沒看的地方。這時候就不要急著改策略，先回到「伸縮是否啟用、是否綁定到正確資源、是否有權限去執行」這三件事。

第二章：指標與監控口徑是最常見的根因

1. 檢查觸發指標是否真的達標

自動擴展失效最直觀的原因：你以為達標，但其實沒有。這裡的陷阱在於指標延遲、取樣頻率、或指標選取錯誤。

請你回到你設定的觸發指標，做三件事：

• 對照峰值期間，指標是否真的跨過閾值（Threshold）。
• 對照「評估週期」（例如連續 N 分鐘）是否滿足。
• 對照「單位與維度」是否一致（例如 CPU vs Aurora 指標 CPU，或 Replica Lag 的定義）。

很多團隊用「看起來差不多」的圖表做判斷，但自動擴展用的是另一個指標或另一種統計方式（平均、最大、p99）。一旦口徑不一致，就會出現你在圖上看到了壓力，系統卻說「沒有達到觸發條件」。

2. 確認指標是否有延遲：伸縮是慢的

伸縮不是即時反應。即便達到條件，也要經過監控採樣、計算、再下發策略執行，整個週期可能是數分鐘。你需要把「達標時間」與「伸縮活動時間」對齊。

如果峰值在幾分鐘內就過去，而伸縮需要更長的評估週期，那自然會看起來像失效。這不是 bug，而是策略設計與業務脈衝不匹配。

3. 檢查指標是否缺失或不再上報

如果指標突然消失，伸縮通常不會繼續評估（或會保守地視為無效）。造成指標缺失的原因可能包括：監控權限、指標系統故障、或你在建雲時更換了集群/資源導致指標來源變了。

你可以把指標曲線的完整性檢查一遍：是否存在明顯空窗？是否剛好在部署變更後開始異常？如果是，回到變更時間點，通常比從策略重新推導更快。

第三章：伸縮設定本身的常見坑

1. 最小值/最大值（Min/Max）直接決定你能不能擴

很多「永遠擴不出來」的案例其實是因為 Max 設得太小，或 Min 已經等於 Max。另一種情況是你預期擴的是讀副本，但策略綁定的可擴維度不是你想像的那個。

排查時請把你關心的三個上限/下限寫下來：

• 讀節點最大數（或容量最大值）是否真的大於目前數量。
• 最小值是否把它固定住（Min = Max）。
• 是否存在多條策略互相打架（例如一條想擴，一條想縮，還有冷卻時間）。

2. 冷卻時間與衝突條件：看似失效，其實被抑制

策略常見設計包含冷卻時間（Cooldown）或暫停時間（Scale in cooldown / scale out cooldown）。如果上一輪剛縮過，系統可能暫時不允許再擴，導致你在下一次峰值時看到沒動。

此外，如果你用多個策略（例如根據不同指標觸發擴/縮），就要確認它們的優先順序或是否存在條件互斥。沒有細讀策略的團隊，常會在「策略可以出手」的情況下仍然觀察不到結果，原因就是被其他策略覆蓋。

3. 評估週期與資料粒度：閾值雖然達到，卻沒有連續

假設你的閾值是 Replica Lag > 30s，評估週期要求連續 5 分鐘。但你的 Replica Lag 在峰值過程中只維持了 2 分鐘，就會觸發不了。你需要把你業務尖峰的持續時間與評估設計對齊。

這一點很容易在壓測或真實流量下被忽略：真實流量的尖峰可能更短、更尖，而策略的評估窗口更長。

4. 擴容類型選錯：該擴的是讀，卻擴了寫或容量

AWS國際帳號 在 Aurora 的世界裡，常見有兩類需求：

• 讀壓力上升，需要增加只讀副本（讀節點）。
• 寫入或整體性能壓力上升，需要增加容量或調整負載。

如果你把觸發條件綁到不對的維度，結果就會「動了但沒改善」甚至「看起來像失效」。例如你增加了容量卻沒有增加讀副本，導致讀延遲仍然高。

第四章：資源容量、配額與網路條件會讓擴展「決策失敗」

1. 伸縮決策發出了，但執行失敗

若你在事件日誌中看到了伸縮活動，但最後是失敗，請不要再糾結指標，優先查失敗原因。常見錯誤類型包括：

• AWS國際帳號 配額不足（例如目標區域可用的某類資源容量不足）。
• 容量不足或可用性問題（實例無法在該可用區快速建立）。
• 網路或安全限制（子網路由、SG/IAM 綁定不允許連通）。
• 依賴資源缺失（例如需要的子網或 KMS 設定不完整）。

這類問題最傷的是：你以為系統不動，其實它嘗試過，只是失敗了。你要做的是把事件錯誤碼釘到表面上，然後對症下手。

2. VPC 與子網：自動伸縮常依賴正確的選址

自動擴展時新增的資源（讀副本或更高容量）通常需要落在特定子網。若子網配置不足，例如缺少可用區覆蓋、路由或 NAT 不能正常出站、或安全群組規則不匹配，擴展就可能卡住或失敗。

排查時可以把三個條件核對一次：

• 伸縮目標是否綁定正確的 VPC 與子網集合。
• 安全群組是否允許必要的連線（特別是新加入節點的互通）。
• AWS國際帳號 若使用加密/KMS，新增資源是否具備必要的 KMS 權限。

3. 配額與預留容量：為什麼平時沒問題，尖峰時出事

平時流量小時你不用擴，配額也不會逼到上限；而在尖峰時，伸縮才會向上追，這時才暴露配額不足。常見情況是某個地區或某類資源配額接近極限。

另外還有「預留容量」的問題：即使配額足夠，當前可用區供給緊張，仍可能造成建立時間拉長或直接失敗。你在排查時要留意伸縮活動的時間成本：如果每次都拖很久，那多半是容量問題。

第五章：IAM 權限與自動化角色：看似配置好，其實缺一個權限

1. 最小權限策略造成的 AccessDenied

自動擴展涉及控制平面（伸縮服務）去執行資源變更。若你使用了自訂角色或收斂過權限，容易只差一個動作導致失敗。這類錯誤往往會在事件或日誌中明確顯示 AccessDenied。

AWS國際帳號 排查時不要泛查：直接針對失敗事件中的權限錯誤碼，回到角色策略做對照。把「允不允許該資源類型」與「允不允許該動作」分開檢查。

2. 資源綁定錯誤：角色允許，但指到錯的資源

有些團隊修好了權限，卻仍然看不到伸縮活動效果，原因是策略綁定的 ARN（或資源 ID）不正確。角色允許的是某個特定集群，但你的伸縮策略綁到了另一個集群，導致決策通過卻執行不了。

因此在檢查資源時，要同時核對：

• 伸縮策略實際綁定到的 Aurora 集群 ID。
• 該集群是否是你正在觀察的那個環境。
• 是否有環境切換（例如藍綠部署）導致策略仍留在舊集群。

第六章：檢查事件與日誌的「讀法」

AWS國際帳號 1. 先抓三個欄位：時間、原因、結果

不論你用的是哪種自動擴展機制，事件日誌通常都能提供足夠信息。你要做的是把每一次活動整理成表格或清單，至少包含：

• 活動時間（開始、結束或失敗時間）。
• 原因（觸發指標達標、手動觸發、或冷卻抑制等）。
• 結果（成功、失敗、取消）。

這個整理能立刻回答兩個問題：第一，系統在你以為的窗口內是否真的嘗試伸縮；第二，嘗試失敗時是否每次都同一個原因。

2. 對照指標：如果事件說「沒有達標」，就不要急著改容量

很多情況事件會直接告訴你「因為指標未達到觸發條件」或「資料不足」。這時最合理的動作是回到第三章的指標口徑與監控延遲。你不應該一上來就改 Min/Max，因為你可能在錯的層級浪費時間。

3. 對照資源：如果事件說「執行失敗」，就回到容量與網路

如果事件顯示伸縮命令下發了但執行失敗，通常就是資源與環境條件問題。這種情況最常見的是新節點無法建立或初始化失敗。你應該把失敗原因鎖定到類型上，再進行具體修復。

第七章：一套實戰排查流程（可照做）

步驟一：鎖定最近一次尖峰與期望結果

確認你看到的問題是「沒觸發」還是「觸發失敗」。寫下時間窗口、伸縮目標（讀/寫/容量）和期望數值。

步驟二：查伸縮活動是否存在

在事件日誌中找同一時間窗口的伸縮活動。如果完全沒有，先檢查：是否啟用、是否綁對資源、角色是否有權限、冷卻是否抑制。

步驟三：核對指標達標與評估週期

回看你用來觸發的指標：尖峰期間是否真的跨過閾值？連續幾個採樣週期是否達標？如果指標延遲或統計方式不同，這一步會直接給出答案。

步驟四：核對 Min/Max 與策略互斥

確認最大值沒有把伸縮上限卡死，確認策略冷卻沒有剛好抑制下一次。若有多條策略，檢查是否互相抵消。

AWS國際帳號 步驟五：如果有失敗事件，直接按錯誤類型修

配額不足就先提額或調整部署規劃；容量不足就擴充可用區策略或檢查節點放置限制；網路與安全群組就把新增節點的連通性跑一遍。

步驟六：改完不是立刻放行，要做回歸測試

任何策略與配額調整都要回歸。最簡單做法是用壓測或可控的流量演練，在你設定的評估窗口內把指標推到預期區間，觀察是否會觸發伸縮，以及觸發後是否真的落地。

第八章：幾個典型案例與對應結論

案例一：Replica Lag 很高，但沒有擴

表面看起來是讀壓力爆了，但系統說未達標。最後往往是口徑問題：你看的圖表是某個延遲類似指標，策略用的是另一個（或是用了不同統計聚合方式）。改完指標後，伸縮才恢復。

結論：優先核對你用來判斷的圖表與策略實際綁定的指標，並對齊聚合方式與評估週期。

案例二：伸縮活動有，但一直失敗

事件日誌顯示執行失敗，錯誤碼指向配額或容量不足。團隊一開始懷疑策略，反覆調閾值，結果仍然失敗。最後是提額或調整部署後，可用區可建立資源才恢復。

結論：事件裡如果有明確失敗原因，就不要把時間浪費在指標調參上。

案例三：觸發了但改善不明顯

系統確實擴了，但你看到延遲還是高。常見原因是擴了錯的方向：例如應該增加讀副本，卻改成調整寫入容量；或你的應用未真正把讀流量切到新增的讀副本（連線池、路由規則、DNS 缓存策略等）。

結論：伸縮不是目的，改善才是；要同步檢查應用側的讀路由與連線策略。

第九章：把策略設計得更可靠，而不只是「能觸發」

1. 設計要考慮尖峰的持續時間

如果業務尖峰是短促的，評估週期不應該太長。相反，如果壓力是持續性的，你可以用更保守的策略避免抖動。目標是：在合理成本下，以最小延遲把系統拉回穩定狀態。

2. 把伸縮與容量規劃協同

不要只依賴自動擴展來解決一切。至少在容量/配額層面要做保底：確保在你預期的擴展幅度內，區域供給與配額不會直接把伸縮擋住。

3. 指標監控要可驗證：每次策略都要能對得上事實

一套好的排查體系，最後都會回到「可驗證」。你應該能用事件日誌與指標曲線，清楚說明每一次伸縮為什麼發生、為什麼成功或失敗。當團隊能做到這點，自動擴展就不會變成不可控的黑盒。

結語：把黑盒變成可解的問題

Aurora 自動擴展失效最怕的是把排查當成猜測遊戲：改一下策略、等一下、又改一下。真正有效的做法是把問題拆成三段：第一段是「是否該擴」（指標與策略判斷）；第二段是「是否能擴」（配額、容量、網路、依賴資源）；第三段是「擴了是否真的有用」（應用路由、連線策略與實際負載是否轉移）。

你只要沿著這條路徑走，並在每一步用事件與指標做佐證，問題就會從模糊的抱怨變成明確的結論，最後也能沉澱成團隊的可複用檢查清單。