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

# 機群自訂
<a name="fleet-customization"></a>

## 機群類型
<a name="fleet-type"></a>

建立機群時，客戶必須選擇機群類型。每種機群類型為使用者體驗、成本和維護開銷提供不同的優勢。無論選擇的機群類型為何，每個選項都支援 Windows 和 Linux 平台類型，以及桌面檢視或應用程式檢視。

客戶現在可以從下列機群類型中選擇：
+  **Always-On** — 此機群類型可讓使用者即時存取其應用程式。即使沒有使用者在串流應用程式，您仍需支付機群中所有執行中執行個體的費用。
+  **隨需** — 選取此機群類型以最佳化串流成本。使用隨需機群時，使用者的工作階段開始時間約為一到兩分鐘。不過，只有在使用者連線時才會向您收取串流執行個體費用，而且機群中每個執行個體若不是串流應用程式，將按小時支付少許費用。
+  **彈性** — 彈性機群可用於不需要安裝的應用程式，並且可以從虛擬硬碟 (VHD) 執行。彈性機群不支援 WorkSpaces 應用程式映像，也不需要擴展政策。您只需支付串流工作階段期間的費用。

 

*表 2 — Amazon WorkSpaces 應用程式機群類型*


| 機群類型 | 使用情況 | 使用者體驗 |  定價方式 | 備註  | 
| --- | --- | --- | --- | --- | 
|  **Always-On**  | 您的使用者在啟動工作階段時需要立即存取應用程式。您的機群中不會有大量多餘的容量，可能是因為您的用量模式是可預測的，而且您可以使用擴展政策可靠地控制成本。 | 即時存取應用程式 | 您可以為機群中可用的每個執行個體支付完整價格 （無論是否用於工作階段）。 | 支援自訂映像和擴展政策。 | 
|  **On-Demand**  | 您必須在fleetsYou 您想要最符合成本最佳化的環境，並且不想為未使用的capacityYour使用者可以在啟動工作階段後等待一到兩分鐘來存取其應用程式。您正在使用較大的執行個體類型。執行中執行個體的每小時成本比停止的執行個體費用更昂貴。 | 使用者會在啟動工作階段後等待一到兩分鐘來存取其應用程式。 | 您只需為具有作用中工作階段的串流執行個體支付完整價格，然後為閒置執行個體支付小額的每小時成本。 | 支援自訂映像和擴展政策。 | 
|  **彈性**  | 您的應用程式及其相依性小於 \~1.5 GB。每次使用者在彈性機群中啟動工作階段時，您的虛擬硬碟 (VHD) 檔案都必須從 Amazon S3 下載到工作階段。因此，較大的 VHD 檔案 （即大小大於 1.5 GB) 會導致最終使用者體驗不佳。您的應用程式是可攜式的。也就是說，您的應用程式及其所有相依性可以放置在 VHD 上，並從 VHD 啟動。您不需要加入網域的串流執行個體 （網域加入目前不適用於彈性機群） 您只想為作用中工作階段付費 （亦即，您不需要為機群中未使用的容量付費）。您的使用者可以在啟動工作階段後等待 45 秒以上來存取其應用程式。您希望 AWS 為您管理擴展 （無需管理擴展政策）。 | 使用者會在啟動工作階段後等待 45 秒到 3 分鐘來存取應用程式 （等待時間取決於虛擬硬碟的大小）。 | 您只需支付串流工作階段期間的費用。由於沒有彈性機群閒置執行個體的概念，因此未使用的執行個體不會產生任何費用。 | 不支援自訂映像 （客戶向應用程式提供 VHD) 或擴展政策。目前支援 `stream.standard.small`和 `stream.standard.medium`執行個體。如果您的使用案例需要不同的執行個體類型，請聯絡您的 AWS 客戶團隊。 | 

![顯示機群類型使用案例和需求的圖表。](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-for-deploying-amazon-appstream-2/images/use-case-and-requirements.png)


## 機群大小
<a name="fleet-sizing"></a>

### 最小容量和排程擴展
<a name="minimum-capacity-and-scheduled-scaling"></a>

 調整 WorkSpaces 應用程式機群的大小時，有幾個直接轉換為使用者體驗和成本的考量事項。輸入的**最小容量**值可確保 WorkSpaces 應用程式執行個體數目很少低於此值。WorkSpaces 應用程式工作階段結束後，如果 WorkSpaces 應用程式執行個體總數小於**最小容量**值，就會啟動新的機群執行個體。一如往常，請務必記住一個 WorkSpaces 應用程式執行個體會直接映射到一個使用者工作階段，直接影響**最小容量**的值。

 為超出預期並行的**最小容量**輸入值會導致成本增加，但使用者體驗不會受到影響。值太低會導致低成本，但當請求總數超過可用容量時，會影響使用者體驗。管理員會在這種情況下觀察到「容量不足」錯誤。例如，當一天開始時的預期連線數目是可預測的一致值時，等待`PendingCapacity`成為`AvailableCapacity`是使用者時間的效率低落。

 從容納典型離峰時數的最小容量開始，然後使用[https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)，在工作日開始之前有效地重設最小容量。請勿忘記建立另一個排程擴展政策，將最小容量還原為離峰時數。如需擴展政策以及如何實作政策的詳細資訊，請參閱本文件中的[*機群自動擴展策略*](fleet-auto-scaling-strategies.md)一節。

### 最大容量和服務配額
<a name="maximum-capacity-and-service-quotas"></a>

 設定最大容量可能是任意值，但當正確預測和設定時，它會最佳化總資源消耗和成本。輸入的值若高於您 中 [https://docs.aws.amazon.com/appstream2/latest/developerguide/limits.html](https://docs.aws.amazon.com/appstream2/latest/developerguide/limits.html) AWS 帳戶 ，可能看起來是有效的，但當自動擴展事件嘗試將資源擴展到最大容量時，會無法啟動，因為最大容量值超過可用的服務配額。確保為所需的最大容量提出服務配額請求，以確保依照您的組織預期自動擴展函數。

 設定最大容量值時的另一個重要考量是成本。如需詳細資訊，請參閱本文件的[*使用機群類型選擇最佳化成本*](cost-optimization.md#optimizing-costs-with-fleet-type-choice)一節。