本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
監控
使用儀表板
監控機群使用率是一項定期活動，可透過 CloudWatch 指標執行並建立儀表板。或者，從 WorkSpaces 應用程式主控台，使用機群用量索引標籤。定期監控您的機群用量，因為使用者行為並非總是可預測的，而且需求甚至可能超過一級前期規劃。您可以在監控資源下的 WorkSpaces 應用程式管理指南中找到 CloudWatch 的 WorkSpaces 應用程式指標和維度的完整清單。
預期成長
每當 發生大幅跳躍時PendingCapacity，就會發生自動擴展事件。在新的 WorkSpaces 應用程式機群執行個體可用於託管使用者工作階段時，請務必確認 AvailableCapacity和 PendingCapacity 具有反向關係。InsufficientCapacityError 為每個 WorkSpaces 應用程式機群建立 CloudWatch 警示，以通知管理員，確保自動擴展不會落後於需求。
如果需求超過容量且InsufficientCapacityError指標值很常見，請考慮在工作日開始時透過排程擴展政策提高最小容量。此外，具有第二個排程擴展政策，可在滿足需求後降低最小容量。請記住，降低最小容量的值不會影響現有的工作階段。在工作日結束前降低最小容量，可透過降低 的值，有效地讓擴展如預期般運作ActualCapacity。這可最佳化成本。
如果需求持續無法預測，請使用目標追蹤擴展政策，以確保 WorkSpaces 應用程式機群AvailableCapacity有足夠的空間來滿足需求，同時判斷使用模式。繼續監控，因為目標追蹤會使用機群耗用量的百分比。隨著機群執行個體總數的增加，未使用的機群執行個體總數會倍增。除非最大容量設定為保守值，否則這會變得浪費。使用多種擴展政策類型 （例如排程和目標追蹤） 來平衡可靠性與成本最佳化。
監控使用者用量
監控唯一使用者，因為以使用者費用的形式存在與該使用者相關聯的成本
用量報告會以個別.csv檔案形式存放在 S3 儲存貯體中，您可以使用第三方商業智慧 (BI) 工具下載和分析。您可以在 中分析用量資料， AWS 而無需下載報告或建立自訂日期範圍的報告，而無需串連多個.csv檔案。例如，您可以使用 Amazon Athena 和 Amazon Quick 來建立 WorkSpaces 應用程式用量資料的自訂報告和視覺化
持久性應用程式和 Windows 事件日誌
WorkSpaces 應用程式執行個體工作階段完成時，執行個體會結束。這表示工作階段中使用的所有應用程式和 Windows 事件日誌都會遺失。如果需要保留這些應用程式和 Windows 事件日誌，其中一種方法是使用 Amazon Data Firehose 將它們即時交付至 S3
稽核網路和管理活動
如果尚未設定 ，最佳實務是 AWS 帳戶 使用 Amazon WorkSpaces 應用程式AWS CloudTrailappstream.amazonaws.com。
啟用 VPC 流程日誌，以稽核對客戶受管資源的存取。VPC 流程日誌可以發佈至 CloudWatch Logs，以在需要稽核時執行查詢。
隨著 WorkSpaces 應用程式機群的成長，監控子網路 IP 配置非常重要。透過執行 describe-subnets
