# COST 5. 如何在選取服務時評估成本？ Amazon EC2、Amazon EBS 和 Amazon S3 是基礎的 AWS 服務。Amazon RDS 和 Amazon DynamoDB 等受管服務為更高等級或應用程式等級的 AWS 服務。選取適當的基礎和受管服務，就可最佳化此工作負載的成本。舉例來說，您可以使用受管服務減少或省下大部分管理和營運開銷，讓您從事應用程式或企業相關活動。 **Topics** + [ # COST05-BP01 識別組織的成本要求 ](cost_select_service_requirements.md) + [ # COST05-BP02 分析工作負載的所有元件 ](cost_select_service_analyze_all.md) + [ # COST05-BP03 對每個元件執行徹底的分析 ](cost_select_service_thorough_analysis.md) + [ # COST05-BP04 選取具成本效益授權的軟體 ](cost_select_service_licensing.md) + [ # COST05-BP05 選取此工作負載的元件，以按照組織優先事項來優化成本 ](cost_select_service_select_for_cost.md) + [ # COST05-BP06 對不同用量執行一段時間內的成本分析 ](cost_select_service_analyze_over_time.md) # COST05-BP01 識別組織的成本要求 與團隊成員一起為此工作負載定義成本最佳化與其他支柱 (例如效能和可靠性) 之間的平衡。 **未建立此最佳實務時的曝險等級：**高 ## 實作指引 大多數組織的資訊技術 (IT) 部門會由多個小型團隊組成，每個團隊都有自己的議程和重點領域，而這會反映出其團隊成員的專業和技能。您需要了解組織的整體目標、優先順序、目標，以及每個部門或專案如何為這些目標做出貢獻。對於實現組織目標和全面預算規劃來說，將所有重要資源進行分類至關重要，這些資源包括人員、設備、技術、材料和外部服務。採用這種系統化方法來識別和了解成本，是為組織建立實際、可靠成本計畫的基礎。 為工作負載選取服務時，關鍵是了解組織的優先事項。在成本最佳化和其他 AWS Well-Architected Framework 支柱之間建立平衡，例如效能和可靠性。此流程應有系統且定期地進行，以反映組織目標、市場條件和營運動態的變化。完全成本優化的工作負載是最符合您組織需求的解決方案，不一定是成本最低的解決方案。與組織中的所有團隊 (例如產品、業務、技術和財務團隊) 會面以收集資訊。評估在相互衝突的利益或替代方法之間做出權衡的影響，以協助您在確認工作重點或選擇行動方案時做出明智的決定。 例如，新功能加速上市可能是成本優化所強調的重點，或您可為非關聯式資料選擇關聯式資料庫，以便更輕鬆地遷移系統，而非遷移至針對您的資料類型優化的資料庫並更新您的應用程式。 ### 實作步驟 + **確定組織的成本要求**與您組織的團隊成員開會，包括產品管理人員、應用程式擁有者、開發和營運團隊、管理層和財務部人員。排定此工作負載及其元件的 Well-Architected 支柱優先順序。輸出應為依序列出的支柱清單。您也可以為每個支柱新增加權，以指出相應支柱有多少個額外焦點，或兩個支柱之間的焦點有多相似。 + **解決技術債務並將其記錄在案：**在工作負載檢閱期間，處理技術債務。記錄積存項目以在將來重新檢視工作負載，目標是重構或重新架構以將工作負載進一步最佳化。向其他利益相關者清楚傳達所做出的權衡至關重要。 ## 資源 **相關的最佳實務：** + [ REL11-BP07 建構您的產品以滿足可用性目標和運作時間服務等級協議 （SLAs） ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_service_level_agreements.html) + [ OPS01-BP06 評估權衡 ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html) **相關文件：** + [AWS 總擁有成本 （TCO） 計算器](https://aws.amazon.com/tco-calculator/) + [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/) + [雲端產品](https://aws.amazon.com/products/) # COST05-BP02 分析工作負載的所有元件 確認會分析每個工作負載元件，無論目前大小或目前成本為何。審查工作應反映潛在的效益，例如目前和預計的成本。 **未建立此最佳實務時的曝險等級：**高 ## 實作指引 旨在為組織提供商業價值的工作負載元件可能包含各種服務。對於每個元件，可以選擇特定的 AWS 雲端 服務來滿足業務需求。這個選擇可能會受到熟悉與否或之前使用這些服務的經驗等因素所影響。 在確定 [COST05-BP01 確定組織的成本要求](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_select_service_requirements.html)中所述的組織要求之後，請對工作負載中的所有元件執行徹底分析。考慮當前和預測的成本與大小來分析每個元件。針對工作負載生命週期中的任何潛在工作負載節省來考慮分析成本。在分析此工作負載的所有元件上所花費的努力應與最佳化該特定元件所預期的潛在節省或改進相當。例如，如果所提議資源的成本是每月 10 美元，而低於預測的負載不會超過每月 15 美元，則努力一天以減少 50% 成本 (每月 5 美元) 可能會超過系統生命週期內的潛在利益。使用更快速且更有效率的資料型估算，會為此元件建立最佳整體結果。 工作負載可能會隨時間改變，而且如果工作負載架構或用量變化，適當的服務組合可能並非最佳。選擇服務的分析必須納入目前和未來的工作負載狀態以及用量水平。為未來的工作負載狀態或用量實作服務，可減少或消除未來變更所需的工作量，藉此降低整體成本。例如，使用 EMR Serverless 最初可能是合適的選擇。但是，隨著該服務的取用量增加，轉換到 EMR on EC2 可以降低工作負載中該元件的成本。 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 和 AWS Cost and Usage Report ([CUR](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/)) 可分析概念驗證 (PoC) 或執行環境的成本。也可以使用 [AWS 定價計算工具](https://calculator.aws/#/) 來估算工作負載成本。 撰寫工作流程，供技術團隊審核其工作負載。讓此工作流程保持簡單，同時也涵蓋所有必要步驟，以確保團隊了解工作負載的每個元件及其定價。然後，您的組織可以根據每個團隊的特定需求來遵循和自訂此工作流程。 1. **列出工作負載使用的每個服務：**這是一個很好的起點。確定目前使用的所有服務以及成本來源。 1. **了解這些服務的定價方式：**了解每項服務的[定價模式](https://aws.amazon.com/pricing/)。根據用量、資料傳輸和特定功能定價等因素，不同的 AWS 服務會有不同的定價模式。 1. **專注於具有非預期工作負載成本且與預期用量和業務結果不符的服務：**使用 AWS Cost Explorer 或 AWS Cost and Usage Report 識別成本與價值或用量不成比例的異常值或服務。將成本與業務成果相互關聯以優先考慮最佳化工作至關重要。 1. **使用 AWS Cost Explorer、CloudWatch Logs、VPC Flow Logs 和 Amazon S3 Storage Lens，了解這些高成本的根本原因：**這些工具有助於高成本的診斷。每項服務都可提供不同的視角來檢視和分析使用情況和成本。例如，Cost Explorer 可協助判斷整體成本趨勢，CloudWatch Logs 可提供營運洞察，VPC Flow Logs 可顯示 IP 流量，而 Amazon S3 Storage Lens 則適用於儲存分析。 1. **使用 AWS Budgets 為服務或帳戶的某些金額設定預算：**設定預算是管理成本的有效方式。使用 AWS Budgets 設定自訂預算閾值，並在成本超過這些閾值時接收提醒。 1. **設定 Amazon CloudWatch 警示以傳送帳單和用量提醒：**設定成本和用量指標的監控和提醒。CloudWatch 警示可在超出特定閾值時通知您，從而縮短干預回應時間。 透過對所有工作負載元件進行策略審查 (無論其目前屬性為何)，可隨著時間的推移帶來顯著的改進和財務方面的節省。在這個審查流程中所投入的努力應經過深思熟慮，並仔細考慮可能實現的潛在優勢。 ### 實作步驟 + **列出工作負載元件：**建立工作負載元件清單。使用此清單可確認是否已分析每個元件。所做的工作應反映貴組織優先事項所定義之工作負載的關鍵性。按功能將資源分組在一起以提高效率 (例如，生產資料庫儲存 (若有多個資料庫的話))。 + **設定元件清單的優先順序：**取得元件清單並按照工作順序排列其優先順序。這通常是依最昂貴到最便宜的元件成本排序，或依貴組織優先事項所定義的關鍵性排序。 + **執行分析：**對於清單上的每個元件，審核可用的選項和服務並選擇最適合您組織優先事項的選項。 ## 資源 **相關文件：** + [AWS 定價計算工具](https://calculator.aws/#/) + [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) + [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/) + [AWS 雲端 產品](https://aws.amazon.com/products/) **相關影片：** + [AWS 成本最佳化系列：CloudWatch](https://www.youtube.com/watch?v=6imTJUGEzjU) # COST05-BP03 對每個元件執行徹底的分析 查看每個元件的組織整體成本。考量營運和管理成本以計算總體擁有成本，尤其是在使用雲端供應商的受管服務時。審查工作應反映潛在的效益 (例如，用於分析的時間與元件成本成正比)。 **未建立此最佳實務時的曝險等級：**高 ## 實作指引 考量如何節省時間，讓您的團隊能夠專注於淘汰技術負債、創新和附加價值功能，以及創造企業與眾不同之處。例如，您可能需要將內部部署環境中的資料庫盡快「平移」至雲端 (也稱為主機轉換)，然後進行優化。能否使用 AWS 上的受管服務以去除或降低授權成本，進而獲得節省的效益，是值得探討的。AWS 上的受管服務免除了維護服務的營運和管理重擔 (例如修補或升級作業系統)，讓您得以專注於創新和業務。 因為受管服務以雲端規模運作，可使每次交易或服務的成本較低。您可以進行可能的優化以獲得實際的好處，且無須變更應用程式的核心架構。例如，您可能希望透過遷移到諸如 [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) 等資料庫即服務平台，或將應用程式遷移到諸如 [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) 等全受管平台，以減少管理資料庫執行個體所花費的時間。 通常受管服務具有屬性，您可設定以確保備充足容量。您必須設定並監控這些屬性，使得額外的容量保持最低程度，並且獲得最大效能。您可使用 AWS 管理主控台 或 AWS API 和 SDK 來修改 AWS Managed Services 的屬性，使資源需求與持續變動的需求保持一致。例如，可將 Amazon EMR 叢集 (或 Amazon Redshift 叢集上) 節點的數量增加或減少，以便擴展或者縮減。 您也可將多個執行個體裝填到一項 AWS 資源上，啟動密度更高的使用。例如，可將多個小資料庫佈建至單一 Amazon Relational Database Service (Amazon RDS) 資料庫執行個體。隨著用量增長，可使用快照和恢復程序，將其中一個資料庫遷移至專用 Amazon RDS 資料庫執行個體。 將工作負載佈建至受管服務上時，您必須了解調整服務容量的要求。這些要求通常是時間、心力和對一般工作負載運作的影響。佈建的資源必須允許發生任何變更，佈建必要的額外開銷來實現。為了修改服務所需持續投注的心力，利用與系統和監控工具例如 Amazon CloudWatch 相整合的 API 和 SDK，可降低為幾乎是零。 [Amazon RDS](https://aws.amazon.com/rds/)、[Amazon Redshift](https://aws.amazon.com/redshift/) 和 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) 可提供受管資料庫服務。[Amazon Athena](https://aws.amazon.com/athena/)、[Amazon EMR](https://aws.amazon.com/emr/) 和 [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) 可提供受管分析服務。 [AMS](https://aws.amazon.com/managed-services/) 是代表企業客戶和合作夥伴營運 AWS 基礎設施的服務。它提供安全且合規的環境，您可以將工作負載部署至其中。AMS 使用企業雲端營運模型與自動化，讓您符合組織需求、更快速地遷移至雲端，以及降低持續管理成本。 **實作步驟** + **執行徹底的分析：**使用元件清單，從最高優先順序到最低優先順序處理每個元件。對於優先順序更高且成本更高的元件，請執行額外的分析並評估所有可用選項及其長期影響。對於優先順序較低的元件，評估用量的變更是否會變更元件的優先順序，然後執行適當的工作分析。 + **比較受管和非受管資源：**考慮您管理的資源的營運成本，並將其與 AWS 受管資源進行比較。例如，審查在 Amazon EC2 執行個體上執行的資料庫，並且與 Amazon RDS 選項 (AWS 受管服務) 比較，或將 Amazon EMR 相較於在 Amazon EC2 上執行 Apache Spark。從自我管理工作負載移轉至 AWS 全受管工作負載時，請仔細研究您的選項。要考慮的三個最重要的因素是您要使用的[受管服務類型](https://aws.amazon.com/products/?&aws-products-all.q=managed)、將用來[遷移資料](https://aws.amazon.com/big-data/datalakes-and-analytics/migrations/)的程序，以及了解 [AWS 共同責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)。 ## 資源 **相關文件：** + [AWS 總體擁有成本 (TCO) 計算器](https://aws.amazon.com/tco-calculator/) + [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/) + [AWS 雲端 產品](https://aws.amazon.com/products/) + [AWS 共同責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/) **相關影片：** + [為什麼要移至受管資料庫？](https://www.youtube.com/watch?v=VRFdc-MVa4I) + [什麼是 Amazon EMR 以及我該如何使用它來處理資料？](https://www.youtube.com/watch?v=jylp2atrZjc) **相關範例：** + [為什麼要移至受管資料庫](https://aws.amazon.com/getting-started/hands-on/move-to-managed/why-move-to-a-managed-database/) + [使用 AWS DMS 將來自相同 SQL Server 資料庫的資料整合到單一的 Amazon RDS for SQL Server 資料庫](https://aws.amazon.com/blogs/database/consolidate-data-from-identical-sql-server-databases-into-a-single-amazon-rds-for-sql-server-database-using-aws-dms/) + [將資料大規模交付到 Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://aws.amazon.com/getting-started/hands-on/deliver-data-at-scale-to-amazon-msk-with-iot-core/?ref=gsrchandson) + [將 ASP.NET Web 應用程式遷移至 AWS Elastic Beanstalk](https://aws.amazon.com/getting-started/hands-on/migrate-aspnet-web-application-elastic-beanstalk/?ref=gsrchandson&id=itprohandson) # COST05-BP04 選取具成本效益授權的軟體 開放原始碼軟體會剔除對工作負載增加大量成本的軟體授權費用。請在需要授權軟體時，避免繫結至任意屬性 (例如 CPU) 的授權，尋找繫結至輸出或成果的授權。這些授權的成本會更接近其提供的效益。 **未建立此最佳實務時的曝險等級：**低 ## 實作指引 開放原始碼源於軟體開發的背景，以指出該軟體符合某些免費發行條件。開放原始碼軟體會由任何人都可以檢查、修改和增強的原始程式碼組成。根據業務要求、工程師的技能、預測用量或其他技術相依性，組織可以考慮使用 AWS 上的開放原始碼軟體，以最大程度地降低其授權成本。換句話說，使用[開放原始碼軟體](https://aws.amazon.com/what-is/open-source/)可降低軟體授權的成本。隨著工作負載的大小擴展，這可能會對工作負載成本產生重大影響。 請根據總成本來測量授權軟體的效益，以將工作負載最佳化。模擬授權的任何變更以及這些變更對工作負載成本的影響。如果廠商變更資料庫授權的成本，調查這會如何影響工作負載的整體效率。考慮廠商的歷史定價公告，以了解其產品授權變更趨勢。授權成本也可能獨立於輸送量或用量，例如依硬體擴展的授權 (CPU 綁定授權)。應該避免這些授權，因為成本可能會快速增加，而不會帶來相應結果。 例如，相較於執行另一個在 Windows 上執行的 Amazon EC2 執行個體，使用 Linux 作業系統在 us-east-1 中操作 Amazon EC2 執行個體可讓您削減大約 45% 的成本。 [AWS 定價計算工具](https://calculator.aws/) 提供了一種全面的方法來比較具有不同授權選項的各種資源的成本，例如 Amazon RDS 執行個體和不同的資料庫引擎。此外，AWS Cost Explorer 還為現有工作負載的成本提供了寶貴的觀點，尤其是具有不同授權的工作負載的成本。對於許可證管理，[AWS License Manager](https://aws.amazon.com/license-manager) 提供一種簡化的方法來監督和處理軟體授權。客戶可以在 AWS 雲端 中部署和操作自己喜歡的開放原始碼軟體。 ### 實作步驟 + **分析授權選項：**審核可用軟體的授權條款。尋找具有所需功能的開放原始碼版本，以及授權軟體的效益是否超過成本。有利條款會使軟體成本符合其提供的效益。 + **分析軟體供應商：**審核來自於廠商的任何歷史定價或授權變更。尋找不符合成果的任何變更，例如，在特定廠商硬體或平台上執行的懲罰性條款。此外，尋找他們執行稽核和可能施加的懲罰的方式。 ## 資源 **相關文件：** + [AWS 的開放原始碼](https://aws.amazon.com/opensource/) + [AWS 總體擁有成本 (TCO) 計算器](https://aws.amazon.com/tco-calculator/) + [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/) + [雲端產品](https://aws.amazon.com/products/) **相關範例：** + [開放原始碼部落格](https://aws.amazon.com/blogs/opensource/) + [AWS 開放原始碼部落格](https://aws.github.io/) + [最佳化和授權評定](https://aws.amazon.com/optimization-and-licensing-assessment/) # COST05-BP05 選取此工作負載的元件，以按照組織優先事項來優化成本 選取工作負載的所有元件時均應考量成本。這包括使用應用程式層級和受管服務或無伺服器、容器或事件驅動架構，以降低整體成本。使用開放原始碼軟體、無需授權費用的軟體或替代方案，藉以將授權成本降至最低。 **未建立此最佳實務時的曝險等級：**中 ## 實作指引 選取所有元件時均應考量服務和選項的成本。這包括使用應用程式層級和受管服務，例如 [Amazon Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS)、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、[Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS) 以及 [Amazon Simple Email Service](https://aws.amazon.com/ses/) (Amazon SES)，以降低整體組織成本。 使用無伺服器和容器進行運算，例如 [AWS Lambda](https://aws.amazon.com/lambda/) 及針對靜態網站的 [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3)。如果可能，將您的應用程式容器化，並使用 AWS 受管容器服務，例如 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (Amazon ECS) 或 [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) (Amazon EKS)。 使用開放原始碼軟體或沒有授權費用的軟體，將授權成本降到最低 (例如，用於運算工作負載的 Amazon Linux，或將資料庫遷移到 Amazon Aurora)。 您可以使用無伺服器或應用程式層級服務，例如 [Lambda](https://aws.amazon.com/lambda/)、[Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/)、[Amazon SNS](https://aws.amazon.com/sqs/) 以及 [Amazon SES](https://aws.amazon.com/ses/)。這些服務讓您無須管理資源，並提供程式碼執行、佇列服務和訊息傳遞功能。另一個好處是，這些服務可隨用量擴展效能和成本，因此能夠有效率地分配成本和劃分歸屬。 無伺服器服務也可以使用[事件驅動型架構](https://aws.amazon.com/what-is/eda/)。事件驅動型架構是推送架構，因此一切都會在事件呈現於路由器時隨需進行。如此，您就無須付費持續進行輪詢以檢查事件。這表示網路頻寬耗用量、CPU 使用率、閒置機群容量和 SSL/TLS 交握都可降低。 如需有關無伺服器的詳細資訊，請參閱 [Well-Architected 無伺服器應用程式聚焦白皮書](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html)。 ### 實作步驟 + **選取每個服務以最佳化成本：**使用您的優先順序清單和分析，選取最符合您組織優先事項的每個選項。與其增加容量以符合需求，您應考慮使用其他選項，以較低的成本獲得更好的效能。例如，您應審查資料庫在 AWS 上的預期流量，並考慮增加執行個體大小，或使用 Amazon ElastiCache 服務 (Redis 或 Memcached) 為資料庫提供快取的機制。 + **評估事件驅動型架構：**使用無伺服器架構也可讓您為分散式微型服務應用程式建置事件驅動架構，以利設計可擴展、彈性、敏捷且符合成本效益的解決方案。 ## 資源 **相關文件：** + [AWS 總體擁有成本 (TCO) 計算器](https://aws.amazon.com/tco-calculator/) + [AWS Serverless](https://aws.amazon.com/serverless/) + [什麼是事件驅動型架構](https://aws.amazon.com/what-is/eda/) + [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/) + [雲端產品](https://aws.amazon.com/products/) + [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis) **相關範例：** + [事件驅動型架構入門](https://aws.amazon.com/blogs/compute/getting-started-with-event-driven-architecture/) + [事件驅動型架構](https://aws.amazon.com/event-driven-architecture/) + [Statsig 如何使用 Amazon ElastiCache (Redis OSS) 以 100 倍的成本效益運行](https://aws.amazon.com/blogs/database/how-statsig-runs-100x-more-cost-effectively-using-amazon-elasticache-for-redis/) + [使用 AWS Lambda 函數的最佳實務](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) # COST05-BP06 對不同用量執行一段時間內的成本分析 工作負載可能隨時間變更。某些服務或功能在不同的用量層級上更具成本效益。按預計用量對每個元件執行一段時間內的分析，讓工作負載在其生命週期內保持成本效益。 **未建立此最佳實務時的曝險等級：**中 ## 實作指引 隨著 AWS 發佈新的服務和功能，工作負載的最佳服務可能會改變。所需的努力應與潛在效益相符。工作負載審核頻率取決於您的組織需求。如果成本高昂，則更快實作新的服務可節省最多成本，因此更頻繁的審核是有利的。另一個需要審核的方面是使用模式的變更。用量的重大變更可能表示替代服務更理想。 如果需要將資料移至 AWS 雲端 中，您可以選取 AWS 所提供的各種服務以及合作夥伴工具，以便遷移您的資料集，無論是檔案、資料庫、機器映像、區塊磁碟區甚或磁帶備份均可。例如，若要對 AWS 移入或移出大量資料，或是在邊緣處理資料，您可以使用其中一項 AWS 專用裝置，以符合成本效益的方式離線移動數以 PB 計的資料。另一個範例是，在資料傳輸速率較高時，直接連線服務可能會比 VPN 更便宜，為您的企業提供所需的連線能力。 根據對不同用量在一段時間內的成本分析，審查您的擴展活動。分析結果，確認是否可以調整擴展政策，以使用多個執行個體類型和購買選項新增執行個體。審查您的設定，確認是否可以降低最小值，以較小的機群大小處理使用者要求，以及新增更多資源以符合預期的高需求。 透過與組織中的利益相關者討論，針對不同使用情況執行成本分析，並使用 [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) 的預測功能來預測服務變更的潛在影響。使用 AWS Budgets、CloudWatch 帳單警示和 AWS Cost Anomaly Detection 來監控用量等級發佈，以快速識別及實作最符合成本效益的服務。 **實作步驟** + **定義預測使用模式：**與您的組織 (例如行銷和產品擁有者) 合作，記錄工作負載的預期和預測使用模式。與利益相關者討論關於歷史和預測成本與用量增加的議題，並確定這類增加符合業務要求。識別您預期會有較多使用者使用 AWS 資源的日曆日、週或月，這表示您應增加現有資源的容量或採用其他服務，以降低成本並提升效能。 + **根據預測用量執行成本分析：**使用定義的使用模式，在上述每個點執行分析。分析工作應反映潛在成果。例如，如果用量變化很大，則應執行徹底的分析以驗證任何成本和變化。換句話說，當成本增加時，企業的用量也應增加。 ## 資源 **相關文件：** + [AWS 總體擁有成本 (TCO) 計算器](https://aws.amazon.com/tco-calculator/) + [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/) + [雲端產品](https://aws.amazon.com/products/) + [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + [雲端資料遷移](https://aws.amazon.com/cloud-data-migration/) + [AWS Snow Family](https://aws.amazon.com/snow/) **相關影片：** + [AWS OpsHub for Snow Family](https://www.youtube.com/watch?v=0Q7s7JiBCf0)