

# COST 2  您如何管控用量？
<a name="w2aac19c13b7b5"></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>

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

執行管控的第一步是使用組織的要求來制定雲端使用政策。這些政策定義您的組織如何使用雲端以及如何管理資源。政策應涵蓋資源和工作負載的成本或用量的各方面，包括在資源生命週期中資源的建立、修改和除役。

政策應該簡單易懂，以便有效地在整個組織中實作。從廣泛的高階政策開始，例如允許使用哪個地理區域，或一天中應該執行資源的時間。逐步為各組織單位和工作負載優化政策。常用政策包括可以使用哪些服務和功能 (例如，測試或開發環境中的效能較低儲存體)，以及不同群組可以使用哪些類型的資源 (例如，開發帳戶中最大的資源大小是中型)。

**實作步驟**
+  **與團隊成員會面： **若要制定政策，請讓組織中所有團隊成員指定其要求，並據此加以記錄。採取反复的方法，從廣泛討論開始，然後在每個步驟持續細化至最小的單位。團隊成員包括對工作負載有直接關係的人員，例如組織單位或應用程式擁有者，以及支援群組，例如安全和財務團隊。
+ ** 定義工作負載的位置： **定義工作負載營運的位置，包括國家和國家中的區域。此資訊用來映射至 AWS 區域和可用區域。
+ ** 定義並分組服務和資源： **定義工作負載所需的服務。針對每項服務，指定所需的類型、大小和資源數量。依職能定義資源群組，例如應用程式伺服器或資料庫儲存體。資源可屬於多個群組。
+  **依職能定義並分組使用者： **定義與工作負載互動的使用者，專注於使用者執行的操作以及他們如何使用工作負載，而不是專注於他們的身分或他們在組織中的位置。將類似的使用者或職能分組在一起。您可以使用 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/) 
+  [AWS 服務的動作、資源和條件金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html) 
+  [雲端產品](https://aws.amazon.com/products/) 
+  [使用 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/) 

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

 為您的工作負載實作成本和用量目標。總目標可為您的組織提供成本和用量的方向，而具體目標可為您的工作負載提供可測量的結果。 

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

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

為您的組織制定成本與用量總目標和具體目標。總目標可為您的組織提供預期結果的指導和方向。具體目標是要實現的具體可衡量成果。總目標範例：平台用量應該大幅增加，而成本只稍微增加 (非線性)。具體目標範例：平台用量增加 20%，成本增加少於 5%。另一個常見的總目標是工作負載每 6 個月必須更有效率。相關的具體目標可能是，工作負載的每個輸出成本需要每 6 個月減少 5%。

雲端工作負載的常見總目標是提高工作負載效率，也就是隨著時間降低工作負載每個業務成果的成本。建議為所有工作負載實作此總目標，並設定一個具體目標，例如每 6-12 個月效率增加 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/) 

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

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

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

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

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

