適用於 Amazon AppStream 2.0 的擴展概念

在單一工作階段案例中，每個使用者工作階段都有其專用預留執行個體。在多工作階段模式中，可在一個執行個體上佈建多個使用者工作階段。機群容量和自動擴展政策必須根據使用者工作階段進行設定，而且服務將會計算並啟動所需的執行個體數量。

執行個體數量下限 (針對單一工作階段機群) 或使用者工作階段數量下限 (針對多工作階段機群)。執行個體的數量 (針對單一工作階段機群) 或使用者工作階段的數量 (針對多工作階段機群) 不可低於此值，且擴展政策不會將您機群的規模調整到低於此值。例如，在單一工作階段案例中，如果您將機群的容量下限設定為 2，機群所擁有的執行個體數量便永遠不會少於 2 個。同樣地，在多工作階段案例中，執行個體上的工作階段數量上限設為 5 的情況下，如果您將機群的最小容量設定為 12，則機群擁有的執行個體數量四捨五入後將永遠不會少於 (12/5) = 3 個。

執行個體數量上限 (針對單一工作階段機群) 或使用者工作階段數量上限 (針對多工作階段機群)。執行個體的數量 (針對單一工作階段機群) 或使用者工作階段的數量 (針對多工作階段機群) 不可高於此值，且擴展政策不會將您機群的規模調整到高於此值。例如，在單一工作階段案例中，如果您將機群的容量上限設定為 10，機群所擁有的執行個體數量便永遠不會超過 10 個。同樣地，在多工作階段案例中，執行個體上的工作階段數量上限設為 5 的情況下，如果您將機群的最大容量設定為 52，則機群擁有的執行個體數量四捨五入後將永遠不會超過 (52/5) = 11 個。

執行中或待定的執行個體總數 (針對單一工作階段機群) 或使用者工作階段總數 (針對多工作階段機群)。此值表示在穩定狀態下，您的機群可支援的並行串流工作階段的總數。若要設定 Desired Capacity (所需的容量) 值，請編輯 Fleet Details (機群詳細資料)。當您使用擴展政策時，我們不建議手動變更所需容量值。

如果 Desired Capacity (所需的容量) 的值設為低於 Minimum Capacity (容量下限) 的值，且觸發向外調整規模活動，則 Application Auto Scaling 會將 Desired Capacity (所需的容量) 的值向上調整規模到 Minimum Capacity (容量下限) 的值，並根據調整規模政策繼續視需要向外調整規模。但是，在此案例中，向內調整規模活動不會調整 Desired Capacity (所需的容量)，因為它已低於 Minimum Capacity (容量下限) 的值。

如果 Desired Capacity (所需的容量) 的值設為高於 Maximum Capacity (容量上限) 的值，且觸發向內調整規模活動，則 Application Auto Scaling 會將 Desired Capacity (所需的容量) 的值向下調整規模到 Maximum Capacity (容量上限) 的值，並根據調整規模政策繼續視需要向內調整規模。但是，在此案例中，向外調整規模活動不會調整 Desired Capacity (所需的容量)，因為它已高於 Maximum Capacity (容量上限) 的值。

滿足 Scaling Policy Condition (調整規模政策條件) 時，調整規模政策在您機群上所執行的動作。您可以根據 % 容量或執行個體數量 (針對單一工作階段機群) 或使用者工作階段數量 (針對多工作階段機群) 來選擇動作。例如，如果 Current Capacity 為 4，且 Scaling Policy Action 設定為「新增 25% 容量」，則在滿足 Scaling Policy Condition 時，所需容量將增加為 5。

觸發 Scaling Policy Action (調整規模政策動作) 中所設定動作的條件。此條件包含調整規模政策指標、一個比較運算子，以及一個閾值。例如，若要在機群使用率超過 50% 時調整規模機群，您的調整規模政策條件應設為「若容量使用率 > 50%」。

您的調整規模政策會以此指標作為根據。以下指標可用於調整規模政策：