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

設定 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。