# 成本最佳化
成本最佳化支柱包括以最低價格執行系統來產生商業價值的能力。您可以在下列白皮書中找到規範指引： [成本最佳化支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html?ref=wellarchitected-wp)。
**Topics**
+ [實作雲端財務管理](a-practice-cloud-financial-management.md)
+ [支出和用量感知](a-expenditure-and-usage-awareness.md)
+ [具有經濟效益的資源](a-cost-effective-resources.md)
+ [管理需求與供應資源](a-manage-demand-and-supply-resources.md)
+ [隨時間優化](a-optimize-over-time.md)
# 實作雲端財務管理
**Topics**
+ [COST 1.如何實作雲端財務管理？](cost-01.md)
# COST 1.如何實作雲端財務管理？
透過實作雲端財務管理，就可幫助組織最佳化成本和用量，並且在 AWS 上進行規模調整，進而實現商業價值和財務上的成功。
**Topics**
+ [COST01-BP01 建立優化成本的負責團隊](cost_cloud_financial_management_function.md)
+ [COST01-BP02 在財務與技術之間建立合作夥伴關係](cost_cloud_financial_management_partnership.md)
+ [COST01-BP03 建立雲端預算和預測](cost_cloud_financial_management_budget_forecast.md)
+ [COST01-BP04 在組織程序中實作成本感知](cost_cloud_financial_management_cost_awareness.md)
+ [COST01-BP05 報告並通知成本優化](cost_cloud_financial_management_usage_report.md)
+ [COST01-BP06 主動監控成本](cost_cloud_financial_management_proactive_process.md)
+ [COST01-BP07 及時了解新的服務版本](cost_cloud_financial_management_scheduled.md)
+ [COST01-BP08 建立成本感知文化](cost_cloud_financial_management_culture.md)
+ [COST01-BP09 量化成本最佳化所帶來的商業價值](cost_cloud_financial_management_quantify_value.md)
# COST01-BP01 建立優化成本的負責團隊
建立負責建立並維護整個組織的成本感知的團隊 (雲端商業辦公室、雲端卓越中心或 FinOps 團隊)。成本最佳化的負責人可以是個人或是團隊，條件是必須是來自財務、技術或業務團隊，且了解整個組織和雲端財務的人員。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
這份說明會介紹雲端商業辦公室 (CBO) 或雲端卓越中心 (CCOE) 的職能，或是負責建立並維護雲端運算成本感知文化的團隊。這個職能可以是現有個人、組織內的團隊，或是由組織內主要財務、技術和組織利害關係人組成的新團隊。
此職能部門 (個人或團隊) 會優先並花費一定比例的時間，進行成本管理和成本最佳化活動。相較於大型企業的全職職能部門，小型組織的此職能部門花費的時間比例可能較少。
此職能部門 (個人或團隊) 會優先並花費一定比例的時間，進行成本管理和成本最佳化活動。相較於大型企業的全職職能部門，小型組織的此職能部門在成本管理、及最佳化活動方面花費的時間比例可能較少。
此職能部門必須採行跨領域合作的方法，並要具備專案管理、資料科學、財務分析和軟體或基礎架構開發等能力。藉此，在三種不同的所有權下執行成本最佳化，以改善工作負載效率：
+ **集中式：** 透過 FinOps 團隊、雲端財務管理 (CFM) 團隊、雲端商業辦公室 (CBO) 或雲端卓越中心 (CCoE) 等特設團隊，客戶可以設計和實作管控機制，並在全公司推動最佳實務。
+ **分散式：** 影響技術團隊，進行成本最佳化。
+ **混合:** 結合集中式與去中心化方法，讓團隊互相合作，進行成本最佳化。
可以根據成本最佳化目標 (例如工作負載效率指標) 來衡量此職能部門的執行和交付能力。
您必須設法讓高層支持此職能部門，這是成功的關鍵因素。高層支持者會成為運用雲端服務節省成本的推動者，並替團隊提報支援，確保成本最佳化活動獲組織認定為優先要務。否則，相關的方針可能不會受到重視，且節省成本將不會被列為優先要務。高層支持者和這個團隊共同協助您的組織，讓其得以聰明高效地使用雲端，並提供商業價值。
如果您有商業計劃、Enterprise-On-Ramp 或 Enterprise [Support 計劃，](https://aws.amazon.com/premiumsupport/plans/) 且需要建立此團隊或職能部門的相關協助，請透過客戶團隊洽詢雲端財務管理 (CFM) 專家。
### 實作步驟
+ **定義關鍵成員：** 貴組織的所有相關人員都必須貢獻己力，進一步了解成本管理。組織內的常見團隊通常包括：財務、應用程式或產品擁有者、管理和技術團隊 (DevOps)。有些團隊必須全職參與 (財務或技術)，有些團隊則可視需要定期參與。執行 CFM 的個人或團隊需要具備下列技能：
+ **軟體開發：** 如果您正在建構指令碼和自動化程序。
+ **基礎架構工程：** 用以部署指令碼、自動化程序，並理解服務或資源的佈建方式。
+ **操作敏銳度：** CFM 關乎雲端的高效運作，具體做法包括評估、監控、修改、規劃及擴展雲端的有效使用。
+ **定義目標和指標： **該職能部門需要以不同的方式提供價值給組織。定義的目標會隨著組織的發展而不斷演變。常見的活動包括：建立和執行整個組織成本最佳化的教育計畫，制定整個組織的標準 (例如成本最佳化的監控和報告)，以及設定工作負載最佳化目標。此職能部門也需要定期向組織報告其成本最佳化的能力。
您可以定義以價值或成本衡量的關鍵績效指標 (KPI)。在定義 KPI 時，您可以從效率的角度來計算預期成本，並計算預期的商業成果。以價值衡量的 KPI 會將成本與用量指標連結商業價值驅動力，協助釐清變更 AWS 支出的合理性。要導出以價值衡量的 KPI，首重整個組織的相互合作，以期能共同擬定出一組標準 KPI。
+ **建立定期規律：** 各群組 (財務、技術和業務團隊) 應定期會談，並審查其目標和指標。一般的規律包括審查組織的狀態、審查目前執行的任何計畫、整體財務和最佳化指標。然後，再更詳細地報告關鍵工作負載。
在這類定期會談中，您可以審查工作負載效率 (成本) 和商業成果。例如，工作負載成本上升 20% 與增加的客戶用量，是相對應的。在此案例中，這 20% 的成本上升可被視為投資。這些定期會議可協助團隊找出為整個組織提供實質意義的價值 KPI。
## 資源
**相關文件：**
+ [AWS CCOE 部落格](https://aws.amazon.com/blogs/enterprise-strategy/tag/ccoe/)
+ [建立雲端商業辦公室](https://aws.amazon.com/blogs/enterprise-strategy/creating-the-cloud-business-office/)
+ [CCOE - 雲端卓越中心](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html)
**相關影片：**
+ [Vanguard CCOE 成功案例](https://www.youtube.com/watch?v=0XA08hhRVFQ)
**相關範例：**
+ [使用雲端卓越中心 (CCOE) 推動整體企業轉型](https://aws.amazon.com/blogs/enterprise-strategy/using-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise/)
+ [建置 CCOE 以推動整體企業轉型](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/building-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise.html)
+ [建置 CCOE 時應避開的 7 大陷阱](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)
# COST01-BP02 在財務與技術之間建立合作夥伴關係
讓財務和技術團隊參與討論雲端之旅各個階段的成本和用量。各團隊定期碰面並討論相關主題，例如，組織總目標和具體目標、成本和用量的目前狀態，以及財務和會計實務。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
由於核准、採購和基礎設施部署週期縮短，技術團隊可在雲端提高創新速度。對於之前習慣於執行耗時且資源密集型程序，以便採購資料中心和內部部署環境，並且只在核准專案時才分配成本的財務組織來說，這是一項調整。
就金融與採購組織的觀點而言，資本預算、資金要求、核准、採購和安裝實體基礎架構的流程，在過去數十年來早已廣為人知並標準化：
+ 工程或 IT 團隊通常是要求者
+ 核准者和採購者由不同的財務團隊擔任
+ 營運團隊負責建構、堆疊及交付現成可用的基礎架構
![\[Circular workflow diagram showing technology teams, procurement, supply chain, and operations interactions.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/cost01-bp02-finance-and-procurement-workflow.png)
採用雲端後，基礎架構的採購和取用不再受制於一連串的相依性。在雲端模型中，技術及產品小組不再只是建置者，而是產品的操作人員和擁有者，負責處理在過去與財務與營運團隊相關聯的多數活動，包括採購和部署。
要佈建雲端資源，所需的其實就是使用者帳戶，和正確的一組許可。IT 和財務風險也因而降低；這意味著，團隊只需按幾下滑鼠或執行 API 呼叫，即可終止閒置或非必要的雲端資源。這也讓技術團隊得以加速創新 – 基於建立和推翻試驗的靈活性與能力。儘管使用雲端的本質是多變的，就資本預算和預測的角度而言可能會影響到可預測性，但雲端仍讓組織得以降低過度佈建的成本，以及降低因保守的佈建不足而伴隨的機會成本。
![\[Diagram showing Technology and Product teams deploying, Finance and Business teams operating, with optimization at the center.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/cost01-bp02-deploy-operate-optimize.png)
在關鍵財務和技術利害關係人之間建立合作夥伴關係，以形成對組織目標的共識，並建立可在雲端運算可變支出模型中取得財務成功的機制。組織內的相關團隊必須參與雲端之旅各個階段的成本和用量討論，包括：
+ ** 財務主管：** 財務長、財務總監、財務規劃師、商業分析師、採購和應付帳款必須了解雲端消費模式、購買選項和每月發票開立程序。財務部門需要與技術團隊合作，來建立 IT 價值故事並加以傳播，以協助業務團隊了解技術支出與業務成果之間的連結。這樣，技術支出就不再被視為成本，而是投資。由於雲端與內部部署營運存在基本差異 (例如，用量改變速率、按使用付費定價、分級定價、定價模式以及詳細帳單和用量資訊)，財務組織必須了解雲端用量如何影響商業層面，包括採購程序、激勵追蹤、成本分配和財務報表。
+ **技術主管：** 技術主管 (包括產品和應用程式擁有者) 必須了解財務需求 (例如，預算限制) 以及業務需求 (例如，服務水準協議)。如此可允許實作工作負載，達成組織希望的目標。
財務與科技的合作夥伴關係可帶來下列好處：
+ 財務和技術團隊可近乎即時地檢視成本和用量。
+ 財務和技術團隊建立標準操作程序來處理雲端支出變化。
+ 在資本如何用於購買承諾折扣 (例如，預留執行個體或 AWS Savings Plans)，以及如何使用雲端來發展組織方面，財務利害關係人會擔任策略顧問。
+ 現有的應付帳款和採購程序會與雲端搭配使用。
+ 財務和技術團隊共同預測未來的 AWS 成本和用量，以評估並擬定組織預算。
+ 透過共同的語言以及對財務概念的一致理解，促進跨組織溝通。
組織內應參與成本和用量討論的其他利害關係人包括：
+ **業務單位擁有者：** 業務單位擁有者必須了解雲端業務模式，以便對業務單位和全公司提供指引。當有需要預測成長和工作負載用量，以及需要評估長期購買選項，例如預留執行個體或 Savings Plans 時，此項雲端知識相當重要。
+ **工程團隊： **在財務與技術團隊之間建立合作夥伴關係至關重要，這是培養成本感知文化，鼓勵工程師對雲端財務管理 (CFM) 採取行動，所不可或缺的。CFM 或財務營運從業人員與財務團隊的常見問題之一，是不易讓工程師了解雲端業務的全貌、遵循最佳實務，以及執行建議的動作。
+ **第三方： **如果您的組織使用第三方 (例如，顧問或工具)，請確保他們符合您的財務目標，並能透過其參與模式和投資報酬率 (ROI) 證實符合。通常第三方會報告和分析其管理的一切工作負載，並且提供所設計一切工作負載的成本分析。
要實作 CFM 並取得成功，需要財務、技術和業務團隊之間進行協作，並且需要轉變整個組織傳達和評估雲端支出的方式。請納入工程團隊，使他們在各階段都能加入這些成本與用量的討論中，並鼓勵他們遵循最佳實務，並據以執行已達成共識的動作。
**實作步驟**
+ **定義關鍵成員： **確認您的財務和技術團隊中的所有相關成員都參與此合作夥伴關係。相關財務成員會處理雲端帳單。涉及人員通常包括財務總監、財務控制者、財務規劃師、商業分析師、採購和採購專員。技術成員通常是產品與應用程式擁有者、技術經理以及在雲端進行建置的所有團隊的代表。其他成員可能包括業務單位擁有者，例如，顧問等會影響產品用量的行銷單位，以及實現與目標和機制保持一致並協助報告的第三方人員。
+ **定義討論主題：** 確定團隊中常見的主題，或需要有共識的主題。從建立時開始追蹤成本，直到帳單支付為止。請記下所有參與的成員，以及需要應用的組織程序。了解採用的每個步驟或程序及相關資訊，例如可用的定價模式、分級定價、折扣模式、預算編列和財務要求。
+ **建立定期規律： **若要建立財務與技術的合作夥伴關係，請建立定期通訊規律，以樹立並維持一致性。該群組需要針對他們的目標和指標定期聚會進行討論。一般的規律包括審查組織的狀態、審查目前執行的任何計畫，以及審查整體財務和優化指標。然後，會更詳細地報告關鍵工作負載。
## 資源
**相關文件：**
+ [AWS 新聞部落格](https://aws.amazon.com/blogs/aws/)
# COST01-BP03 建立雲端預算和預測
調整現有的組織預算編列和預測程序，使其與本質會高度變動的雲端成本和用量相容。程序必須是動態的，並使用以趨勢為基礎和/或以業務驅動因素為基礎的演算法。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
客戶使用雲端以提高效率、速度和靈活性，這會產生高度變動的成本和用量。成本會隨著工作負載效率的增加或部署新的工作負載和功能降低或增加。可以擴展工作負載，服務更多客戶，同時提高雲端用量和成本。如今，資源的立即存取性比以往更高。借助於雲端的彈性，成本和預測也更具彈性。必須修改現有的組織預算編列程序，以納入這樣的變動。
預算通常以一年為期，且保持固定不變，所有參與者必須嚴格遵守預算計畫。相較之下，預測可以更加靈活，也可以全年隨時調整，並提供一年、兩年或三年的動態預測。要在技術和商業利益關係人之間建立財務期望，預算編列和預測皆非常重要。準確的預測和實作，不僅讓直接負責佈建成本的利益關係人更能掌握狀況，還能夠提高整體成本感知。
不論使用以趨勢為基礎的演算法 (使用歷史成本輸入)、適合動態多元成本環境、以驅動因素為基礎的演算法 (例如：新產品推出、區域擴展或新工作負載環境)，或結合兩種演算法，皆能調整現有的預算編列和預測程序，變得更加靈活。
您可以使用 [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) 根據您過去的支出預測已定義的未來時間範圍內的趨勢成本。AWS Cost Explorer 的預測引擎會根據收費類型 (例如，預留執行個體) 對您的歷史資料進行細分，並結合使用機器學習和基於規則的模型，來分別預測所有收費類型的支出。
找出可能影響使用成本的業務驅動因素，並分別預測每個因素，以確保預先計算好預期用量。部分驅動因素與組織內的 IT 和產品團隊相關。而您的銷售、行銷和業務主管已經熟知行銷活動、促銷和併購等其他業務驅動因素，團隊必須合作和重視所有需求驅動因素。您要與團隊密切合作，了解對新內部驅動因素的影響。
使用 Cost Explorer 判斷以趨勢為基礎的預測後，請使用 [AWS 定價計算工具](https://calculator.aws/#/) 根據預期的用量 (流量、每秒請求數、必要的 Amazon EC2 執行個體等) 來估計您的 AWS 使用案例與未來的成本。您可以據此規劃支出、尋找節省成本的機會，以及在使用 AWS 時做出明智的決定。追蹤預測準確度非常重要，因為您可以根據這些預測計算結果來編列預算。
使用 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 藉由指定時段、重複週期或金額 (固定或可變)，並新增篩選條件 (例如服務、AWS 區域 和標籤)，來設定周延的自訂預算。若要及時了解現有預算的執行情況，您可以建立和排程 [AWS Budgets 報告](https://docs.aws.amazon.com/cost-management/latest/userguide/reporting-cost-budget.html) ，以定期透過電子郵件將報告傳送給您和利害關係人。您也可以建立 [AWS Budgets 提醒](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html) (根據本質上是被動的實際成本，或根據預測成本)，以便有足夠的時間可對潛在的成本超支實作緩解措施。當您的成本或用量超出或預計超出預算額度時，系統會提醒您。
使用 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 防止或避免成本超出預期，並強化控制且不影響創新速度。AWS Cost Anomaly Detection 採用機器學習來識別異常支出與根本原因，以便您迅速採取行動。 [只需簡單的三個步驟](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)，您即可建立自己的情境化監視器，並且在偵測到任何異常支出時收到提醒。
如同 Well-Architected 成本最佳化支柱的 [財務與技術的合作夥伴關係一節中所述，](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/finance-and-technology-partnership.html)IT、財務和其他利害關係人之間必須建立合作關係和規律，才能確認所有人以一致的方式使用相同的工具或程序。如果預算可能需要改變，提高接觸頻率可能有助於提升對這些變化的因應速度。
### 實作步驟
+ **分析以趨勢為基礎的預測：** 使用偏好的趨勢型預測工具，例如 AWS Cost Explorer 和 Amazon Forecast。從服務、帳戶、標籤和成本類別等不同角度分析您的使用成本。如果需要進階預測，請將您的 AWS Cost and Usage Report 資料匯入 Amazon Forecast，其將線性迴歸作為一種機器學習形式，用於進行預測。
+ **分析以驅動因素為基礎的預測：** 識別出業務驅動因素對雲端使用情況的影響，並分別預測每個因素，以預先計算預期使用成本。與業務單位主管和利害關係人密切合作，了解對新驅動因素的影響，並計算預期成本變動，以準確編列預算。
+ **更新現有預測與預算處理程序：** 根據您所採用的預測方法 (例如以趨勢為基礎、以業務驅動因素為基準或兩種方式結合)，定義您的預測預算程序。預算應根據這些預測程序進行編列，不能不切實際。
+ **設定提醒和通知：** 使用 AWS Budgets 警示和 AWS Cost Anomaly Detection，以接收警示和通知。
+ **會同主要利害關係人執行定期審查： **例如，應該要會同 IT、財務、平台等團隊和其他業務部門的利害關係人，商討如何因應經營方向與用量的變化。
## 資源
**相關文件：**
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/?sc_channel=cfm-blog&sc_campaign=using-the-right-tools-for-your-cloud-cost-forecasting&sc_medium=plan-and-evaluate&sc_content=cfm-blog&sc_detail=link&sc_outcome=aw&sc_publisher=cfm-awareness&trk=using-the-right-tools-for-your-cloud-cost-forecasting_cfm-blog_link)
+ [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)
+ [Quick 預測](https://docs.aws.amazon.com/quicksight/latest/user/forecasts-and-whatifs.html)
+ [Amazon Forecast](https://aws.amazon.com/forecast/)
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS 新聞部落格](https://aws.amazon.com/blogs/aws/)
**相關影片：**
+ [如何使用 AWS Budgets 追蹤我的支出和用量](https://www.youtube.com/watch?v=Ris23gKc7s0)
+ [成本最佳化系列：AWS Budgets](https://www.youtube.com/watch?v=5vYEVQzoMeM)
**相關範例：**
+ [了解並建置以驅動因素為基礎的預測](https://aws.amazon.com/blogs/aws-cloud-financial-management/understand-and-build-driver-based-forecasting/)
+ [如何建立和推動預測文化](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-establish-and-drive-a-forecasting-culture/)
+ [如何改善雲端成本預測](https://aws.amazon.com/blogs/aws-cloud-financial-management/forecasting-blog-series-1-3-ways-to-more-effectively-forecast-cloud-spend/)
+ [使用正確的工具進行雲端成本預測](https://aws.amazon.com/blogs/aws-cloud-financial-management/using-the-right-tools-for-your-cloud-cost-forecasting/)
# COST01-BP04 在組織程序中實作成本感知
在會影響用量的全新或現有程序中實作成本感知、建立成本的透明度與權責劃分，並利用現有程序落實成本感知。在員工培訓中實作成本感知。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
必須在新的和現有的組織程序中實作成本感知。對於其他最佳實務而言，這是基本的必備能力之一。建議盡可能重複使用和修改現有程序，這樣可將對靈活性和速度的影響降到最低。向技術團隊以及業務與財務團隊的決策者報告雲端成本，不僅可增強成本感知，也可為財務與業務利害關係人建立效率的關鍵績效指標 (KPI)。下列建議有助於在您的工作負載中實作成本感知：
+ 確認變更管理包含成本測量，以量化變更所帶來的財務影響。這有助於主動解決成本相關疑慮，並提供成本節省資訊。
+ 確認成本優化是您營運能力的核心部分。例如，您可以利用現有的事故管理程序，調查並找出成本和用量異常或成本超支的根本原因。
+ 透過自動化或工具加速節省成本和實現商業價值。考慮實作的成本時，將投資報酬率 (ROI) 部分納入對話中，以證明投入時間或金錢的合理性。
+ 藉由實作雲端支出的回報 (showback) 或計費 (chargeback) 來分配雲端成本 (包括以承諾為基礎的購買選項、共用服務和市場購買的支出)，以實現最具成本感知力的雲端使用。
+ 擴展現有的培訓和發展計畫，納入整個組織的成本感知培訓。建議包含持續培訓和認證。這將建立一個能夠自我管理成本和用量的組織。
+ 充分利用免費的 AWS 原生工具，例如 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)、[AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)和 [AWS Budgets 報告](https://aws.amazon.com/about-aws/whats-new/2019/07/introducing-aws-budgets-reports/)。
如果組織一貫採行 [雲端財務管理](https://aws.amazon.com/aws-cost-management/) (CFM) 實務準則，這些行為將深植於工作與決策制定的機制中。結果會產生更注重成本的文化，無論是開發人員設計新的雲端原生應用程式，還是財務經理分析這些新的雲端投資的投資報酬率，皆注重成本。
**實作步驟**
+ ** 識別相關的組織程序： **每個組織單位審查其程序，並識別影響成本和用量的程序。任何導致資源建立或終止的程序都需要納入審查。尋找能夠在業務上支援成本感知的程序，例如事故管理和培訓。
+ **建立自主的成本感知文化：** 確定所有相關的利害關係人都認同成本的改變原因和影響，因此都了解雲端成本。這將可讓您的組織針對創新建立自主的成本感知文化。
+ ** 以成本感知更新程序：** 每項程序都會修改為可感知成本。程序可能需要額外的預先檢查，例如評估成本的影響，或進行後置檢查以驗證成本和用量預期的變更是否發生。可以擴展培訓和事件管理等支援程序，以包含成本和用量的項目。
如需協助，請透過客戶團隊洽詢 CFM 專家，或瀏覽下方的資源和相關文件。
## 資源
**相關文件：**
+ [AWS 雲端財務管理](https://aws.amazon.com/aws-cost-management/)
**相關範例：**
+ [高效雲端成本管理的策略](https://aws.amazon.com/blogs/enterprise-strategy/strategy-for-efficient-cloud-cost-management/)
+ [成本控制部落格系列 3：如何處理成本衝擊](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-control-blog-series-3-how-to-handle-cost-shock/)
+ [AWS Cost Management 入門指南](https://aws.amazon.com/blogs/aws-cloud-financial-management/beginners-guide-to-aws-cost-management/)
# COST01-BP05 報告並通知成本優化
設定雲端預算及相關機制，偵測使用期間的異常情況。針對預先定義的目標設定成本和用量警示的相關工具，並於用量超過目標時接收通知。舉辦定期會議，分析工作負載的成本效益並提升成本感知。
**未建立此最佳實務時的曝險等級：** 低
## 實作指引
您必須定期在組織內報告成本和用量最佳化。您可以舉辦專門的會議討論成本效益，或在工作負載的定期營運報告週期中包含優化成本的內容。使用服務和工具定期監控您的成本效益，並實施能夠節省成本的措施。
透過多種篩選條件和精細度來檢視成本和用量時，可使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)，這項功能會提供儀表板和報告，例如依服務或帳戶分類的成本、每日成本或市場成本。根據設定的預算追蹤成本使用和用量狀況時可使用 [AWS Budgets 報告](https://aws.amazon.com/about-aws/whats-new/2019/07/introducing-aws-budgets-reports/)。
使用 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) ，設定自訂預算以追蹤成本與用量，並且在超出閾值時快速回應電子郵件或 Amazon Simple Notification Service (Amazon SNS) 通知所傳來的提醒。 [將您偏好的預算](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-create.html) 期間設定為每日、每月、每季或每年，並建立特定預算限制，以持續掌握實際或預測的成本與用量逐漸接近預算閾值的情形。您也可以設定 [提醒](https://docs.aws.amazon.com/cost-management/latest/userguide/sns-alert-chime.html) 和 [動作](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html) ，使其自動執行以因應這些提醒，或是在超出預算目標時透過核准程序執行。
實作成本和用量通知，以確保能夠快速處理非預期的成本和用量變化。 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 可避免成本超出預期，並強化控制且不影響創新速度。AWS Cost Anomaly Detection 可識別異常支出與根本原因，有助於降低帳單超出預期的風險。只需簡單的三個步驟，您即可建立自己的情境化監視器，並且在偵測到任何異常支出時收到提醒。
您也可以使用 [Quick](https://aws.amazon.com/quicksight/) 搭配 AWS Cost and Usage Report (CUR) 資料，用更精細的資料提供高度自訂的報告。Quick 可讓您排程報告及接收定期成本報告電子郵件，以了解歷史成本與用量或節省成本的機會。歡迎查看我們的 [成本智慧儀表板](https://aws.amazon.com/blogs/aws-cloud-financial-management/a-detailed-overview-of-the-cost-intelligence-dashboard/) (CID) 解決方案 (建於 Quick 上)，可以更清楚檢視資料。
使用 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)作為指引，以確認已佈建的資源是否符合 AWS 的成本優化最佳實務。
根據您的成本細項和用量，透過視覺化圖表查看您的 Savings Plans 建議。每小時呈現的圖表顯示隨需支出以及建議的 Savings Plans 承諾，提供估計成本節省、Savings Plans 涵蓋範圍和 Savings Plans 使用率的深入分析。這些資訊能協助組織了解 Savings Plans 如何在無需投入時間資源建立模型來分析支出的條件下，應用於每小時的支出。
定期建立相關報告，納入 Savings Plans 重點、預留執行個體和 Amazon EC2 適當調整大小的建議 (來自 AWS Cost Explorer)，開始降低與穩定工作負載、閒置和低利用率資源相關聯的成本。識別並收回與已部署資源的雲端浪費相關聯的支出。若建立了大小不當的資源，或是發現非預期的不同用量模式時，就會發生雲端浪費。遵循 AWS 最佳實務來減少浪費，或請您的客戶團隊和合作夥伴協助您 [優化和節省](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/) 您的雲端成本。
定期產生報告以找出更好的資源採購選項，進而降低工作負載的單位成本。Savings Plans、預留執行個體或 Amazon EC2 Spot 執行個體等購買選項可為容錯工作負載提供最大的成本節省效益，並且可讓利害關係人 (企業擁有者、財務和技術團隊) 參與這些承諾討論。
將報告分享給相關各方，使其了解可能有助於降低雲端總體擁有成本 (TCO) 的機會或新版本公告。採用新的服務、區域、功能、解決方案或新方法來實現進一步的成本降低。
### 實作步驟
+ **設定 AWS Budgets：** 針對您的工作負載在所有帳戶上設定 AWS Budgets。使用標籤來設定整體帳戶支出的預算，以及工作負載的預算。
+ [Well-Architected 實驗室：成本與管控用量](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html)
+ **成本優化報告：** 設置定期週期來討論和分析工作負載的效率。使用建立的指標來報告所達到的指標和達到指標所需的成本。識別並修正任何負面趨勢，並識別您可以在整個組織中推廣的正面趨勢。報告參與者應包含應用程式團隊和擁有者、財務和雲端成本相關重要決策者的代表。
## 資源
**相關文件：**
+ [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)
+ [AWS Budgets 最佳實務](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html#budgets-best-practices-setting-budgets%3Fsc_channel=ba%26sc_campaign=aws-budgets%26sc_medium=manage-and-control%26sc_content=web_pdp%26sc_detail=how-do-I%26sc_outcome=aw%26trk=how-do-I_web_pdp_aws-budgets)
+ [Amazon S3 分析](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html)
**相關範例：**
+ [Well-Architected 實驗室：成本與管控用量](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html)
+ [開始優化 AWS 雲端成本的關鍵方法](https://aws.amazon.com/blogs/aws-cloud-financial-management/key-ways-to-start-optimizing-your-aws-cloud-costs/)
# COST01-BP06 主動監控成本
實作工具和儀表板來主動監控工作負載的成本。定期使用已設定的工具或現成可用的工具來審查成本。不要只在收到通知時才查看成本和類別。主動監控和分析成本有助於識別正面趨勢，並讓您在整個組織中推廣。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
建議監控組織內的成本與用量，而不只是在發生例外狀況或異常狀況時。在所有辦公室或工作環境中均可以使用高度可見的儀表板，確保了關鍵人員可存取所需的資訊，並且這些儀表板指出組織專注於成本優化的程度。可見的儀表板可讓您主動推廣成功的成果，並在整個組織中加以實作。
建立日常工作或常規以使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 或任何其他儀表板 (例如 [Amazon Quick](https://aws.amazon.com/quicksight/) )，以查看成本並主動分析。在 AWS 帳戶層級、工作負載層級或特定 AWS 服務層級使用群組和篩選來分析 AWS 服務用量與成本，並驗證是否符合預期。使用每小時和資源層級精細度與標籤，來篩選及識別最高排名資源所產生的成本。您也可以使用 [成本智慧儀表板](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/)自行建置報告，這是一個 [Amazon Quick](https://aws.amazon.com/quicksight/) 解決方案，由 AWS 解決方案架構師所建置，會比較您的預算和實際的成本與用量。
**實作步驟**
+ **成本優化報告：** 設置定期週期來討論和分析工作負載的效率。使用建立的指標來報告所達到的指標和達到指標所需的成本。識別並修正任何負面趨勢，並識別要在整個組織中推廣的正面趨勢。報告應讓應用程式團隊和擁有者、財務和管理層的代表參與。
+ **針對成本與用量建立並啟用每日精細度 [AWS Budgets](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-daily-cost-and-usage-budgets/) ，以及時採取相關措施來防止任何潛在的成本超支： ** AWS Budgets 可讓您設定提醒通知，以隨時獲知是否有任何預算類型超出預先設定的閾值。AWS Budgets 的最佳運用方式是將您預期的成本與用量設為限制，如此即可將任何超過預算的部分視為超支。
+ **建立 AWS Cost Anomaly Detection 作為成本監視器： ** [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 會使用進階機器學習技術來識別異常支出與根本原因，以便您迅速做出因應。它可讓您設定成本監視器以定義您要評估的支出區段 (例如個別 AWS 服務、成員帳戶、成本分配標籤和成本類別)，並且可讓您設定接收提醒通知的時間、位置和方式。每個監視器可以為企業擁有者和技術團隊連結多個提醒訂閱，包括每個訂閱的名稱、成本影響閾值和提醒頻率 (個別提醒、每日摘要、每週摘要)。
+ **使用 AWS Cost Explorer，或整合您的 AWS Cost and Usage Report (CUR) 資料與 Amazon Quick 儀表板，將組織的成本視覺化：** AWS Cost Explorer 有簡單易用的介面可讓您視覺化、了解和管理您在一段時間內的 AWS 成本和用量。AWS Well-Architected [成本智慧儀表板](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) 是一個可自訂且可供存取的儀表板，可協助您建立自身成本管理和優化工具的基礎。
## 資源
**相關文件：**
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ [每日成本與用量預算](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-daily-cost-and-usage-budgets/)
+ [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)
**相關範例：**
+ [Well-Architected 實驗室：視覺化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html)
+ [Well-Architected 實驗室：進階視覺化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html)
+ [Well-Architected 實驗室：雲端智慧儀表板](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/)
+ [Well-Architected 實驗室：成本視覺化](https://wellarchitectedlabs.com/cost/200_labs/200_5_cost_visualization/)
+ [Slack 的 AWS Cost Anomaly Detection 提醒](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/)
# COST01-BP07 及時了解新的服務版本
定期諮詢專家或 AWS 合作夥伴，以了解哪些服務和功能可以降低成本。檢閱 AWS 部落格和其他資訊來源。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
AWS 持續加入新功能，讓您能夠利用最新技術加快試驗及創新速度。您可以實作新的 AWS 服務和功能，以提升工作負載的成本效益。定期檢閱 [AWS 成本管理](https://aws.amazon.com/aws-cost-management/)、 [AWS 新聞部落格](https://aws.amazon.com/blogs/aws/)、 [AWS 成本管理部落格](https://aws.amazon.com/blogs/aws-cloud-financial-management/)和 [AWS 最新消息](https://aws.amazon.com/new/) 以取得新的服務和功能版本的相關資訊。最新消息貼文會在所有 AWS 服務、功能和區域擴充公告發行時提供其簡短概要。
**實作步驟**
+ **訂閱部落格：** 前往 AWS 部落格頁面，訂閱最新消息部落格和其他相關部落格。您可以用電子郵件地址 [在通訊偏好設定](https://pages.awscloud.com/communication-preferences?languages=english) 頁面進行註冊。
+ **訂閱 AWS 新聞： **定期檢閱 [AWS 新聞部落格](https://aws.amazon.com/blogs/aws/) 和 [AWS 最新消息](https://aws.amazon.com/new/) 以取得新的服務和功能版本的相關資訊。訂閱 RSS 摘要，或透過您的電子郵件關注公告和版本。
+ **關注 AWS 降價：** 我們所有服務的定期價降，已成為 AWS 將來自於規模的經濟效益傳遞給客戶的標準機制。截至 2022 年 4 月為止，AWS 自 2006 年推出後已降價 115 次。如果您有任何商業決策因價格考量而未定，您可以在降價和新的服務整合之後再次加以審查。您可以了解先前執行過的降價，包括 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體，請前往 [AWS 新聞部落格的降價類別](https://aws.amazon.com/blogs/aws/category/price-reduction/)。
+ ** AWS 活動和會議： **參加您當地的 AWS 高峰會，以及與您當地區域的其他組織一同參加當地會議。如果您無法親自與會，請試著參加線上活動，聽聽 AWS 專家和其他客戶的商業案例。
+ ** 與您的客戶團隊會面： **與您的客戶團隊排定一個定期規律，與他們會面並討論產業趨勢和 AWS 服務。與您的客戶經理、解決方案架構師和支援團隊進行討論。
## 資源
**相關文件：**
+ [AWS 成本管理](https://aws.amazon.com/aws-cost-management/)
+ [AWS 最新消息](https://aws.amazon.com/new/)
+ [AWS 新聞部落格](https://aws.amazon.com/blogs/aws/)
**相關範例：**
+ [Amazon EC2 – 15 年的 IT 成本優化和節省](https://aws.amazon.com/blogs/aws-cost-management/amazon-ec2-15th-years-of-optimizing-and-saving-your-it-costs/)
+ [AWS 新聞部落格 - 降價](https://aws.amazon.com/blogs/aws/category/price-reduction/)
# COST01-BP08 建立成本感知文化
在您的組織中實作變更或計畫，以建立成本感知文化。建議從較小的計劃開始，然後隨著能力的增強和使用雲端的增加，再實作更大和更廣泛的計劃。
**未建立此最佳實務時的曝險等級：** 低
## 實作指引
成本感知文化可讓您透過在組織中以系統和分散的方式執行最佳實務，擴展成本優化和雲端財務管理 (財務營運、智慧雲端中心、雲端維運團隊等等)。相較於嚴格的由上而下、集中式方法，成本感知可讓您輕鬆地在整個組織建立高水準的能力。
建立雲端運算的成本感知 (尤其是對於雲端運算的主要成本動因)，可讓團隊了解成本方面的任何變更預期會產生的結果。存取雲端環境的團隊應了解定價模型，以及傳統內部部署資料中心與雲端運算之間的差異。
成本感知文化的主要優點是，技術團隊可主動且持續地優化成本 (例如，在建構新的工作負載，或對現有的工作負載進行變更時，會將其視為非功能性需求)，而不是等到必要時才被動執行成本優化。
文化中的小幅變化可以對目前和未來工作負載的效率產生很大的影響。這些範例包括：
+ 在工程團隊中提供可見性和建立感知以了解其工作性質，及其對成本方面有何影響。
+ 在您的組織中對成本和用量進行遊戲化。這可以透過公開可見的儀表板，或比較各團隊的標準化成本和用量報告來實現 (例如，每一工作負載的成本和每一交易的成本)。
+ 認識成本效益。公開或私下獎勵自願或未經要求完成的成本優化成就，並從錯誤中學習，以避免重蹈覆轍。
+ 建立由上而下的組織要求，讓工作負載依預先定義的預算執行。
+ 探究企業的變更需求，以及要求的變更對於基礎架構或工作負載組態的成本影響，以確保您只須就需要的部分付費。
+ 確定變更的規劃師了解預期的變更有何成本影響，且已經過利害關係人的確認，應以符合成本效益的方式提供商業成果。
**實作步驟**
+ **向技術團隊報告雲端成本：** 增強成本感知，並且為財務與業務利害關係人建立效率 KPI。
+ **通知利害關係人或團隊成員有已規劃的變更：** 在每週變更會議期間建立議程項目來討論已規劃的變更，以及對於工作負載的成本效益影響。
+ ** 與您的客戶團隊會面： **安排與客戶團隊的定期會面，與他們討論產業趨勢和 AWS 服務。與您的客戶經理、架構師和支援團隊進行討論。
+ **分享成功案例：** 分享關於任何工作負載、AWS 帳戶 或組織降低成本的成功案例，以建立成本優化方面的正面態度與鼓勵。
+ **培訓： **確定技術團隊或其成員已受過 AWS 雲端 資源成本感知的相關培訓。
+ ** AWS 活動和會議： **參加當地的 AWS 高峰會，以及與您當地區域的其他組織一同參加當地會議。
+ **訂閱部落格：** 前往 AWS 部落格頁面，訂閱 [最新消息部落格](https://aws.amazon.com/new/) 和其他相關部落格，以關注 AWS 所分享的新版本、實作、範例和變更。
## 資源
**相關文件：**
+ [AWS 部落格](https://aws.amazon.com/blogs/)
+ [AWS 成本管理](https://aws.amazon.com/blogs/aws-cost-management/)
+ [AWS 新聞部落格](https://aws.amazon.com/blogs/aws/)
**相關範例：**
+ [AWS 雲端財務管理](https://aws.amazon.com/blogs/aws-cloud-financial-management/)
+ [AWS Well-Architected 實驗室：雲端財務管理](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/1_cloud_financial_management/)
# COST01-BP09 量化成本最佳化所帶來的商業價值
量化成本優化所帶來的商業價值，可讓您了解給組織提供的全部效益。由於成本優化是一項必要的投資，因此量化商業價值可讓您向利害關係人解釋投資報酬率。量化商業價值有助於您在未來就成本優化投資獲得利害關係人更多的支持，並提供一個框架來衡量組織成本優化活動的成果。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
量化商業價值意味著衡量企業從採取的行動和決策中所獲得的好處。商業價值可以是有形的 (例如費用降低或利潤增加)，也可以是無形的 (例如品牌信譽提升或客戶滿意度變高)。
量化成本最佳化所帶來的商業價值意味著判斷您在更有效率地支出成本上所做的努力，可以讓您獲得多少價值或收益。例如，如果公司支出 100,000 美元在 AWS 上部署工作負載，然後將其最佳化，而新成本變成只有 80,000 美元，且並未犧牲品質或輸出。在這種情況下，成本最佳化所帶來的量化商業價值會是節省了 20,000 美元。不過，除了節省成本外，公司還可以從更快的交貨時間、提高的客戶滿意度或成本最佳化努力所產生的其他指標等方面來量化價值。利害關係人需要就成本最佳化的潛在價值、工作負載的最佳化成本和回報價值做出決策。
除了報告成本優化所帶來的節省之外，建議您量化提供的額外價值。成本優化效益通常根據每個業務成果所較低的成本進行量化。例如，您可以在購買 Savings Plans (可降低成本和維持工作負載輸出水準) 時量化 Amazon Elastic Compute Cloud (Amazon EC2) 所節省的成本。您可以在閒置的 Amazon EC2 執行個體遭到移除或未連接的 Amazon Elastic Block Store (Amazon EBS) 磁碟區遭到刪除時，量化所降低的 AWS 支出成本。
不過，成本優化的消費絕非僅限於成本降低或避免。考慮擷取額外資料，以測量效率改善和商業價值。
### 實作步驟
+ **評估商業效益：**這是分析和調整 AWS 雲端 成本的程序，這個程序所採用的方法會將每一美元支出所能獲得的效益最大化。請不要不顧商業價值，一昧地降低成本，而是要考慮成本最佳化所帶來的商業效益和投資回報，這樣才有可能從支出的成本中獲得更多價值。重點在於聰明地支出，以及在能產生最佳回報的領域進行投資和支出。
+ **分析預測的 AWS 成本：**預測可讓財務利害關係人與其他內部和外部組織利害關係人設定期望，並可改善組織的財務可預測性。[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 可以用來預測您的成本和用量。
## 資源
**相關文件：**
+ [AWS 雲端 成本 ](https://aws.amazon.com/economics/)
+ [AWS 部落格](https://aws.amazon.com/blogs/)
+ [AWS 成本管理](https://aws.amazon.com/blogs/aws-cost-management/)
+ [AWS 新聞部落格](https://aws.amazon.com/blogs/aws/)
+ [Well-Architected 可靠性支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
**相關影片：**
+ [ 在 AWS 上充分發揮 Windows 的商業價值 ](https://aws.amazon.com/windows/tco/)
**相關範例：**
+ [測量並最大化 Customer 360 的業務價值](https://pages.awscloud.com/measuring-and-maximizing-the-business-value-of-customer-360-062022.html)
+ [ 採用 Amazon Web Services 受管資料庫所帶來的商業價值 ](https://pages.awscloud.com/rs/112-TZM-766/images/The Business Value of Adopting Amazon Web Services Managed Databases.pdf)
+ [ 獨立軟體開發廠商的 Amazon Web Services 商業價值 ](https://pages.awscloud.com/rs/112-TZM-766/images/The Business Value of Amazon Web Services %28AWS%29 for Independent Software Vendors %28ISVs%29.pdf)
+ [ 雲端現代化的商業價值 ](https://pages.awscloud.com/aws-cfm-known-business-value-of-cloud-modernization-2022.html)
+ [ 遷移到 Amazon Web Services 的商業價值 ](https://pages.awscloud.com/global-in-gc-500-business-value-of-migration-whitepaper-learn.html)
# 支出和用量感知
**Topics**
+ [COST 2.如何管控用量？](cost-02.md)
+ [COST 3.如何監控您的成本和用量？](cost-03.md)
+ [COST 4.如何進行資源除役？](cost-04.md)
# COST 2.如何管控用量？
制訂政策和機制以確認產生合理的成本，同時達成目標。您可以運用相互制衡的方法，在不超支的情況下進行創新。
**Topics**
+ [COST02-BP01 根據貴組織的需求制定政策](cost_govern_usage_policies.md)
+ [COST02-BP02 實作總目標和具體目標](cost_govern_usage_goal_target.md)
+ [COST02-BP03 實作帳戶結構](cost_govern_usage_account_structure.md)
+ [COST02-BP04 實作群組和角色](cost_govern_usage_groups_roles.md)
+ [COST02-BP05 實作成本控制措施](cost_govern_usage_controls.md)
+ [COST02-BP06 追蹤專案生命週期](cost_govern_usage_track_lifecycle.md)
# COST02-BP01 根據貴組織的需求制定政策
制定定義組織如何管理資源的政策，並定期加以檢查。政策應涵蓋資源和工作負載的成本面向，包括資源生命週期中的建立、修改和除役。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
了解組織的成本和動因對於有效管理成本和用量，以及識別降低成本的機會至關重要。組織通常會營運由多個團隊執行的多個工作負載。這些團隊可能分屬不同組織單位，各有本身的收入流。將資源成本歸因至工作負載、個別組織或產品擁有者的能力，能夠帶動高效使用的行為模式，並且有助於減少浪費。精確的成本和用量監控可協助您了解工作負載的優化程度，以及組織單位和產品的獲利程度。這項知識可讓您更明智地決定應將資源分配到組織內的何處。讓組織內所有層級建立用量意識，是推動變革的關鍵，因為用量的變革會帶來成本變革。請考慮採行多面向的方法以了解您的用量和開支。
執行管控的第一步是使用組織的要求來制定雲端使用政策。這些政策定義您的組織如何使用雲端以及如何管理資源。政策應涵蓋資源和工作負載的成本或用量的各面向，包括在資源生命週期中資源的建立、修改和除役。確認已遵循政策和程序，並已實作雲端環境中的任何變更。在 IT 變更管理會議中提出問題，以釐清計畫性變更對成本的影響 (無論是增加還是減少)、商務理由和預期成果。
政策應該簡單易懂，以便有效地在整個組織中實作。政策還需要易於遵循和解釋 (以方便使用) 並且明確 (團隊間不會產生誤解)。此外，必須定期加以檢查 (如我們的機制)，並隨著客戶業務狀況或優先權的變化 (政策會因而過時) 進行更新。
從廣泛的高階政策開始，例如應使用哪個地理區域，或一天中應該執行資源的時間。逐步為各組織單位和工作負載優化政策。常用政策包括可以使用哪些服務和功能 (例如，測試和開發環境中較低效能的儲存體)、不同群組可以使用哪些類型的資源 (例如，開發帳戶中最大的資源大小是中型)，以及這些資源的使用期間長短 (暫時、短期還是一段特定期間)。
**政策範例**
以下是範例政策，可供您檢閱以建立自己的雲端管控政策，其重點為成本優化。確實根據組織的要求和利害關係人的請求來調整政策。
+ **政策名稱：** 定義明確的政策名稱，例如「資源優化」和「成本降低」政策。
+ **目的：** 解釋為何應使用此政策，以及預期的結果為何。此政策的目標是要確認部署和執行所需的工作負載以符合業務需求時的最低成本。
+ **範圍：** 明確定義誰應使用此政策，以及何時應使用此政策，例如 DevOps X Team 在 X 環境 (生產或非生產) 將此政策用於美國東部客戶。
**政策聲明**
1. 根據工作負載的環境和業務要求 (開發、使用者接受度測試、生產前或生產)，選取美國東部 1 或多個美國東部區域。
1. 將 Amazon EC2 和 Amazon RDS 執行個體排程在早上六點到晚上八點之間執行 (東部標準時間 (EST))。
1. 在八小時後停止所有未使用的 Amazon EC2 執行個體，並在閒置 24 小時後停止未使用的 Amazon RDS 執行個體
1. 在非生產環境中閒置 24 小時後，終止所有未使用的 Amazon EC2 執行個體。提醒 Amazon EC2 執行個體擁有者 (根據標籤) 檢閱其生產環境中已停止的 Amazon EC2 執行個體，並通知他們如果 Amazon EC2 執行個體未使用，將在 72 小時內終止。
1. 使用一般執行個體系列和大小 (例如 m5.large)，然後根據 CPU 和記憶體使用率，使用 AWS Compute Optimizer 調整執行個體大小。
1. 使用自動擴展根據流量動態調整執行中的執行個體數量，以訂定優先順序。
1. 對非關鍵工作負載使用 Spot 執行個體。
1. 檢閱容量要求，以認可可預測工作負載的 Savings Plans 或預留執行個體，並通知雲端財務管理團隊。
1. 使用 Amazon S3 生命週期政策將不常存取的資料移至成本較低的儲存層。若未定義保留政策，請使用 Amazon S3 Intelligent Tiering 將物件自動移至封存層。
1. 使用 Amazon CloudWatch 監控資源使用率並設定警示以觸發擴展事件。
1. 針對每個 AWS 帳戶，使用 AWS Budgets 根據成本中心和業務單位設定帳戶的成本及用量預算。
1. 使用 AWS Budgets 設定帳戶的成本和用量預算，可協助您掌握支出並避免出現非預期的帳單，進而讓您更有效地控制成本。
**程序：** 提供實作此政策的詳細程序，或參閱說明如何實作每項政策聲明的其他文件。本節應提供執行政策要求的逐步指示。
若要實作此政策，您可以使用各種第三方工具或 AWS Config 規則來檢查是否符合政策聲明，並使用 AWS Lambda 函數觸發自動修復動作。您也可以使用 AWS Organizations 來強制執行政策。此外，您應定期檢閱資源用量，並視需要調整政策，以確認政策持續符合您的商業需求。
## 實作步驟
+ **與利害關係人會面：** 若要制定政策，請要求組織內的利害關係人 (雲端業務辦公室、工程師或執行政策的功能決策者) 指定其要求，並將其記錄下來。採取反覆的方法，從廣泛討論開始，然後在每個步驟持續細化至最小的單位。團隊成員包括對工作負載有直接關係的人員，例如組織單位或應用程式擁有者，以及支援群組，例如安全和財務團隊。
+ **獲取確認：** 確定團隊成員均同意誰可對 AWS 雲端 進行存取及部署的政策。請確定成員遵循組織的政策，並確認其資源建立符合議定的政策和程序。
+ **建立上線培訓課程：** 要求新進的組織成員完成上線培訓課程，以建立對成本的掌握度和組織要求。他們可以根據自身過往的經驗採行不同的政策，也可以完全不列入考量。
+ ** 定義工作負載的位置： **定義工作負載營運的位置，包括國家和國家中的區域。這項資訊用來對應至 AWS 區域 和可用區域。
+ ** 定義並分組服務和資源： **定義工作負載所需的服務。針對每項服務，指定所需的類型、大小和資源數量。依職能定義資源群組，例如應用程式伺服器或資料庫儲存體。資源可屬於多個群組。
+ **依職能定義並分組使用者： **定義與工作負載互動的使用者，專注於使用者執行的操作以及他們如何使用工作負載，而不是專注於他們的身分或他們在組織中的位置。將類似的使用者或職能分組在一起。您可以使用 AWS 受管政策做為指南。
+ ** 定義動作：** 使用先前識別的位置、資源和使用者，定義每個項目在其生命週期內 (開發、營運和除役) 達成工作負載結果所需的動作。根據每個位置中的群組 (不是群組中的個別元素) 來識別動作。從廣泛地讀取或寫入開始，然後縮小精細至每項服務的特定動作。
+ ** 定義審查期間：** 工作負載和組織要求會隨著時間變更。定義工作負載審查排程，以確保其與組織優先事項保持一致。
+ **記錄政策： **確認組織可視需要存取已定義的政策。這些政策用於實作、維護和稽核環境的存取權。
## 資源
**相關文件：**
+ [雲端中的變更管理](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-cloud.html)
+ [適用於各工作職能的 AWS 受管政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
+ [AWS 多帳戶帳單策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [AWS 服務的動作、資源和條件金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html)
+ [AWS 管理與管控](https://aws.amazon.com/products/management-and-governance/)
+ [使用 IAM 政策控制對 AWS 區域 的存取](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [全球基礎架構區域和可用區域](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)
**相關影片：**
+ [大規模的 AWS 管理與管控](https://www.youtube.com/watch?v=xdJSUnPcPPI)
**相關範例：**
+ [VMware - 什麼是雲端政策？](https://blogs.vmware.com/cloudhealth/what-are-cloud-policies/)
# COST02-BP02 實作總目標和具體目標
為您的工作負載實作成本與用量的總目標和具體目標。總目標可為您的組織提供預期成果的方向，具體目標則可提供要為您的工作負載達成的特定可測量成果。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
為您的組織制定成本與用量總目標和具體目標。作為 AWS 上成長中的組織，設定和追蹤成本優化的總目標是非常重要的。這些總目標或 [關鍵績效指標 (KPI)](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metric-the-touchstone-of-your-it-planning-and-evaluation/) 可包含隨需支出的百分比，或是否採用特定優化服務 (例如 AWS Graviton 執行個體或 gp3 EBS 磁碟區類型) 等等。設定可衡量和可實現的總目標有助於繼續衡量效率的改善情況，這對於持續性的業務營運非常重要。總目標可為您的組織提供預期結果的指引和方向，具體目標是要實現的具體可衡量成果。簡言之，總目標是您的努力方向，具體目標則表示該方向有多遠，以及多久可以達成總目標；其原則為具體 (Specific)、可測量 (Measurable)、可指派 (Assignable)、務實 (Realistic) 和及時 (Timely)，簡稱 SMART。舉例來說，平台用量大幅增加，而成本僅稍微增加 (非線性)，即為總目標。另外，平台用量增加 20%，成本增加少於 5%，則是具體目標之一。另一個常見的總目標，是工作負載的效率每隔六個月就必須有所成長。相關的具體目標是每個業務指標的成本每六個月需要減少百分之五。
成本優化的總目標是提高工作負載效率，也就是隨著時間降低工作負載的每個業務成果成本。建議為所有工作負載實作這個總目標，並設定具體目標，例如每六個月至一年將效率提高百分之五。這可透過建立成本優化的能力以及發佈新的服務和功能，在雲端中達成。
務必要能夠近乎即時地檢視 KPI 和相關節省機會，並追蹤一段時間內的進度。若要開始定義和追蹤 KPI 總目標，建議您使用 [雲端智慧儀表板 (CID) 架構中的 KPI 儀表板](https://aws.amazon.com/blogs/mt/visualize-and-gain-insights-into-your-aws-cost-and-usage-with-cloud-intelligence-dashboards-using-amazon-quicksight/)。根據來自 AWS Cost and Usage Report 的資料，KPI 儀表板會提供一系列建議的成本優化 KPI，讓您能夠設定自訂總目標以及追蹤一段時間內的進度。
如果您有其他解決方案可以設定和追蹤 KPI 總目標，請確定組織中的所有雲端財務管理利害關係人都採用該解決方案。
## 實作步驟
+ **定義預期的用量等級： **首先，請專注於用量等級。與應用程式擁有者、行銷團隊和更大的業務團隊互動，以了解工作負載的預期用量等級。客戶需求如何隨著時間而變更，以及是否會因季節性增加或行銷活動而有所變更？
+ ** 定義工作負載資源與成本： **定義用量等級後，量化達成這些用量等級所需的工作負載資源變更。您可能需要為工作負載元件增加資源的大小或數量、增加資料傳輸，或將工作負載元件變更為特定等級的不同服務。指定這些要點的成本為何，以及當用量發生變化時，成本會有什麼變化。
+ **定義業務總目標： **從預期用量和成本變更中取得輸出，將此項目與預期的技術變更或任何您正在執行的計畫結合，並制定工作負載的總目標。總目標必須涵蓋用量、成本和兩者之間的關係。總目標必須簡單具體，以協助大家了解企業預期的成果 (例如，確實將未使用的資源控制在特定成本水位以下)。您無須為每個未使用的資源類型定義總目標，或是為總目標和具體目標定義造成損失的成本。如果預期有成本變更但用量不變，請確認已有組織計畫 (例如培訓和教育等能力打造計畫)。
+ **定義具體目標： **對定義的每個總目標，指定可測量的具體目標。如果總目標是要提高工作負載的效率，具體目標將會量化改善的程度 (通常是所有經費所獲得的業務輸出)，及其達成時間。例如，如果您的總目標設定為盡可能降低因過度佈建而造成的浪費，則具體目標可設為因第一層生產工作負載的運算過度佈建而造成的浪費不應超過該層運算成本的 10%，且因第二層生產工作負載的運算過度佈建而造成的浪費不應超過該層運算成本的 5%。
## 資源
**相關文件：**
+ [適用於各工作職能的 AWS 受管政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
+ [適用於 AWS Control Tower 登陸區域的 AWS 多帳戶策略](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)
+ [使用 IAM 政策控制對 AWS 區域 的存取](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [ SMART 總目標 ](https://en.wikipedia.org/wiki/SMART_criteria)
**相關影片：**
+ [ Well-Architected 實驗室：總目標和具體目標 (Level 100) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/)
**相關範例：**
+ [ Well-Architected 實驗室：除役資源 (總目標和具體目標) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/)
+ [ Well-Architected 實驗室：資源類型、大小和數目 (總目標和具體目標) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/6_resource_type_size_number/)
# COST02-BP03 實作帳戶結構
實作與您的組織對應的帳戶結構。這有助於在整個組織中分配和管理成本。
**未建立此最佳實務時的風險暴露等級：**高
## 實作指引
AWS Organizations 可讓您建立多個 AWS 帳戶，當您在 AWS 上擴展工作負載時，這可協助您集中管控環境。您可以採用組織單位 (OU) 結構來為 AWS 帳戶 進行分組，再於每個組織單位下建立多個 AWS 帳戶，藉此塑造組織階層的模型。若要建立帳戶結構，您必須先決定要以哪個 AWS 帳戶 作為管理帳戶。之後，便能建立新的 AWS 帳戶，或根據您指定的帳戶結構將現有帳戶選為成員帳戶，相關做法請遵循[管理帳戶最佳實務](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html)和[成員帳戶最佳實務](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)。
無論您的組織規模或用量為何，都建議您一律要有至少一個管理帳戶，以及一個與管理帳戶連結的成員帳戶。所有工作負載資源都只應位於成員帳戶內，請勿在管理帳戶內建立任何資源。關於應該擁有多少個 AWS 帳戶，並沒有一體適用的答案。請評估您目前和未來的運作與成本模式，確保 AWS 帳戶 的結構呼應組織的目標。有些公司基於業務原因建立多個 AWS 帳戶，例如：
+ 組織單位、成本中心或特定工作負載之間需要行政管理或會計年度和帳單上的區隔。
+ AWS 服務限制是依照特定工作負載區分所設定。
+ 工作負載和資源之間需要區隔和隔離。
在 [AWS Organizations](https://aws.amazon.com/organizations/) 內，[合併帳單](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)會在一或多個成員帳戶與管理帳戶之間建立結構。成員帳戶可讓您依群組隔離和區分成本和用量。常見實務是各組織單位分別有成員帳戶 (例如財務、行銷和銷售)，或是各個環境生命週期分立 (例如開發、測試和生產)，或是各工作負載分立 (工作負載 a、b 和 c)，再使用合併帳單彙總這些連結帳戶。
合併帳單可讓您將多個 AWS 帳戶 的款項合併至單一管理帳戶之下，同時仍為各連結帳戶的活動提供可見度。由於成本和用量的在管理帳戶中彙總，這可讓您獲得最大的服務容量折扣以及最大的使用承諾折扣 (Savings Plans 和預留執行個體)，以享受最高折扣。
下圖顯示如何使用 AWS Organizations 與組織單位 (OU) 來將多個帳戶分組，並將多個 AWS 帳戶 放到每個 OU 底下。建議您使用 OU 來處理各種使用案例和工作負載，以便提供用於整理帳戶的模式。
![\[Tree diagram showing how to group multiple accounts under organizational units.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/aws-organizations-ou-grouping.png)
[AWS Control Tower](https://aws.amazon.com/controltower/) 可以快速建立和設定多個 AWS 帳戶，確保管控符合組織的要求。
**實作步驟**
+ **定義分隔要求：**分隔要求是多個因素的組合，包括安全性、可靠性和財務結構。依序處理每個因素，並指定工作負載或工作負載環境是否應與其他工作負載分開。為了安全，我們必須遵守存取和資料要求。為求可靠，我們必須有所限制，以免環境和工作負載影響其他資源。請定期檢閱 Well-Architected 架構的安全性和可靠性支柱，並遵循其中所提供的最佳實務。財務結構會建立嚴格的財務分隔 (不同的成本中心、工作負載擁有權和責任)。常見的分隔範例是生產和測試工作負載會在不同的帳戶開始執行，或使用單獨的帳戶，以便將發票和帳單資料提供給組織內的個別業務單位或部門，或是擁有帳戶的利害關係人。
+ **定義分組要求：**分組要求不會覆寫分隔要求，而是用來協助管理。將不需要分隔的類似環境或工作負載分成同一組。例如，將來自一或多個工作負載的多個測試或開發環境分組在一起。
+ **定義帳戶結構：**使用這些分隔和群組，為每個群組指定一個帳戶，並維持分隔要求。這些帳戶是您的成員帳戶或連結帳戶。透過將這些成員帳戶分組到單一管理帳戶或付款人帳戶下，您可以結合用量，以讓所有帳戶獲得更多數量折扣，而為所有帳戶提供單一帳單。您可以分隔帳單資料，以便在每個成員帳戶中檢視單獨的帳單資料。如果不允許透過任何其他帳戶查看某個成員帳戶中的用量或帳單資料，或是需要與 AWS 分開的帳單，請定義多個管理帳戶或付款人帳戶。在這種情況下，每個成員帳戶都有自己的管理帳戶或付款人帳戶。資源應一律放在成員或連結帳戶中。管理帳戶或付款人帳戶只能用於管理。
## 資源
**相關文件：**
+ [使用成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [適用於各工作職能的 AWS 受管政策](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html)
+ [AWS 多帳戶帳單策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [使用 IAM 政策控制對 AWS 區域 的存取](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [AWS Control Tower](https://aws.amazon.com/controltower/)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [管理帳戶](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html)和[成員帳戶](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)的最佳實務
+ [使用多個帳戶整理您的 AWS 環境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [開啟共用的預留執行個體和 Savings Plans 折扣](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html)
+ [合併帳單](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)
+ [合併帳單](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)
**相關範例：**
+ [分割 CUR 和共用存取](https://wellarchitectedlabs.com/Cost/Cost_and_Usage_Analysis/300_Splitting_Sharing_CUR_Access/README.html)
**相關影片：**
+ [ 向您介紹 AWS Organizations](https://www.youtube.com/watch?v=T4NK8fv8YdI)
+ [ 設定會使用 AWS Organizations 最佳實務的多帳戶 AWS 環境 ](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)
**相關範例：**
+ [ Well-Architected 實驗室：建立 AWS 組織 (Level 100) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_1_aws_account_setup/2_account_structure/)
+ [ 分割 AWS Cost and Usage Report 和共用存取 ](https://wellarchitectedlabs.com/cost/300_labs/300_splitting_sharing_cur_access/)
+ [為電信公司定義 AWS 多帳戶策略](https://aws.amazon.com/blogs/industries/defining-an-aws-multi-account-strategy-for-telecommunications-companies/)
+ [將 AWS 帳戶 最佳化的最佳實務](https://aws.amazon.com/blogs/architecture/new-whitepaper-provides-best-practices-for-optimizing-aws-accounts/)
+ [AWS Organizations 的組織單位最佳實務](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog)
# COST02-BP04 實作群組和角色
實作符合您政策的群組和角色，並控制哪些人員可以建立、修改或除役每個群組中的執行個體和資源。例如，實作開發、測試和生產群組。這適用於 AWS 服務和第三方解決方案。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
使用者角色和群組是設計和實作安全高效系統的基礎建置組塊。角色和群組可協助組織在控制需求與靈活性和生產力的要求兩方面取得平衡，從而最終能支援組織目標和使用者需求。如 AWS Well Architected Framework 安全支柱的[身分和存取管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html)一節所建議，您需要有強大的身分管理和許可，以在合適條件下為合適的人員提供合適資源的存取權。使用者只會獲得要完成其任務所需的存取權。這可將未經授權存取或濫用的相關風險降至最低。
在制定政策後，您可以在組織內建立邏輯群組和使用者角色。這可讓您指派許可、控制使用情況，並協助實作強大的存取控制機制，防止有人未經授權存取敏感資訊。從簡要的人員分組開始。通常這與組織單位和工作角色 (例如 IT 部門的系統管理員、財務控制者或商業分析師) 相符。這些群組會將執行類似任務且需要類似存取權限的人員進行分類。角色定義群組必須執行的工作。管理群組和角色的許可會比管理個別使用者的許可容易。角色和群組能以一致且有系統的方式為所有使用者指派許可，以避免錯誤和不一致。
當使用者的角色變更時，管理員可以調整角色或群組層級的存取權，而不是重新設定個別使用者帳戶。例如，IT 的系統管理員需要建立所有資源的存取權限，但分析團隊成員只需要建立分析資源的權限。
### 實作步驟
+ ** 實作群組：**使用組織政策中定義的使用者群組，視需要實作對應的群組。如需關於使用者、群組和驗證的最佳實務，請參閱 AWS Well-Architected Framework 的[安全支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)。
+ **實作角色和政策：**使用組織政策中定義的動作，建立所需的角色和存取政策。如需關於角色和政策的最佳實務，請參閱 AWS Well-Architected Framework 的[安全支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)。
## 資源
**相關文件：**
+ [適用於各工作職能的 AWS 受管政策](https://docs.aws.amazon.com/iam/latest/UserGuide/access_policies_job-functions.html)
+ [AWS 多帳戶帳單策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [AWS Well-Architected Framework 安全支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
+ [AWS Identity and Access Management (IAM) ](https://aws.amazon.com/iam/)
+ [AWS Identity and Access Management 政策 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)
**相關影片：**
+ [為什麼要使用身分和存取管理 ](https://www.youtube.com/watch?v=SXSqhTn2DuE)
**相關範例：**
+ [Well-Architected 實驗室基本身分和存取](https://wellarchitectedlabs.com/Security/100_Basic_Identity_and_Access_Management_User_Group_Role/README.html)
+ [使用 IAM 政策控制對 AWS 區域 的存取](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [ 開始您的雲端財務管理之旅：雲端成本營運 ](https://aws.amazon.com/blogs/aws-cloud-financial-management/op-starting-your-cloud-financial-management-journey/)
# COST02-BP05 實作成本控制措施
根據組織政策以及定義的群組和角色實作控制措施。這些控制措施可證明成本的發生始終符合組織要求：例如，控制對區域或資源類型的存取。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
實作成本控制常見的第一步設定在發生偏離政策的成本或用量事件時發出通知。您可以快速採取動作，並驗證是否需要採取糾正措施，而不會限制或對工作負載或新的活動造成負面影響。在您了解工作負載和環境限制之後，即可施行管控。[AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 可讓您針對 AWS 的成本、用量和承諾折扣 (Savings Plans 和預留執行個體) 來設定通知和定義每月預算。您可以在彙總成本層級 (例如，所有成本) 或更精細的層級建立預算，其中只包含特定維度，例如連結的帳戶、服務、標籤或可用區域。
在透過 AWS Budgets 設定預算限制後，請使用 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 來降低非預期的成本。AWS Cost Anomaly Detection 是成本管理服務，可使用機器學習來持續監控成本和用量，以偵測不尋常的支出。其可協助您識別異常支出與根本原因，以便您迅速因應。請先在 AWS Cost Anomaly Detection 中建立成本監視器，然後設定美元閾值以選擇提醒偏好 (例如，針對影響金額大於 1,000 美元的異常設定提醒)。收到提醒後，便能分析異常背後的根本原因，以及其對成本的影響。您也可以在 AWS Cost Explorer 中監控和執行您自己的異常分析。
透過 [AWS Identity and Access Management](https://aws.amazon.com/iam/) 和 [AWS Organizations 服務控制政策 (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html) 在 AWS 中施行管控。IAM 可讓您安全地管理對 AWS 服務和資源的存取。使用 IAM，您可以控制誰可以建立或管理 AWS 資源、可建立的資源類型以及建立資源的位置。這可以最大程度地降低在所定義的政策外建立資源的可能性。使用先前建立的角色和群組，並指派 [IAM 政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)以執行正確的用量。SCP 可集中控制組織中所有帳戶的最大可用許可，讓您的帳戶符合您的存取控制指導方針。SCP 只能在啟用所有功能的組織中使用，而且您可以設定 SCP， 為成員帳戶設定預設拒絕或允許的動作。如需實作存取權限管理的詳細資訊，請參閱 [Well-Architected 安全性支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)。
亦可透過管理 [AWS 服務配額](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)來實作管控。藉由確保服務配額設定為冗餘最低並且正確維護，可盡量避免建立超出組織要求的資源。為達成此目的，您必須了解要求的變更速度能有多快、了解進行中的專案 (包括資源的建立與除役兩者) 並將變更配額的實作速度能有多快列入作為考量因素。[服務配額](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)可在需要時用來增加您的配額。
**實作步驟**
+ **實作支出通知：**使用您定義的組織政策，建立 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 以在支出超出您的政策要求時發出通知。設定多個成本預算 (每個帳戶一個)，各帳戶會通知您整體帳戶支出。請針對帳戶中的較小單位，為每個帳戶設定額外的成本預算。這些單位會根據您的帳戶結構而有所不同。一些常見的範例是 AWS 區域、工作負載 (使用標籤) 或 AWS 服務。請將電子郵件分發清單設定為通知收件人，而非個人的電子郵件帳戶。您可以設定超過數量時的實際預算，或使用預測預算來通知預測用量。您也可以預先設定 AWS 預算操作，以實施特定的 IAM 或 SCP 政策，或停止目標 Amazon EC2 或 Amazon RDS 執行個體。預算操作可以自動執行，也可以要求工作流程核准。
+ **實作異常支出通知：**使用 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 可降低組織中的意外成本，並分析潛在異常支出的根本原因。在建立成本監視器以識別指定精細度的不尋常支出，並在 AWS Cost Anomaly Detection 中設定通知後，其便會在偵測到不尋常支出時向您發出提醒。這可讓您分析異常背後的根本原因，並了解其對成本的影響。在設定 AWS Cost Anomaly Detection 時使用 AWS Cost Categories，可識別哪個專案團隊或業務單位團隊能夠分析非預期成本的根本原因，並及時採取必要動作。
+ **實作用量控制措施：**使用您定義的組織政策，實作 IAM 政策和角色來指定使用者可以執行的動作，以及他們無法執行的動作。一項 AWS 政策中可包含多項組織政策。使用與您定義政策相同的方式，一開始廣泛定義，然後在每個步驟中套用更精細的控制措施。服務限制也能有效控制用量。在您所有帳戶中實作正確的服務限制。
## 資源
**相關文件：**
+ [適用於各工作職能的 AWS 受管政策](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html)
+ [AWS 多帳戶帳單策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [使用 IAM 政策控制對 AWS 區域 的存取](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)
+ [控制您的 AWS 成本](https://aws.amazon.com/getting-started/hands-on/control-your-costs-free-tier-budgets/)
**相關影片：**
+ [如何使用 AWS Budgets 追蹤我的支出和用量](https://www.youtube.com/watch?v=Ris23gKc7s0)
**相關範例：**
+ [範例 IAM 存取管理政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html)
+ [範例服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
+ [AWS 預算操作](https://aws.amazon.com/blogs/aws-cloud-financial-management/get-started-with-aws-budgets-actions/)
+ [建立 IAM 政策以使用標籤控制 Amazon EC2 資源的存取](https://aws.amazon.com/premiumsupport/knowledge-center/iam-ec2-resource-tags/)
+ [限制只有特定 Amazon EC2 資源能夠存取 IAM 身分](https://aws.amazon.com/premiumsupport/knowledge-center/restrict-ec2-iam/)
+ [建立 IAM 政策以便依系列限制 Amazon EC2 用量](https://www.wellarchitectedlabs.com/cost/200_labs/200_2_cost_and_usage_governance/3_ec2_restrict_family/)
+ [Well-Architected 實驗室：成本與用量管控 (Level 100)](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html)
+ [Well-Architected 實驗室：成本與用量管控 (Level 200)](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_2_Cost_and_Usage_Governance/README.html)
+ [使用 Amazon Q Developer in chat applications 來針對 Cost Anomaly Detection 進行 Slack 整合](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/)
# COST02-BP06 追蹤專案生命週期
追蹤、測量和稽核專案、團隊和環境的生命週期，以避免使用不必要的資源並節省成本。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
有效地追蹤專案生命週期可讓組織透過提升資源、時間和品質的規劃、管理與最佳化，而對成本有更好的控制能力。透過追蹤所獲得的見解十分寶貴，可讓您做出有助於專案成本效益和整體成功率的明智決策。
追蹤工作負載的整個生命週期可協助您了解何時不再需要工作負載或工作負載元件。現有的工作負載和元件可能看似有在使用，但當 AWS 發行新的服務或功能時，其可能會除役，也可能會獲得採用。請檢查之前的工作負載階段。工作負載進入生產環境後，之前的環境可能會停用或大幅降低容量，直到再次需要這些環境為止。
AWS 提供多種管理和管控服務，您可以用於實體生命週期追蹤。您可以使用 [AWS Config](https://aws.amazon.com/config/) 或 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 來提供 AWS 資源和組態的詳細目錄。建議與您現行的專案或資產管理系統整合，與持續追蹤您的組織進行中的專案和產品。將您目前的系統與 AWS 提供的一組豐富的活動與指標合併，就能供您檢視重要的生命週期活動，並積極管理資源，以降低不必要的成本。
與[應用程式生命週期管理 (ALM)](https://aws.amazon.com/what-is/application-lifecycle-management/) 類似，追蹤專案生命週期應該會涉及多個流程、工具和團隊共同合作，例如設計與開發、測試、生產、支援和工作負載備援。
透過仔細監控專案生命週期的每個階段，組織可以獲得重要的見解和增強的控制力，從而能成功地規劃、實作和完成專案。這種仔細的監督會驗證專案不僅符合品質標準，而且會準時地在預算內交付，從而提高整體成本效率。
如需實作實體生命週期追蹤的詳細資訊，請參閱 [AWS Well-Architected 卓越營運支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)。
### 實作步驟
+ **建立專案生命週期監控流程：**[雲端卓越中心團隊](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_cloud_financial_management_function.html)必須建立專案生命週期監控流程。建立結構化與系統化的方法來監控工作負載，以改善專案的控制、可見性和效能。讓監控流程透明、協作並專注於持續改進，以最大程度地提高其有效性和價值。
+ **執行工作負載審查：**根據組織政策的定義，設定定期規律以稽核現有專案並執行工作負載審查。在稽核上付出的工作量應與組織的大致風險、價值或成本成正比。要納入稽核的關鍵領域包括事件或中斷給組織帶來的風險、對組織的價值或貢獻 (以收入或品牌聲譽來衡量)、工作負載成本 (以資源總成本和營運成本來衡量)，以及工作負載用量 (以每單位時間的組織結果數量來衡量)。如果這些領域在生命週期內發生變化，則需要調整工作負載，例如完整或部分除役。
## 資源
**相關文件：**
+ [ 對 AWS 進行標記的指引 ](https://aws.amazon.com/solutions/guidance/tagging-on-aws/)
+ [ 什麼是 ALM (應用程式生命週期管理)？](https://aws.amazon.com/what-is/application-lifecycle-management/)
+ [適用於各工作職能的 AWS 受管政策](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html)
**相關範例：**
+ [使用 IAM 政策控制對 AWS 區域 的存取](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
**相關工具：**
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
# COST 3.如何監控您的成本和用量？
制訂政策和程序以監控並適當分配成本。這樣能夠讓您衡量並改善此工作負載的成本效益。
**Topics**
+ [COST03-BP01 設定詳細資訊來源](cost_monitor_usage_detailed_source.md)
+ [COST03-BP02 將組織資訊新增至成本與用量](cost_monitor_usage_org_information.md)
+ [COST03-BP03 識別成本歸因類別](cost_monitor_usage_define_attribution.md)
+ [COST03-BP04 建立組織指標](cost_monitor_usage_define_kpi.md)
+ [COST03-BP05 設定帳單和成本管理工具](cost_monitor_usage_config_tools.md)
+ [COST03-BP06 根據工作負載指標分配成本](cost_monitor_usage_allocate_outcome.md)
# COST03-BP01 設定詳細資訊來源
設定精細程度為每小時的成本管理和報告工具，以提供詳細的成本和用量資訊，進而獲得更深入的分析和洞悉。設定您的工作負載，使其產出或具有每個交付商業成果的日誌項目。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
像是精細程度為每小時的成本管理工具，可以提供詳細的帳單資訊，讓組織可以追蹤耗用量，協助找出一些成本增加的原因。這些資料來源提供整個組織最準確的成本和用量的檢視。
AWS Cost and Usage Report 為所有收費 AWS 服務提供每日或每小時用量細節、費率、成本和屬性。CUR 中包含所有可能的維度，包括：標記、位置、資源屬性和帳戶 ID。
使用以下自訂項目設定您的 CUR：
+ 包含資源 ID
+ 自動重新整理 CUR
+ 每小時的精細程度
+ **版本控制：** 覆寫現有的報告
+ **資料整合：** Athena (Parquet 格式和壓縮)
使用 [AWS Glue](https://aws.amazon.com/glue/) 準備資料用於分析，並使用 [Amazon Athena](https://aws.amazon.com/athena/) 執行資料分析，使用 SQL 查詢資料。您也可以使用 [Quick](https://aws.amazon.com/quicksight/) 建立自訂且複雜的視覺化，並將它們分發到整個組織。
### 實作步驟
+ **設定成本和用量報告：** 使用帳單主控台，設定至少一個成本和用量報告。用含所有識別符與資源 ID 的每小時精細度設定報告。您也可以使用不同的精細度建立其他報告，以提供較高層級的摘要資訊。
+ **在 Cost Explorer 中設定每小時精細度：** 啟用 **每小時** 和 **資源層級資料** 以過去 14 天的每小時精細度以及資源層級的細分度存取成本和使用量資料。
+ **設定應用程式記錄：** 確認您的應用程式會記錄其交付的每個業務成果，以便追蹤和衡量相應成果。確保此資料的精細程度至少為每小時，以符合成本和用量資料。如需記錄和監控的詳細資訊，請參閱 [Well-Architected 卓越營運支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)。
## 資源
**相關文件：**
+ [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [AWS 成本管理定價](https://aws.amazon.com/aws-cost-management/pricing/)
+ [標記 AWS 資源](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)
+ [使用 AWS Budgets 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [管理 AWS Cost and Usage Report](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
+ [Well-Architected 卓越營運支柱](https://wa.aws.amazon.com/wat.pillar.operationalExcellence.en.html)
**相關範例：**
+ [AWS 帳戶設定](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html)
+ [AWS Cost Explorer 的新外觀和常見使用案例](https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-cost-explorers-new-ui-and-common-use-cases/)
# COST03-BP02 將組織資訊新增至成本與用量
根據您的組織、工作負載屬性和成本分配類別來定義標記結構描述，以便您在成本管理工具中篩選及搜尋資源，或監控成本與用量。情況允許時，依據目的、團隊、環境，或其他與您的業務有關的條件，在所有資源間實作一致的標記。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
[在 AWS 中實作標記](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)，將組織資訊新增到您的資源，然後將這些資訊新增至您的成本與用量資訊。標籤是鍵/值對；鍵已定義，且在組織中必須是唯一的，而值對於一組資源是唯一的。鍵值對的範例：鍵是 `Environment` (環境)，其值為 `Production` (生產)。生產環境中的所有資源都會有此鍵/值對。標記可讓您使用有意義且相關的組織資訊，來分類和追蹤成本。您可以套用代表組織類別 (例如成本中心、應用程式名稱、專案或擁有者) 的標籤，並識別工作負載及其特性 (例如，測試或生產)，以在整個組織中劃分成本和用量歸屬。
您套用標籤至 AWS 資源 (例如 Amazon Elastic Compute Cloud 執行個體或 Amazon Simple Storage Service 儲存貯體) 並啟用標籤時，AWS 會將此資訊加入至成本和用量報告。您可以對已標記和未標記的資源執行報告和分析，以便更符合內部成本管理政策，並確保準確劃分歸屬。
在組織的各帳戶建立和實作 AWS 標記標準，能讓您以一致統一的方式管理和管控 AWS 環境。使用 AWS Organizations 中的[標籤政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)，定義如何在 AWS Organizations 中將標籤用於帳戶中 AWS 資源的規則。標籤政策可讓您輕鬆採用標準化方法來標記 AWS 資源。
[AWS Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) 可讓您新增、刪除和管理多個資源的標籤。透過 Tag Editor，您可以搜尋您要標記的資源，然後在搜尋結果中管理資源的標籤。
[AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 可讓您為成本指派組織的意義，而無須在資源上加上標籤。您可以將成本和用量資訊對應到唯一的內部組織結構。您可以定義類別規則，使用帳單維度 (例如帳戶和標籤) 來映射和分類成本。除了標記，這可提供另一個層級的管理功能。您也可以將特定帳戶和標籤對應到多個專案。
**實作步驟**
+ **定義標記結構描述：**聚集整個企業的所有利害關係人以定義結構描述。這通常包括屬於技術、財務和管理角色的人員。定義所有資源必須具備的標籤清單，以及資源應該具備的標籤清單。確認標籤名稱和值在整個組織中保持一致。
+ **標記資源：**使用您定義的成本屬性類別，並根據類別在工作負載中的所有資源上[放置標籤](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)。使用 CLI、Tag Editor 或 AWS Systems Manager 等工具來提高效率。
+ **實作 AWS Cost Categories：**您可以建立 [Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 而不實作標記。Cost Categories 會使用現有的成本和用量維度。從您的結構描述建立類別規則，並將其實作至 Cost Categories。
+ **自動化標記：**若要確認您在所有資源中保持高層級標記，請自動化標記，以便在建立資源時自動對其進行標記。使用 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html) 之類的服務，確認資源在建立時會加上標籤。您也可以使用 Lambda 函數建立[自動標記](https://aws.amazon.com/blogs/mt/auto-tag-aws-resources/)的自訂解決方案，或使用自訂微型服務定期掃描工作負載並移除任何未標記的資源，這非常適合用於測試和開發環境。
+ **監控和報告標記：**若要確認您在整個組織中保持高層級標記，請報告並監控工作負載間的標籤。您可以使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 檢視已標記和未標記資源的成本，或使用 [Tag Editor](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) 等服務。定期檢閱未標記資源的數量，並採取措施來新增標籤，直至達到所需的標記層級。
## 資源
**相關文件：**
+ [標記最佳實務](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS CloudFormation 資源標籤](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html)
+ [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/)
+ [標記 AWS 資源](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [使用 AWS 預算分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [管理 AWS 成本和用量報告](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
**相關影片：**
+ [如何標記 AWS 資源以依據成本中心或專案分割我的帳單](https://www.youtube.com/watch?v=3j9xyyKIg6w)
+ [標記 AWS 資源](https://www.youtube.com/watch?v=MX9DaAQS15I)
**相關範例：**
+ [根據身分或角色自動標記新的 AWS 資源](https://aws.amazon.com/blogs/mt/auto-tag-aws-resources/)
# COST03-BP03 識別成本歸因類別
識別組織分類 (例如業務單位、部門或專案)，這些分類可以將組織內的成本分配給內部取用實體。使用這些分類來強制執行支出權責劃分、建立成本感知並推動有效的取用行為。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
成本分類的程序對預算、會計、財務報告、決策制定、基準和專案管理至關重要。透過對費用進行分類，團隊可更加了解他們在整個雲端之旅中將產生的成本類型，從而做出明智的決策並有效管理預算。
雲端支出權責劃分為有紀律的需求和成本管理建立了有力的誘因。對於將大部分雲端支出分配給取用業務單位或團隊的組織，這樣可以大幅節省雲端成本。此外，分配雲端支出有助於組織採用更多集中式雲端控管的最佳實務。
在定期會議中與財務團隊和其他相關利害關係人合作，了解在組織內分配成本的要求。工作負載成本必須在整個生命週期中分配，包括開發、測試、生產和除役。了解組織內學習、員工發展和創意成本的狀況。這有助於將用於此目的的帳戶正確分配到培訓和開發預算，而不是籠統的 IT 成本預算。
與您的組織中的利害關係人共同定義成本歸因類別後，請使用 [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 將您的成本與用量資訊在 AWS 雲端 中分組成有意義的類別，例如特定專案的成本，或是部門或業務單位的 AWS 帳戶。您可以建立自訂類別，並使用各種不同的維度 (例如帳戶、標籤、服務或費用類型)，根據您定義的規則將成本與用量資訊對應至這些類別中。設定成本類別後，您就能依據這些類別檢視成本與用量資訊，進而讓組織能制定更好的策略與購買決策。這些類別也會顯示在 AWS Cost Explorer、AWS Budgets 和 AWS Cost and Usage Report 中。
例如，假設您為業務單位 (DevOps 團隊) 建立成本類別，並根據您所定義的群組，在每個類別下建立多個規則 (每個子類別的規則)，分別具有多個維度 (AWS 帳戶、成本分配標籤、服務或收費類型)。透過成本類別，您可以使用規則型引擎來組織成本。您設定的規則會將成本組織到類別中。在這些規則中，您可以對每個類別使用多個維度以進行篩選，例如特定 AWS 帳戶、AWS 服務，或費用類型。然後，您可以跨多個產品使用這些類別 (在 [AWS 帳單與成本管理 和成本管理](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html) [主控台)](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/view-billing-dashboard.html)。其中包括 AWS Cost Explorer、AWS Budgets、AWS Cost and Usage Report 和 AWS Cost Anomaly Detection。
例如，下圖顯示您可以有多個團隊 (成本類別)、多個環境 (規則)，且每個環境有多個資源或資產 (維度)，進而分組您組織中的成本與用量資訊。
![\[詳細說明組織內的成本與用量之間有何關係的流程圖。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/cost-usage-organization-chart.png)
您也可以使用成本類別建立成本的群組。在您建立成本類別後 (您的用量記錄可在成本類別建立後的 24 小時內更新為新值)，這些類別會出現在 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)、 [AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)、 [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)和 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)。在 AWS Cost Explorer 和 AWS Budgets 中，成本類別會顯示為額外的帳單維度。您可以使用此維度來篩選特定成本類別值，或依成本類別分組。
### 實作步驟
+ **定義您的組織類別：** 與內部利害關係人和業務單位會談，定義可反映組織的結構和要求的類別。這些類別應該直接對應至現有財務類別的結構，例如業務單位、預算、成本中心或部門。查看雲端服務為您的業務帶來的成果，例如培訓或教育，因為這些也是屬於組織類別。
+ **定義您的功能類別：** 與內部利害關係人和業務單位會談，定義可反映您在企業內具有之職能的類別。這可能是工作負載或應用程式名稱，以及環境類型，例如生產、測試或開發。
+ **定義 AWS Cost Categories：** 建立成本類別以組織成本和用量資訊，過程中使用 [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 並將 AWS 成本和用量對應至 [適當的類別](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html)。您可以將多個類別指派給一個資源，而資源可以位於多個不同的類別中，因此請視需要定義任意數量的類別，以便 [管理您的成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) (使用 AWS Cost Categories 在分類結構內管理)。
## 資源
**相關文件：**
+ [標記 AWS 資源](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [使用成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [使用 AWS Budgets 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [管理 AWS Cost and Usage Report](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
+ [AWS Cost Categories](https://docs.aws.amazon.com/wellarchitected/latest/framework/aws-cost-management/aws-cost-categories/)
+ [使用 AWS Cost Categories 管理您的成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html)
+ [建立成本類別](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html)
+ [標記成本類別](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/tag-cost-categories.html)
+ [將費用分割到成本類別內](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/splitcharge-cost-categories.html)
+ [AWS Cost Categories 功能](https://aws.amazon.com/aws-cost-management/aws-cost-categories/features/)
**相關範例：**
+ [使用 AWS Cost Categories 組織您的成本與用量資料](https://aws.amazon.com/blogs/aws-cloud-financial-management/organize-your-cost-and-usage-data-with-aws-cost-categories/)
+ [使用 AWS Cost Categories 管理您的成本](https://aws.amazon.com/aws-cost-management/resources/managing-your-costs-with-aws-cost-categories/)
+ [Well-Architected 實驗室：成本與用量視覺化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html)
+ [Well-Architected 實驗室：Cost Categories](https://wellarchitectedlabs.com/cost/200_labs/200_cost_category/)
# COST03-BP04 建立組織指標
建立此工作負載所需的組織指標。工作負載的指標範例包括產生的客戶報告或向客戶提供的網頁。
**未建立此最佳實務時的風險暴露等級：**高
## 實作指引
了解工作負載的輸出是否算得上業務成功。每個工作負載通常都有少數幾個能夠指出效能的主要輸出。如果您有包含許多元件的複雜工作負載，則可以排定清單的優先順序，或定義和追蹤每個元件的指標。與您的團隊合作，以了解要使用哪些指標。此單位將用於了解工作負載的效率，或每個業務輸出的成本。
**實作步驟**
+ **定義工作負載成果：**與業務的利害關係人會談，並定義工作負載的成果。這些是客戶用量的主要衡量方式，並且必須是業務指標而非技術指標。每個工作負載應該有少量的高層級指標 (少於五個)。如果工作負載為不同的使用案例產生多個成果，請將它們分組為單一指標。
+ **定義工作負載元件成果：**或者，如果您有大型且複雜的工作負載，或者可以用明確定義的輸入和輸出輕易將工作負載分成元件 (例如微型服務)，請為每個元件定義指標。工作應該反映元件的價值和成本。從最大的元件開始，並向較小的元件運行。
## 資源
**相關文件：**
+ [標記 AWS 資源](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [使用 AWS 預算分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [管理 AWS 成本和用量報告](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
# COST03-BP05 設定帳單和成本管理工具
設定符合組織政策的成本管理工具，以管理及優化雲端支出。其中包括以服務、工具和資源來組織及追蹤成本與用量資料、透過整合的帳單和存取許可加強控制、透過預算制定與預測提升規劃效能、接收通知或提醒，以及藉由資源與定價優化進一步降低成本。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
為了建立健全的權責劃分，您應先將帳戶策略視為成本分配策略的一部分予以考量。正確做到這一點，應該就夠了。否則，後續會發生意料之外和棘手的問題。
為了鼓勵雲端支出的權責劃分，使用者應有權存取可讓他們檢視成本與用量的工具。建議所有工作負載和團隊針對下列詳細資訊及用途設定工具：
+ **組織：** 使用您自己的標記策略和分類來建立成本分配與管控基準。
+ **組織：** 使用您自己的標記策略和分類法，來建立成本分配與管控基準。標記支援的 AWS 資源，並根據您的組織結構 (業務單位、部門或專案) 對其進行有意義的分類。標記特定成本中心的帳戶名稱，並與 AWS Cost Categories 對應，以將其成本中心的特定業務單位的帳戶分組，讓業務單位擁有者可在一個位置查看多個帳戶的耗用量。
+ **存取：** 追蹤整個組織的帳單資訊 (透過 [合併帳單](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) )，並確認適當的利害關係人和企業擁有者具有存取權。
+ **控制：** 使用適當防護機制建立有效控管機制，以避免在使用服務控制政策 (SCP)、標記政策和預算警示時發生意外狀況。例如，您只能使用有效的控制機制，讓團隊在偏好的區域中建立資源。
+ **目前狀態：** 設定儀表板，顯示目前的成本和用量等級。儀表板應在工作環境中顯眼的位置提供，類似於營運儀表板。您可以使用 [雲端智慧儀表板 (CID)](https://github.com/aws-samples/aws-cudos-framework-deployment) 或任何其他支援的產品來建立此可見性。
+ **通知：** 在成本或用量超出定義的限制時和 AWS Budgets 或 AWS Cost Anomaly Detection 發生異常時提供通知。
+ **報告：** 彙總所有成本和用量資訊，並以詳細的可分配成本資料強化對雲端支出的意識與權責劃分。報告應與使用報告的團隊相關，且理想情況下應包含建議。
+ **追蹤：** 顯示相對於設定的總目標或具體目標目前成本和用量的狀況。
+ **分析：** 讓團隊成員能夠以所有可能的維度執行每小時精細度的自訂和深度分析。
+ **檢查：** 隨時掌握最新的資源部署和成本優化機會。取得組織層級資源部署的通知 (使用 Amazon CloudWatch、Amazon SNS 或 Amazon SES)，並檢閱成本最佳化建議 (例如 AWS Compute Optimizer 或 AWS Trusted Advisor)。
+ **趨勢：** 以所需的精細度顯示所需期間內的成本與用量變化。
+ **預測：** 使用您建立的預測儀表板顯示預估的未來成本，以及預估您的資源用量和支出。
您可以使用 AWS 工具，例如 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)、 [AWS 帳單與成本管理](https://aws.amazon.com/aws-cost-management/aws-billing/)或 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 以執行基本功能，或者，您可以將 CUR 資料與 [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway) 和 [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway) 整合，以提供此功能和更詳細的檢視。如果您的組織中沒有基本技能或頻寬，您可以使用 [AWS ProServ](https://aws.amazon.com/professional-services/)、 [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/)或 [AWS Partner](https://aws.amazon.com/partners/) 並使用其工具。您也可以使用第三方工具，但請先確認這項成本能夠為組織提供相應的價值。
### 實作步驟
+ **允許對工具的團隊式存取：** 設定您的帳戶，建立群組，並使其有權存取必要的成本和用量報告以了解其耗用量，使用 [AWS Identity and Access Management](https://aws.amazon.com/iam/) 對相關工具進行 [控制存取](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html) ，例如 AWS Cost Explorer。這些群組必須包含擁有或管理應用程式的所有團隊中的代表。這可證明每個團隊都能存取其成本和用量資訊以追蹤取用情形。
+ **設定 AWS Budgets：** [設定 AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) 於所有帳戶上 (針對您的工作負載)。使用標籤設定整體帳戶支出的預算，以及工作負載的預算。在 AWS Budgets 中設定通知，以接收超出預算金額時的提醒，或預估成本超出預算時的提醒。
+ **設定 AWS Cost Explorer：** 設定 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) (針對您的工作負載和帳戶)，將成本資料視覺化以進行深入分析。根據歷史成本資料建立工作負載的儀表板，以追蹤整體支出、工作負載的關鍵用量指標，以及未來成本的預測。
+ **設定 AWS Cost Anomaly Detection：** 使用 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) (針對您的帳戶、核心服務或您所建立的 Cost Categories)，以監控成本與用量並偵測異常支出。您可以在彙總報告中個別接收提醒，也可以透過電子郵件或 Amazon SNS 主題接收提醒，以便分析和判斷發生異常的根本原因，並找出導致成本上升的因素。
+ **設定進階工具：** 或者，您可以為組織建立自訂工具，以提供額外的詳細資訊和精細度。您可以實作進階分析功能，方法為使用 [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway)，以及實作儀表板，方法為使用 [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway)。考慮使用 [CID 解決方案](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) 做為預先設定的進階儀表板。您也可以與 [AWS Partner](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management) 合作，並採用其雲端管理解決方案，在便利的同一位置啟用雲端帳單監控與優化。
## 資源
**相關文件：**
+ [AWS 成本管理](https://docs.aws.amazon.com/cost-management/latest/userguide/what-is-costmanagement.html)
+ [標記](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) AWS 資源
+ [使用 AWS Budgets 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [管理 AWS Cost and Usage Report](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
+ [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/)
+ [AWS 的雲端財務管理](https://aws.amazon.com/aws-cost-management/)
+ [範例服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
+ [AWS APN 合作夥伴 – 成本管理](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management)
**相關影片：**
+ [部署雲端智慧儀表板](https://www.youtube.com/watch?v=FhGZwfNJTnc)
+ [取得任何 FinOps 或成本優化指標或 KPI 的提醒](https://www.youtube.com/watch?v=dzRKDSXCtAs)
**相關範例：**
+ [Well-Architected 實驗室 - AWS 帳戶設定](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html/)
+ [Well-Architected 實驗室：帳單視覺化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html)
+ [Well-Architected 實驗室：成本與管控用量](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html)
+ [Well-Architected 實驗室：成本與用量分析](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_4_Cost_and_Usage_Analysis/README.html)
+ [Well-Architected 實驗室：成本與用量視覺化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html)
+ [Well-Architected 實驗室：雲端智慧儀表板](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/)
+ [如何使用 SCP 設定跨帳戶的權限防護機制](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/)
# COST03-BP06 根據工作負載指標分配成本
按用量指標或商業成果分配工作負載的成本，以衡量工作負載的成本效率。實作程序以透過分析服務 (可提供洞見和退款功能) 來分析成本和用量資料。
**未建立此最佳實務時的曝險等級：** 低
## 實作指引
成本優化以最低的價格提供業務成果，只有依工作負載指標 (按工作負載效率測量) 來分配工作負載成本才能達成。透過記錄檔或其他應用程式監控，監控已定義的工作負載指標。結合此資料與工作負載成本，您可以透過查看具有特定標籤值或帳戶 ID 的成本來取得成本資料。建議您每小時執行一次此分析。如果您有一些靜態成本元件 (例如，持續執行的後端資料庫) 且請求率不同 (例如，用量尖峰在早上九到晚上五點，晚上只有少量請求)，您的效率通常會有所改變。了解靜態成本與可變成本之間的關係，將協助您確定優化活動的重點。
與 Amazon Elastic Container Service (Amazon ECS) 和 Amazon API Gateway 上的容器化應用程式等資源相比，為共用資源建立工作負載指標可能具有挑戰性。但是，您可以透過某些方式對用量進行分類，以及追蹤成本。如果您需要追蹤 Amazon ECS 和 AWS Batch 共用資源，可以在 AWS Cost Explorer 中啟用分割成本分配資料。使用分割成本分配資料，您可以了解並優化您的容器化應用程式的成本和用量，並根據共用運算和記憶體資源的使用情形，將應用程式成本分配給個別業務實體。如果您有共用 API Gateway 和 AWS Lambda 函數用量，則可以使用 [AWS Application Cost Profiler](https://docs.aws.amazon.com/application-cost-profiler/latest/userguide/introduction.html) 對其耗用量進行分類 (根據 `租用戶 ID` 或 `客戶 ID)`。
### 實作步驟
+ **將成本分配到工作負載指標：** 使用定義的指標和設定的標籤，建立結合工作負載輸出和工作負載成本的指標。使用諸如 Amazon Athena 和 Amazon Quick 等分析服務，為整體工作負載和任何元件建立效率儀表板。
## 資源
**相關文件：**
+ [標記 AWS 資源](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [使用 AWS Budgets 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [管理 AWS 成本和用量報告](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
**相關範例：**
+ [ 透過 AWS 分割成本分配資料提升 Amazon ECS 和 AWS Batch 的成本可見性 ](https://aws.amazon.com/blogs/aws-cloud-financial-management/la-improve-cost-visibility-of-containerized-applications-with-aws-split-cost-allocation-data-for-ecs-and-batch-jobs/)
# COST 4.如何進行資源除役？
從啟動到結束專案期間，控制變更並管理資源。這樣做可確保您關閉或終止未使用的資源，以減少浪費。
**Topics**
+ [COST04-BP01 在資源生命週期內追蹤資源](cost_decomissioning_resources_track.md)
+ [COST04-BP02 實作除役程序](cost_decomissioning_resources_implement_process.md)
+ [COST04-BP03 除役資源](cost_decomissioning_resources_decommission.md)
+ [COST04-BP04 自動除役資源](cost_decomissioning_resources_decomm_automated.md)
+ [COST04-BP05 強制執行資料保留政策](cost_decomissioning_resources_data_retention.md)
# COST04-BP01 在資源生命週期內追蹤資源
定義並實作一種方法，在資源的生命週期內追蹤資源及其與系統的關聯。您可以使用標記來識別資源的工作負載或功能。
**未建立此最佳實務時的風險暴露等級：**高
## 實作指引
除役不再需要的工作負載資源。常見的範例是用於測試的資源：測試完成後，便可移除資源。使用標籤來追蹤資源 (並針對這些標籤執行報告) 可協助您識別要除役的資產 (不會再使用這些資產，或是其授權將到期時)。使用標籤是追蹤資源的有效方法，方法是使用資源的功能標記資源，或標記除役日期。然後，即可對這些標籤執行報告。功能標記的範例值是`功能 X 測試`，可識別資源在工作負載生命週期的用途。另一個範例是為資源 (例如，待刪除的標籤金鑰名稱和值) 使用 `LifeSpan` 或 `TTL`，以定義要除役的時段或特定時間。
**實作步驟**
+ **實作標記結構描述：**實作識別資源所屬工作負載的標記結構描述，確認工作負載內的所有資源都已相應地加上標籤。標記可協助您依用途、團隊、環境或其他與您業務相關的準則，來將資源分類。如需標記使用案例、策略和技術的詳細資訊，請參閱 [AWS 標記最佳實務](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)。
+ **實作工作負載輸送量或輸出監控：**實作工作負載輸送量監控或警示，並在輸入請求或輸出完成時觸發。將其設定為在工作負載請求或輸出降至零時提供通知，指示不再使用工作負載資源。如果工作負載在正常條件下定期下降到零，則併入時間因素。如需未使用的資源或未充分利用的資源的詳細資訊，請參閱 [AWS Trusted Advisor 成本最佳化檢查](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html)。
+ **將 AWS 資源分組：**為 AWS 資源建立群組。您可以使用 [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) 來組織和管理位於相同 AWS 區域 的 AWS 資源。您可以針對大多數的資源新增標籤，以便識別和排序組織內的資源。使用 [Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) 可大量地對受支援的資源新增標籤。請考慮使用 [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/index.html) 來建立、管理和分配已核准的產品組合給終端使用者，以及管理產品的生命週期。
## 資源
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [AWS Trusted Advisor 成本最佳化檢查](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html)
+ [標記 AWS 資源](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [發布自訂指標](https://docs.aws.amazon.com/Amazon/latest/monitoring/publishingMetrics.html)
**相關影片：**
+ [如何使用 AWS Trusted Advisor 將成本最佳化](https://youtu.be/zcQPufNFhgg)
**相關範例：**
+ [組織 AWS 資源](https://aws.amazon.com/premiumsupport/knowledge-center/resource-groups/)
+ [使用 AWS Trusted Advisor 將成本最佳化](https://aws.amazon.com/premiumsupport/knowledge-center/trusted-advisor-cost-optimization/)
# COST04-BP02 實作除役程序
實作識別和除役未使用資源的程序。
**未建立此最佳實務時的風險暴露等級：**高
## 實作指引
在您的組織中實作標準化程序，以識別並移除未使用的資源。此程序應該要定義執行搜尋的頻率，以及移除資源的程序，以便驗證是否有符合組織的所有要求。
**實作步驟**
+ **建立並實作除役程序：**與工作負載開發人員和擁有者合作，為工作負載及其資源建置除役程序。此程序應該涵蓋用於驗證工作負載是否正在使用的方法，以及用於驗證每個工作負載資源是否正在使用的方法。詳述除役資源的必要步驟，將它們從服務中移除，同時確保符合任何的法規要求。應包含任何關聯的資源，例如授權或連接的儲存。發出通知讓工作負載擁有者知道除役程序已經執行。
使用下列除役步驟來引導您了解過程中應檢查的事項：
+ **識別要除役的資源：**識別 AWS 雲端 中符合除役資格的資源。記錄所有必要資訊，並排定除役時間。在規劃時間表時，請務必考慮到過程中可能會發生沒預期到的問題。
+ **協調和溝通：**與工作負載擁有者合作，確認要除役的資源
+ **記錄中繼資料並建立備份：**如果是生產環境資源的必要項目或如果是重要資源，請記錄中繼資料 (例如公用 IP、區域、AZ、VPC、子網路和安全群組) 並建立備份 (例如 Amazon Elastic Block Store 快照或擷取 AMI、金鑰匯出和憑證匯出)。
+ **驗證基礎設施即程式碼：**確定資源的部署工具是 CloudFormation、Terraform、AWS Cloud Development Kit (AWS CDK) 或任何其他基礎設施即程式碼部署工具，以便能在必要時加以重新部署。
+ **防止存取：**套用限制性控制措施一段時間，以便在您確定資源必要性時，防止有人使用資源。確認資源環境可在必要時恢復為原始狀態。
+ **遵循內部除役程序：**遵循組織的管理任務和除役程序，例如移除組織網域內的資源、移除 DNS 記錄，以及移除組態管理工具、監控工具、自動化工具和安全工具內的資源。
如果有 Amazon EC2 執行個體，請參考下列清單。[如需詳細資訊，請參閱「如何刪除或終止 Amazon EC2 資源？」](https://aws.amazon.com/premiumsupport/knowledge-center/delete-terminate-ec2/)
+ 停止或終止所有 Amazon EC2 執行個體和負載平衡器。Amazon EC2 執行個體終止後，仍會在主控台中短暫顯示。您不需要為任何未處於執行中狀態的執行個體付費
+ 刪除您的 Auto Scaling 基礎設施。
+ 釋放所有專用執行個體。
+ 刪除所有 Amazon EBS 磁碟區和 Amazon EBS 快照。
+ 釋放所有彈性 IP 地址。
+ 取消註冊所有 Amazon Machine Image (AMI)。
+ 終止所有 AWS Elastic Beanstalk 環境。
如果資源是 Amazon Glacier 儲存中的物件，而且在封存未達最低儲存持續時間之前就將其刪除，則會按比例向您收取過早刪除費 (Amazon Glacier 的最低儲存持續時間取決於所使用的儲存類別)。如需每個儲存類別的最低儲存持續時間摘要，請參閱[各種 Amazon S3 儲存類別的效能](https://aws.amazon.com/s3/storage-classes/?nc=sn&loc=3#Performance_across_the_S3_Storage_Classes)。如需過早刪除費的計算方式，請參閱 [Amazon S3 定價](https://aws.amazon.com/s3/pricing/)。
下面的簡單除役程序流程圖會概述除役步驟。在將資源除役之前，請先確認組織已不再使用這些識別為要除役的資源。
![\[Flow chart depicting the steps of decommissioning a resource.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/decommissioning-process-flowchart.png)
## 資源
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
**相關影片：**
+ [刪除 CloudFormation 堆疊但保留某些資源](https://www.youtube.com/watch?v=bVmsS8rjuwk)
+ [了解是哪位使用者啟動了 Amazon EC2 執行個體](https://www.youtube.com/watch?v=SlyAHc5Mv2A)
**相關範例：**
+ [刪除或終止 Amazon EC2 資源](https://aws.amazon.com/premiumsupport/knowledge-center/delete-terminate-ec2/)
+ [了解是哪位使用者啟動了 Amazon EC2 執行個體](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-user-launched-instance/)
# COST04-BP03 除役資源
除役由諸如定期稽核或用量變更等事件觸發的資源。除役通常會定期執行，其執行方式可以手動，也可以自動。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
搜尋未使用資源的頻率和努力應該反映潛在節省的成本，因此較低成本的帳戶的分析頻率應該比較高成本帳戶低。搜尋和除役事件可由工作負載的狀態變更觸發，例如產品壽命結束或被取代。搜尋和除役事件也可由外部事件觸發，例如市場條件變化或產品終止。
**實作步驟**
+ **除役資源：**對於不再需要或是授權合約結束的 AWS 資源來說，這是折舊階段。請先完成所有最終檢查，再移至處置階段並將資源除役，以防止發生任何不需要的中斷，例如擷取快照或備份。使用除役程序，除役已識別為未使用的每個資源。
## 資源
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
**相關範例：**
+ [Well-Architected 實驗室：除役資源 (Level 100)](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/)
# COST04-BP04 自動除役資源
設計工作負載，在識別和除役非關鍵資源、不需要的資源或低利用率資源時，妥善處理資源終止。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
使用自動化來降低或消除除役程序的相關成本。將工作負載設計為執行自動除役，可降低工作負載生命週期內的整體成本。您可以使用 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 來執行除役程序。您也可以使用 [API 或 SDK](https://aws.amazon.com/developer/tools/) 實作自訂程式碼，自動除役工作負載資源。
[現代化應用程式](https://aws.amazon.com/modern-apps/)會優先以無伺服器方式來建置，這個策略會優先採用無伺服器服務。AWS 針對下列三個堆疊層都開發了[無伺服器服務](https://aws.amazon.com/serverless/)：運算、整合和資料存放區。使用無伺服器架構可讓您透過自動縱向擴展和縮減規模，在低流量期間節省成本。
**實作步驟**
+ **實作 AWS Auto Scaling：**對於受支援的資源，請使用 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 來為其進行設定。AWS Auto Scaling 可以協助您在取用 AWS 服務時，獲得最佳的使用率和成本效率。當需求下降時，AWS Auto Scaling 會自動移除超額的資源容量，以免您超支。
+ **設定 CloudWatch 來終止執行個體：**執行個體可以設定為使用 [CloudWatch 警示加以終止](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingTerminateActions)。使用來自於除役程序的指標，以 Amazon Elastic Compute Cloud 動作實作警示。推出之前，確認非生產環境中的操作。
+ **在工作負載內實作程式碼：**您可以使用 AWS SDK 或 AWS CLI 將工作負載資源除役。在整合 AWS 的應用程式內實作程式碼，並終止或移除不再使用的資源。
+ **使用無伺服器服務：**在 AWS 上優先建置[無伺服器架構](https://aws.amazon.com/serverless/)和[事件驅動架構](https://aws.amazon.com/event-driven-architecture/)，以建置和執行應用程式。AWS 提供了多個無伺服器技術服務，這些服務本身就會提供自動最佳化的資源使用率和自動化的除役 (縮減和橫向擴展)。在使用無伺服器應用程式時，系統會自動為您提供最佳化的資源使用率，您永遠不會因為過度佈建而支付費用。
## 資源
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [AWS 上的無伺服器](https://aws.amazon.com/serverless/)
+ [建立警示以停止、終止、重新啟動或復原執行個體](https://docs.aws.amazon.com/Amazon/latest/monitoring/UsingAlarmActions.html)
+ [Amazon EC2 Auto Scaling 入門](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [在 Amazon CloudWatch 警示中新增終止動作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingTerminateActions)
**相關範例：**
+ [排程自動刪除 AWS CloudFormation 堆疊](https://aws.amazon.com/blogs/infrastructure-and-automation/scheduling-automatic-deletion-of-aws-cloudformation-stacks/)
+ [Well-Architected 實驗室：自動除役資源 (Level 100)](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/)
+ [Servian AWS 自動清理](https://github.com/servian/aws-auto-cleanup)
# COST04-BP05 強制執行資料保留政策
對支援的資源定義資料保留政策，以根據組織的要求處理物件刪除。識別並刪除不再需要的非必要或孤立資源與物件。
**未建立此最佳實務時的風險暴露等級：**中
使用資料保留政策和生命週期政策，降低已識別資源的除役程序相關成本和儲存成本。定義資料保留政策和生命週期政策以執行自動化儲存類別遷移和刪除，可降低生命週期內的整體儲存成本。您可以使用 Amazon Data Lifecycle Manager 自動建立和刪除 Amazon Elastic Block Store 快照與 Amazon EBS 支援的 Amazon Machine Image (AMI)，並且可使用 Amazon S3 Intelligent-Tiering 或 Amazon S3 生命週期組態來管理 Amazon S3 物件的生命週期。您也可以使用 [API 或 SDK](https://aws.amazon.com/tools/)，針對要自動刪除的物件建立生命週期政策和政策規則。
**實作步驟**
+ **使用 Amazon Data Lifecycle Manager：**對 Amazon Data Lifecycle Manager 使用生命週期政策，以自動刪除 Amazon EBS 快照和 Amazon EBS 支援的 AMI。
+ **設定儲存貯體的生命週期組態：**對儲存貯體使用 Amazon S3 生命週期組態，定義要讓 Amazon S3 在物件的生命週期內執行的動作，以及根據業務要求在物件的生命週期結束時進行的刪除。
## 資源
**相關文件：**
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/dlm/?icmpid=docs_homepage_mgmtgov)
+ [如何設定 Amazon S3 儲存貯體的生命週期組態](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)
**相關影片：**
+ [使用 Amazon Data Lifecycle Manager 自動執行 Amazon EBS 快照](https://www.youtube.com/watch?v=RJpEjnVSdi4)
+ [使用生命週期組態規則清空 Amazon S3 儲存貯體](https://www.youtube.com/watch?v=JfK9vamen9I)
**相關範例：**
+ [使用生命週期組態規則清空 Amazon S3 儲存貯體](https://aws.amazon.com/premiumsupport/knowledge-center/s3-empty-bucket-lifecycle-rule/)
+ [Well-Architected 實驗室：自動除役資源 (Level 100)](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/)
# 具有經濟效益的資源
**Topics**
+ [COST 5.如何在選取服務時評估成本？](cost-05.md)
+ [COST 6.如何在選取資源類型、大小和數量時達成成本目標？](cost-06.md)
+ [COST 7.如何使用定價模式降低成本？](cost-07.md)
+ [COST 8.如何規劃資料傳輸費？](cost-08.md)
# 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 建立您的產品架構以符合可用性目標和運行時間服務水準協議 (SLA)](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 美元) 可能會超過系統生命週期內的潛在利益。使用更快速且更有效率的資料型估算，會為此元件建立最佳整體結果。
工作負載可能會隨時間改變，而且如果工作負載架構或用量變化，適當的服務組合可能並非最佳。選擇服務的分析必須納入目前和未來的工作負載狀態以及用量水平。為未來的工作負載狀態或用量實作服務，可減少或消除未來變更所需的工作量，藉此降低整體成本。例如，使用 Amazon EMR Serverless 最初可能是合適的選擇。但是，隨著該服務的取用量增加，轉換到 Amazon EC2 上的 Amazon EMR 可以降低工作負載中該元件的成本。
所有工作負載元件的策略審查 (無論其目前屬性為何) 都有可能隨著時間的推移帶來顯著的增強和財務方面的節省。在這個審查流程中所投入的努力應經過深思熟慮，並仔細考慮可能實現的潛在優勢。
[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 和 [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) (CUR) 可分析概念驗證 (PoC) 或執行環境的成本。您也可以使用 [AWS 定價計算工具](https://calculator.aws/#/) 來估算工作負載成本。
### 實作步驟
+ **列出工作負載元件：**建置工作負載元件的清單。這會做為檢查每個元件是否已經過分析的確認清單。所做的工作應反映貴組織優先事項所定義之工作負載的關鍵性。如果有多個資料庫，在功能上將資源分組在一起可提高效率 (例如，生產資料庫儲存)。
+ **排定元件清單的優先順序：**取得元件清單，並依工作順序排定其優先順序。這通常是依最昂貴到最便宜的元件成本排序，或依貴組織優先事項所定義的關鍵性排序。
+ **執行分析：**對於清單上的每個元件，檢閱可用的選項和服務並選擇最適合您組織優先事項的選項。
## 資源
**相關文件：**
+ [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/)
+ [雲端產品](https://aws.amazon.com/products/)
# 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 無伺服器](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/)
+ [如何利用 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)
# COST 6.如何在選取資源類型、大小和數量時達成成本目標？
確認您為手邊的任務選取適當的資源大小和數量。選取最具成本效益的類型、大小和數量，就能盡量減少浪費。
**Topics**
+ [COST06-BP01 執行成本建模](cost_type_size_number_resources_cost_modeling.md)
+ [COST06-BP02 根據資料選取資源類型、大小及數目](cost_type_size_number_resources_data.md)
+ [COST06-BP03 根據指標自動選取資源類型、大小和數目](cost_type_size_number_resources_metrics.md)
# COST06-BP01 執行成本建模
識別組織要求 (例如商業需求和現有承諾)，並對工作負載及其每個元件執行成本建模 (整體成本)。在不同預測負載下對工作負載執行基準測試活動，並比較成本。建模工作應反映潛在效益。例如，花費的時間與元件成本成正比。
**未建立此最佳實務時的風險暴露等級：**高
## 實作指引
為您的工作負載及其每個元件執行成本建模，以了解資源之間的平衡，並根據特定效能等級，找出工作負載中每個資源的合適大小。了解成本考量，可在評估計劃性工作負載部署的價值實現成果時，傳達組織的商業案例和決策程序。
在不同預測負載下對工作負載執行基準測試活動，並比較成本。建模工作應反映潛在效益；例如，花費的時間與元件成本或預測的節省成正比。如需最佳實務，請參閱 [AWS Well-Architected Framework 的效能效率要素的審查一節](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/review.html)。
例如，若要為包含運算資源的工作負載建立成本模型，[AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 將有助於對執行中的工作負載進行成本建模。它根據歷史用量，提供運算資源的合適大小建議。請確定 CloudWatch Agent 已部署至 Amazon EC2 執行個體以收集記憶體指標，可在 AWS Compute Optimizer 內為您提供更精確的建議。這是運算資源的理想資料來源，因為它是免費服務，並使用機器學習根據風險等級提出多個建議。
有[多個服務](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)可與自訂日誌搭配使用，作為其他服務和工作負載元件 (例如 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)) 適當調整大小操作的資料來源。AWS Trusted Advisor 會檢查資源，並標示使用率偏低的資源，以協助您為資源適當調整大小以及建立成本模型。
以下是成本建模資料和指標的建議：
+ 監控必須精確反映使用者體驗。為時段選擇正確的精細度，並悉心選擇最大或 99%，而非平均值。
+ 為分析的時段選擇涵蓋任何工作負載週期所需的正確精細度。例如，假設所執行的是為期兩週的分析，您可能會忽略高利用率的每月週期，導致佈建不足。
+ 考量您現有的承諾、為其他工作負載選取的定價模式，以及加速創新和專注於核心業務價值的能力，藉此為您的計劃性工作負載選擇正確的 AWS 服務。
**實作步驟**
+ **執行資源的成本建模：**將工作負載或概念驗證部署到有特定資源類型和大小要測試的獨立帳戶。使用測試資料執行工作負載，並記錄輸出結果以及測試執行時的成本資料。然後，重新部署工作負載或變更資源類型和大小，並再次執行測試。納入可能用於這些資源之任何產品的授權費用，以及在建立成本模型時部署和管理這些資源的預估營運 (勞工或工程師) 成本。考慮建立一段時間 (每小時、每日、每月、每月或三年) 的成本模型。
## 資源
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [識別適當調整大小的機會](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)
+ [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/)
+ [成本優化：Amazon EC2 適當調整大小](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html)
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [AWS 定價計算器](https://calculator.aws/#/)
**相關範例：**
+ [執行資料驅動型成本建模](https://aws.amazon.com/blogs/mt/how-to-use-aws-well-architected-with-aws-trusted-advisor-to-achieve-data-driven-cost-optimization/)
+ [預估計劃性 AWS 資源組態的成本](https://aws.amazon.com/premiumsupport/knowledge-center/estimating-aws-resource-costs/)
+ [選擇適當的 AWS 工具](https://www.learnaws.org/2019/09/27/choose-right-aws-tools/)
# COST06-BP02 根據資料選取資源類型、大小及數目
根據有關工作負載和資源特性的資料來選擇資源大小或類型。例如，運算、記憶體、輸送量或寫入密集。通常使用工作負載的先前 (內部部署) 版本、文件或其他有關工作負載的資訊來源來進行此選擇。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
Amazon EC2 提供各種執行個體類型，其各自具有不同等級的 CPU、記憶體、儲存和網路容量，適合不同的使用案例。這些執行個體類型具有 CPU、記憶體、儲存和網路功能的不同組合，可讓您在選取適合專案的資源組合時獲得多樣選擇。每個執行個體類型都有多種大小，因此您可以根據工作負載的需求調整資源。若要判斷您需要的執行個體類型，請收集有關您計劃在執行個體上執行之應用程式或軟體系統要求的詳細資訊。這些詳細資訊應包括以下內容：
+ 作業系統
+ CPU 核心數量
+ GPU 核心
+ 系統記憶體 (RAM) 數量
+ 儲存類型和空間
+ 網路頻寬要求
確定運算要求的目的以及需要的執行個體，然後探索各種 Amazon EC2 執行個體系列。Amazon 提供下列執行個體類型系列：
+ 一般用途
+ 運算最佳化
+ 記憶體最佳化
+ 儲存最佳化
+ 加速運算
+ HPC 最佳化
若要深入了解特定 Amazon EC2 執行個體系列可以滿足的具體目的和使用案例，請參閱 [AWS 執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)。
收集系統要求對於您選取最適合需求的特定執行個體系列和執行個體類型來說非常重要。執行個體類型的名稱由系列名稱和執行個體大小組成。例如，t2.micro 執行個體來自 T2 系列，並且是微型大小。
根據工作負載和資源特性選擇資源大小或類型 (例如，運算、記憶體、輸送量或寫入密集)。通常使用成本建模、工作負載的先前版本 (例如內部部署版本)、文件或其他有關工作負載的資訊來源 (白皮書或已發佈的解決方案) 來進行此選擇。使用 AWS 定價計算器或成本管理工具可協助您對執行個體類型、大小和組態做出明智的決策。
### 實作步驟
+ **根據資料選取資源：**使用成本建模資料來選取預期的工作負載用量等級，然後選擇指定的資源類型和大小。依據成本建模資料，決定虛擬 CPU 數目、總記憶體 (GiB)、本機執行個體儲存體磁碟區 (GB)、Amazon EBS 磁碟區和網路效能等級，並將執行個體所需的資料傳輸速率納入考量。一律根據詳細分析和準確的資料進行選取，以最佳化效能，同時有效地管理成本。
## 資源
**相關文件：**
+ [AWS 執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/)
+ [成本優化：EC2 調整大小](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html)
**相關影片：**
+ [ 為您的工作負載選取合適的 Amazon EC2 執行個體 ](https://www.youtube.com/watch?v=q5Dn9gcmpJg)
+ [ 為服務調整適當大小 ](https://youtu.be/wcp1inFS78A)
**相關範例：**
+ [ 探索和比較 Amazon EC2 執行個體類型變得更容易 ](https://aws.amazon.com/blogs/compute/it-just-got-easier-to-discover-and-compare-ec2-instance-types/)
# COST06-BP03 根據指標自動選取資源類型、大小和數目
使用目前執行的工作負載中的指標來選擇正確的大小和類型，以最佳化成本。為運算、儲存、資料和聯網服務適當地佈建輸送量、大小和儲存。這可透過回饋迴圈 (例如自動調整規模) 或工作負載中的自訂程式碼來完成。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
在工作負載中建立意見回饋迴圈，使用執行中工作負載的作用中指標來變更該工作負載。您可以使用受管服務 (例如 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/))，將其設定為為您執行精簡化操作。AWS 也會提供 [API、SDK](https://aws.amazon.com/developer/tools/) 和功能，讓修改資源變得非常輕鬆。您可以設定工作負載來停止和啟動 Amazon EC2 執行個體，以允許變更執行個體大小或執行個體類型。這不僅帶來精簡化的效益，同時消除變更所需的幾乎所有營運成本。
有些 AWS 服務內建自動類型或大小選擇，例如 [Amazon Simple Storage Service 智慧型分層](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/)。Amazon S3 智慧型分層會根據您的使用模式，自動在兩個存取層 (經常存取和不常存取) 之間移動您的資料。
**實作步驟**
+ **設定工作負載指標來提升可觀察性：**擷取工作負載的重要指標。這些指標提供客戶體驗 (例如工作負載輸出) 的指示，並符合資源類型和大小 (例如 CPU 和記憶體用量) 之間的差異。針對運算資源，請分析效能資料以將 Amazon EC2 執行個體調整到適當大小。識別閒置的執行個體，以及未充分使用的執行個體。要尋找的重要指標是 CPU 使用率和記憶體使用率 (例如，90% 的時間有 40% CPU 使用率，如[在 AWS Compute Optimizer 和記憶體使用率已啟用的情況下適當調整大小](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/))。識別在四週期間內，CPU 使用率達到最大且記憶體使用率小於 40% 的執行個體。這些便是需要適當調整大小以降低成本的執行個體。針對 Amazon S3 之類的儲存資源，您可以使用 [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)，以便在儀表板中查看儲存貯體層級中各種類別的 28 項指標，以及 14 天的歷史資料 (預設值)。您可以依摘要和成本最佳化或事件來篩選 Amazon S3 Storage Lens 儀表板，以分析特定指標。
+ **檢視適當調整大小的建議：**使用 AWS Compute Optimizer 中的適當調整大小建議以及成本管理主控台中的 Amazon EC2 適當調整大小工具，或檢閱 AWS Trusted Advisor 的適當調整資源大小以在工作負載上進行調整。在為不同資源調整適當大小時，無論其為 Amazon EC2 執行個體、AWS 儲存類別或 Amazon RDS 執行個體類型，都請務必使用[合適的工具](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)，並遵循[適當調整大小指導方針](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)。針對儲存資源，您可以使用 Amazon S3 Storage Lens，以便能夠檢視物件儲存用量、活動趨勢並提出可行建議，以將成本最佳化並套用資料保護最佳實務。使用 [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) 透過分析組織內的指標而得出的適合情境的建議，您可以立即採取行動來將儲存最佳化。
+ **根據指標自動選取資源類型和大小：**使用工作負載指標，手動或自動選取您的工作負載資源。針對運算資源，在應用程式內設定 AWS Auto Scaling 或實作程式碼，可在需要頻繁變更時減少所需的工作量，而且它可能比手動程序更快地實作變更。您可以啟動並自動擴展單一 Auto Scaling 群組內的一組隨需執行個體和 Spot 執行個體。除了獲得使用 Spot 執行個體的折扣外，您還可以使用預留執行個體或 Savings Plan 來獲得常規隨需執行個體定價的折扣費率。這些因素合在一起可協助您將 Amazon EC2 執行個體所能節省的成本最佳化，並確定應用程式所需的規模和效能。您也可以在 [Auto Scaling Groups (ASG)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) 中使用[屬性型執行個體類型選取 (ABS)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) 策略，以透過一組屬性 (例如 vCPU、記憶體和儲存) 來表達您的執行個體要求。您可以自動使用新發行的較新一代執行個體類型，並使用 Amazon EC2 Spot 執行個體來存取更大範圍的容量。Amazon EC2 機群和 Amazon EC2 Auto Scaling 會選取和啟動符合指定屬性的執行個體，您不必再手動挑選執行個體類型。針對儲存資源，您可以使用 [Amazon S3 Intelligent Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) 和 [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/) 功能，以便能夠在資料存取模式發生改變時，自動選取可自動節省儲存成本的儲存類別，卻又不會影響效能或造成營運負擔。
## 資源
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS 適當調整大小](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/)
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/)
+ [CloudWatch 設定](https://docs.aws.amazon.com/Amazon/latest/monitoring/GettingSetup.html)
+ [CloudWatch 發布自訂指標](https://docs.aws.amazon.com/Amazon/latest/monitoring/publishingMetrics.html)
+ [Amazon EC2 Auto Scaling 入門](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)
+ [Amazon S3 Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/)
+ [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/)
+ [使用 SDK 啟動 Amazon EC2 執行個體](https://docs.aws.amazon.com/sdk-for-net/v2/developer-guide/run-instance.html)
**相關影片：**
+ [為服務調整適當大小](https://www.youtube.com/watch?v=wcp1inFS78A)
**相關範例：**
+ [Amazon EC2 機群的 Auto Scaling 屬性型執行個體類型選取](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [使用排定的擴展來將 Amazon Elastic Container Service 的成本最佳化](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [Amazon EC2 Auto Scaling 的預測擴展](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [使用 Amazon S3 Storage Lens 將成本最佳化並獲得用量檢視能力](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)
+ [Well-Architected 實驗室：適當調整大小的建議 (Level 100)](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
+ [Well-Architected 實驗室：在 AWS Compute Optimizer 和記憶體使用率已啟用的情況下適當調整大小 (Level 200)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)
# COST 7.如何使用定價模式降低成本？
使用最適合您資源的定價模式，就能盡量減少支出。
**Topics**
+ [COST07-BP01 執行定價模式分析](cost_pricing_model_analysis.md)
+ [COST07-BP02 根據成本選擇區域](cost_pricing_model_region_cost.md)
+ [COST07-BP03 選取具成本效益條款的第三方協議](cost_pricing_model_third_party.md)
+ [COST07-BP04 針對此工作負載的所有元件實作定價模式](cost_pricing_model_implement_models.md)
+ [COST07-BP05 在管理帳戶層級執行定價模式分析](cost_pricing_model_master_analysis.md)
# COST07-BP01 執行定價模式分析
分析工作負載的每個元件。判斷元件與資源會執行較長期間 (針對承諾折扣)，還是動態短期執行 (針對 Spot 或隨需)。使用成本管理工具中的建議對工作負載執行分析，並且對這些建議套用商業規則，以達到高報酬。
**未建立此最佳實務時的風險暴露等級：**高
## 實作指引
AWS 有多種[定價模式](https://aws.amazon.com/pricing/)，可讓您根據組織的需求和產品，以最經濟實惠的方式為資源付費。請與您的團隊合作，確認最適當的定價模式。定價模式常會包含多種選項的組合，這取決於您的可用性
**隨需執行個體**可讓您根據您所執行的執行個體按小時或秒 (最低 60 秒) 支付運算或資料庫容量的費用，而無需長期承諾或預付款。
**Savings Plans** 是一種彈性定價模式，您只需承諾一年或三年期的穩定使用量 (以每小時的金額計算)，即可以低價使用 Amazon EC2、Lambda 和 AWS Fargate。
**Spot 執行個體**是一種 Amazon EC2 定價機制，可讓您以折扣的每小時費率要求備用運算容量 (最多可折扣隨需價格的 90%)，且無需前期承諾。
**預留執行個體**可讓您藉由預付容量費用而享有最高 75% 的折扣。如需詳細資訊，請參閱[透過保留達到最佳成本](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html)。
您可能會選擇為生產、品質和開發環境的相關資源納入 Savings Plans。或者，由於沙盒資源在需要時才會開啟，您可能會為該環境中的資源選擇隨需模式。請使用 Amazon [Spot 執行個體](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#spot-instances)降低 Amazon EC2 成本，或使用 [Compute Savings Plans](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#savings-plans) 降低 Amazon EC2、Fargate 和 Lambda 成本。[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 建議工具提供透過 Savings Plans 獲得承諾折扣的機會。
如果您過去曾購買 Amazon EC2 的[預留執行個體](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/reserved-instances/?track=costop)，或已在您的組織內建立成本分配準則，您將可繼續使用 Amazon EC2 預留執行個體。但我們建議應擬定相關策略，在未來使用 Savings Plans 作為更具彈性的節省成本機制。您可以隨時重新整理 AWS Cost Management 中的 Savings Plans (SP) 建議，以重新產生新的 Savings Plans 建議。使用預留執行個體 (RI) 降低 Amazon RDS、Amazon Redshift、Amazon ElastiCache 和 Amazon OpenSearch Service 成本。有三個選項提供 Saving Plans 和預留執行個體：全額預付款、部分預付款和無預付款。使用 AWS Cost Explorer RI 和 SP 購買建議中提供的建議。
若要尋找 Spot 工作負載的機會，可使用整體用量的每小時檢視，並尋找定期出現用量或彈性變化的時段。您可以將 Spot 執行個體用於各種不同的容錯和彈性應用程式。範例包括無狀態 Web 伺服器、API 端點、大數據和分析應用程式、容器化工作負載、CI/CD 與其他彈性工作負載。
分析您的 Amazon EC2 和 Amazon RDS 執行個體是否可在未使用時 (下班時間和週末) 關閉。相較於全年無休地使用，此方法可讓您降低成本達 70% 甚或更高。如果您有僅需在特定時間啟用的 Amazon Redshift 叢集，您可以暫停叢集，等稍後再繼續執行。Amazon Redshift 叢集或 Amazon EC2 和 Amazon RDS 執行個體停止時，運算計費也會隨之停止，而只會計算儲存費用。
請注意，[隨需容量保留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-pricing-billing.html) (ODCR) 並非定價折扣。容量保留會依同等的隨需費率計費，無論您是否以預留容量執行執行個體。若需要為預計要執行的資源提供足夠的容量，就必須考量這些因素。ODCR 無須綁定長期承諾，您不再需要時即可取消，但也可適用 Savings Plans 或預留執行個體所提供的折扣。
**實作步驟**
+ **分析工作負載彈性：**使用 Cost Explorer 中的每小時精細度或自訂儀表板，分析您工作負載的彈性。尋找正在執行的執行個體數量的定期變更。短期執行個體是 Spot 執行個體或 Spot 叢集的候選項目。
+ [Well-Architected 實驗室：Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity)
+ [Well-Architected 實驗室：成本視覺化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html)
+ **審查現有的定價合約：**審查目前基於長期需求的合約或承諾。分析您目前擁有的項目，以及有多少承諾正在使用中。運用既有的合約折扣或企業協議。[企業協議](https://aws.amazon.com/pricing/enterprise/)可為客戶提供根據其需求自訂最適切合約的選項。針對長期承諾，請考慮將預留定價折扣、預留執行個體或 Savings Plans 用於特定執行個體類型、執行個體系列、AWS 區域 和可用區域。
+ **執行承諾折扣分析：**在您的帳戶中使用 Cost Explorer，檢閱 Savings Plans 和預留執行個體建議。若要確認在承擔相應風險的同時以所需折扣實作正確的建議，請遵循 [Well-Architected 實驗室](https://wellarchitectedlabs.com/cost/costeffectiveresources/)的指示進行。
## 資源
**相關文件：**
+ [存取預留執行個體的推薦](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [執行個體購買選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
+ [AWS 企業](https://aws.amazon.com/pricing/enterprise/)
**相關影片：**
+ [節省高達 90% 的成本並在 Spot 執行生產工作負載](https://www.youtube.com/watch?v=BlNPZQh2wXs)
**相關範例：**
+ [Well-Architected 實驗室：Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity)
+ [Well-Architected 實驗室：成本視覺化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html)
+ [Well-Architected 實驗室：定價模式](https://wellarchitectedlabs.com/Cost/CostEffectiveResources.html)
# COST07-BP02 根據成本選擇區域
| |
| --- |
| 此最佳實務已於 2023 年 7 月 13 日隨新版指引更新。 |
每個區域的資源定價可能不同。識別區域成本差異，並僅部署於具有較高成本的區域，以符合延遲、資料落地和資料主權要求。考量區域成本，有助於您為此工作負載支付最低的總價。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
此 [AWS 雲端 基礎設施](https://aws.amazon.com/about-aws/global-infrastructure/) 是全球性的，託管於 [全球多個地點](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)，其建置基礎為 AWS 區域、可用區域、Local Zones、AWS Outposts 和 Wavelength Zones。區域是世界上的實體位置，每個區域各有一個地理區域，而 AWS 在其中有多個可用區域。可用區域是每個區域內的多個隔離位置，由一或多個分散的資料中心組成，各自有其備援電力、網路和連線能力。
每個 AWS 區域 各在當地市場條件之下運作，且各區域的資源定價因土地、光纖設施、電力和稅賦等因素而有所差異。您可以選擇特定區域以操作解決方案的元件或全部，以便以最低價格於全球執行。使用 [AWS 計算器](https://calculator.aws/#/) 按位置類型 (區域、Wavelength Zone 和 Local Zone) 和區域搜尋服務，以預估您的工作負載在不同區域中的成本。
當您建構解決方案時，一項最佳實務是盡量將運算資源置於接近使用者之處，以提供較低延遲和強大的資料主權。根據您的業務、資料隱私權、效能和安全要求，選取適當的地理位置。對於全球各地都有使用者的應用程式，請使用多個位置。
如果您在資料隱私權、安全和業務要求方面不受約束，請使用提供較低 AWS 服務價格的區域來部署工作負載。例如，如果您的預設區域是 ap-southeasth-2 (雪梨)，且沒有使用其他區域方面的限制 (例如資料隱私權、安全)，則將非關鍵性 (開發和測試) Amazon EC2 執行個體部署在 north-east-1 (維吉尼亞北部) 區域，將可降低成本。
![\[此圖顯示不同區域的合規性、延遲、成本以及服務和功能。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/region-feature-matrix.png)
上方的矩陣表顯示區域 4 是這種情況下的最佳選擇，因為與其他區域相比，其延遲很低、服務可供使用，並且是成本最低的區域。
## 實作步驟
+ ** 檢閱 AWS 區域 定價： **分析目前區域的工作負載成本。依服務和用量類型，從最高成本開始，計算其他可用區域的成本。如果預測儲存超過移動元件或工作負載的成本，請遷移至新區域。
+ **檢閱多區域部署的要求：** 分析您的業務要求和義務 (資料隱私權、安全或效能)，確認是否有任何限制使您無法使用多個區域。如果沒有使用單一區域的限制，請使用多個區域。
+ **分析所需的資料傳輸：** 選取區域時請考量資料傳輸成本。將資料存放在接近客戶與資源之處。選取資料流動成本較低、且資料傳輸最少的 AWS 區域。根據資料傳輸的商業需求，您可以使用 [Amazon CloudFront](https://aws.amazon.com/cloudfront/)、[AWS PrivateLink](https://aws.amazon.com/privatelink/)、 [AWS Direct Connect](https://aws.amazon.com/directconnect/)和 [AWS Virtual Private Network](https://aws.amazon.com/vpn/) 降低網路成本、提升效能並增強安全性。
## 資源
**相關文件：**
+ [存取預留執行個體的推薦](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [Amazon EC2 定價](https://aws.amazon.com/ec2/pricing/)
+ [執行個體購買選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
+ [區域表](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)
**相關影片：**
+ [節省高達 90% 的成本並在 Spot 執行生產工作負載](https://www.youtube.com/watch?v=BlNPZQh2wXs)
**相關範例：**
+ [ 常見架構的資料傳輸成本概觀 ](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [ 全球部署的成本考量 ](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-considerations-for-global-deployments/)
+ [ 為工作負載選取區域時應考慮的事項 ](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
+ [ Well-Architected 實驗室：按區域限制服務用量 (Level 200) ](https://www.wellarchitectedlabs.com/cost/200_labs/200_2_cost_and_usage_governance/2_ec2_restrict_region/)
# COST07-BP03 選取具成本效益條款的第三方協議
具成本效益的協議和條款可確保這些服務的成本隨其提供的優勢而擴展。選擇可在為您的組織提供額外優勢時擴展的協議和定價。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
市場上有多種產品可以幫助您管理雲端環境的成本。它們在功能方面可能會有一些差異，而這取決於客戶要求，例如有些客戶專注於成本管控或成本可見性，其他客戶則專注於成本最佳化。有效成本最佳化和管控的一個關鍵因素是使用具有必要功能和合適定價模式的合適工具。這些產品具有不同的定價模式。有些產品會向您收取每月賬單的一定百分比，有些產品則收取所實現節省金額的百分比。理想情況下，請只為您需要的功能付費。
當您在雲端中使用第三方解決方案或服務時，定價結構務必要符合您想要的成果。定價應根據其提供的結果和價值進行擴展。例如，在會從節省的成本中提取一定比例的軟體中，節省的成本 (成果) 越多，收費就越高。會隨著開支增加而要支付更多費用的授權協議可能不會永遠對您的成本最佳化目標有利。但是，如果供應商能為您帳單的所有部分提供明確的效益，則此擴展費用可能是合理的。
例如，如果您使用其他無效益的服務，則會提供 Amazon EC2 建議並收取整個帳單一定比例的解決方案可能會變得更加昂貴。另一個範例是受管服務，其會依受管資源成本的一定百分比計費。較大的執行個體大小不一定需要更多的管理工作，但收費會更高。請確認這些服務定價安排在其服務中包含成本最佳化計劃或功能，以提升效率。
客戶可能會發現市場上的這些產品更先進或更易於使用。您需要考慮這些產品的成本，並考慮長遠的潛在成本最佳化成果。
### 實作步驟
+ ** 分析第三方協議和條款：**審查第三方協議中的定價。針對不同的用量等級執行建模，並將新成本納入考量，例如新服務用量，或因工作負載成長而產生的目前服務增加量。決定額外成本是否為您的企業提供所需的優勢。
## 資源
**相關文件：**
+ [存取預留執行個體的推薦](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [執行個體購買選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
**相關影片：**
+ [節省高達 90% 的成本並在 Spot 執行生產工作負載](https://www.youtube.com/watch?v=BlNPZQh2wXs)
# COST07-BP04 針對此工作負載的所有元件實作定價模式
永久執行的資源應使用預留容量，例如 Savings Plans 或預留執行個體。設定短期容量以使用 Spot 執行個體或 Spot 叢集。隨需執行個體僅用於無法中斷且執行時間不夠長，以及不適合使用預留容量的短期工作負載 (介於 25% 到 75% 之間的時間，視資源類型而定)。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
為了提高成本效率，AWS 會根據您過去的用量提供多個承諾建議。您可以使用這些建議來了解您可以節省的成本，以及如何使用承諾。您可以將這些服務作為隨需服務、Spot 服務，也可以承諾一定時間，並使用預留執行個體 (RI) 和 Savings Plans (SP) 降低隨需成本。您不僅需要了解每個工作負載元件和多項 AWS 服務，還需要了解這些服務的承諾折扣、購買選項和 Spot 執行個體，才能將工作負載最佳化。
考慮工作負載元件的要求，並了解這些服務的不同定價模式。定義這些元件的可用性要求。判斷是否有多個獨立資源在工作負載中執行相同功能，以及隨時間工作負載需求的變化。比較使用預設隨需定價模式和其他適用的模式的資源成本。考量資源或工作負載元件的任何潛在變更。
例如，讓我們看看 AWS 上的這個 Web 應用程式架構。此範例工作負載包括多個 AWS 服務，例如 Amazon Route 53、AWS WAF、Amazon CloudFront、Amazon EC2 執行個體、Amazon RDS 執行個體、負載平衡器、Amazon S3 儲存和 Amazon Elastic File System (Amazon EFS)。您需要檢閱這些服務中的每一項，並透過不同的定價模式找出潛在的成本節省機會。其中有些服務可能符合 RI 或 SP 的資格，有些則可能只會隨需提供。如下圖所示，部分 AWS 服務可以使用 RI 或 SP 來重諾。
![\[Chart of AWS services committed using Reserved Instances and Savings Plans\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/ri-sp-services.png)
### 實作步驟
+ **實作定價模式：**使用分析結果購買 Savings Plans、預留執行個體或實作 Spot 執行個體。如果是第一次購買承諾，請選擇清單中的前五項或前十項建議，然後監控和分析未來一兩個月的結果。AWS Cost Management Console 會引導您完成該過程。從主控台檢閱 RI 或 SP 建議、自訂建議 (類型、付款和期限)，並檢閱每小時承諾 (例如每小時 20 美元)，然後加入到購物車。折扣會自動套用到符合資格的用量。定期購買少量承諾折扣 (例如每 2 週或每月)。針對可能中斷或無狀態的工作負載，實作 Spot 執行個體。最後，選取隨需 Amazon EC2 執行個體，並為其餘要求配置資源。
+ **工作負載審查週期：**實作會具體分析定價模式涵蓋範圍的工作負載審查週期。一旦工作負載達到所需的涵蓋範圍，請部分購買額外的承諾折扣 (每隔幾個月)，或隨著組織用量的變更進行購買。
## 資源
**相關文件：**
+ [ 了解您的 Savings Plans 建議 ](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+ [存取預留執行個體的推薦](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [如何購買預留執行個體](https://aws.amazon.com/ec2/pricing/reserved-instances/buyer/)
+ [執行個體購買選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
+ [Spot 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)
+ [ 其他 AWS 服務的保留模式 ](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-reservation-models/reservation-models-for-other-aws-services.html)
+ [ Savings Plans 支援的服務 ](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-services.html)
**相關影片：**
+ [節省高達 90% 的成本並在 Spot 執行生產工作負載](https://www.youtube.com/watch?v=BlNPZQh2wXs)
**相關範例：**
+ [ 在購買 Savings Plans 前應考量哪些事項？](https://repost.aws/knowledge-center/savings-plans-considerations)
+ [ 如何使用 Cost Explorer 分析開支和用量？](https://repost.aws/knowledge-center/cost-explorer-analyze-spending-and-usage)
# COST07-BP05 在管理帳戶層級執行定價模式分析
查看計費和成本管理工具，並檢視承諾和保留的建議折扣，在管理帳戶層級定期執行分析。
**未建立此最佳實務時的曝險等級：** 低
## 實作指引
執行定期成本建模可讓您有機會進行多個工作負載間的優化。例如，如果多個工作負載使用隨需執行個體，則在彙總層級變更的風險會更低，而且實作以承諾為基礎的折扣能獲得更低的整體成本。建議以兩週到一個月的頻率定期執行分析。這可讓您進行小幅的調整，因此定價模式的涵蓋範圍會隨著不斷變化的工作負載及其元件不斷演變。
使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 建議工具，在您的管理帳戶中尋找承諾折扣的機會。管理帳戶層級的建議在計算過程中會考量您的 AWS 組織中已啟用預留執行個體 (RI) 或 Savings Plans (SP) 折扣分享的帳戶。計算過程也會在折扣分享啟用時啟動，以推薦可盡量節省整體帳戶成本的承諾。
雖然在許多情況下，在管理帳戶層級購買可省下最多成本，但在某些情況下，您可以考慮在連結帳戶層級購買 SP，例如，您希望先將折扣套用至該連結帳戶中的用量時。成員帳戶建議會在個別帳戶層級上進行計算，以盡可能節省各個獨立帳戶的成本。如果您的帳戶同時擁有 RI 和 SP 承諾，則會按以下順序套用這些承諾：
1. 區域 RI
1. 標準 RI
1. 可轉換 RI
1. Instance Savings Plan
1. Compute Savings Plan
如果您在管理帳戶層級購買 SP，則將根據最高到最低的折扣百分比來套用節省的金額。管理帳戶層級的 SP 會查看所有連結帳戶，並以最高的折扣套用節省的金額。如果您希望限定節省金額的套用項目，您可以在連結的帳戶層級購買 Savings Plan，如此，每當該帳戶執行符合資格的運算服務時，就會先為該項目套用折扣。當帳戶未執行符合資格的運算服務時，折扣將會分享到相同管理帳戶下的其他連結帳戶。折扣分享預設為開啟，但可視需要關閉。
在合併帳單系列中，Savings Plans 會先套用至擁有者帳戶的用量，然後套用至其他帳戶的用量。只有在折扣分享啟用時，才會執行此模式。您的 Savings Plans 會先套用至您最高的節省金額百分比。如果有多種用法皆具有相同的節省百分比，Savings Plans 會套用至使用最低 Savings Plans 率的第一個用量。Savings Plans 會繼續套用，直到沒有剩餘用量或承諾用量耗盡。任何剩餘用量均按隨需費率收費。您可以隨時重新整理 AWS Cost Management 中的 Savings Plans 建議，以產生新的 Savings Plans 建議。
分析執行個體的彈性後，您可以採納建議的承諾。使用可能的不同資源選項分析工作負載的短期成本、分析 AWS 定價模型，並使其符合您的業務要求，以找出總體擁有成本和 [成本最佳化](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html) 機會，進而建立成本模型。
### 實作步驟
**執行承諾折扣分析**：在您的帳戶中使用 Cost Explorer，檢閱 Savings Plans 和預留執行個體建議。請確實了解 Saving Plan 建議，並估計您的每月支出和每個月節省的成本。審查管理帳戶層級的建議；其計算過程中考量到您的 AWS 組織中已啟用 RI 或 Savings Plans 折扣分享，以盡可能節省帳戶成本的所有成員帳戶間的整體用量。您可以依照 Well-Architected 實驗室的指示，確定在所需的折扣與風險方面，採用了正確的建議。
## 資源
**相關文件：**
+ [AWS 定價的運作方式為何？](https://aws.amazon.com/pricing/?nc2=h_ql_pr_ln)
+ [執行個體購買選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
+ [Saving Plan 概觀](file:///Users/mergenf/Documents/WELL%20ARCHITECTED/COST%20OPT%20PILLAR/phase3a/COST06/•%09https:/docs.aws.amazon.com/savingsplans/latest/userguide/sp-overview.html)
+ [Saving Plan 建議](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+ [存取預留執行個體的推薦](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [了解您的 Saving Plans 建議](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+ [Savings Plans 如何套用至您的 AWS 用量](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html)
+ [Saving Plans 與合併帳單](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-consolidated-billing/)
+ [開啟共用的預留執行個體和 Savings Plans 折扣](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html)
**相關影片：**
+ [節省高達 90% 的成本並在 Spot 執行生產工作負載](https://www.youtube.com/watch?v=BlNPZQh2wXs)
**相關範例：**
+ [AWS Well-Architected 實驗室：定價模式 (Level 200)](https://wellarchitectedlabs.com/cost/200_labs/200_3_pricing_models/)
+ [AWS Well-Architected 實驗室：定價模式分析 (Level 200)](https://www.wellarchitectedlabs.com/cost/200_labs/200_pricing_model_analysis/)
+ [在購買 Savings Plan 前，我應考量哪些事項？](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-considerations/)
+ [如何利用滾動 Savings Plans 降低承諾風險？](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-can-i-use-rolling-savings-plans-to-reduce-commitment-risk/)
+ [何時應使用 Spot 執行個體](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-leveraging-ec2-spot-instances/when-to-use-spot-instances.html)
# COST 8.如何規劃資料傳輸費？
確實規劃和監控資料傳輸費，以便做出盡量減少成本的架構決策。小規模而有效的架構變更能夠隨時間大幅減少營運成本。
**Topics**
+ [COST08-BP01 執行資料傳輸建模](cost_data_transfer_modeling.md)
+ [COST08-BP02 選取元件以將資料傳輸成本最佳化](cost_data_transfer_optimized_components.md)
+ [COST08-BP03 實作可降低資料傳輸成本的服務](cost_data_transfer_implement_services.md)
# COST08-BP01 執行資料傳輸建模
收集組織要求並執行工作負載及其每個元件的資料傳輸建模。這可確定其目前資料傳輸要求的最低成本點。
**未建立此最佳實務時的風險暴露等級：**高
## 實作指引
在設計雲端解決方案時，由於習慣使用內部部署資料中心來設計架構或缺乏知識，通常會忽略掉資料傳輸費用。AWS 中的資料傳輸費用會由來源、目的地和流量的數量來決定。在設計階段考慮這些費用能夠讓您省下成本。了解資料傳輸在工作負載中的發生位置、傳輸成本及其相關效益，對於準確估算總體擁有成本 (TCO) 來說非常重要。這可讓您做出明智的決策，以修改或接受架構決策。例如，您可能有一個多個可用區域組態，您在可用區域之間複寫資料。
您要為會在工作負載中傳輸資料的服務元件建模，並決定這是實現所需可靠性和彈性可接受的成本 (類似於在兩個可用區域中支付運算和儲存費用)。針對不同用量等級建立成本模型。工作負載用量會隨時間改變，在不同等級，不同的服務可能更經濟實惠。
在為資料傳輸建模時，請考慮所擷取的資料量以及資料的來源。此外，也請考慮所處理的資料量以及需要的儲存或運算容量。在建模期間，請遵循工作負載架構的網路最佳實務，以將潛在的資料傳輸成本最佳化。
AWS 定價計算工具 可以幫助您查看特定 AWS 服務的預估成本和預期的資料傳輸。如果您有已在執行的工作負載 (用於測試目的或在生產前環境中)，請使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 或 [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) (CUR) 來了解資料傳輸成本並建模。設定概念驗證 (PoC) 或測試工作負載，並以逼真的模擬負載執行測試。您可以根據不同的工作負載需求建立成本模型。
### 實作步驟
+ **確定要求：**來源和目的地之間所計劃資料傳輸的主要目標和業務要求是什麼？ 所預期的最終業務成果是什麼？ 收集業務要求並定義預期的成果。
+ **確定來源和目的地：**資料傳輸的資料來源和目的地是什麼 (例如在 AWS 區域 內、到 AWS 服務，或向外傳輸到網際網路)？
+ [AWS 區域 內的資料傳輸 ](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-within-region)
+ [AWS 區域 之間的資料傳輸 ](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-between-regions)
+ [ 向外傳輸到網際網路的資料傳輸 ](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-out-internet)
+ **確定資料分類：**此資料傳輸的資料分類是什麼？ 這是什麼種類的資料？ 資料有多大？ 資料必須以何種頻率進行傳輸？ 資料敏感嗎？
+ **確定要使用的 AWS 服務或工具：**哪些 AWS 服務會用於此資料傳輸？ 是否可將已佈建的服務用於其他工作負載？
+ ** 計算資料傳輸成本：**使用先前建立的 [AWS 定價](https://aws.amazon.com/pricing/)資料傳輸模型來計算工作負載的資料傳輸成本。針對工作負載用量的增加和減少，計算不同用量等級的資料傳輸成本。如果工作負載架構具有多個選項，請計算每個選項的成本進行比較。
+ **將成本與成果連結：**對於產生的每筆資料傳輸成本，請指定工作負載達到的成果。如果在元件之間傳輸，可能是用於解耦，如果在可用區域之間傳輸，則可能是用於備援。
+ **建立資料傳輸模型：**在收集所有資訊後，為多個使用案例和不同工作負載建立概念性基礎資料傳輸模型。
## 資源
**相關文件：**
+ [AWS 快取解決方案](https://aws.amazon.com/caching/aws-caching/)
+ [AWS 定價](https://aws.amazon.com/pricing/)
+ [Amazon EC2 定價](https://aws.amazon.com/ec2/pricing/on-demand/)
+ [Amazon VPC 定價](https://aws.amazon.com/vpc/pricing/)
+ [ 了解資料傳輸費用 ](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html)
**相關影片：**
+ [監控並最佳化您的資料傳輸成本](https://www.youtube.com/watch?v=UjliYz25_qo)
+ [ S3 Transfer Acceleration ](https://youtu.be/J2CVnmUWSi4)
**相關範例：**
+ [常見架構的資料傳輸成本概觀](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [AWS 網路方案指引 ](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortDate&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23network&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all)
# COST08-BP02 選取元件以將資料傳輸成本最佳化
選擇所有元件，並設計架構以降低資料傳輸成本。這包括使用廣域網路 (WAN) 最佳化和多可用區域 (AZ) 組態等元件
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
資料傳輸建構可將資料傳輸成本降至最低。這可能涉及使用內容交付網路以將資料靠近使用者放置，或從您內部至 AWS 使用專用網路連結。您也可以使用 WAN 優化和應用程式優化，來減少元件之間傳輸的資料量。
將資料傳輸到 AWS 雲端 或於其中傳輸資料時，重要的是根據不同的使用案例來了解目的地、資料性質和可用的網路資源，以便選取合適的 AWS 服務來將資料傳輸最佳化。AWS 提供了一系列針對各種資料遷移要求量身打造的資料傳輸服務。根據組織內的業務需求，選取合適的[資料儲存](https://aws.amazon.com/products/storage/)和[資料傳輸](https://aws.amazon.com/cloud-data-migration/)選項。
在計劃或檢閱工作負載架構時，請考慮下列事項：
+ **在 AWS 內使用 VPC 端點：**VPC 端點可讓您在 VPC 與支援的 AWS 服務之間建立私人連線。這可讓您避免使用可能會產生資料傳輸成本的公用網際網路。
+ **使用 NAT 閘道：**使用 [NAT 閘道](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)，讓私有子網路中的執行個體可以連線到網際網路或 VPC 外的服務。檢查 NAT 閘道後方傳送最多流量的資源是否與 NAT 閘道位於相同的可用區域。如果沒有，請在與該資源相同的可用區域中建立新的 NAT 閘道，以降低跨 AZ 資料傳輸費用。
+ **使用 AWS Direct Connect** Direct Connect 繞過公用網際網路，並在內部部署網路與 AWS 之間建立直接的私有連線。這可能會比透過網際網路傳輸大量資料更具成本效益和一致性。
+ **避免跨區域界限傳輸資料**：AWS 區域 之間的資料傳輸 (從某個區域到另一個區域) 通常會產生費用。請深思熟慮後再決定是否追求多區域路徑。如需詳細資訊，請參閱[多區域案例](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/multi-region-scenarios.html)。
+ **監控資料傳輸：**使用 Amazon CloudWatch 和 [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 來擷取有關資料傳輸和網路用量的詳細資訊。分析 VPC 中擷取到的網路流量資訊，例如進出網路介面的 IP 地址或範圍。
+ **分析您的網路用量：**使用計量和報告工具 (例如 AWS Cost Explorer、CUDOS 儀表板或 CloudWatch) 以了解工作負載的資料傳輸成本。
### 實作步驟
+ **選取用於資料傳輸的元件：**使用 [COST08-BP01 執行資料傳輸建模](cost_data_transfer_modeling.md) 中所說明的資料傳輸模型時，請專注於資料傳輸成本最高的位置或工作負載用量變更時資料傳輸成本最高的位置。尋找替代架構或其他元件，以消除或降低資料傳輸需求 (或降低其成本)。
## 資源
**相關的最佳實務：**
+ [COST08-BP01 執行資料傳輸建模](cost_data_transfer_modeling.md)
+ [COST08-BP03 實作可降低資料傳輸成本的服務](cost_data_transfer_implement_services.md)
**相關文件：**
+ [雲端資料遷移](https://aws.amazon.com/cloud-data-migration/)
+ [AWS 快取解決方案](https://aws.amazon.com/caching/aws-caching/)
+ [使用 Amazon CloudFront 更快地交付內容](https://aws.amazon.com/getting-started/tutorials/deliver-content-faster/)
**相關範例：**
+ [常見架構的資料傳輸成本概觀](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [AWS 網路最佳化要訣 ](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [使用 Apache Parquet 格式的 VPC 流程日誌針對網路分析最佳化效能和降低成本](https://aws.amazon.com/blogs/big-data/optimize-performance-and-reduce-costs-for-network-analytics-with-vpc-flow-logs-in-apache-parquet-format/)
# COST08-BP03 實作可降低資料傳輸成本的服務
實作服務以減少資料傳輸。例如，使用邊緣節點或內容交付網路 (CDN) 將內容提供給終端使用者、在應用程式伺服器或資料庫前面建置快取層，以及使用專用網路連線而非 VPN 來連線至雲端。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
有許多 AWS 服務可以協助您最佳化網路資料傳輸用量。根據您的工作負載元件、類型和雲端架構，這些服務可以協助您在雲端上壓縮、快取、共用和分配流量。
+ [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 是一個全球內容交付網路，在低延遲和高傳輸速度之下遞送資料。其快取位於全球節點的資料，能減輕您的資源所受的負載。藉由 CloudFront，在最低延遲之下交付內容給全球大量使用者方面，您可減少管理所費的心力。AWS Well-Architected [安全節省搭售方案](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/?sc_channel=em&sc_campaign=Launch_mult_OT_awsroadmapemail_20200910&sc_medium=em_whats_new&sc_content=launch_ot_ot&sc_country=mult&sc_geo=mult&sc_category=mult&sc_outcome=launch) 可以在您計劃隨著時間的推移增加使用量，幫助您節省高達 30% 的 CloudFront 使用率。
+ [AWS Direct Connect](https://aws.amazon.com/directconnect/) 服務可讓您建立連接至 AWS 的專用網路連線。如此可降低網路成本，增加頻寬，並且比網際網路連線提供更一致的網路體驗。
+ [Site-to-Site VPN](https://aws.amazon.com/vpn/) 可讓您在私有網路和 AWS 全球網路之間建立安全且私有的連線。它非常適合小型辦公室或商業合作夥伴，因為它提供簡便的連線，而且是全受管的彈性服務。
+ [VPC 端點](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) 允許透過私有網路連接各 AWS 服務，可用於降低公有網路的資料傳輸量和 [NAT 閘道](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 成本。 [閘道 VPC 端點](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-gateway.html) 不收取小時費用，且支援 Amazon S3 和 Amazon DynamoDB。 [界面 VPC 端點](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) 由 [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) 提供，收取每小時費用和每 GB 使用費。
+ [NAT 閘道的](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 提供內建擴展和管理功能，與獨立 NAT 執行個體相比，成本更低。將 NAT 閘道放置在與高流量執行個體相同的可用區域中，並考慮為需要存取 Amazon DynamoDB 或 Amazon S3 的執行個體使用 VPC 端點，來降低資料傳輸和處理成本。
+ 使用 [AWS Snow Family](https://aws.amazon.com/snow/) 裝置，其中的運算資源可以用來收集與處理在邊緣 AWS Snow Family 裝置上的資料 ([Snowball Edge](https://aws.amazon.com/snowcone/)、 [Snowball Edge](https://aws.amazon.com/snowball/) 和 [Snowmobile](https://aws.amazon.com/snowmobile/)) 讓您能夠以具成本效益的方式將數 PB 的資料離線移至 AWS 雲端。
### 實作步驟
+ **實作服務：** 根據您的服務選擇適用的 AWS 網路服務、使用資料傳輸建模的工作負載類型，以及檢閱 VPC Flow Logs。查看成本最高和磁碟區流量最大的情況。檢閱 AWS 服務，並評估是否有可減少或移除傳輸的服務，特別是聯網和內容交付方面。另請尋找可重複存取資料或大量資料的快取服務。
## 資源
**相關文件：**
+ [AWS Direct Connect](https://aws.amazon.com/directconnect/)
+ [AWS 探索我們的產品](https://aws.amazon.com/)
+ [AWS 快取解決方案](https://aws.amazon.com/caching/aws-caching/)
+ [Amazon CloudFront](https://aws.amazon.com/cloudfront/)
+ [AWS Snow Family](https://aws.amazon.com/snow/)
+ [Amazon CloudFront 安全節省搭售方案](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/)
**相關影片：**
+ [監控並最佳化您的資料傳輸成本](https://www.youtube.com/watch?v=UjliYz25_qo)
+ [AWS 成本最佳化系列：CloudFront](https://www.youtube.com/watch?v=k8De2AfAN3k)
+ [如何降低 NAT 閘道的資料傳輸費用？](https://www.youtube.com/watch?v=hq4KtPRezus)
**相關範例：**
+ [如何退款共享服務：AWS Transit Gateway 範例](https://aws.amazon.com/blogs/aws-cloud-financial-management/gs-chargeback-shared-services-an-aws-transit-gateway-example/)
+ [使用 Athena 查詢和 QuickSight，從成本和用量報告深入了解 AWS 資料傳輸詳細資訊](https://aws.amazon.com/blogs/networking-and-content-delivery/understand-aws-data-transfer-details-in-depth-from-cost-and-usage-report-using-athena-query-and-quicksight/)
+ [常見架構的資料傳輸成本概觀](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [使用 AWS Cost Explorer 分析資料傳輸成本](https://aws.amazon.com/blogs/mt/using-aws-cost-explorer-to-analyze-data-transfer-costs/)
+ [利用 Amazon CloudFront 功能，針對您的 AWS 架構進行成本最佳化](https://aws.amazon.com/blogs/networking-and-content-delivery/cost-optimizing-your-aws-architectures-by-utilizing-amazon-cloudfront-features/)
+ [如何降低 NAT 閘道的資料傳輸費用？](https://aws.amazon.com/premiumsupport/knowledge-center/vpc-reduce-nat-gateway-transfer-costs/)
# 管理需求與供應資源
**Topics**
+ [COST 9.如何管理需求和供應資源？](cost-09.md)
# COST 9.如何管理需求和供應資源？
針對支出和效能達到平衡的工作負載，確認您購買的每一個項目都用到，並避免極少使用執行個體。往任一端傾斜的使用指標，對您組織在營運成本 (因過度使用而降低效能) 或浪費的 AWS 花費 (因過度佈建) 方面會造成負面影響。
**Topics**
+ [COST09-BP01 對工作負載需求進行分析](cost_manage_demand_resources_cost_analysis.md)
+ [COST09-BP02 實作緩衝或調節機制來管理需求](cost_manage_demand_resources_buffer_throttle.md)
+ [COST09-BP03 動態提供資源](cost_manage_demand_resources_dynamic.md)
# COST09-BP01 對工作負載需求進行分析
分析工作負載隨時間的需求。確認分析涵蓋季節性趨勢，並準確反映整個工作負載生命週期內的運作狀況。分析工作應反映潛在效益：例如，花費的時間與工作負載成本成正比。
**未建立此最佳實務時的曝險等級：** 高
## 實作指引
要分析工作負載對雲端運算的需求，就必須了解雲端環境中啟動的運算工作模式和特性。這類分析可協助使用者優化資源配置、管理成本，並確保效能符合所需等級。
了解工作負載的需求。組織要求應指出請求的工作負載回應時間。回應時間可用來判斷需求是否已得到滿足，或是資源供應是否需要改變以符合需求。
分析應包含需求的可預測性和重複性、需求的變化速率，以及需求的變化量。針對足夠長的時間執行分析，以納入任何季節變化，例如月底處理或節假日尖峰。
分析工作應反映實作擴展的潛在效益。查看元件的預期總成本，以及工作負載生命週期內用量和成本的任何增加或減少。
以下是執行雲端運算的工作負載需求分析時需要考慮的一些關鍵事項：
1. **資源使用和效能指標**：分析 AWS 資源在一段時間內的使用情形。確認尖峰和離峰使用模式，以最佳化資源配置和擴展策略。監控效能指標，例如回應時間、延遲、輸送量和錯誤率。這些指標有助於評估雲端基礎架構的整體運作狀態和效率。
1. **使用者和應用程式擴展行為**：了解使用者行為及其對工作負載需求的影響。檢查使用者流量的模式，有助於提高交付內容的完整性和應用程式的回應能力。分析工作負載如何隨著需求增加而擴展。判斷是否已正確、有效地設定自動擴展參數，以處理負載波動。
1. **工作負載類型**：識別出在雲端中執行的不同工作負載類型，例如批次處理、即時資料處理、Web 應用程式、資料庫或機器學習。每種工作負載類型可能有不同的資源需求和效能資料。
1. **服務水準協議 (SLA)**：將實際效能與 SLA 進行比較，以確保合規性並找出需要改進的部分。
您可以使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 收集和追蹤指標、監控日誌檔、設定警示，以及自動對 AWS 資源的變更做出反應。您也可以利用 Amazon CloudWatch 來全面了解整個系統的資源使用率、應用程式效能和運作狀態。
透過 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)，您可以根據最佳實務佈建資源，以改善系統效能和可靠性、提高安全性，並尋找節省成本的機會。您也可以關閉非生產執行個體，並使用 Amazon CloudWatch 和 Auto Scaling 來因應需求增加或減少。
最後，您可以使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 或者 [Quick](https://aws.amazon.com/quicksight/) 搭配 AWS Cost and Usage Report CUR 檔案或應用程式日誌，以執行工作負載需求的進階分析。
整體而言，全面的工作負載需求分析可讓組織在資源佈建、擴展和最佳化方面做出明智決策，進而提高效能、成本效益和使用者滿意度。
### 實作步驟
+ **分析現有的工作負載資料：** 分析現有工作負載、舊版工作負載或預測使用模式中的資料。使用 Amazon CloudWatch、日誌檔和監控資料來深入了解工作負載的使用情況。分析工作負載的完整週期，並收集所有季節性變更的資料，例如月末或年末事件。分析中所反映的工作應反映工作負載特性。應將工作重點放在需求變更最大的高價值工作負載上。針對需求變更最少的低價值工作負載，應將投入的工作量降到最低。
+ **預測外部影響：** 與整個組織中的團隊成員面談，這些成員可能會影響或變更工作負載的需求。常見的團隊是銷售團隊、行銷團隊或業務開發團隊。與這些團隊合作以了解其作業週期，以及是否有任何事件會改變工作負載需求。利用此資料來預測工作負載需求。
## 資源
**相關文件：**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ [Amazon SQS 入門](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ [Quick](https://aws.amazon.com/quicksight/)
**相關影片：**
**相關範例：**
+ [監控、追蹤和分析，以達到成本最佳化](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/monitor-track-and-analyze/)
+ [搜尋和分析 CloudWatch 中的日誌](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-search-analysis.html)
# COST09-BP02 實作緩衝或調節機制來管理需求
緩衝和調節機制會修改工作負載的需求，以消除任何尖峰時段。在用戶端執行重試時實作調節機制。實作緩衝機制以儲存請求，並將處理的時間往後延遲。確認調節和緩衝機制經過設計，以便讓用戶端在所需時間內收到回應。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
在雲端運算中實作緩衝或調節機制至關重要，如此才能管理需求並降低工作負載所需的佈建容量。為了獲得最佳效能，請務必評估總需求，包括峰值、請求變更速度以及必要的回應時間。當用戶端能夠重新發送他們的請求時，套用限流就變得很實用。相反地，對於缺少重試功能的用戶端，最理想的方法是實作緩衝解決方案。這類緩衝機制簡化了請求的湧入作業，並且會將有不同操作速度之應用程式的互動最佳化。
![\[Demand curve with two distinct peaks that require high provisioned capacity\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/provisioned-capacity-1.png)
假設某個工作負載的需求曲線如上圖所示。此工作負載有兩個尖峰，為了處理這些尖峰，已佈建了資源容量 (以橙色線顯示)。用於此工作負載的資源和能源並非由需求曲線底下的區域表示，而是已佈建的容量底下的區域，因為這兩個尖峰必須用已佈建的容量處理。使工作負載需求曲線扁平化，有助於減少工作負載所需的已佈建容量，以及降低對環境造成的影響。若要消除尖峰時段，請考慮實作限流或緩衝解決方案。
為了深入了解，讓我們探索一下限流和緩衝機制。
**限流：**如果需求來源具有重試功能，則您可以實作限流。限流會告知來源，如果目前無法服務請求，則應稍後再試。來源會等待一段時間，然後重試請求。實作調節的優點是限制最大資源量和工作負載成本。在 AWS 中，您可以使用 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 來實作限流。
**緩衝為主：**緩衝為主的方法會使用*生產者* (會將訊息傳送到佇列的元件)、*取用者* (會從佇列接收訊息的元件) 和*佇列* (保存訊息) 來儲存訊息。消費者可讀取訊息並進行處理，允許以符合取用者業務要求的速度運作訊息。透過使用緩衝為主的方法，生產者的訊息會儲存在佇列或串流中，隨時可供取用者以符合其操作需求的速度來存取。
在 AWS 中，有多重服務可供選擇以實作緩衝方法。[Amazon Simple Queue Service(Amazon SQS)](https://aws.amazon.com/sqs/) 是受管服務，會提供可讓單一取用者讀取個別訊息的佇列。[Amazon Kinesis](https://aws.amazon.com/kinesis/) 會提供可讓許多取用者讀取相同訊息的串流。
緩衝和限流可透過修改工作負載的需求來消除任何尖峰時段。當用戶端會重試動作時請使用限流，並使用緩衝機制來保存請求以供稍後處理。使用緩衝為主的方法時，請將工作負載建構為可在所需的時間內為請求提供服務，並確認您能夠處理重複的工作請求。分析整體需求、變更率及所需的回應時間，以適當調整所需的調節或緩衝區大小。
### 實作步驟
+ **分析用戶端要求：**分析用戶端請求，以判斷其是否能夠執行重試。針對無法執行重試的用戶端，則需要實作緩衝機制。分析整體需求、變更率及所需的回應時間，以便判斷所需的調節或緩衝區大小。
+ ** 實作緩衝或調節機制：**在工作負載中實作緩衝或調節機制。Amazon Simple Queue Service (Amazon SQS) 等佇列可為工作負載元件提供緩衝機制。Amazon API Gateway 可為工作負載元件提供限流。
## 資源
**相關的最佳實務：**
+ [SUS02-BP06 實作緩衝或調節使需求曲線趨於扁平化](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a7.html)
+ [REL05-BP02 限流請求](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
+ [Amazon Simple Queue Service](https://aws.amazon.com/sqs/)
+ [Amazon SQS 入門](https://aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/)
**相關影片：**
+ [為分散式應用程式選擇適當的傳訊服務](https://www.youtube.com/watch?v=4-JmX6MIDDI)
**相關範例：**
+ [管理和監控工作負載中的 API 調節](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [使用 API Gateway 大規模地限流分級的多租用戶 REST API ](https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-1/)
+ [使用 Amazon API Gateway 在多租用戶 Amazon EKS SaaS 解決方案中啟用分級和限流 ](https://aws.amazon.com/blogs/apn/enabling-tiering-and-throttling-in-a-multi-tenant-amazon-eks-saas-solution-using-amazon-api-gateway/)
+ [使用佇列和訊息進行應用程式整合](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)
# COST09-BP03 動態提供資源
資源是按計畫進行佈建。這可以是以需求為基礎 (例如，透過自動調整規模)，或是以時間為基礎，其中需求可預測，並且根據時間提供資源。這些方法可盡量減少過度佈建或佈建不足的數量。
**未建立此最佳實務時的曝險等級：** 低
## 實作指引
AWS 客戶有數種方法可以增加應用程式的可用資源並提供資源，以滿足需求。其中一個選項是使用 AWS Instance Scheduler，以自動執行 Amazon Elastic Compute Cloud (Amazon EC2) 和 Amazon Relational Database Service (Amazon RDS) 執行個體的啟動及停止。另一個選項是使用 AWS Auto Scaling，這可讓您根據應用程式或服務的需求自動擴展運算資源。根據需求提供資源可讓您僅為自己使用的資源付費，以及在需要時啟動資源，並在不需要資源時將其終止，藉以降低成本。
[AWS Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/) 可讓您將 Amazon EC2 和 Amazon RDS 執行個體設定為在已定義的時間停止及啟動，以便在一致的時間模式下達到相同資源的需求，例如，使用者在每天早上八點存取 Amazon EC2 執行個體，而晚上六點後則不需存取。此解決方案可停止非使用中的資源，並在需要時才加以啟動，藉以降低營運成本。
![\[此圖顯示使用 AWS Instance Scheduler 的成本優化。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/instance-scheduler-diagram.png)
您也可以使用 AWS Systems Manager 快速設定，透過簡單的使用者介面 (UI) 輕鬆設定跨帳戶和區域的 Amazon EC2 執行個體排程。您可以使用 AWS Instance Scheduler 來排程 Amazon EC2 或 Amazon RDS 執行個體，也可以停止和啟動現有的執行個體。不過，您無法停止及啟動屬於 Auto Scaling 群組 (ASG) 或管理 Amazon Redshift 或 Amazon OpenSearch Service 等服務的執行個體。Auto Scaling 群組對於群組內的執行個體有其本身的排程，據以建立這些執行個體。
[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 可協助您調整容量，盡可能以最低的成本維持穩定、可預測的效能，以因應持續變動的需求。這是全受管的免費服務，可與 Amazon EC2 執行個體和 Spot 機群、Amazon ECS、Amazon DynamoDB 與 Amazon Aurora 整合，以擴展應用程式的容量。Auto Scaling 提供自動資源探索，以協助尋找工作負載中可設定的資源，它具有內建的擴展策略以優化效能、成本或兩者之間的平衡，並提供預測擴展以協助處理定期發生的尖峰。
有多個擴展選項可用來擴展您的 Auto Scaling 群組：
+ 一律保持目前的執行個體層級
+ 手動擴展
+ 根據排程進行擴展
+ 根據需求進行擴展
+ 使用預測擴展
Auto Scaling 政策不同，可分類為動態和排程擴展政策。動態政策是手動或動態擴展，屬於排程或預測擴展。您可以使用擴展政策來進行動態、排程和預測擴展。您也可以使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 的指標和警示，來觸發工作負載的擴展事件。我們建議您使用 [啟動範本](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)，這可讓您存取最新的功能和改進內容。當您使用啟動組態時，並非所有的 Auto Scaling 功能都可供使用。例如，您無法建立同時啟動 Spot 和隨需執行個體，或指定多個執行個體類型的 Auto Scaling 群組。您必須使用啟動範本來設定這些功能。使用啟動範本時，建議您對每個範本進行版本控制。使用啟動範本的版本控制，可以建立完整參數集的子集。然後，您可加以重複使用，以建立相同啟動範本的其他版本。
您可以使用 AWS Auto Scaling，或使用 [AWS API 或 SDK 在您的程式碼中納入擴展](https://aws.amazon.com/developer/tools/)。透過消除手動變更環境所需的營運成本，這可讓您降低整體工作負載成本，且變更的執行速度更快。這也可讓您隨時依據需求做出相應的工作負載資源配置。為了遵循此最佳實務，並且為組織動態提供資源，您應了解 AWS 雲端 中的水平和垂直擴展，以及在 Amazon EC2 執行個體中執行的應用程式有何性質。建議讓您的雲端財務管理團隊與技術團隊相互合作，以遵循此最佳實務。
[Elastic Load Balancing (Elastic Load Balancing)](https://aws.amazon.com/elasticloadbalancing/) 可將需求分散到多個資源以協助您進行擴展。藉由使用 ASG 和 Elastic Load Balancing，您可以用最佳方式路由流量以管理傳入請求，讓 Auto Scaling 群組中沒有任何執行個體不堪負荷。請求會以循環方式散佈在目標群組的所有目標之間，而不考量容量或使用率。
典型的指標可以是標準 Amazon EC2 指標，例如 CPU 使用率、網路輸送量，以及 Elastic Load Balancing 觀察到的請求與回應延遲。若可行的話，您應該使用可指示客戶體驗的指標，這通常是自訂指標，可能源自您工作負載內的應用程式程式碼。為了在本文件中詳細說明如何動態滿足需求，我們將 Auto Scaling 分類為需求為主和時間為主的供應模式，並深入探討這兩種模式。
**需求為主的供應：** 依賴幾近即時的需求狀態，充分利用雲端的彈性來供應資源，以滿足不斷變化的需求。對於需求為主的供應，請使用 API 或服務功能，以程式設計方式更動架構中的雲端資源量。這樣可讓您增減架構中元件的規模，在需求激增時增加資源數量以維持效能，待需求消退時減少容量以降低成本。
![\[此圖說明需求為主的擴展政策，例如簡單/階段式擴展和目標追蹤。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/demand-based-supply.png)
+ **簡單/階段式擴展：** 根據客戶手動定義的步驟，監控指標及新增/移除執行個體。
+ **目標追蹤：** 類似恆溫器的控制機制，可自動新增或移除執行個體，以在客戶定義的目標上維護指標。
以需求為主的方法進行建構時，請牢記兩大考量要點。第一，了解必須多迅速地佈建起新的資源。第二，了解供應與需求之間差距的大小會改變。您必須隨時因應需求的改變速度，並為資源失敗做好準備。
**時間為主的供應：** 時間為主方法能使資源容量符合可預測或依照時間定義完善的需求。這種方法通常不依存於資源的利用率。時間為主方法能確保需要資源的特定時間有資源可用，並且因為啟動程序和系統或一致性檢查的緣故，能在毫無延遲之下提供。採用時間為主的方法，您可在忙碌期提供更多資源或增加容量。
![\[此圖說明時間為主的擴展政策，例如排程和預測調整。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/time-based-supply.png)
您可以使用排程或預測自動擴展來實作時間為主的方法。可排定工作負載於定義的時間橫向擴展或縮減 (例如在營業時段開始時)，以便在使用者到來或需求增加時有資源可用。預測擴展會使用模式進行橫向擴展，而排程的擴展則使用先定義的時間進行橫向擴展。您也可以使用 [屬性型執行個體類型選取 (ABS) 策略](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) (在 Auto Scaling 群組中)，以透過一組屬性 (例如 vCPU、記憶體和儲存) 來表達您的執行個體要求。這也可讓您自動使用新發行的新世代執行個體類型，並使用 Amazon EC2 Spot 執行個體來存取更大範圍的容量。Amazon EC2 機群和 Amazon EC2 Auto Scaling 會選取和啟動符合指定屬性的執行個體，您不必再手動挑選執行個體類型。
您也可善用 [AWS API 和 SDK](https://aws.amazon.com/developer/tools/) 和 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 以視需要自動佈建整個環境以及除役。這種方法十分適合僅在定義的營業時段或時期執行的開發或測試環境。您可使用 API 縮放環境之內的資源大小 (垂直縮放)。例如，可變更執行個體的大小或類別，以擴展生產工作負載。作法是將執行個體停止再啟動，選擇不同的執行個體大小或類別。此技法亦可套用至其他資源，例如 Amazon EBS Elastic Volumes，在使用中時經過修改可增加大小、調整效能 (IOPS) 或變更磁碟區類型。
以時間為主的方法進行建構時，請牢記兩大考量要點。首先，用量模式的一致性有多高？ 第二，若是模式改變會有何影響？ 您可藉由監控工作負載和使用商業智慧來提高預測的準確性。若看出用量模式有明顯變化，可調整時間以確保涵蓋。
## 實作步驟
+ ** 設定排程擴展： **針對可預測的需求變更，以時間為主的擴展機制可以及時提供正確的資源數目。此外，當資源建立和設定的速度不夠快，不足以回應隨需變更時，此機制也能派上用場。透過 AWS Auto Scaling，使用工作負載分析來設定排程的擴展。若要設定以時間為主的排程，您可以根據預期或可預測的負載變更，事先使用排程擴展的預測擴展來增加 Auto Scaling 群組中的 Amazon EC2 執行個體數目。
+ **設定預測擴展：** 預測擴展可讓您事先在 Auto Scaling 群組中增加每日和每週流量模式的 Amazon EC2 執行個體數目。如果您有定期流量尖峰和啟動耗時的應用程式，則應考慮使用預測擴展。預測擴展可在預估的負載之前初始化容量，協助您以優於單純動態擴展 (本質上是被動的) 的速度進行擴展。例如，如果使用者在營業時間開始時開始使用您的工作負載，且在營業時間結束後不使用，則預測擴展可在營業時間之前新增容量，以消除動態擴展為了回應變動的流量而產生的延遲。
+ ** 設定動態自動擴展： **若要根據作用中的工作負載指標來設定擴展，請使用 Auto Scaling。使用分析和設定 Auto Scaling 以在正確的資源層級上啟動，並確認工作負載在所需的時間內擴展。您可以啟動並自動擴展單一 Auto Scaling 群組內的一組隨需執行個體和 Spot 執行個體。除了獲得使用 Spot 執行個體的折扣外，您還可以使用預留執行個體或 Savings Plan 來獲得常規隨需執行個體定價的折扣費率。將這些因素全部結合在一起，可協助您將 Amazon EC2 執行個體所能節省的成本優化，並確定應用程式所需的規模和效能。
## 資源
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ 擴展 Auto Scaling 群組的大小
+ [Amazon EC2 Auto Scaling 入門](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Amazon SQS 入門](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [Amazon EC2 Auto Scaling 的排程擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [ Amazon EC2 Auto Scaling 的預測擴展 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html)
**相關影片：**
+ [ Auto Scaling 的目標追蹤擴展政策 ](https://www.youtube.com/watch?v=-RumeaoPB2M)
+ [AWS Instance Scheduler ](https://www.youtube.com/watch?v=nTLEyo2NzUs)
**相關範例：**
+ [ Amazon EC2 機群的 Auto Scaling 屬性型執行個體類型選取 ](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [ 使用排程的擴展將 Amazon Elastic Container Service 的成本優化 ](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [ Amazon EC2 Auto Scaling 的預測擴展 ](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [ 如何搭配使用 Instance Scheduler 與 CloudFormation 來排程 Amazon EC2 執行個體？ ](https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-instance-scheduler/)
# 隨時間優化
**Topics**
+ [COST 10.如何評估新服務？](cost-10.md)
+ [COST 11.如何評估工作的成本？](cost-11.md)
# COST 10.如何評估新服務？
隨著 AWS 推出新服務和功能，最佳實務是檢視現有架構決策，以確認其持續發揮最大成本效益。
**Topics**
+ [COST10-BP01 制定工作負載審查程序](cost_evaluate_new_services_review_process.md)
+ [COST10-BP02 定期審查和分析此工作負載](cost_evaluate_new_services_review_workload.md)
# COST10-BP01 制定工作負載審查程序
制定一個程序，用於定義工作負載審查的標準和程序。審查工作應反映潛在的效益。例如，核心工作負載或價值超過帳單 10% 的工作負載每季或每六個月審查一次，而低於 10% 的工作負載則每年審查一次。
**未建立此最佳實務時的風險暴露等級：**高
## 實作指引
為了擁有最符合成本效益的工作負載，您必須定期審查工作負載，以了解是否有機會實作新的服務、功能和元件。若要實現較低的整體成本，程序必須與可能的節省金額成正比。例如，相較於佔整體支出 5% 的工作負載，您應更頻繁且更徹底地審查佔整體支出 50% 的工作負載。考量任何外部因素或波動性。如果工作負載服務特定的地理或市場區隔，並且預測該區域會發生改變，則更頻繁的檢閱可能會帶來成本節省。需要檢閱的另一個因素是實作變更的工作量。如果測試與驗證變更需要付出大量成本，則應降低檢閱頻率。
考量維護過時和舊版元件和資源的長期成本，以及無法在其中實作新的功能。目前的測試和驗證成本可能會超過提議的效益。不過，隨著時間推移，工作負載與目前技術之間的差距增大，從而變更的成本可能會大幅增加，進而產生更高的成本。例如，移至新的程式設計語言目前看來可能並非具有成本效益之舉。不過，在五年後，該語言熟練人員的成本可能會增加，而且由於工作負載的成長，您會將更大的工作負載轉移到新的語言，此時需要付出的努力會比以前更多。
將您的工作負載細分成多個元件，指派元件的成本 (估算值就足夠)，然後在每個元件旁列出因素 (例如，工作量和外部市場)。使用這些指標來決定每個工作負載的檢閱頻率。例如，您可能會將 Web 伺服器視為高成本、變更所需工作量低和受外部因素影響高，因此檢閱頻率高。中央資料庫可能是中等成本、變更所需工作量高，以及受外部因素影響低，因此檢閱頻率中等。
定義一個程序，以在新的服務、設計模式、資源類型和組態可用時對其進行評估，進而優化您的工作負載。如同[效能要素審查](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf-06.html)和[可靠性要素審查](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_monitor_aws_resources_review_monitoring.html)程序，請進行優化和改進活動與問題修復的識別、驗證及優先順序排定，並將其併入您的積存中。
**實作步驟**
+ **定義審查頻率：**定義工作負載及其元件的審查頻率。配置時間和資源給持續性改進與審查頻率，以改進工作負載的效率和優化。這結合了許多因素，可能隨著組織內的工作負載而異，也可能隨著工作負載中的元件而異。常見的因素包括，在收入或品牌方面對組織的重要性、執行工作負載的總成本 (包括營運和資源成本)、工作負載的複雜性、實作變更的簡易性、任何軟體授權合約，以及因懲罰性授權，變更會導致授權成本大幅增加。元件可在功能或技術上進行定義，例如 Web 伺服器和資料庫，或運算和儲存資源。相應平衡這些因素，並為工作負載及其元件制定一個期間。您可以決定每 18 個月審查一次完整工作負載、每 6 個月審查一次 Web 伺服器、每 12 個月審查一次資料庫、每 6 個月審查一次運算和短期儲存，以及每 12 個月審查一次長期儲存。
+ **定義審查完整性：**定義耗費於審查工作負載或工作負載元件的工作量。與審查頻率類似，這需在多個因素之間取得平衡。評估改進機會並制定其優先順序，以將精力集中在可以帶來最大收益的機會上，同時預估這些活動需要多少工作量。如果預期成果未能達到目標，且所需的工作量成本較高，請使用替代行動方案重複進行。您的審查程序應包含專用的時間和資源，用於持續的漸進式改善。例如，您可以決定花費一週分析來資料庫元件、一週分析運算資源，以及花費四小時進行儲存審查。
## 資源
**相關文件：**
+ [AWS 新聞部落格](https://aws.amazon.com/blogs/aws/)
+ [雲端運算的類型](https://aws.amazon.com/types-of-cloud-computing/)
+ [AWS 最新消息](https://aws.amazon.com/new/)
**相關範例：**
+ [AWS 支援主動服務](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)
+ [SAP 工作負載的定期工作負載審查](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-4-4.html)
# COST10-BP02 定期審查和分析此工作負載
現有的工作負載會根據每個定義的程序定期接受審查，以確認是否可採用新服務、是否可取代現有服務、或是否可重新建構工作負載。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
AWS 持續加入新功能，讓您能夠利用最新技術加快試驗及創新速度。[AWS 最新消息](https://aws.amazon.com/new/)會詳述 AWS 執行這項工作的情形，並且在 AWS 服務、功能和區域性擴充公告發行時提供其快速概覽。您可以深入探討已公告推出的項目，並將其用來審查和分析現有的工作負載。若要取得新的 AWS 服務和功能帶來的效益，您必須對工作負載進行審查，並視需要實作新的服務和功能。這表示您可能需要取代用於工作負載的現有服務，或將工作負載現代化，以採用這些新的 AWS 服務。例如，您可以審查工作負載，並使用 Amazon Simple Email Service 取代傳訊元件。這消除了營運和維護執行個體叢集的成本，同時以較低的成本提供所有功能。
若要分析工作負載並凸顯潛在機會，您不僅應考慮使用新服務，也應使用新方法來建置解決方案。觀看 AWS 上的 [This is My Architecture](https://aws.amazon.com/architecture/this-is-my-architecture) 影片以了解其他客戶的架構設計，及其面臨的挑戰和解決方案。查看 [All-In 系列](https://aws.amazon.com/architecture/all-in-series/)，以了解 AWS 服務的實際應用和客戶案例。您也可以觀看 [Back to Basics](https://aws.amazon.com/architecture/back-to-basics/) 影片系列，其中包含對基本雲端架構模式的最佳實務所做的說明、探討和解析。另一個來源是 [How to Build This](https://aws.amazon.com/architecture/how-to-build-this/) 影片，其用意是要協助人們大致了解如何利用 AWS 服務 (MVP) 將其最低可行產品 (MVP) 推出上市。全球各地的建置人員只要有強烈意願想獲得經驗豐富的 AWS 解決方案架構師提供的架構指引，都可循此途徑。最後，您可以檢閱[入門](https://aws.amazon.com/getting-started/)資源素材，其中包含逐步教學課程。
執行審查程序之前，請遵循您的企業在工作負載、安全和資料隱私權等方面的要求，以期在執行您同意的審查程序時，能夠採用特定的服務或區域和效能要求。
**實作步驟**
+ **定期審查工作負載：**使用您定義的程序，以指定的頻率執行審查。確認您在每個元件上付出正確的工作量。此程序與您選取服務來進行成本優化的初始設計程序類似。分析服務以及服務會帶來的效益，此時需考慮變更成本，而不僅僅是長期效益。
+ **實作新服務：**如果分析結果是要實作變更，請先執行工作負載的基準，以了解每個輸出的目前成本。實作變更，然後執行分析以確認每個輸出的新成本。
## 資源
**相關文件：**
+ [AWS 新聞部落格](https://aws.amazon.com/blogs/aws/)
+ [AWS 最新消息](https://aws.amazon.com/new/)
+ [AWS 文件](https://docs.aws.amazon.com/)
+ [AWS 入門](https://aws.amazon.com/getting-started/)
+ [AWS 一般資源](https://docs.aws.amazon.com/#general_resources)
**相關影片：**
+ [AWS - This is My Architecture](https://aws.amazon.com/architecture/this-is-my-architecture)
+ [AWS - Back to Basics](https://aws.amazon.com/architecture/back-to-basics/)
+ [AWS - All-In 系列](https://aws.amazon.com/architecture/all-in-series/)
+ [How to Build This](https://aws.amazon.com/architecture/how-to-build-this/)
# COST 11.如何評估工作的成本？
**Topics**
+ [COST11-BP01 執行操作自動化](cost_evaluate_cost_effort_automations_operations.md)
# COST11-BP01 執行操作自動化
評估雲端操作的工作成本。運用自動化，將管理任務、部署和其他操作所需的時間與工作量化。評估操作的工作所需的時間和成本，並盡可能自動執行管理任務以減少人力付出。
**未建立此最佳實務時的風險暴露等級：**低
自動操作可提升一致性和可擴展性、提供更高的可見性、可靠性和彈性、降低成本，並可藉由釋出人力資源及改善指標而加速創新。它可減少人工作業的頻率、提升效率，且企業可在部署、管理或操作工作負載時享有一致而穩定的體驗。您可以從手動操作任務中釋出基礎設施資源，並將其用於價值更高的任務與創新，進而提升商業成果。企業需要以經過實證和測試的方式來管理其雲端中的工作負載。該解決方案必須安全、快速、符合成本效益，且具有最低的風險和最高的可靠性。
首先，請查看雲端的整體營運成本，以根據所需的工作量訂出操作的優先順序。例如，在雲端中部署新資源、對現有資源進行優化變更，或實作所需的組態，分別需要多久的時間？ 將營運和管理成本納入考量，以查看人為活動的整體成本。排定管理任務自動化的優先順序，以減少人力付出。審查工作應反映潛在的效益。例如，對照手動和自動執行任務花費的時間。優先將重複性、高價值的活動自動化。有風險較高會發生人為錯誤的活動，通常會成為自動化的起點，因為這類風險常伴隨著我們不樂見的額外營運成本 (例如營運團隊的加班費)。
使用 AWS 服務、工具或第三方產品時，您可以選擇要實作及自訂哪些 AWS 自動化以滿足您的特定要求。下表顯示您可以透過 AWS 服務取得哪些核心操作功能與能力，以自動執行管理與操作：
+ [AWS Audit Manager](https://aws.amazon.com/audit-manager/)：持續稽核 AWS 用量以簡化風險和合規的評估
+ [AWS Backup](https://aws.amazon.com/backup/)：集中管理及自動執行資料保護。
+ [AWS Config](https://aws.amazon.com/config/)：設定運算資源，並評估、稽核及衡量組態和資源清查。
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)：使用基礎設施即程式碼啟動高度可用的資源。
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)：IT 變更管理、合規和控制。
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)：排程事件並觸發 AWS Lambda 以採取行動。
+ [AWS Lambda](https://aws.amazon.com/lambda/)：透過事件觸發重複性程序或使用 Amazon EventBridge 按固定排程來執行，藉以自動執行重複性程序。
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)：啟動和停止工作負載、修補作業系統、自動進行設定和持續管理。
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)：排程任務並自動執行工作流程。
+ [AWS Service Catalog](https://aws.amazon.com/servicecatalog/)：符合規範並受到控制的範本取用和基礎設施即程式碼。
考慮所節省的時間，讓您的團隊能夠專注於淘汰技術負債、創新和增值功能。例如，您可能需要將內部部署的環境盡快隨即轉移至雲端，稍後進行優化。使用 AWS 的全受管服務去除或降低授權成本所體現的節省也值得探討，例如 [Amazon Relational Database Service](https://aws.amazon.com/rds/)、[Amazon EMR](https://aws.amazon.com/emr/)、[Amazon WorkSpaces](https://aws.amazon.com/workspaces/) 和 [Amazon SageMaker AI](https://aws.amazon.com/sagemaker/)。受管服務免除了維護服務的營運和管理重擔，讓您專注於創新。此外，因為受管服務以雲端規模運作，可使每次交易或服務的成本較低。
如果您想要使用 AWS 產品和服務立即採用自動化，且您的組織不具備相關技能，請聯繫 [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/)、[AWS Professional Services](https://aws.amazon.com/professional-services/) 或 [AWS 合作夥伴](https://aws.amazon.com/partners/work-with-partners/)，以提升您採用自動化的能力，並改善您在雲端中的營運效能。
[AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) 是代表企業客戶和合作夥伴營運 AWS 基礎設施的服務。它提供安全且合規的環境，您可以將工作負載部署至其中。AMS 使用企業雲端營運模型與自動化，讓您符合組織需求、更快速地遷移至雲端，以及降低持續管理成本。
[AWS Professional Services](https://aws.amazon.com/professional-services/) 也可協助您透過 AWS 達成預期的商業成果和操作的自動化。AWS Professional Services 提供的通用專業實務，可支援您在企業雲端運算的重點領域投入的工作。專業實務會透過解決方案、技術和產業等主題領域適用的最佳實務、架構、工具和服務，提供目標導向的指引。這些實務準則可協助客戶部署自動化、穩健而靈活的 IT 營運及管控能力 (已針對雲端中心進行優化)。
**實作步驟**
+ **建置一次即可多次部署：**使用 AWS CloudFormation、AWS SDK 或 AWS Command Line Interface (AWS CLI) 之類的基礎設施即程式碼部署一次，可以對相同的環境或災難復原案例使用多次。在部署時加上標籤以追蹤您的使用量，如其他最佳實務所定義。使用 [AWS Launch Wizard](https://aws.amazon.com/launchwizard/) 可縮短部署許多常用企業工作負載所需的時間。AWS Launch Wizard 會引導您依據 AWS 最佳實務完成企業工作負載的大小調整、設定和部署。您也可以使用 [AWS Service Catalog](https://aws.amazon.com/servicecatalog/)，這有助於建立及管理基礎設施即程式碼核准用於 AWS 的範本，讓任何人都可探索已核准的自助服務雲端資源。
+ **自動化操作：**自動執行例行性操作而無需人為介入。使用 AWS 服務和工具時，您可以選擇要實作及自訂哪些 AWS 自動化以滿足您的特定要求。例如，使用 [EC2 Image Builder](https://aws.amazon.com/image-builder/) 來建置、測試及部署虛擬機器和容器映像，以用於 AWS 或內部部署。若您所需的動作無法以 AWS 服務完成，或您需要使用篩選資源的複雜動作，請使用 [AWS CLI](https://aws.amazon.com/cli/index.html) 或 AWS SDK 工具將操作自動化。AWS CLI 可讓您透過指令碼自動執行控制及管理 AWS 服務的完整程序，而無須使用 AWS 主控台。選取您慣用的AWS SDK 與 AWS 服務互動。如需其他程式碼範例，請參閱 [AWS SDK 程式碼範例儲存庫](https://github.com/awsdocs/aws-doc-sdk-examples)。
## 資源
**相關文件：**
+ [將 AWS 雲端 中的操作現代化](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-operations-integration/welcome.html)
+ [用於自動化的 AWS 服務](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-operations-integration/aws-services-for-automation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [用於 SAP 管理和操作的 AWS 自動化](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-sap-automation/automations.html)
+ [AWS Managed Services](https://aws.amazon.com/managedservices/index.html)
+ [AWS Professional Services](https://aws.amazon.com/professional-services/)
+ [基礎設施和自動化](https://aws.amazon.com/blogs/infrastructure-and-automation/)
**相關範例：**
+ [重塑自動化操作 (第 I 部分)](https://aws.amazon.com/blogs/mt/reinventing-automated-operations-part-i/)
+ [重塑自動化操作 (第 II 部分)](https://aws.amazon.com/blogs/mt/reinventing-automated-operations-part-ii/)
+ [用於 SAP 管理和操作的 AWS 自動化](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-sap-automation/automations.html)
+ [AWS Lambda 的 IT 自動化](https://aws.amazon.com/lambda/it-automation/)
+ [AWS 程式碼範例儲存庫](https://github.com/awsdocs/aws-doc-sdk-examples)
+ [AWS 範例](https://github.com/aws-samples)