成本最佳化

成本優化著重於避免不必要的成本。關鍵主題包括了解和控制花錢的位置，以及選擇最合適和正確的資源類型數量。分析隨時間推移的支出並擴展以滿足業務需求。以下 AppStream 2.0 資源會產生 pay-as-you-go 費用：

• 永遠在線的叢集執行個體

• 隨需叢集實例

• 隨需停止執行個體費

• 映像建置器執行個體

• 使用者費用

如需目前的定價資訊，請參閱AWS網站以瞭解 Amazon AppStream 2.0 定價。

設計具成本效益的 AppStream 2.0 部署

規劃和設計 AppStream 2.0 部署的第一步是使用簡單的定價工具來估算與使用量相關的AWS費用基準。提供您的使用者總數、每小時的實際並行使用量、執行個體類型和叢集使用率，而定價工具會估算每位使用者的價格。當您使用隨需叢集而非永遠在線的叢集時，它也會顯示預估節省的價格。

客戶喜歡 AppStream 2.0 定價模式，只需為佈建的執行個體付費，以滿足使用者的串流需求。此模型與現有的應用程式串流環境不同。這些通常是以尖峰容量佈建為基礎，即使在夜間、週末和節假日，當負載較低時也是如此。Amazon AppStream 2.0 定價工具僅提供與您使用 AppStream 2.0 相關的 AWS 費用估算，不包括任何可能適用的稅金。您的實際費用取決於各種因素，包括 AWS 服務的實際使用情況。

AppStream 2.0 定價工具是以 Microsoft Excel 或 OpenOffice Calc 試算表的形式提供，可讓您輸入叢集的基本資訊，然後根據您的使用模式，為隨需和永遠在線的叢集提供 AppStream 2.0 環境的成本估算。您可以根據歷史或預期的使用趨勢來模擬成本。透過內建這些功能，Elastic 叢集可讓管理員免除預測使用情況、建立、維護擴展政策和映像的需求。執行 Amazon Linux 2 的彈性叢集和執行個體 (所有叢集類型) 按串流工作階段的持續時間計費，以秒為單位，最少 15 分鐘。

透過選擇執行個體類型來優化成本

對於叢集和映像產生器執行個體，您可以為應用程式選擇一系列不同的執行個體系列和類型。

一般使用者測試 — 下一步是將 AppStream 2.0 叢集推出給一群試驗使用者進行測試，以驗證我們選擇的執行個體類型。請務必要求試驗使用者測試其所有常規和繁重的工作流程，以擷取記憶體、CPU 和圖形周圍的指標，以便擷取基準效能指標。試驗群組應包含使用應用程式的各種使用者角色，以確保您是從多個使用者經驗中進行測試。使用者接受度測試可讓您收集串流工作階段體驗的意見反應。建立或更新堆疊時，可以選擇使用自訂意見反應 URL。使用者選擇 [傳送意見反應] 連結以提交有關其應用程式串流體驗的意見反應之後，就會被重新導向至 如果發生效能瓶頸，請使用 Windows 效能測量結果來分析資源限制條件。例如，如果目前的叢集執行個體類型 stream.standard.medium 顯示資源限制，請將執行個體類型升級為串流 .standard.large。相反地，如果效能指標顯示資源使用率過高，請考慮降級執行個體類型。

通過車隊類型選擇優化成本

建立新的 AppStream 2.0 叢集時，開發人員必須選擇永遠開啟或隨選叢集類型。從定價角度選擇執行個體類型時，了解 AppStream 2.0 如何管理叢集執行個體非常重要。對於永遠在線的叢集，叢集執行個體會保持在執行中狀態。因此，當使用者嘗試串流工作階段時，叢集執行個體隨時可以開始串流工作階段。

對於隨需叢集，叢集執行個體啟動後，它們會保持在停止狀態。停止的執行個體費用低於執行中執行個體費用，有助於降低成本。隨需叢集執行個體必須從停止狀態啟動。使用者必須等待大約兩分鐘，才能使用串流工作階段。

彈性叢集是獨立應用程式的最佳選擇，可安裝到儲存在 Amazon Simple Storage Service (Amazon S3) 貯體中的虛擬硬碟。由於僅在串流期間每秒計費，彈性叢集可能會進一步降低某些使用案例的成本。費率是您在建立叢集時選擇的執行個體類型、大小以及作業系統的函數。

