本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

設定 Auto Scaling 群組的預設執行個體暖機期

CloudWatch 收集並彙總 Auto Scaling 執行個體的使用情況資料，例如CPU和網路 I/O。您可以使用這些指標來建立擴展政策，而這些政策會根據所選指標值的增加和減少來調整 Auto Scaling 群組中的執行個體數量。

您可以指定執行處理在將使用InService狀態提供給聚總測量結果之前等待的時間長度。這個指定的時間稱為預設執行個體暖機。這樣可防止動態擴展受到尚未處理應用程式流量且運算資源暫時高使用率的個別執行個體的指標影響。

為了最佳化目標追蹤和步驟擴展政策的效能，我們強烈建議您啟用並設定預設執行個體暖機。默認情況下未啟用或配置它。

啟用預設執行個體暖機時，請記住，如果 Auto Scaling 群組設定為使用執行個體維護政策，或者您使用執行個體重新整理來取代執行個體，您可以防止執行個體在完成初始化之前計入最低運作狀態百分比。

擴展效能考量

對於大多數應用程式來說，只要有一個預設執行個體暖機時間，可套用至所有功能，而不是不同功能的不同暖機時間。例如，如果您未設定預設執行個體暖機，執行個體重新整理功能會使用健康狀態檢查寬限期做為預設暖機時間。如果您有任何目標追蹤和步數調整政策，它們會使用為預設冷卻時間設定的值作為預設暖機時間。如果您有任何預測性擴展政策，則它們沒有預設的預熱時間。

當執行個體正在預熱時，只有在未預熱的執行個體的指標值大於政策的警示高閾值 (或目標追蹤擴展政策的目標使用率) 時，才會向外擴充動態擴展政策。如果需求減少，動態擴展會變得更加保守，以保護應用程式的可用性。這會阻止活動中的比例以進行動態縮放，直到新實例完成預熱為止。

在向外擴展時，Amazon EC2 Auto Scaling 會在決定要新增多少個執行個體到群組時，將正在暖機的執行個體視為群組容量的一部分。因此，需要添加類似容量的多個警報漏洞會導致單個擴展活動。目的是不斷向外擴展，而不會過度這樣做。

如果未啟用預設執行個體暖機，則執行個體在傳送指標 CloudWatch 並將其計入目前容量之前等待的時間會因執行個體而異。因此，與正在發生的實際工作負載相比，您的擴展政策可能會執行不可預測的情況。

例如，假設具有週期性 on-and-off 工作負載模式的應用程式。預測擴展政策可用於針對是否增加執行個體數量做出週期性決策。由於預測性擴展政策沒有預設的預熱時間，因此執行個體會立即開始貢獻彙總指標。如果這些執行個體在啟動時有較高的資源使用量，則新增執行個體可能會導致彙總指標激增。這可能會影響使用這些指標的任何動態擴展政策，視使用量穩定下來所需的時間而定。如果違反動態擴展政策的高警示閾值，則群組的大小會再次增加。當新實例正在升溫時，活動中的規模將被阻止。

選擇預設執行個體暖機時間

設定預設執行個體暖機期的關鍵在於確定執行個體完成初始化所需的時間，以及在執行個體達到 InService 狀態後資源消耗穩定下來所需的時間。選擇執行個體暖機時間時，請嘗試在收集合法流量的使用情況資料，以及將啟動時暫時使用量峰值相關的資料收集降到最低之間保持最佳平衡。

假設您有一個 Auto Scaling 群組連接到 Elastic Load Balancing 負載平衡器。新的執行個體完成啟動後，它們會註冊到負載平衡器，然後再進入 InService 狀態。在執行個體進入 InService 狀態後，資源耗用仍然會遇到暫時峰值，並需要時間來穩定。例如，相較於無需下載大型資產的輕量型 Web 伺服器，必須下載和快取大型資產的應用程式伺服器的資源耗用需要更長的穩定時間。執行個體暖機期提供了穩定資源耗用所需的時間延遲。

可以考慮將生命週期關聯用於在啟動時要執行組態任務或指令碼的使用案例。生命週期關聯可以延遲新的執行個體投入使用，直到其完成初始化。它們特別適用於您的自舉指令碼需要一段時間才能完成的情況。如果您新增 lifecycle hook，則可以減少預設執行個體暖機期的值。如需有關 lifecycle hook 的詳細資訊，請參閱 Amazon EC2 Auto Scaling lifecycle hook。