Azure的雲端成本優化

14 min readMar 16, 2024

本文將介紹如何使用Azure WAF(Well-Architected Framework)中的成本優化評估問卷，來協助我們理解事情脈絡中關於人的層面，以及工程師、DevOps、產品經理和解決方案架構師在 Azure 中建置和部署工作負載時所遵循的實務。當評估完成後，我們會有會有一個基線分數(baseline score)。這個分數是我們追蹤一季或一年內的成本優化起點。當組織進行細部微調時，這個分數會隨著時間的推移而逐漸進步。第二個工具是 Microsoft 的Cost Management + Billing，用於顯示目前的雲端成本及其背後的驅動因素。

一旦我們在雲端成本中獲得了可見性，接下來就需要知道怎麼進行成本分配。我們將會根據組織的財務單位的成本定義，使用"accounts/management groups/subscriptions/tags"來進行成本分配。

本文將會討論以下的要點:

在Azure中實行FinOps用到的工具
什麼是Azure Well-Architected Framework?
使用Azure WAF的成本優化評估來建立基線
從會計角度看成本分配
Azure 中 FinOps 的成本分配
在Azure Portal中進行成本分析

PS:關於什麼是FinOps，請參閱本部落格中關於FinOps的系列文章。

在Azure中實行FinOps用到的工具

Azure提拱了以下的工具讓組織得以實現FinOps的實踐。

Azure CLI(Command-line interface)
Power BI Desktop:
可與Azure Cost Analysis直接連結
Azure Cost Management + Billing:
可針對組織在Azure中的工作負載/系統對其成本進行分析、管理與優化
Azure Advisor:
Azure Advisor 是一項個人化服務，可定期主動掃描 Azure 資源，並提供可行的工作負載最佳化建議
Azure Monitor:
Azure的監控系統
Azure 價格計算機

什麼是Azure Well-Architected Framework?

Azure WAF 是跨越卓越架構五個支柱的指導原則，可為 Azure 中的工作負載產生高品質且高效的架構。這些支柱如下：

可靠性(Reliability)
安全性(Security)
成本優化(Cost Optimization)
卓越維運(Operational Excellence)
效能效率(Performance Efficiency)

由於 FinOps 團隊專注於管理雲端成本並最大化為組織業務所提供的價值，因此我們將重點放在 WAF 的成本優化支柱上。 WAF 由六個要素提供支援:

Well-Architected Review
Azure Advisor
Documentation
Partner Support and Service Offer
Reference Architectures
Design Principles

Azure Well-Architected Review透過成本管理的角度檢查工作負載。 WAF review還有助於提高工程、產品和 DevOps 團隊知識的可見性，以及考慮他們為雲端基礎設施做出的每個決策的成本的能力和優先順序。讓我們組建團隊並讓他們進行 WAF 成本優化評估。

使用Azure WAF的成本優化評估來建立基線

WAF 成本優化評估的範圍是每個系統或工作負載。首先，我們必須確定系統或工作負載範圍。此評估是 FinOps、CCoE、IT、DevOps、架構和產品團隊之間的協作努力。理想情況下，這個評估應用一次約2–3小時的會議中完成。 FinOps 負責人主持會議、澄清問題並記錄答案。此會議是一個絕佳的機會，可以讓我們深入了解IT和 DevOps 團隊的思維和決策模式。

我們可以在微軟的網站在開始這一個評估(如上圖)。如果我們已經有在使用Azure的話，我們可以在這個評估中把"Advisor recommendation"的資料import進來。當我們點選Import時，如果我們有多個Azure account，系統會需要我們選擇要用哪一個account(需要被評估的系統)來進行評估(如下圖)。

當選擇完帳號之後(如下圖)。我們就可以開始進行評估作業了。

由於成本優化只是Azure WAF的其中之一，所以我們只需要選擇關於成本優化的作業(如下圖)。

選擇成本(如下圖)

至此，我們就開始了WAF成本評估問卷。讓我們了解評估問題的關鍵部分。共有九個部分(如下圖)，每個部分都有不同數量的問題，團隊需要一起合作回答。

上面的畫面分為以下5個部分:

左手邊的是成本優化問題集清單
短影音解釋每一個問題集的意思
問題集的主大綱，例如上面的畫面 — 我們如何對此系統進行成本建模?
問題集 — 團隊必須一起討論而後進行勾選。如果不確定則可以不用勾選。
針對該問題有更多的涵義解釋

全部完成之後我們會得到一個分數表，如下圖所示。下圖中我們看到得到的分數介於中位數，意思是還有很大的進步空間，而某些行為我們也有遵循到成本優化的最佳實踐。我們也可把該評估用CSV的方式來下載。

該評估報告也會給我們所有建議的清單(如下圖)，並帶有 Microsoft 文件的URL，可協助優化特定的成本優化領域。

從會計角度看雲端的成本分配

根據牛津字典的定義，成本會計是用來改進管理的方式並記錄企業產生的所有成本。成本核算中有兩種成本分配方法：傳統成本和基於活動的成本（ABC-activity-based cost）。

在傳統的成本會計中，我們有整個組織的間接費用率。它是使用機器工時或人工工時計算的。這將會有一個全年分配的費率。由於這種簡單性，傳統成本會計很容易實施。

在傳統成本會計中，它只分配產品成本，並考慮製造費用。傳統成本會計中不考慮銷售及行政費用 (SG&A — Selling, general, and administrative) 成本。傳統的成本會計可用於計算銷售商品的成本，並且是稽核人員接受的方法。但傳統成本計算方法也有缺點 — — 例如，它只考慮一種費率。讓我們假設一個場景，其中一種產品有缺陷並且需要更多的後續客戶支援。在這種情況下，我們低估了我們的成本，因為我們只算到了製造成本而沒有納入後續維護成本。

成本會計是關於做出高品質的決策，ABC 成本分配法可以提供我們準確的成本。 ABC 將在該活動發生時計算每個成本池的費率。一旦我們掌握了準確的成本，我們就可以做出是保留、放棄該產品線或優化某些流程的最佳決策。

什麼是ABC成本分配

成本會計中的ABC是一種將成本準確地分攤到相關業務活動中的方法，以便可以根據業務活動的比率來計算間接費用(overhead costs)。在看 ABC 成本分配的範例之前，讓我們先了解關鍵定義：

產品(Product):
銷售給客戶的產品/服務，這些產品/服務可以是實體或虛擬的。
間接費用(overhead):
這些是企業必須要付出的成本，企業才有辦法營運下去。像是公司的後勤體系(人資/財務/IT/總務等)，電力，辦公室空間等。
成本池(Cost Pool)或稱成本中心(Cost Center):
業務流程活動會被分組到一個池中以進行成本分配。每個組織都會定義與其業務需求最相關的成本池。組裝、訂單處理、行銷和客戶支援都是成本池的例子。
度量(Measure):
這是成本池的驅動因素。最常見的度量範例是單位數量、客戶數量或訂單數量。
活動率(Activity rate):
這是透過將成本除以活動來計算的。它是活動的每單位成本 — 例如，1000,000/20,000 個單位的組裝成本 = 每單位活動率 50元。

Azure 中 FinOps 的成本分配

FinOps 團隊的目標是建立雲端支出的可見性並實現細緻化成本分配，以產生雲端支出的共同責任。適當的成本分配將幫助團隊了解他們的雲端支出以及他們的作為與不作為對帳單的影響。必須使用帳戶層次結構和資源標籤將支出資料正確地按成本中心、應用程式和業務單位對應到組織層級結構。

使用account/management group/subscription hierarchy進行成本分配

EA(Enterprise Agreement)類型的billing account、Departments和account hierarchy(帳號層次結構)可讓我們在最高層級"組織和分配"成本。在以下範例中(如下圖)，組織在billing account下建立了兩個部門（Marketing和HR）。 Invoice是在billing account層級產生的。 Department將account（包含subscriptions）分組，以將成本組織到邏輯群組中。 EA管理員可以配置每個部門的支出額度。這是執行預算的地方。當配額達到50%、75%、90%、100%時，EA管理員和部門管理員都會收到通知。

雖然可以使用EA的部門層級進行成本分配，但實際上，它不會提供 FinOps 團隊所尋求的資料精細度。