如果使用者在工作時間需要叢集執行個體，最好保留相同的串流工作階段。這是因為叢集執行個體按小時計費，而且每次新的串流工作階段啟動時，會產生另一個叢集執行個體費用。

表十- AppStream 2.0 車隊類型比較

艦隊類型	優點	考量
永遠在線	減少串流工作階段的等待時間	使用者需支付每小時執行個體費用，因為無法讓執行個體保持停止狀態。
按需求	執行個體保持在停止狀態時節省成本	更長的串流工作階段等待時間
彈性	對於可以安裝在虛擬硬碟上的應用程式具有零星使用模式的使用案例，每秒計費可能很有用	隨著應用程序虛擬硬盤的大小變大，將其掛接到流實例所花費的時間可能會很長

AppStream 2.0 會監控您的車隊使用率，並自動調整車隊容量，以盡可能低的成本滿足您的使用者需求。容量調整是根據您定義的擴展政策，根據目前的使用率或根據排程進行。定期檢閱叢集使用量指標，以驗證叢集擴展政策沒有高層級的備用容量。

擴展政策

Fleet Auto Scaling 可讓您不必過度認可等待使用者登入的資源，從而最佳化叢集資源。管理員可以根據不同的使用率調整叢集的大小，以符合使用者的需求。使用 CloudWatch AppStream 2.0 叢集指標或第三方監控工具來瞭解使用者活動，並設定擴展政策，以根據預期使用情況擴充或縮小 AppStream 2.0 叢集。用戶日誌是了解實際使用情況的重要機制。透過 Auto Scaling，您可以使用此深入分析資料來動態變更叢集大小。

在許多情況下， AppStream 2.0 車隊是根據最大用戶數量創建的，而不是針對一天和一周中的不同時間（例如夜晚和周末）進行調整。串流應用程式的並行使用者人數通常會少於使用者總數，尤其是當使用者具備遠端工作彈性時。在投影使用模式時考慮到這些因素是非常重要的。高估計時會導致超額佈建 AppStream 2.0 個執行個體，導致額外成本。若要達到最佳組態，您可能需要將一或多個排程擴充政策與向外延展政策結合。

若要進一步了解實作擴展政策，請參閱擴展 Amazon AppStream 2.0 叢集。

使用者費用

使用者從 AppStream 2.0 叢集執行個體串流應用程式時，每AWS 區域個使用者每月收取使用者費用。為 AppStream 2.0 使用者提供一致的使用者 ID，而不是產生不同的使用者 ID。連線至映像產生器時，不會收取使用者費用。

學校、大學和某些公共機構可能有資格獲得每位使用者每月 0.44 USD 的 Microsoft RDS SAL 使用者費用降低。如需資格需求，請參閱 Microsoft 授權條款與文件。

如果您擁有 Microsoft 授權行動性，您可能有資格攜帶自己的 Microsoft RDS 用戶端存取授權 (CAL)，並將其與亞馬遜 AppStream 2.0 搭配使用。如果您擁有自己的授權，就不會產生每月使用者費用。如需有關是否可以將現有的 Microsoft RDS CAL 授權與 Amazon AppStream 2.0 搭配使用的詳細資訊，請參閱AWS授權行動性指南，或洽詢您的 Microsoft 授權代表。

Image Builder 使用

AppStream 2.0 Image Builder 執行個體按小時計費。Image Builder 執行個體費用包括串流通訊協定使用的運算、儲存和任何網路流量。所有正在執行的 Image Builder 執行個體都會收取適用的執行中執行個體費 這筆費用是根據執行個體類型和大小計算的，即使沒有管理員連線也是如此。

最佳做法是將成本最佳化，請在未使用 Image Builder 執行個體時關閉該執行個體。 CloudWatch 事件規則可用於排程每日工作，例如叫用 Lambda 函數來停止映像產生器執行個體。

您可以使用受管理的 AppStream 2.0 映像更新 up-to-date 來保留 AppStream 2.0 映像檔。此更新方法提供最新的 Windows 作業系統更新和驅動程式更新，以及最新的 AppStream 2.0 代理程式軟體。使用此方法更新映像時，Image Builder 會在受管理的服務程序中自動啟動和停止。