**實作步驟**
+  **定義分隔要求： **分隔要求是多個因素的組合，包括安全性、可靠性和財務結構。依序處理每個因素，並指定工作負載或工作負載環境是否應與其他工作負載分開。安全性可確保遵守存取和資料要求。可靠性可確保限制受到管理，讓環境和工作負載不會影響其他項目。財務結構可確保有嚴格的財務分隔和責任。常見的分隔範例是生產和測試工作負載會在不同的帳戶開始執行，或使用單獨的帳戶，以便將發票和帳單資料提供給第三方組織。
+  **定義分組要求：** 分組要求不會覆寫分隔要求，而是用來協助管理。將不需要分隔的類似環境或工作負載分成同一組。例如，將來自一或多個工作負載的多個測試或開發環境分組在一起。
+  **定義帳戶結構： **使用這些分隔和群組，為每個群組指定一個帳戶，並確保分隔要求得到維護。這些帳戶是您的成員帳戶或連結帳戶。透過將這些成員帳戶分組到單一管理帳戶或付款人帳戶下，您可以結合用量，以讓所有帳戶獲得更多數量折扣，並為所有帳戶提供單一帳單。您可以分隔帳單資料，以便在每個成員帳戶中檢視單獨的帳單資料。如果不允許透過任何其他帳戶查看某個成員帳戶中的用量或帳單資料，或是需要與 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 Control Tower](https://aws.amazon.com/controltower/) 
+  [AWS Organizations](https://aws.amazon.com/organizations/) 
+  [合併帳單](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) 

# COST02-BP04 實作群組和角色
<a name="cost_govern_usage_groups_roles"></a>

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

 **若未建立此最佳實務，暴露的風險等級：** 低 

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

在制定政策之後，您可以建立組織內的使用者邏輯群組和角色。這可讓您指派許可和控制用量。從簡要的人員分組開始。通常這與組織單位和工作角色 (例如 IT 部門的系統管理員或財務控制者) 相符。這些群組會匯聚執行類似任務且需要類似存取權限的人員。角色定義群組必須執行的工作。例如，IT 的系統管理員需要建立所有資源的存取權限，但分析團隊成員只需要建立分析資源的權限。

**實作步驟**
+ ** 實作群組： **使用組織政策中定義的使用者群組，視需要實作對應的群組。如需使用者、群組和身份驗證的最佳實務，請參閱安全性支柱。
+ ** 實作角色和政策： **使用組織政策中定義的動作，建立所需角色和存取政策。如需角色和政策的最佳實務，請參閱安全性支柱。

## 資源
<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/) 
+  [Well-Architected 安全支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 

 **相關範例：** 
+  [Well-Architected 實驗室基本身分和存取](https://wellarchitectedlabs.com/Security/100_Basic_Identity_and_Access_Management_User_Group_Role/README.html) 

# COST02-BP05 實作成本控制措施
<a name="cost_govern_usage_controls"></a>

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

 **若未建立此最佳實務，暴露的風險等級：** 低 

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

實作成本控制常見的第一步設定在發生偏離組織政策的成本或用量事件時發出通知。這可讓您快速採取動作，並驗證是否需要採取糾正措施，而不會限制或對工作負載或新的活動造成負面影響。在您了解工作負載和環境限制之後，即可施行管控。在 AWS 中，通知會透過 AWS Budgets執行，您可以在其中定義每月的 AWS 成本預算、用量和承諾折扣 (Savings Plans 和預留執行個體)。您可以在彙總成本層級 (例如，所有成本) 或更精細的層級建立預算，其中只包含特定維度，例如連結的帳戶、服務、標籤或可用區域。

第二步，您可以透過 [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) 和 [AWS Organizations Service Control Policies (SCP)，在 AWS 中執行管控政策。](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)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) 。

亦可透過管理 Service Quotas 來實作管控。藉由確保服務配額設定為冗餘最低並且正確維護，可盡量避免建立超出組織要求的資源。為達成此目的，您必須了解要求的變更速度能有多快、了解進行中的專案 (包括資源的建立與除役兩者) 並將變更配額的實作速度能有多快列入作為考量因素。[Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 可在需要時用來增加您的配額。

**實作步驟**
+ ** 實作支出通知：** 使用您定義的組織政策，建立 AWS 預算以在支出超出您的政策要求時發出通知。設定多個成本預算 (每個帳戶一個)，各帳戶會通知您整體帳戶支出。然後，針對帳戶中的較小單位，為每個帳戶設定額外的成本預算。這些單位會根據您的帳戶結構而有所不同。一些常見的範例是 AWS 區域、工作負載 (使用標籤) 或 AWS 服務。請確保您將電子郵件分發清單設定為通知收件人，而非個人的電子郵件帳戶。您可以設定超過數量時的實際預算，或使用預測預算來通知預測用量。
+ ** 實作用量控制措施： **使用您定義的組織政策，實作 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/) 

 **相關範例：** 
+  [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_2_Cost_and_Usage_Governance/README.html) 

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

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

 **若未建立此最佳實務，暴露的風險等級：** 低 

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

確保您追蹤工作負載的整個生命週期。這可確保不再需要工作負載或工作負載元件時，可以停用或修改它們。當您發佈新的服務或功能時，這特別有用。現有的工作負載和元件可能顯示為使用中，但應停用以便將客戶重新導向至新的服務。請注意先前的工作負載階段 – 工作負載進入生產環境後，之前的環境可能會停用或大幅降低容量，直到再次需要這些環境為止。

AWS 提供多種管理和管控服務，您可以用於實體生命週期追蹤。您可以使用 [AWS Config](https://aws.amazon.com/config/) 或者 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 提供 AWS 資源和組態的詳細目錄。建議與您現行的專案或資產管理系統整合，與持續追蹤您的組織進行中的專案和產品。將您目前的系統與 AWS 提供的一組豐富的活動與指標合併，就能供您檢視重要的生命週期活動，並積極管理資源，以降低不必要的成本。

如需有關 Web 應用程式後端的建議，請參閱 [Well-Architected 卓越營運支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) 。

**實作步驟**
+ ** 執行工作負載審查： **根據您組織的政策定義，稽核您現有的專案。在稽核上付出的工作量應與組織的大致風險、價值或成本成正比。要納入稽核的關鍵領域包括事件或中斷給組織帶來的風險、對組織的價值或貢獻 (以收入或品牌聲譽來衡量)、工作負載成本 (以資源總成本和營運成本來衡量)，以及工作負載用量 (以每單位時間的組織結果數量來衡量)。如果這些領域在生命週期內發生變化，則需要調整工作負載，例如完整或部分除役。

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

 **相關文件：** 
+  [AWS Config](https://aws.amazon.com/config/) 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [適用於各工作職能的 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/) 