這時，我們就需要管理群組(management group)了。如下圖中看到的，我們從最高一級開始，向下移動到更多的細緻度。管理群組允許對數百個subscription進行有效率的"存取、政策和合規"。雖然它們與幫助成本分配沒有直接關係，但最新的成本分析範圍可以包含使用管理群組進行篩選。因此，現在可以將所有資源的成本分組到一個管理群組下，並將其回報給業務部門。以下是有助於成本分配的管理群組層次結構範例：

使用這種管理群組結構，FinOps 團隊可以輕鬆地按特定管理群組對成本進行分組。例如，要了解 Online工作負載的成本，可以到成本分析儀表板並選擇 Online管理群組的範圍。這將包括 Online下的所有訂閱並提供總成本。

我們可以對Azure的sunscription給予tag。若要在sunscription層級分配成本，可以使用subscription的標籤進行成本分組。

使用resources tags進行成本分配

Azure resource使用key/value pair的方式來對資源給予標籤。每一個resource/resource group/subscription最多只支援50個標籤(也就是50對空格)，所以如果要多於50個，我們就要在空格中將單純的文字轉換成JSON格式。Azure Automation/CDN/DNS只支援15個tag。

但並不是所有的Azure resource都可以給予tag，關於那些Azure resource有支援tag，請參閱微軟的官方網站。

根據 FinOps 團隊的成熟度等級，以下是應用於resource的最少標籤。若要強制實施標籤覆蓋(tag coverage)，我們可以使用Azure Policy來稽核或拒絕資源建立（如果沒有提供所需的標籤）：

分為tag名稱與描述：

appid:
這可以是組織所規定的unique ID(或也可以是資產編號)，通常來自組織的CMDB。
env:
環境的分類 — dev/stg/prod等
department:
該資源歸屬哪個部門
itowner:
it部門的哪個角色或團隊負責的
businessowner:
哪個業務單位是負責人（通常是為使用該資源要付費的業務單位）
costcenter:
成本中心

我們可以透過多種方式將這些標籤套用到 Azure resources。最常見、最有效的方法是將標籤嵌入IaC解決方案（例如Terraform）中。或者，可以使用 Azure portal或 Azure CLI command來＂列出、新增、更新或刪除＂標籤。

例如以下是一個使用Terraform來對一個resource group來新增標籤的範例代碼：

resource "azurerm_resource_group" "dev" {
  name     = "marketing-website-dev"
  location = "taiwannorth"
  tags = {
    appid = "12345678"
    env = "dev"
    department = "marketing"
    costcenter = "1234567"
    itowner = "jason.kao@suros.com.tw"
    businessowner = "jason.kao@suros.com.tw"
  }
}

在Azure Portal中進行成本分析

在Azure Portal進行成本分析基本上是免費的。通常都是在Azure的 Cost Management + Billing進行，並通常進行以下作業：

確定Subscription(訂閱)的報價類型
檢視“累計和預測”成本
檢視依服務分群的成本
檢視依管理群組分群的成本
檢視依標籤分群的成本

確定Subscription(訂閱)的報價類型

當組織購買 Microsoft Azure subscriptions時，Azure offer將管轄組織與 Microsoft 之間的付款條款和條件、服務費率、排除項、付款選項、取消政策以及服務協議（如下畫面）。

更多的Azure offer類型請參閱微軟官網。

檢視“累計和預測”成本

財務和採購單位最常見的要求是提供在Azure 中執行的運行系統的＂累積和預測＂成本。為此，我們可以使用內建的累計成本視圖。此外，我們也可以直接與財務和採購團單位共享這個視圖，或以 PNG、Excel 或 CSV 格式匯出資料給予其他單位。預測成本是基於歷史資源使用情況，並可以呈現長達一年的估計成本的預測。

這個畫面呈現在 Cost Management + Billing →Cost Analysis(如下圖)

檢視依服務分群的成本

檢視依管理群組分群的成本

Azure 中的管理群組透過對訂閱進行邏輯分組，為你提供了一種有效的方法來管理資源、存取、政策和合規性。管理群組層次結構也擴展到Cost Management + Billing。Cost management scope filter支援基於管理群組的篩選。例如CIO想知道企業在託管企業內部網站與外部客戶的線上業務網站上花費了多少錢，以計算間接費用。