Auto Scaling — Lifecycle Hooks、Warm Pools 與擴展政策

EC2 Auto Scaling 生命週期勾子 (lifecycle hooks) 與溫集區 (warm pools) 是領域 3（韌性雲端解決方案）的核心。DOP-C02 考試將其視為 安全擴展與部署 的主要機制 —— 勾子允許你在實例啟動或終止期間暫停，以清空連線、註冊監控或預熱快取；溫集區則讓你保留預先初始化的實例，以便在幾秒鐘內（而非幾分鐘）切換到服務狀態。結合 實例重新整理 (instance refresh)、目標追蹤與預測性擴展，以及 與 CodeDeploy 和 SSM 的整合，它們構成了彈性、低擴展延遲架構的工具箱。

本指南假設你已了解什麼是自動擴展群組 (ASG) 以及啟動範本 (launch template)。DOP-C02 的重點在於：Pending:Wait 和 Terminating:Wait 勾子狀態、活動訊號逾時 (heartbeat timeouts) 與 complete-lifecycle-action、逾時時的預設動作 (ABANDON vs CONTINUE)、溫集區狀態 (Stopped, Running, Hibernated)、具有檢查點 (checkpoints) 與跳過匹配 (skip-matching) 的實例重新整理、目標追蹤 vs 步進 vs 簡易擴展政策、預測性擴展、運作狀態檢查類型 (EC2 vs ELB vs 自定義)、終止政策、用於維護的待命 (Standby) 狀態，以及生命週期勾子觸發 Lambda 或 SSM 自動化執行手冊的整合模式。

為什麼生命週期勾子與溫集區在 DOP-C02 中很重要

DOP-C02 在領域 4.3 中明確列出了「各種 AWS 服務的自動擴展功能」，並在領域 3.2 中列出了「識別並實作適當的自動擴展、負載平衡與快取解決方案」。社群考試報告指出，生命週期勾子是最容易混淆的主題之一：考生知道勾子的存在，但在狀態機（「實例是在 Pending:Wait 結束時進入 InService 還是之後？」）和預設動作語義（「如果我的勾子處理器當機，實例會啟動還是被終止？」）上容易出錯。

實際的 DevOps 場景驅動了考試模式。「在終止前清空 Web 伺服器的連線」 —— Terminating:Wait 勾子觸發一個 Lambda，該 Lambda 從負載平衡器取消註冊並等待進行中的請求完成。「在將實例加入 ALB 前預熱快取」 —— Pending:Wait 勾子觸發一個 SSM 自動化，預先載入快取，然後調用 complete-lifecycle-action。「將擴展時間從 4 分鐘縮短至 30 秒」 —— 使用停止實例的溫集區。「將整個 ASG 更新至新的 AMI 且不中斷服務」 —— 使用最小健全百分比為 90 且具備檢查點百分比的實例重新整理。考試將每一項都視為一個獨立的控制項。

白話文解釋 Lifecycle Hooks, Warm Pools 與 Scaling

這些機制與非軟體領域的實際營運模式相呼應。三個角度涵蓋了生命週期的暫停與恢復模型、溫集區以及擴展政策。

類比 1：醫院病患入院與出院流程

醫院以受控的交接方式接收和送走病患。Pending:Wait 是 入院緩衝區 —— 新病患已進入大樓，但尚未進入病房；入院團隊執行登記、生命徵象評估和床位分配，然後病患才變為「InService」（正式住進病房）。生命週期勾子處理器 就是入院協議；只有當協議的 complete-lifecycle-action 被觸發時，病患才會進入病房。

Terminating:Wait 是 出院緩衝區 —— 病患即將離開，但出院護理師還有工作要做（最後藥物審查、交通協調、文書工作）。勾子觸發出院協議 Lambda；只有當它訊號完成時，床位才會真正空出來。

活動訊號逾時 是 緩衝區可以留住病患的最長時間 —— 如果出院護理師在 90 分鐘內沒有回來，預設動作就會生效（CONTINUE = 無論如何都送走病患，ABANDON = 由於出錯，病患繼續留院）。

