此內容已過時。這個版本的 Well-Architected 框架現在可以在以下位置找到： https://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/cost-optimization.html

COST 2: 您如何管控用量？

建立原則和機制以確保產生的成本合理，同時達成目標。您可以運用相互制衡的方法，在不超支的情況下創新。

資源

Control access to AWS Regions using IAM policies
AWS multiple account billing strategy
AWS managed policies for job functions

最佳實務:

改進方案

根據您的組織要求制定政策

  • 與團隊成員會面 : 若要制定政策，請讓組織中所有團隊成員指定其要求，並據此加以記錄。採取反复的方法，從廣泛討論開始，然後在每個步驟持續細化至最小的單位。團隊成員包括對工作負載有直接關係的人員，例如組織單位或應用程式擁有者，以及支援群組，例如安全和財務團隊。
  • 定義工作負載的位置 : 定義工作負載營運的位置，包括國家和國家中的區域。此資訊用來映射至 AWS 區域和可用區域。
    Global Infrastructures Regions and AZs
  • 定義並分組服務和資源 : 定義工作負載所需的服務。針對每項服務，指定所需的類型、大小和資源數量。依職能定義資源群組，例如應用程式伺服器或資料庫儲存體。資源可屬於多個群組。
    Cloud Products
  • 依職能定義並分組使用者 : 定義與工作負載互動的使用者，專注於使用者執行的操作以及他們如何使用工作負載，而不是專注於他們的身分或他們在組織中的位置。將類似的使用者或職能分組在一起。您可以使用 AWS 受管政策做為指南。
    AWS Managed Policies for Job Functions
  • 定義動作 : 使用先前識別的位置、資源和使用者，定義每個項目在其生命週期內 (開發、營運和除役) 達成工作負載結果所需的動作。根據每個位置中的群組 (不是群組中的個別元素) 來識別動作。從廣泛地讀取或寫入開始，然後縮小精細至每項服務的特定動作。
    Actions, Resources, and Condition Keys for AWS Services
  • 定義審查期間 : 工作負載和組織要求會隨著時間變更。定義工作負載審查排程，以確保其與組織優先事項保持一致。高頻率審查週期通常透過安全要求識別，成本或用量是一個重大要點，重要性對組織來說很高，對工作負載的變更量也很重要。
  • 記錄政策 : 確保組織可視需要存取已定義的政策。這些政策用於實作、維護和稽核環境的存取權。

    • 實作總目標和具體目標

  • 定義預期的用量等級 : 從著重於用量等級開始。與應用程式擁有者、行銷團隊和更大的業務團隊互動，以了解工作負載的預期用量等級。客戶需求如何隨著時間而變更，以及如何因季節性增加或行銷活動而變更。
  • 定義工作負載資源與成本 : 定義用量等級後，量化達成這些用量等級所需的工作負載資源變更。您可能需要為工作負載元件增加資源的大小或數量、增加資料傳輸，或將工作負載元件變更為特定等級的不同服務。指定這些要點的成本為何，以及當用量發生變化時，成本會有什麼變化。
  • 定義業務目標 : 從預期用量和成本變更中取得輸出，將此項目與預期的技術變更或任何您正在執行的計畫結合，並制定工作負載的目標。目標必須涵蓋用量、成本和兩者之間的關係。如果預期有成本變更但用量不變，請確保制定有組織計畫，例如培訓和教育等能力打造計畫。
  • 定義具體目標 : 對定義的每個總目標，指定可測量的具體目標。如果總目標是要提高工作負載的效率，具體目標會是量化改善量，這一般是關於花費每一美元所獲得的業務輸出，以及交付時間。

    • 實作帳戶結構

  • 定義分隔要求 : 分隔要求是多個因素的組合，包括安全性、可靠性和財務結構。依序處理每個因素，並指定工作負載或工作負載環境是否應與其他工作負載分開。安全性可確保遵守存取和資料要求。可靠性可確保限制受到管理，讓環境和工作負載不會影響其他項目。財務結構可確保有嚴格的財務分隔和責任。常見的分隔範例是生產和測試工作負載會在不同的帳戶開始執行，或使用單獨的帳戶，以便將發票和帳單資料提供給第三方組織。
  • 定義分組要求 : 分組要求不會覆寫分隔要求，而是用來協助管理。將不需要分隔的類似環境或工作負載分成同一組。例如，將來自一或多個工作負載的多個測試或開發環境分組在一起。
  • 定義帳戶結構 : 使用這些分隔和群組，為每個群組指定一個帳戶，並確保分隔要求得到維護。這些帳戶是您的成員帳戶或連結帳戶。透過將這些成員帳戶分組到單一主帳戶/付款人帳戶下，您可以結合用量，以讓所有帳戶獲得更多數量折扣，並為所有帳戶提供單一帳單。您可以分隔帳單資料，以便在每個成員帳戶中檢視單獨的帳單資料。如果不允許透過任何其他帳戶查看某個成員帳戶中的用量或帳單資料，或是需要與 AWS 分開的帳單，請定義多個主帳戶/付款人帳戶。在這種情況下，每個成員帳戶都有自己的主帳戶/付款人帳戶。資源應一律放在成員/連結帳戶中。主帳戶/付款人帳戶只能用於管理。
    AWS multiple account billing strategy
    Splitting the CUR and Sharing Access

    • 實作群組和角色

  • 實作群組 : 使用組織政策中定義的使用者群組，視需要實作對應的群組。如需使用者、群組和身份驗證的最佳實務，請參閱安全性支柱。
    Well-Architected Security Pillar
    Well-Architected Lab Basic Identity and Access
  • 實作角色和政策 : 使用組織政策中定義的動作，建立所需角色和存取政策。如需角色和政策的最佳實務，請參閱安全性支柱。
    Well-Architected Security Pillar
    Well-Architected Lab Basic Identity and Access

    • 實作成本控制措施

  • 實作支出通知 : 使用您定義的組織政策，建立 AWS 預算以在支出超出您的政策要求時發出通知。設定多個成本預算 (每個帳戶一個)，各帳戶會通知您整體帳戶支出。然後，針對帳戶中的較小單位，為每個帳戶設定額外的成本預算。這些單位會根據您的帳戶結構而有所不同。一些常見的範例是 AWS 區域、工作負載 (使用標籤) 或 AWS 服務。請確保您將電子郵件分發清單設定為通知收件人，而非個人的電子郵件帳戶。您可以設定超過數量時的實際預算，或使用預測預算來通知預測用量。
    Well-Architected Labs: Cost and Usage Governance
  • 實作用量控制措施 : 使用您定義的組織政策，實作 IAM 政策和角色來指定使用者可以執行的動作，以及他們無法執行的動作。一項 AWS 政策中可包含多項組織政策。使用與您定義政策相同的方式，一開始廣泛定義，然後在每個步驟中套用更精細的控制措施。服務限制也能有效控制用量。在您所有帳戶中實作正確的服務限制。
    Well-Architected Labs: Cost and Usage Governance
    Control access to AWS Regions using IAM policies
    AWS managed policies for job functions

    • 追蹤專案生命週期

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