

# COST 2. 如何管控用量？
<a name="cost-02"></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/framework/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) 