溫集區 是 值班待命醫師休息室 —— 預先獲得證照、預先刷好手的醫生在休息室等待，以便當急診室湧入病患時，他們可以在幾秒鐘內被召喚到診間，而無需經歷完整的證照審核和換裝過程。停止狀態的溫集區 是「醫生在家裡帶著呼叫器」；運行狀態的溫集區 是「穿著刷手服在休息室待命的醫生」。

實例重新整理 是 計畫中的大夜班與日班團隊輪換 —— 每次替換 30%，永遠不讓人員配置低於最小健全比例。

類比 2：餐廳服務生到職與服務排程

餐廳引進新服務生並以受控的交接方式進行輪換。Pending:Wait 是 班前簡報 —— 新服務生已打卡，但尚未開始服務餐桌；經理說明特餐、過敏原和座位表。只有在簡報完成訊號後，服務生才開始接桌 (InService)。

Terminating:Wait 是 下班交接 —— 在打卡下班前，服務生將活動餐桌轉交給下一班，結清最後帳單並提交小費。勾子觸發交接流程；只有在 complete-lifecycle-action 後，服務生才會真正離開。

停止實例的溫集區 是 隨叫隨到的代班人員 —— 已經培訓好，排班靈活，可以在 5 分鐘內激活，而無需招募和培訓新員工。運行實例的溫集區 是 在場邊待命的服務生 —— 已穿好制服在場，只是尚未分配餐桌；他們可以在 30 秒內進入活動狀態。

目標追蹤擴展 是 領班的自動排班規則 —— 「保持 70% 的入座率；如果攀升到 80%，就加派一名服務生」。步進擴展 是 明確的閾值圖表 —— 「在 70% 入座率時加 1 人；在 90% 時加 3 人」。預測性擴展 是 歷史需求預測 —— 領班知道週五晚上 7-9 點總是客滿，因此為那些時段預先安排 5 名額外服務生。

類比 3：航空公司飛機登機與下機流程

航空公司以受控階段執行登機和下機。Pending:Wait 是 起飛前準備 —— 飛機已到達登機門，但尚未準備好迎接乘客；地勤人員執行機艙清潔、燃油檢查、載單驗證。只有在所有檢查訊號完成後，登機門代理人負責人才開放登機 (InService)。

Terminating:Wait 是 抵達後下機流程 —— 飛機已降落，但在乘客下機、機組人員完成文書工作並將飛機拖回維修庫 (complete-lifecycle-action) 之前，無法釋放停機位。

停止的溫集區 是 停在機庫中的機隊 —— 已維護好，隨時準備在 20 分鐘內拖到登機門。運行的溫集區 是 在滑行道上怠速的機隊 —— 引擎已熱，隨時準備在 5 分鐘內佔用停機位；成本較高但速度更快。

實例重新整理 是 全機隊機艙改裝 —— 每次更換 10 架飛機，永遠不讓活動機隊低於容量的 80%。ELB 類型運作狀態檢查 是調度員的「這架飛機是否正在接收乘客」檢查，而 EC2 運作狀態檢查 僅僅是「飛機是否已通電」。

生命週期勾子狀態機

生命週期勾子為標準 ASG 狀態機增加了等待狀態。無勾子的預設流程為：

[水平擴展 scale-out] → Pending → InService → [水平縮減 scale-in 或終止] → Terminating → Terminated

使用啟動勾子時：

Pending → Pending:Wait → (活動訊號或逾時) → Pending:Proceed → InService

使用終止勾子時：

InService → Terminating → Terminating:Wait → (活動訊號或逾時) → Terminating:Proceed → Terminated

活動訊號與預設結果

建立勾子時，你需要指定：

• LifecycleTransition: EC2_INSTANCE_LAUNCHING 或 EC2_INSTANCE_TERMINATING。
• HeartbeatTimeout: ASG 等待 complete-lifecycle-action 的秒數（30 到 7200）。
• DefaultResult: CONTINUE 或 ABANDON。

