

# 了解支出和用量
<a name="expenditure-and-usage-awareness"></a>

 了解組織的成本和驅動因素對於有效管理成本和用量以及識別降低成本的機會至關重要。組織通常會營運由多個團隊執行的多個工作負載。這些團隊可能分屬不同組織單位，各有本身的收入流。能夠將資源成本歸因於工作負載、個別組織或產品擁有者，這可推動高效的使用行為並有助於減少浪費。準確的成本和用量監控可讓您了解組織單位和產品的獲利能力，並允許您對組織內的資源分配做出更明智的決策。讓組織內所有層級建立用量意識，這是推動變革的關鍵，因為用量變化會帶來成本變化。

 請考慮採行多面向的方法以了解您的用量和開支。您的團隊必須收集資料，進行分析，然後報告。要考量的關鍵因素包括：

**Topics**
+ [控管](governance.md)
+ [監控成本與用量](monitor-cost-and-usage.md)
+ [停用資源](decommission-resources.md)

# 控管
<a name="governance"></a>

為了管理雲端的成本，您必須透過以下管控方面來管理用量：

**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 根據貴組織的需求制定政策
<a name="cost_govern_usage_policies"></a>

制定定義組織如何管理資源的政策，並定期加以檢查。政策應涵蓋資源和工作負載的成本面向，包括資源生命週期中的建立、修改和停用。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

了解組織的成本和動因對於有效管理成本和用量，以及識別降低成本的機會至關重要。組織通常會營運由多個團隊執行的多個工作負載。這些團隊可能分屬不同組織單位，各有本身的收入流。將資源成本歸因至工作負載、個別組織或產品擁有者的能力，能夠帶動高效使用的行為模式，並且有助於減少浪費。精確的成本和用量監控可協助您了解工作負載的優化程度，以及組織單位和產品的獲利程度。這項知識可讓您更明智地決定應將資源分配到組織內的何處。讓組織內所有層級建立用量意識，這是推動變革的關鍵，因為用量變化會帶來成本變化。請考慮採行多面向的方法以了解您的用量和開支。

執行管控的第一步是使用組織的要求來制定雲端使用政策。這些政策定義您的組織如何使用雲端以及如何管理資源。政策應涵蓋資源和工作負載的成本或用量的各面向，包括在資源生命週期中資源的建立、修改和停用。確認已遵循政策和程序，並已實作雲端環境中的任何變更。在 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 來強制執行政策。此外，您應定期審核資源用量，並視需要調整政策，以確認政策持續符合您的商業需求。

## 實作步驟
<a name="implementation-steps"></a>
+  **與利益相關者會面：**若要制定政策，請要求組織內的利益相關者 (雲端業務辦公室、工程師或執行政策的功能決策者) 指定其要求，並將其記錄下來。採取反復的方法，從廣泛討論開始，然後在每個步驟持續細化至最小的單位。團隊成員包括對工作負載有直接關係的人員，例如組織單位或應用程式擁有者，以及支援群組，例如安全和財務團隊。
+  **獲取確認：**確定團隊成員均同意誰可對 AWS 雲端 進行存取及部署的政策。請確定成員遵循組織的政策，並確認其資源建立符合議定的政策和程序。
+  **建立上線培訓課程：**要求新進的組織成員完成上線培訓課程，以建立對成本的掌握度和組織要求。他們可以根據自身過往的經驗採行不同的政策，也可以完全不列入考量。
+ **定義工作負載的位置：**定義工作負載運作的位置，包括國家和國家中的區域。這項資訊用來對應至 AWS 區域 和可用區域。
+ **定義並分組服務和資源：**定義工作負載所需的服務。針對每項服務，指定所需的類型、大小和資源數量。依職能定義資源群組，例如應用程式伺服器或資料庫儲存體。資源可屬於多個群組。
+  **依職能定義並分組使用者：**定義與工作負載互動的使用者，專注於使用者執行的操作以及他們如何使用工作負載，而不是專注於他們的身分或他們在組織中的位置。將類似的使用者或職能分組在一起。您可以使用 AWS 受管政策做為指南。
+ **定義動作：**使用先前識別的位置、資源和使用者，定義每個項目在其生命週期內 (開發、營運和停用) 達成工作負載結果所需的動作。根據每個位置中的群組 (不是群組中的個別元素) 來識別動作。從廣泛地讀取或寫入開始，然後縮小精細至每項服務的特定動作。
+ **定義審查期間：**工作負載和組織需求可能會隨時間變更。定義工作負載審查排程，以確保其與組織優先事項保持一致。
+  **記錄政策：**確認組織可視需要存取已定義的政策。這些政策用於實作、維護和稽核環境的存取權。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [雲端中的變更管理](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) 

# COST02-BP02 實作總目標和具體目標
<a name="cost_govern_usage_goal_target"></a>

 為您的工作負載實作成本與用量的總目標和具體目標。總目標可為您的組織提供預期成果的方向，具體目標則可提供要為您的工作負載達成的特定可測量成果。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 為您的組織制定成本與用量總目標和具體目標。作為 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%，成本增加少於百分之五，則是具體目標範例。另一個常見的總目標是工作負載每六個月必須更有效率。相關的具體目標是每個業務指標的成本每六個月需要減少百分之五。使用正確的指標，並為組織設定已計算好的 KPI。可以從基礎 KPI 開始，並在稍後根據業務需求進行發展。

 成本優化的總目標是提高工作負載效率，這對應於工作負載的每個業務成果的成本隨著時間而降低。為所有工作負載實作這個總目標，並設定具體目標，例如每六個月至一年將效率提高百分之五。在雲端中，可以透過建立成本最佳化功能以及發行新服務和功能來達成此目標。

 具體目標是您希望達到以達到的可量化基準，以實現總體目標，而基準則會將您的實際結果與具體目標進行比較。使用 KPI 針對每個運算單位服務的成本 (例如 Spot 採用、Graviton 採用、最新執行個體類型和隨需涵蓋範圍)、儲存服務 (例如 EBS GP3 採用、過時的 EBS 快照和 Amazon S3 標準儲存) 或資料庫服務用量 (例如 RDS 開放原始碼引擎、Graviton 採用和隨需涵蓋範圍) 建立基準。這些基準和 KPI 可協助您確認是否以最具成本效益的方式使用 AWS 服務。

 下表列出標準 AWS 指標，以供參考。每個組織可以針對這些 KPI 設定不同的目標值。


|  類別  |  KPI (%)  |  描述  | 
| --- | --- | --- | 
|  運算  |  EC2 用量涵蓋範圍  |  使用 SP\$1RI\$1Spot 的 EC2 執行個體 (以成本或小時為單位) 與 EC2 執行個體的總計 (以成本或小時為單位) 的比較  | 
|  運算  |  計算 SP/RI 使用率  |  與總體可用的 SP 或 RI 小時數相比，已使用的 SP 或 RI 小時數  | 
|  運算  |  EC2/小時成本  |  EC2 成本除以該小時內執行的 EC2 執行個體數量  | 
|  運算  |  vCPU 成本  |  所有執行個體的每個 vCPU 成本  | 
|  運算  |  最新一代執行個體  |  Graviton (或其他新一代執行個體類型) 上的執行個體百分比  | 
|  資料庫  |  RDS 涵蓋範圍  |  使用 RI 的 RDS 執行個體 (以成本或小時為單位) 與 RDS 執行個體的總計 (以成本或小時為單位) 的比較  | 
|  資料庫  |  RDS 使用率  |  與總體可用的 RI 小時數相比，已使用的 RI 小時數  | 
|  資料庫  |  RDS 執行時間  |  RDS 成本除以該小時內執行的 RDS 執行個體數量  | 
|  資料庫  |  最新一代執行個體  |  Graviton (或其他現代執行個體類型) 上的執行個體百分比  | 
|  儲存  |  儲存使用率  |  最佳化儲存成本 (例如 Glacier、Deep Archive 或 Infrequent Access) 除以總儲存成本  | 
|  標記  |  未標記資源  |   Cost Explorer：  1. 篩選掉抵用金、折扣、稅金、退款、市場，並複製最新的每月成本   2. 在 Cost Explorer 中選取**僅顯示未標記的資源**   3. 將**未標記資源**中的金額除以您的每月成本。  | 

 使用此表格，包括目標或基準值，應根據組織目標計算這些值。您需要衡量業務的某些指標，並了解該工作負載的業務成果，以定義準確且切合實際的 KPI。當您評估組織內的績效指標時，請區分服務於不同目的之不同類型的指標。這些指標主要衡量技術基礎設施的效能和效率，而不是直接衡量整體業務影響。例如，它們可能會追蹤伺服器響應時間、網路延遲或系統正常運行時間。這些指標對於評估基礎設施如何支援組織的技術操作至關重要。但是，它們不能直接洞察更廣泛的業務目標，例如客戶滿意度，收入增長或市場份額。為了全面了解業務績效，請使用與業務成果直接相關的策略性業務指標來補充這些效率指標。

 要能夠近乎即時地檢視 KPI 和相關節省機會，並追蹤一段時間內的進度。若要開始定義和追蹤 KPI 總目標，建議您使用[雲端智慧儀表板](https://wellarchitectedlabs.com/cloud-intelligence-dashboards/) (CID) 中的 KPI 儀表板。根據來自成本和用量報告 (CUR) 的資料，KPI 儀表板會提供一系列建議的成本優化 KPI，讓您能夠設定自訂總目標以及追蹤一段時間內的進度。

 如果您有其他解決方案可以設定和追蹤 KPI 總目標，請確定組織中的所有雲端財務管理利益相關者都採用這些方法。

### 實作步驟
<a name="implementation-steps"></a>
+  **定義預期的用量等級：**首先，請關注用量等級。與應用程式擁有者、行銷團隊和更大的業務團隊互動，以了解工作負載的預期用量等級。客戶需求如何隨著時間而變更，以及因季節性增加或行銷活動會發生哪些變更？ 
+  **定義工作負載資源與成本：**定義用量等級後，量化達成這些用量等級所需的工作負載資源變更。您可能需要為工作負載元件增加資源的大小或數量、增加資料傳輸，或將工作負載元件變更為特定等級的不同服務。指定每個要點的成本，並預測當用量發生變化時成本會有什麼變化。
+  **定義業務總目標：**從預期用量和成本變更中取得輸出，將此項目與預期的技術變更或任何您正在執行的計畫結合，並制定工作負載的總目標。總目標必須涵蓋用量和成本，以及兩者之間的關係。總目標必須簡單具體，以協助大家了解企業預期的成果 (例如，確保將未使用的資源控制在特定成本水位以下)。無須為每個未使用的資源類型定義總目標，也不需要為總目標和具體目標定義造成損失的成本。如果預期有成本變更但用量不變，請確認制定有組織計畫 (例如培訓和教育等能力打造計畫)。
+  **定義具體目標：**對於定義的每個總目標，指定可測量的具體目標。如果總目標是要提高工作負載的效率，具體目標將會量化改善的程度 (通常是所有經費所獲得的業務輸出)，及其達成時間。例如，可設定一個總目標，以盡量減少因過度佈建而造成的浪費。有了這個總目標後，您的具體目標可能是生產工作負載第一層中的運算過度佈建產生的浪費不應超過分層運算成本的 10%。此外，第二個具體目標可能是生產工作負載第二層中的運算過度佈建產生的浪費不應超過分層運算成本的 5%。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [工作職能的 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/) 
+  [使用 IAM 政策控制對 AWS 區域 的存取](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [S.M.A.R.T. 目標](https://en.wikipedia.org/wiki/SMART_criteria) 
+  [如何使用 CID KPI 儀表板追蹤成本最佳化 KPI](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/) 

 **相關影片：**
+  [Well-Architected 實驗室：總目標和具體目標 (Level 100)](https://catalog.workshops.aws/well-architected-cost-optimization/en-US/2-expenditure-and-usage-awareness/150-goals-and-targets) 

 **相關範例：**
+  [什麼是單位指標](https://aws.amazon.com/blogs/aws-cloud-financial-management/what-is-a-unit-metric/)？ 
+  [選擇單位指標以支援您的業務](https://aws.amazon.com/blogs/aws-cost-management/selecting-a-unit-metric-to-support-your-business/) 
+  [實務中的單位指標 — 經驗教訓](https://aws.amazon.com/blogs/aws-cost-management/unit-metrics-in-practice-lessons-learned/) 
+  [單位指標如何幫助在業務職能之間建立一致性](https://aws.amazon.com/blogs/aws-cost-management/unit-metrics-help-create-alignment-between-business-functions/) 

# COST02-BP03 實作帳戶結構
<a name="cost_govern_usage_account_structure"></a>

 實作與您的組織對應的帳戶結構。這有助於在整個組織中分配和管理成本。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 AWS Organizations 可讓您建立多個 AWS 帳戶，當您在 AWS 上擴展工作負載時，這可協助您集中管控環境。您可以採用組織單位 (OU) 結構來為 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 服務限制是依照特定工作負載區分所設定。
+ 工作負載和資源之間需要區隔和隔離。

 在 [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 來處理各種使用案例和工作負載，以便提供用於整理帳戶的模式。

![\[樹狀圖顯示如何將多個帳戶分組到組織單位下。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/cost-optimization-pillar/images/aws-organizations-ou-grouping.png)


 [AWS Control Tower](https://aws.amazon.com/controltower/) 可以快速建立和設定多個 AWS 帳戶，確保管控符合組織的要求。

**實作步驟** 
+  **定義分隔要求：**分隔要求是多個因素的組合，包括安全性、可靠性和財務結構。依序處理每個因素，並指定工作負載或工作負載環境是否應與其他工作負載分開。為了安全，我們必須遵守存取和資料要求。為求可靠，我們必須有所限制，以免環境和工作負載影響其他資源。請定期審核 Well-Architected 架構的安全性和可靠性支柱，並遵循其中所提供的最佳實務。財務結構會建立嚴格的財務分隔 (不同的成本中心、工作負載擁有權和責任)。常見的分隔範例是生產和測試工作負載會在不同的帳戶開始執行，或使用單獨的帳戶，以便將發票和帳單資料提供給組織內的個別業務單位或部門，或是擁有帳戶的利益相關者。
+  **定義分組要求：**分組要求不會覆寫分隔要求，而是用來協助管理。將不需要分隔的類似環境或工作負載分成同一組。例如，將來自一或多個工作負載的多個測試或開發環境分組在一起。
+  **定義帳戶結構：**使用這些分隔和分組，為每個群組指定一個帳戶，並維護分隔要求。這些帳戶是您的成員帳戶或連結帳戶。透過將這些成員帳戶分組到單一管理帳戶或付款人帳戶下，您可以結合用量，以讓所有帳戶獲得更多數量折扣，而為所有帳戶提供單一帳單。您可以分隔帳單資料，以便在每個成員帳戶中檢視單獨的帳單資料。如果不允許透過任何其他帳戶查看某個成員帳戶中的用量或帳單資料，或是需要與 AWS 分開的帳單，請定義多個管理帳戶或付款人帳戶。在這種情況下，每個成員帳戶都有自己的管理帳戶或付款人帳戶。資源應一律放在成員或連結帳戶中。管理帳戶或付款人帳戶只能用於管理。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [使用成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.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/) 
+  [使用 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)

 **相關範例：**
+  [定義電信公司的 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 實作群組和角色
<a name="cost_govern_usage_groups_roles"></a>

 實作符合您政策的群組和角色，並控制哪些人員可以建立、修改或停用每個群組中的執行個體和資源。例如，實作開發、測試和生產群組。這適用於 AWS 服務和第三方解決方案。

 **未建立此最佳實務時的曝險等級：**低 

## 實作指引
<a name="implementation-guidance"></a>

使用者角色和群組是設計和實作安全高效系統的基礎建置組塊。角色和群組可協助組織在控制需求與靈活性和生產力的要求兩方面取得平衡，從而最終能支援組織目標和使用者需求。如同 AWS Well-Architected Framework 安全支柱的[身分識別與存取管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html)部分所建議，您需要強大的身分識別管理和權限，才能在適當的條件下為適當的人員提供適當資源的存取權。使用者只會獲得要完成其任務所需的存取權。這可將未經授權存取或濫用的相關風險降至最低。

 在制定政策後，您可以在組織內建立邏輯群組和使用者角色。這可讓您指派許可、控制使用情況，並協助實作強大的存取控制機制，防止有人未經授權存取敏感資訊。從簡要的人員分組開始。通常這與組織單位和工作角色 (例如 IT 部門的系統管理員、財務控制者或商業分析師) 相符。這些群組會將執行類似任務且需要類似存取權限的人員進行分類。角色定義群組必須執行的工作。管理群組和角色的許可會比管理個別使用者的許可容易。角色和群組能以一致且有系統的方式為所有使用者指派許可，以避免錯誤和不一致。

 當使用者的角色變更時，管理員可以調整角色或群組層級的存取權，而不是重新設定個別使用者帳戶。例如，IT 的系統管理員需要建立所有資源的存取權限，但分析團隊成員只需要建立分析資源的權限。

### 實作步驟
<a name="implementation-steps"></a>
+ **實作群組：**使用組織政策中定義的使用者群組，視需要實作對應的群組。如需有關使用者、群組和驗證的最佳實務，請參閱 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)。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [工作職能的 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)

 **相關影片：**
+ [為何使用 Identity and Access Management](https://www.youtube.com/watch?v=SXSqhTn2DuE)

 **相關範例：**
+  [使用 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 實作成本控制
<a name="cost_govern_usage_controls"></a>

 根據組織政策以及定義的群組和角色實作控制。這些控制措施可證明成本的發生始終符合組織要求：例如，控制對區域或資源類型的存取。

 **未建立此最佳實務時的曝險等級：**中 

## 實作指引
<a name="implementation-guidance"></a>

實作成本控制常見的第一步設定在發生偏離政策的成本或用量事件時發出通知。您可以快速採取動作，並驗證是否需要採取糾正措施，而不會限制或對工作負載或新的活動造成負面影響。了解工作負載和環境限制之後，就可以強制執行管控。[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 政策中可包含多項組織政策。使用與您定義政策相同的方式，一開始廣泛定義，然後在每個步驟中套用更精細的控制措施。服務限制也能有效控制用量。在您所有帳戶中實作正確的服務限制。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [工作職能的 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/) 
+  [使用 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/) 
+  [限制 IAM 身分對特定 Amazon EC2 資源的存取](https://aws.amazon.com/premiumsupport/knowledge-center/restrict-ec2-iam/) 
+  [使用聊天應用程式中的 Amazon Q Developer 進行成本異常偵測的 Slack 整合](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/) 

# COST02-BP06 追蹤專案生命週期
<a name="cost_govern_usage_track_lifecycle"></a>

 追蹤、測量和稽核專案、團隊和環境的生命週期，以避免使用不必要的資源並節省成本。

 **未建立此最佳實務時的曝險等級：**低 

## 實作指引
<a name="implementation-guidance"></a>

 透過有效追蹤專案生命週期，組織可以透過強化的規劃、管理和資源最佳化來實現更好的成本控制。透過追蹤所獲得的見解十分寶貴，可讓您做出有助於專案成本效益和整體成功率的明智決策。

 追蹤工作負載的整個生命週期可協助您了解何時不再需要工作負載或工作負載元件。現有的工作負載和元件可能正在使用中，但 AWS 當發行新的服務或功能時，它們可以停用或採用。檢查工作負載的先前階段。工作負載進入生產環境後，之前的環境可能會停用或大幅降低容量，直到再次需要這些環境為止。

 您可以使用時間範圍或提醒來標記資源，以固定審核工作負載的時間。舉例來說，如果開發環境上次是在幾個月前進行審核，那麼現在是時候再次審核，以探索是否可以採用新的服務，或是環境是否正在使用中。您可以在 [myApplications](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/aws-myApplications.html) 上將應用程式分組和標記 AWS ，以管理和追蹤重要性、環境、上次檢閱和成本中心等中繼資料。可以追蹤工作負載的生命週期，監控和管理應用程式的成本、運作狀態、安全狀態和效能。

 AWS 提供各種管理和治理服務，可用於實體生命週期追蹤。您可以使用 [https://aws.amazon.com/config/](https://aws.amazon.com/config/)或 [https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/) 提供 AWS 資源和組態的詳細清查。建議與您現行的專案或資產管理系統整合，與持續追蹤您的組織進行中的專案和產品。將您目前的系統與 提供的豐富事件和指標集相結合， AWS 可讓您建立重大生命週期事件的檢視，並主動管理 資源以減少不必要的成本。

 與 [Application Lifecycle Management （ALM）](https://aws.amazon.com/what-is/application-lifecycle-management/) 類似，追蹤專案生命週期應涉及多個程序、工具和團隊合作，例如設計和開發、測試、生產、支援和工作負載備援。

 透過仔細監控專案生命週期的每個階段，組織可以獲得重要的洞見和增強控制，促進成功的專案規劃、實作和完成。這種仔細的監督會驗證專案不僅符合品質標準，而且會準時地在預算內交付，從而提高整體成本效率。

 如需有關實作實體生命週期追蹤的詳細資訊，請參閱 [https://aws.amazon.com/architecture/well-architected/](https://aws.amazon.com/architecture/well-architected/)。

### 實作步驟
<a name="implementation-steps"></a>
+  **建立專案生命週期監控程序：**[雲端卓越中心團隊](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_cloud_financial_management_function.html)必須建立專案生命週期監控程序。建立結構化與系統化的方法來監控工作負載，以改善專案的控制、可見性和效能。讓監控流程透明、協作並專注於持續改進，以最大程度地提高其有效性和價值。
+  **執行工作負載審核：**根據組織政策所定義，設定一個定期節奏以稽核現有專案並執行工作負載審核。在稽核上付出的工作量應與組織的大致風險、價值或成本成正比。要納入稽核的關鍵領域包括事件或中斷給組織帶來的風險、對組織的價值或貢獻 (以收入或品牌聲譽來衡量)、工作負載成本 (以資源總成本和營運成本來衡量)，以及工作負載用量 (以每單位時間的組織結果數量來衡量)。如果這些領域在生命週期內發生變化，則需要調整工作負載，例如完整或部分停用。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [上的標記指南 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/IAM/latest/UserGuide/access_policies_job-functions.html) 

 **相關範例：**
+  [AWS 區域 使用IAM政策控制對 的存取](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/?c=mg&sec=srv) 

# 監控成本與用量
<a name="monitor-cost-and-usage"></a>

 讓團隊透過詳細檢視工作負載的方式，對成本和用量採取動作。成本優化始於對成本和用量細分的詳細了解，建立模型並預測未來支出、用量和功能的能力，以及實作足夠的機制，讓成本和用量符合組織的目標。以下是監控成本和用量的必要方面：

**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 設定詳細資訊來源
<a name="cost_monitor_usage_detailed_source"></a>

設定成本管理和報告工具，以增強分析以及成本和用量資料的透明度。設定您的工作負載以建立日誌項目，以便追蹤和隔離成本和用量。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 詳細的帳單資訊 (例如成本管理工具中的每小時精細度) 可讓組織更詳細地追蹤其耗用量，並協助他們找出一些成本增加的原因。這些資料來源提供整個組織最準確的成本和用量的檢視。

 可以使用 AWS 資料匯出 來建立 AWS Cost and Usage Report (CUR) 2.0 的匯出。這是從 AWS 接收詳細成本和用量資料的最新建議方法。它提供所有 AWS 收費服務的每日或每小時使用精細度、費率、成本和使用屬性 (與 CUR 的資訊相同)，以及一些改進。CUR 中包含所有可能的維度，例如：標記、位置、資源屬性和帳戶 ID。

 根據您要建立的匯出類型，有三種匯出類型：標準資料匯出、透過 Quick 整合匯出至成本和用量儀表板，或是舊式資料匯出。
+  **標準資料匯出：**表格的自訂匯出，可定期交付給 Amazon S3。
+  **成本和用量儀表板：**匯出和整合至 Quick，以部署預先建置的成本和用量儀表板。
+  **舊式資料匯出：**舊式 AWS Cost and Usage Report (CUR) 的匯出。

 可以使用下列自訂來建立資料匯出：
+  包含資源 ID 
+  分割成本分配資料 
+  每小時的精細程度 
+  版本控制 
+  壓縮類型和檔案格式 

 對於在 Amazon ECS 或 Amazon EKS 上執行容器的工作負載，請啟用分割成本分配資料，以便根據容器工作負載消耗共用運算和記憶體資源的方式，將容器成本分配給個別業務單位和團隊。分割成本分配資料會將新容器層級資源的成本和用量資料引入 AWS Cost and Usage Report。分割成本分配資料是透過運算在叢集上執行的個別 ECS 服務和任務的成本來計算的。

 成本和用量儀表板會定期將成本和用量儀表板資料表匯出到 S3 儲存貯體，並將預先建立的成本和用量儀表板部署到 Quick。如果想要在不進行自訂的情況下快速部署成本和用量資料的儀表板，請使用此選項。

 如有需要，仍可以使用舊版模式匯出 CUR，在這裡您可以整合其他處理服務，例如 [AWS Glue](https://aws.amazon.com/glue/)，以準備要分析的資料，並使用 SQL 來查詢資料，從而透過 [Amazon Athena](https://aws.amazon.com/athena/) 執行資料分析。

### 實作步驟
<a name="implementation-steps"></a>
+  **建立資料匯出：**使用您想要的資料建立自訂匯出，並控制匯出結構描述。使用基礎 SQL 建立帳單和成本管理資料匯出，並透過與 Quick 整合，將您的帳單和成本管理資料視覺化。也可以使用標準模式匯出資料，以使用 Amazon Athena 等其他處理工具來分析資料。
+  **設定成本和用量報告：**使用帳單主控台，設定至少一個成本和用量報告。用含所有識別符與資源 ID 的每小時精細度設定報告。您也可以使用不同的精細度建立其他報告，以提供較高層級的摘要資訊。
+  **在 Cost Explorer 中設定每小時精細度：**若要存取過去 14 天內每小時精細度的成本和用量資料，請考慮在帳單主控台中啟用每小時和資源層級資料。
+  **設定應用程式日誌記錄：**確認您的應用程式會記錄其交付的每個業務成果，以便追蹤和衡量相應成果。確保此資料的精細度至少為每小時，以便與成本和用量資料相符。如需有關日誌記錄和監控的詳細資訊，請參閱[Well-Architected 卓越營運支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [AWS 資料匯出](https://docs.aws.amazon.com/cur/latest/userguide/what-is-data-exports.html) 
+  [AWS Glue](https://aws.amazon.com/glue/) 
+  [快速](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) 
+  [使用 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 帳戶設定](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html) 
+ [用於 AWS 帳單和成本管理的資料匯出](https://aws.amazon.com/blogs/aws-cloud-financial-management/introducing-data-exports-for-billing-and-cost-management/)
+  [AWS Cost Explorer 常用案例](https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-cost-explorers-new-ui-and-common-use-cases/) 

# COST03-BP02 將組織資訊新增至成本與用量
<a name="cost_monitor_usage_org_information"></a>

根據您的組織、工作負載屬性和成本分配類別來定義標記結構描述，以便您在成本管理工具中篩選及搜尋資源，或監控成本與用量。情況允許時，依據目的、團隊、環境，或其他與您的業務有關的條件，在所有資源間實作一致的標記。

 **未建立此最佳實務時的曝險等級：**中 

## 實作指引
<a name="implementation-guidance"></a>

在 [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) 讓您可以新增、刪除和管理多個資源的標籤。利用標籤編輯器，您會搜尋要加標籤的資源，然後為搜尋結果中的資源管理標籤。

[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 函數建立自訂解決方案以進行自動標記，或者使用可定期掃描工作負載並移除任何未標記資源的微型服務，這非常適合用於測試和開發環境。
+ **監控和報告標記：**為驗證您可在整個組織中保有高層級標記，請報告並監控工作負載間的標籤。您可以使用 [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) 等服務。定期審查未標記資源的數量，並採取措施來新增標籤，直至達到所需的標記層級。

## 資源
<a name="resources"></a>

 **相關文件：**
+ [標記最佳實務](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 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 資源以按成本中心或專案劃分帳單](https://www.youtube.com/watch?v=3j9xyyKIg6w)
+ [標記 AWS 資源](https://www.youtube.com/watch?v=MX9DaAQS15I)

# COST03-BP03 識別成本歸因類別
<a name="cost_monitor_usage_define_attribution"></a>

 識別組織分類 (例如業務單位、部門或專案)，這些分類可以將組織內的成本分配給內部取用實體。使用這些分類來強制執行支出權責劃分、建立成本感知並推動有效的取用行為。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 成本分類的程序對預算、會計、財務報告、決策制定、基準和專案管理至關重要。透過對費用進行分類，團隊可更加了解他們在整個雲端之旅中將產生的成本類型，從而做出明智的決策並有效管理預算。

 雲端支出權責劃分為有紀律的需求和成本管理建立了有力的誘因。對於將大部分雲端支出分配給取用業務單位或團隊的組織，這樣可以大幅節省雲端成本。此外，分配雲端支出有助於組織採用更多集中式雲端控管的最佳實務。

 在定期會議中與財務團隊和其他相關利益相關者合作，了解在組織內分配成本的要求。工作負載成本必須在整個生命週期中分配，包括開發、測試、生產和停用。了解組織內學習、員工發展和創意成本的狀況。這有助於將用於此目的的帳戶正確分配到培訓和開發預算，而不是籠統的 IT 成本預算。

 與組織中的利益相關者一起定義成本歸因類別之後，請在 AWS 雲端 中使用 [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 將成本與用量資訊分組為有意義的類別，例如特定專案的成本或者部門或業務單位的 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/latest/cost-optimization-pillar/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 中，成本類別會顯示為額外的帳單維度。您可以使用該值來篩選特定的成本類別值，或依成本類別分組。

### 實作步驟
<a name="implementation-steps"></a>
+  **定義您的組織類別：**與內部利益相關者和業務單位會談，定義可反映組織結構和要求的類別。這些類別應該直接對應至現有財務類別的結構，例如業務單位、預算、成本中心或部門。查看雲端服務為您的業務帶來的成果，例如培訓或教育，因為這些也是屬於組織類別。
+  **定義您的功能類別：**與內部利益相關者和業務單位會談，定義可反映您在企業內具有之職能的類別。這可能是工作負載或應用程式名稱，以及環境類型，例如生產、測試或開發。
+  **定義 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)中。您可以將多個類別指派給一個資源，而資源可以位於多個不同的類別中，因此請視需要定義任意數量的類別，以便可使用 AWS Cost Categories 在分類的結構中[管理您的成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html)。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [標記 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/) 

# COST03-BP04 建立組織指標
<a name="cost_monitor_usage_define_kpi"></a>

 建立此工作負載所需的組織指標。工作負載的指標範例包括產生的客戶報告或向客戶提供的網頁。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

了解工作負載的輸出是否算得上業務成功。每個工作負載通常都有少數幾個能夠指出效能的主要輸出。如果您有包含許多元件的複雜工作負載，則可以排定清單的優先順序，或定義和追蹤每個元件的指標。與您的團隊合作，以了解要使用哪些指標。此單位將用於了解工作負載的效率，或每個業務輸出的成本。

**實作步驟**
+  **定義工作負載成果：**與業務中的利益相關者會面，並定義工作負載的成果。這些是客戶用量的主要衡量方式，並且必須是業務指標而非技術指標。每個工作負載應該有少量的高層級指標 (少於五個)。如果工作負載為不同的使用案例產生多個成果，請將它們分組為單一指標。
+  **定義工作負載元件成果：**或者，如果您有大型且複雜的工作負載，或者可以用明確定義的輸入和輸出，輕鬆地將工作負載分成元件 (例如微型服務)，則請為每個元件定義指標。工作應該反映元件的價值和成本。從最大的元件開始，並向較小的元件運行。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [標記 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) 

# COST03-BP05 設定帳單和成本管理工具
<a name="cost_monitor_usage_config_tools"></a>

 設定符合組織政策的成本管理工具，以管理及優化雲端支出。其中包括以服務、工具和資源來組織及追蹤成本與用量資料、透過整合的帳單和存取許可加強控制、透過預算制定與預測提升規劃效能、接收通知或提醒，以及藉由資源與定價優化降低成本。

 **未建立此最佳實務時的風險暴露等級**：高 

## 實作指引
<a name="implementation-guidance"></a>

 為了建立健全的權責劃分，應先將帳戶策略視為成本分配策略的一部分。正確做到這一點，應該就夠了。否則，後續會發生意料之外和棘手的問題。

 為了鼓勵雲端支出的權責劃分，使用者應有權存取可讓他們檢視成本與用量的工具。AWS 建議您基於下列目的設定所有工作負載和團隊：
+  **組織：**使用您自己的標記策略和分類法，來建立成本分配與管控基準。使用 AWS Control Tower 或 AWS Organization 等工具建立多個 AWS 帳戶。標記支援的 AWS 資源，並根據您的組織結構 (業務單位、部門或專案) 進行有意義的分類。標記特定成本中心的帳戶名稱，並與 AWS Cost Categories 對應，以將其成本中心的業務單位的帳戶分組，讓業務單位擁有者可在一個位置查看多個帳戶的耗用量。
+  **存取：**在合併帳單中追蹤整個組織的帳單資訊。確認適當的利益相關者和企業擁有者具有存取權。
+  **控制：**使用適當防護機制建立有效控管機制，以避免在使用服務控制政策 (SCP)、標記政策、IAM 政策和預算警示時發生意外狀況。例如，您可以允許團隊只使用有效的控制機制在首選區域中建立特定資源，並防止在沒有特定標籤的情況下建立資源 (例如成本中心)。
+  **目前狀態：**設定儀表板，顯示目前的成本和用量級別。儀表板應在工作環境中顯眼的位置提供，類似於營運儀表板。可以匯出資料，並使用 AWS 成本最佳化中心的成本和用量儀表板或任何支援產品來建立此可見性。您可能需要為不同的角色建立不同的儀表板。例如，管理員儀表板可能與工程儀表板不同。
+  **通知：**使用「AWS 預算」或「AWS 成本異常偵測」，在成本或用量超過定義的限制並發生異常情況時提供通知。
+  **報告：**彙總所有成本和用量資訊。利用詳細的可歸因成本資料，提高雲端支出的意識和責任。建立與使用這些報告的團隊相關且包含建議的報告。
+  **追蹤：**顯示相對於設定的總目標或具體目標目前成本和用量的狀況。
+  **分析：**允許團隊成員使用不同的篩選條件 (資源、帳戶、標籤等) 執行自訂和深度分析，精確到每小時、每日或每月。
+  **檢查：**隨時掌握資源部署和成本最佳化商機的最新資訊。使用 Amazon CloudWatch、Amazon SNS 或 Amazon SES 接收通知，以便在組織層級進行資源部署。使用 AWS Trusted Advisor 或 AWS Compute Optimizer 審核成本最佳化建議。
+  **趨勢報告：**以所需的精細度顯示所需期間內的成本與用量變化。
+  **預測：**使用您建立的預測儀表板顯示預估的未來成本，以及預估您的資源用量和支出。

 您可以使用 [AWS 成本最佳化中心](https://aws.amazon.com/aws-cost-management/cost-optimization-hub/)，了解從中央位置整合的潛在成本節省機會，並建立資料匯出以便與 Amazon Athena 整合。您也可以使用 AWS 成本最佳化中心來部署成本和用量儀表板，它利用 Quick 進行互動式成本分析和安全的成本洞察分享。

 如果您的組織中沒有基本技能或頻寬，可以使用 [AWS ProServ](https://aws.amazon.com/professional-services/)、[AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) 或 [AWS 合作夥伴](https://aws.amazon.com/partners/)。您也可以使用第三方工具，但請務必驗證價值主張。

### 實作步驟
<a name="implementation-steps"></a>
+  **允許以團隊為基礎的工具存取權：**設定您的帳戶並建立群組，以存取所需的成本和用量報告以供其使用，並使用 [AWS Identity and Access Management](https://aws.amazon.com/iam/) 來控制諸如 AWS Cost Explorer 等工具的[存取權](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html)。這些群組必須包含擁有或管理應用程式的所有團隊中的代表。這可證明每個團隊都能存取其成本和用量資訊以追蹤取用情形。
+  **管理成本標籤和類別：**跨團隊、業務單位、應用程式、環境和專案來管理成本。使用資源標籤依成本分配標籤來管理成本。使用標籤、帳戶、服務等，依據維度建立成本類別以對應您的成本。
+  **設定 AWS Budgets：**針對您的工作負載在所有帳戶上[設定 AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)。使用標籤和成本類別，設定整體帳戶支出的預算以及工作負載的預算。在 AWS Budgets 中設定通知，以接收超出預算金額時的提醒，或預估成本超出預算時的提醒。
+  **設定 AWS 成本異常偵測：**針對您的帳戶、核心服務或您所建立的成本類別使用 [AWS 成本異常偵測](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)，以監控成本與用量並偵測異常支出。您可以在彙總報告中個別接收提醒，也可以透過電子郵件或 Amazon SNS 主題接收提醒，以便分析和判斷發生異常的根本原因，並找出導致成本上升的因素。
+  **使用成本分析工具：**針對您的工作負載和帳戶來設定 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)，將成本資料視覺化以進行深入分析。根據歷史成本資料建立工作負載的儀表板，以追蹤整體支出、工作負載的關鍵用量指標，以及未來成本的預測。
+  **使用成本節省分析工具：**使用 AWS 成本最佳化中心，透過量身訂做的建議來識別節省機會，包括刪除未使用的資源、調整大小、Savings Plans、保留以及運算最佳化工具建議。
+  **設定進階工具：**您可以選擇性地建立視覺效果以促進交互式分析和成本洞見分享。透過 AWS 成本最佳化中心上的資料匯出，可以為您的組織建立由 Quick 提供支援的成本和用量儀表板，以提供更多詳細資訊和精細度。您也可以在 [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway) 中使用資料匯出實作進階分析功能，以進行進階查詢，並在 [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway) 上建立儀表板。與 [AWS 合作夥伴](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management)進行合作，採用雲端管理解決方案，進行整合式雲端帳單監控與最佳化。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [什麼是 AWS 帳單與成本管理 和成本管理](https://docs.aws.amazon.com/cost-management/latest/userguide/what-is-costmanagement.html)？ 
+  [建立您的最佳實務 AWS 環境](https://aws.amazon.com/organizations/getting-started/best-practices/) 
+  [標記 AWS 資源的最佳實務](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) 
+  [標記您的 AWS 資源](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 
+  [使用 AWS Budgets 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [使用 AWS Cost Explorer 分析您的成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [什麼是 AWS 資料匯出](https://docs.aws.amazon.com/cur/latest/userguide/what-is-data-exports.html)？ 

 **相關影片：**
+  [部署雲端智慧儀表板](https://www.youtube.com/watch?v=FhGZwfNJTnc) 
+  [取得任何 FinOps 或成本優化指標或 KPI 的提醒](https://www.youtube.com/watch?v=dzRKDSXCtAs) 

 **相關範例：**
+  由 Quick 提供支援的[成本和用量儀表板](https://aws.amazon.com/blogs/aws-cloud-financial-management/new-cost-and-usage-dashboard-powered-by-amazon-quicksight/) 
+  [AWS 成本與用量管控研討會](https://catalog.workshops.aws/well-architected-cost-optimization/en-US/2-expenditure-and-usage-awareness/20-cost-and-usage-governance) 

# COST03-BP06 根據工作負載指標分配成本
<a name="cost_monitor_usage_allocate_outcome"></a>

 依據用量指標或商業成果分配工作負載的成本，以衡量工作負載的成本效率。實作程序以透過分析服務 (可提供洞見和退款功能) 來分析成本和用量資料。

 **未建立此最佳實務時的曝險等級：**低 

## 實作指引
<a name="implementation-guidance"></a>

 成本優化意味著以最低的價格提供業務成果，只有依工作負載指標 (按工作負載效率測量) 來分配工作負載成本才能達成。透過日誌檔案或其他應用程式監控，監控已定義的工作負載指標。結合此資料與工作負載成本，您可以透過查看具有特定標籤值或帳戶 ID 的成本來取得成本資料。每小時執行一次此分析。如果您擁有靜態成本元件 (例如，持續執行的後端資料庫) 且請求率不同 (例如，用量尖峰在早上九到晚上五點，晚上只有少量請求)，您的效率通常會有所改變。了解靜態成本與可變成本之間的關係，有助於您確定優化活動的重點。

 相較於 Amazon Elastic Container Service (Amazon ECS) 和 Amazon API Gateway 上的容器化應用程式等資源，為共用資源建立工作負載指標可能具有挑戰性。但是，可以透過某些方法對使用情況進行分類並追蹤成本。如果您需要追蹤 Amazon ECS 和 AWS Batch 共用資源，則可以在 AWS Cost Explorer 中啟用分割成本分配資料。使用分割成本分配資料，您可以了解並優化容器化應用程式的成本和用量，並根據共用運算和記憶體資源的使用情形，將應用程式成本分配給個別業務實體。

### 實作步驟
<a name="implementation-steps"></a>
+  **將成本分配到工作負載指標：**使用定義的指標和設定的標籤，建立結合工作負載輸出和工作負載成本的指標。使用諸如 Amazon Athena 和 Amazon Quick 等分析服務，為整體工作負載和任何元件建立效率儀表板。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [標記 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/)

# 停用資源
<a name="decommission-resources"></a>

 在管理專案、員工和技術資源清單一段時間之後，您就可以識別不再使用的資源或不再有負責人的專案。

**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 追蹤其生命週期的資源
<a name="cost_decomissioning_resources_track"></a>

 定義並實作一種方法，在資源的生命週期內追蹤資源及其與系統的關聯。您可以使用標記來識別資源的工作負載或功能。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

停用不再需要的工作負載資源。常見的範例是用於測試的資源：測試完成後，便可移除資源。使用標籤來追蹤資源 (並針對這些標籤執行報告) 可協助您識別要停用的資產 (不會再使用這些資產，或是其授權將到期時)。使用標籤是追蹤資源的有效方法，方法是使用資源的功能標記資源，或標記停用日期。然後，即可對這些標籤執行報告。功能標記的範例值可以是 `feature-X testing`，可識別資源在工作負載生命週期的用途。另一個範例是`TTL`針對 資源使用 `LifeSpan`或 ，例如 to-be-deleted標籤金鑰名稱和值，以定義停用的時段或特定時間。

**實作步驟**
+ **實作標記結構描述：**實作識別資源所屬工作負載的標記結構描述，確保工作負載內的所有資源都已相應地加上標籤。標記可協助您依用途、團隊、環境或其他與您業務相關的準則，來將資源分類。有關標記使用案例、策略和技巧的更多詳細資訊，請參閱 [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 區域。可以針對大多數的資源新增標籤，以便識別和排序組織內的資源。使用[標籤編輯器](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)將標籤大量新增至支援的資源。考慮使用 [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/index.html) 來建立、管理並向最終使用者分發批准的產品組合，並管理產品生命週期。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [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/AmazonCloudWatch/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 實作停用程序
<a name="cost_decomissioning_resources_implement_process"></a>

 實作識別和停用未使用資源的程序。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

在您的組織中實作標準化程序，以識別並移除未使用的資源。此程序應該要定義執行搜尋的頻率，以及移除資源的程序，以便驗證是否有符合組織的所有要求。

**實作步驟**
+  **建立並實作停用程序：**與工作負載開發人員和擁有者合作，為工作負載及其資源建置停用程序。此程序應該涵蓋用於驗證工作負載是否正在使用的方法，以及用於驗證每個工作負載資源是否正在使用的方法。詳述停用資源的必要步驟，將它們從服務中移除，同時確保符合任何的法規要求。應包含任何關聯的資源，例如授權或連接的儲存。發出通知讓工作負載擁有者知道停用程序已經執行。

   使用下列停用步驟來引導您了解過程中應檢查的事項：
  +  **識別要停用的資源：**識別在 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/)。

 下面的簡單停用程序流程圖會概述停用步驟。在停用資源之前，請先確認您確定要停用的資源沒有被組織使用。

![\[說明停用資源之步驟的流程圖。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/cost-optimization-pillar/images/decommissioning-process-flowchart.png)


## 資源
<a name="resources"></a>

 **相關文件：**
+  [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 停用資源
<a name="cost_decomissioning_resources_decommission"></a>

 停用由諸如定期稽核或用量變更等事件觸發的資源。通常會定期執行停用，其執行方式可以手動，也可以自動。

 **未建立此最佳實務時的曝險等級：**中 

## 實作指引
<a name="implementation-guidance"></a>

搜尋未使用資源的頻率和努力應該反映潛在節省的成本，因此較低成本的帳戶的分析頻率應該比較高成本帳戶低。搜尋和停用事件可由工作負載的狀態變更觸發，例如產品壽命結束或被取代。搜尋和停用事件也可由外部事件啟動，例如市場條件變化或產品終止。

**實作步驟**
+  **停用資源：**這是不再被需要或授權協議結束的 AWS 資源的折舊階段。請先完成所有最終檢查，再移至處置階段並停用資源，以防止發生任何不需要的中斷，例如擷取快照或備份。使用停用程序，停用已識別為未使用的每個資源。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 

# COST04-BP04 自動停用資源
<a name="cost_decomissioning_resources_decomm_automated"></a>

 設計工作負載，在識別和停用非關鍵資源、不需要的資源或低利用率資源時，妥善處理資源終止。

 **未建立此最佳實務時的曝險等級：**低 

## 實作指引
<a name="implementation-guidance"></a>

使用自動化來降低或消除停用程序的相關成本。將工作負載設計為執行自動停用，可降低工作負載生命週期內的整體成本。可以使用 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 或 [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide) 來執行停用程序。也可以使用 [API 或 SDK](https://aws.amazon.com/developer/tools/) 來實作自訂程式碼，以自動停用工作負載資源。

 [現代化應用程式](https://aws.amazon.com/modern-apps/)以無伺服器為優先，這是一種優先採用無伺服器服務的策略。AWS 為堆疊的全部三個層級開發了[無伺服器服務](https://aws.amazon.com/serverless/)：運算、整合和資料存放區。使用無伺服器架構可讓您透過自動縱向擴展和縮減規模，在低流量期間節省成本。

**實作步驟**
+ **實作 Amazon EC2 Auto Scaling 或 Application Auto Scaling：**對於受支援的資源，請使用 Amazon EC2 Auto Scaling 或 Application Auto Scaling 進行設定。這些服務可協助您在使用 AWS 服務時優化使用率和成本效益。當需求下降時，這些服務會自動移除超額的資源容量，以免您超支。
+ **設定 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 提供多種無伺服器技術服務，本質上可提供自動最佳化的資源使用率和自動停用 (縮減和擴充)。在使用無伺服器應用程式時，系統會自動為您提供最佳化的資源使用率，您永遠不會因為過度佈建而支付費用。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 
+  [Amazon EC2 Auto Scaling 入門](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [AWS 上的無伺服器](https://aws.amazon.com/serverless/) 
+  [建立警示以停止、終止、重新啟動或復原執行個體](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.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/) 

# COST04-BP05 強制執行資料保留政策
<a name="cost_decomissioning_resources_data_retention"></a>

 對支援的資源定義資料保留政策，以根據組織的要求處理物件刪除。識別並刪除不再需要的非必要或孤立資源與物件。

 **未建立此最佳實務時的曝險等級：**中 

 使用資料保留政策和生命週期政策，降低已識別資源的停用程序相關成本和儲存成本。定義資料保留政策和生命週期政策以執行自動化儲存類別遷移和刪除，可降低生命週期內的整體儲存成本。您可以使用 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 在物件生命週期中採取的動作，以及根據您的業務需求在物件生命週期結束時進行刪除。

## 資源
<a name="resources"></a>

 **相關文件：**
+  [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/) 