逾時時的行為：

• 對於 LAUNCHING + CONTINUE: 實例繼續進入 InService。
• 對於 LAUNCHING + ABANDON: 實例被終止。
• 對於 TERMINATING + CONTINUE: 實例繼續終止流程。
• 對於 TERMINATING + ABANDON: ASG 跳過此實例的其餘生命週期勾子並直接終止。

如果勾子處理器需要更多時間而未完成動作，可透過 record-lifecycle-action-heartbeat 延長逾時。

勾子處理器模式

勾子處理器通常是：

• 針對 Auto Scaling Lifecycle Action 事件模式的 EventBridge 規則 → SNS → Lambda 或 Step Functions。
• 由勾子調用的 SSM 自動化執行手冊（Run Command 已內置 —— 勾子可以包含一個 Run Command 文件目標）。

處理器流程：

1. 接收帶有實例 ID 和生命週期動作權杖 (token) 的生命週期事件。
2. 執行工作（預熱快取、等待 ALB 清空、刷新日誌、拍照等）。
3. 調用 complete-lifecycle-action 並傳入動作結果和權杖。

溫集區 (Warm Pools)

溫集區在 ASG 的 InService 容量之外維護一池預先初始化的實例，將水平擴展延遲從幾分鐘縮短到幾秒鐘。

溫集區狀態

溫集區中的實例可以是：

• Stopped: 最便宜（僅產生 EBS 存儲成本），啟動約需 30 秒。
• Running: 最昂貴，切換到 InService 約需 5 秒（無需引導）。
• Hibernated: 內存狀態保留在 EBS 上，恢復最快（約 10 秒），需要支援休眠的實例類型。

溫集區配置

• MinSize: 最小溫集區大小；ASG 會保持集區至少有這麼大。
• MaxGroupPreparedCapacity: 總容量（InService + 溫集區）上限。
• PoolState: 溫集區實例的目標狀態。
• InstanceReusePolicy: ReuseOnScaleIn=true 在水平縮減時將 InService 實例返回溫集區而非終止；當啟動成本高昂時很有用。

生命週期勾子與溫集區

你可以專門為溫集區轉換附加生命週期勾子：

• EC2_INSTANCE_LAUNCHING: 當溫集區實例最初建立時觸發。
• WARMED:EC2_INSTANCE_LAUNCHING: 當實例正在為溫集區進行準備時觸發。
• WARMED:PENDING:WAIT: 溫集區實例在提升為 InService 之前進入 Pending:Wait。

這讓你可以針對溫集區實例最初建立時執行一次性昂貴的設置（安裝 Distributor 套件、基準修補、應用程式碼預取），然後在提升為 InService 時僅執行快速動作（註冊服務發現、掛載 ALB）。

實例重新整理 (Instance Refresh)

實例重新整理是對 ASG 中所有實例進行受控的滾動替換。用例：部署新 AMI、更新使用者數據、切換啟動範本版本。

重新整理配置

• MinHealthyPercentage (預設 90): 健全的 InService 容量永遠不低於預期容量的此百分比。
• InstanceWarmup (預設使用運作狀態檢查寬限期): 新實例進入 InService 後等待多長秒數才將其計為就緒。
• CheckpointPercentages: 要暫停的重新整理進度百分比列表；對畫線 (canary) 模式很有用。
• CheckpointDelay: 在每個檢查點暫停的分鐘數，允許手動驗證或外部測試。
• SkipMatching: 跳過已運行最新啟動範本版本的實例。
• MaxHealthyPercentage: 重新整理期間暫時超額配置的上限。

重新整理生命週期

重新整理會終止一個實例，ASG 以新啟動範本啟動一個替代實例，替代實例經歷 Pending:Wait（如果有勾子）、預熱，然後計為就緒。隨後替換下一個實例。若 MinHealthyPercentage=90 且有 10 個實例，則每次終止一個。

取消與回滾

你可以取消進行中的重新整理，保留已完成的部分新實例。自 2023 年起，RollbackInstanceRefresh 透過執行另一次回到先前啟動範本版本的重新整理來反轉重新整理流程 —— 這對於從損壞的 AMI 快速恢復至關重要。

擴展政策 (Scaling Policies)

ASG 支援四種擴展政策類型。

目標追蹤 (Target Tracking)

最簡單的一種。指定一個目標值（例如 50% CPU），ASG 會計算並調整容量以維持該值。內部建立並管理 CloudWatch 警示。最適合利用率可預測的穩態指標。

預定義目標指標：ASGAverageCPUUtilization、ASGAverageNetworkIn、ASGAverageNetworkOut、ALBRequestCountPerTarget。你也可以使用自定義指標。

步進擴展 (Step Scaling)

具有明確容量調整的多個閾值：

• 70-80% CPU: +1 個實例。
• 80-90% CPU: +3 個實例。
• 90% 以上 CPU: +5 個實例。

當容量調整應隨需求呈非線性變化時很有用。

簡易擴展 (Simple Scaling)

單一閾值配合單一調整，並在下一次動作前有一段冷卻期。較舊的模式，大部分已被目標追蹤和步進擴展取代。

預測性擴展 (Predictive Scaling)

使用歷史 CloudWatch 指標（至少 24 小時，理想情況為 14 天）來預測容量需求，並提前於需求計畫容量變更。適用於可預測的週期性工作負載（辦公時間流量、零售週末）。

你可以在 ForecastOnly 模式下運行預測性擴展以評估預測而不採取行動，在有信心後切換到 ForecastAndScale。

運作狀態檢查與終止

ASG 監控實例健全狀況以決定何時更換。

運作狀態檢查類型

• EC2: 如果 EC2 報告實例狀態檢查失敗，ASG 認為實例不健全。
• ELB: 如果註冊的目標群組報告實例不健全，ASG 認為其不健全。
• 自定義: 外部系統可透過 API 調用 set-instance-health 將實例標記為不健全。

HealthCheckGracePeriod (預設 0) 是實例達到 InService 後的秒數，在此期間 ASG 忽略運作狀態檢查失敗 —— 這讓啟動緩慢的實例在因啟動太慢而被殺死前能完全完成引導。

終止政策 (Termination Policies)

當 ASG 進行水平縮減時，它會按配置的 TerminationPolicies 挑選實例（按順序評估）：

• Default: 跨 AZ 平衡，然後是最舊的啟動範本，最後是最接近計費小時的實例。
• OldestInstance, NewestInstance。
• OldestLaunchTemplate, OldestLaunchConfiguration。
• ClosestToNextInstanceHour: 最小化浪費的小時計費。
• AllocationStrategy: 用於混合實例類型。

在不使用實例重新整理而想逐步更新 AMI 時，請使用 OldestLaunchTemplate。

待命 (Standby) 狀態

你可以將 InService 實例移動到 Standby，這會將其從輪詢中移除（從目標群組取消註冊）而不終止。適用於 SSH 登入偵錯、手動修補或更換內核模組。exit-standby 將其返回 InService。

CodeDeploy 與 SSM 整合

生命週期勾子與 CodeDeploy 和 SSM 自然整合：

• CodeDeploy 可在 ASG 註冊，以便在新實例啟動時自動處理部署（ASG 的 Deployment 勾子）。
• SSM 狀態管理員 (State Manager) 在新實例註冊時執行，作為勾子流程的一部分套用基準配置。
• 自定義的 Pending:Wait 勾子可為 SSM 執行手冊調用 start-automation-execution 以預熱實例，然後發送完成訊號。

標準模式：啟動勾子處理器是一個 EventBridge → Lambda → SSM 自動化管道，負責運行預熱執行手冊並發送生命週期完成訊號。

常見陷阱 (Common Pitfalls)

1. 處理器中忘記 complete-lifecycle-action: 實例會卡在等待狀態直到活動訊號逾時，浪費水平擴展時間。
2. 錯誤的預設動作: 啟動時的 ABANDON 會終止實例；啟動時的 CONTINUE 會讓僅部分預熱的實例進入 InService。請有意識地選擇。
3. 假設溫集區可以處理流量: 溫集區是緩衝池；只有 InService 實例接收流量。
4. 沒有足夠歷史記錄即使用預測性擴展: 需要 24 小時以上，理想為 14 天。
5. 對啟動緩慢的實例設置 HealthCheckGracePeriod=0: 實例會在啟動期間由於 ELB 運作狀態檢查失敗而被殺死。
6. 不帶 MinHealthyPercentage 運行實例重新整理: 預設 90 通常沒問題，但對於小型 ASG（例如 4 個實例），數學計算可能會導致比預期更激進的替換。
7. 混淆目標追蹤與步進擴展: 目標追蹤是指標驅動且自調優的；步進擴展具有明確的閾值。考試可能會將它們作為備選方案進行對比。

FAQ

Q1：我應該何時使用溫集區，而非調高 MinSize？

溫集區更便宜，因為停止狀態的實例僅產生 EBS 成本，不產生計算成本。調高 MinSize 會讓實例保持 InService 並產生完整的計算成本。當你需要快速的水平擴展響應能力，又不想為永久閒置的容量支付計算費時，請使用溫集區。穩定的基準負載請使用較高的 MinSize。

Q2：如何將生命週期勾子用於 ALB 連線清空？

將目標群組的 deregistration_delay.timeout_seconds 設置為所需的清空時間。當 ASG 開始終止時，ALB 會開始清空。Terminating:Wait 勾子可以透過輪詢目標運作狀態來等待清空，並在目標完全清空後調用 complete-lifecycle-action。

Q3：生命週期勾子會在 Spot 中斷時觸發嗎？

會。ASG 會針對 Spot 中斷觸發 Terminating 勾子，但你最多只有約 2 分鐘（Spot 終止通知）來完成。請將活動訊號逾時設置為 120 秒並確保處理器足夠快。

Q4：EC2 Auto Scaling 與 Application Auto Scaling 有什麼區別？

EC2 Auto Scaling 專門管理 EC2 ASG。Application Auto Scaling 是一個更高級別的服務，管理 ECS 服務、DynamoDB 表、Aurora 副本、Comprehend 端點等的擴展。它們使用相同的擴展政策原語，但針對的資源不同。

Q5：實例重新整理如何處理生命週期勾子？

重新整理會對其替換的每個實例觸發 Terminating 勾子。勾子處理器必須在配置的活動訊號逾時內完成，否則預設動作生效（CONTINUE 意味著終止，ABANDON 意味著跳過剩餘勾子但仍終止）。對於重新整理期間啟動的新實例，Launching 勾子會正常觸發。

Q6：我可以在同一個 ASG 上使用多種擴展政策嗎？

可以。ASG 會結合目標追蹤、步進和排程動作；最激進的擴展決策勝出（取容量變更的最大值）。預測性擴展是累加的（它在預測高峰前設置最小容量）。

Q7：為了維護，我應該何時使用 Standby 而非 Terminate？

Standby 會保留實例並僅將其從輪詢中移除。將其用於現場偵錯、更換核心模組或暫時隔離一個有問題的實例進行取證。Terminate 適用於應被更換的實例 —— ASG 會啟動一個全新的實例。

總結

EC2 Auto Scaling 生命週期勾子在啟動和終止期間暫停實例，以便你執行預熱、清空或清理工作流。溫集區保留預先初始化的實例，隨時準備在幾秒鐘內切換。實例重新整理部署新的啟動範本，並具備檢查點和最小健全閾值。目標追蹤是擴展政策的首選，步進擴展適用於非線性需求，預測性擴展適用於週期性工作負載。記住生命週期狀態機（Pending:Wait, Terminating:Wait, 逾時預設動作）、溫集區狀態選項（Stopped/Running/Hibernated）、重新整理控制項（MinHealthyPercentage, CheckpointPercentages, SkipMatching）以及擴展政策分類。掌握了這些，考試中的 ASG 場景就能在不到一分鐘內解決。