FinOps-Azure的計費機制

運用"雲端服務"加速企業的數位轉型願景

12 min readJun 25, 2024

辨識Azure 計費帳戶
解釋和配置 Azure 計費帳戶
充分利用詳細資源使用情況
描述 Azure 計費資料
了解 Azure 最佳化機制

Azure Billing Accounts

Azure 提供多種Billing Accountd類型。我們可以在文章最後參考資料找到完整的清單，有一大堆。以下是最常見類型的概述。

Online Service Program(PAYG-Pay as you go)

在Azure portal中訂購subscription，通常沒有折扣，用的是市價。預設用信用卡付款。

EA(Enterprise Agreement)

Microsoft 與客戶之間的直接關係
提供折扣和額外服務。也可能涵蓋非 Azure 產品
具有預付積分(Credits)和資源使用的多年合約(3–5年)
計費機制的特定選項（專用入口網站 ea.azure.com）

CSP(Partner Agreement)

CSP 管理客戶關係並通常提供自己的入口網站和工具
發票和計費機制各不相同，並且針對每個 CSP

MCA(Microsoft Customer Agreement)

簡化 Azure 產品。通常與 Microsoft 之間有直接關係
微軟的目標是整合所有其他合約到MCA

計費實體層次 — EA

計費實體層次結構可能會有所不同，具體取決於我們與CSP的協議，主要是 EA，這是企業最常跟微軟使用的方式。 EA 每次註冊都有一個計費帳戶，每個計費帳戶只有一張發票和一種付款方式和幣別。部門和註冊帳戶用於建立我們的帳戶層次結構。

每個部門(Departments)可能有多個註冊帳戶(Enrollment accounts)，這些帳戶的訂閱量(subscriptions)最高。它們是透過 EA portal建立的，但這些功能已隨著時間的推移遷移到Cost Management portal。

計費實體層次 — MCA

主要變更位於”Billing profile and Invoice”部分，這些部分是在設定計費帳戶期間配置的。每個計費配置檔案(billing profile)都會收到不同幣別的獨立發票。付款方式也一樣。

Azure 資源實體層次結構

Azure Subscriptions(訂閱)是與計費實體層次結構連接的主要容器。它們包含Resource Groups，它們是建置 Azure 雲端資源的邏輯容器。在Subscriptions之上的有一種新容器，它不在計費實體層次結構中。

MG(Management Groups)的目的是用於治理，它們用於建立我們的Identity 與Azure policies management。作為 Finops，Azure Policies對於支援metadata實作非常有用。

透過policies，我們可以強制執行標籤、檢查其值的合規性、在資源層次結構中的各個層級（從 MG 到資源層級）設定標籤繼承。MG 作為定義新範圍的保留策略的一部分也非常有用。

計費範圍

根據我們的組織結構，或僅因為我們從一個帳戶轉換到另一個帳戶，我們最終可能需要管理多個計費範圍。

在確定範圍時牢記它們很重要，這意味著在成本可見性和報告方面定義限制。除了計費帳戶之外，管理群組、訂閱和資源群組都可以都可以是範圍。

作為 FinOps，我們將在成本管理入口網站中使用範圍進行日常成本分析活動。例如，整個儀錶板畫面向我們呈現了如何專注於特定範圍。我們將在大多數畫面中看到「範圍(scope)」按鈕，從那裡我們可以定義查詢的範圍，這對於按業務部門、專案或應用程式進行分析和報告非常有用。

FinOps在Azure Billing的角色

Enrollment Admin可能是最重要的，用於管理計費帳戶設定和存取權限以及成本配置，當然還有查看所有成本。EA reader role是專注於查看所有成本和帳戶設定的最低權限。然後是classics Azure Reader/Contributor/Owner roles，這些角色不特定於成本管理活動。 Reader role不是必要性的，但對於調查成本驅動因素非常有用。相反，Cost Management、Billing reader 與Tag contributor旨在進行成本管理活動。此外，Reservation Admin是一個新導入的角色，旨在接管所有預購，而無需取得每個reservations objects的權限。

Enrollment Admin:
特定於EA，管理計費帳戶和存取權限。 FinOps 至少需要作為Reader，才能在enrollment level取得所有資源使用詳細資訊

Reader, Contributor, Owner:
用於存取資源的常見 Azure RBAC 角色。 Reader對於 FinOps 資源使用調查非常有價值

Cost Management, Billing reader, Tag contributor
Bill reader存取 Azure 計費資料。 CM reader可以存取所有成本管理功能，但需要contributor才能建立預算和告警。 Tag contributor— 對於成本分配很有用

Reservation Purchaser / Administrator
Reservation Admin是在租戶層級新增的關鍵角色，用於一次性管理租戶的所有預購。除了購買能力之外，購買者角色還使我們能夠獲得購買建議。

計費期間

這根據我們的帳戶類型而有所不同。與信用卡關聯的 PAYG訂閱只需每月同一日期開立發票。

EA 持續時間通常為 3 至 5 年，並涉及預付credits或季度發票序列。首先，我們預計報告計費資料需要一些時間。無論我們在哪裡查看使用詳細資訊，最多可能需要 24 小時才能看到計費資料。 API 具有類似的報告時間，即使它們受 3 天的 SLA 約束。另外，需要注意，與資源使用資料相比，其他一些資料（例如marketplace）可能需要更長的時間。第三方供應商採購會在第 8 天報告。

如果我們使用cost management exports（通常是每月成本的每日更新），它將在下個月的 6 天停止更新。然後微軟有一個時間窗口可以進行調整，直到下個月的10號最終開出發票。當按月開立發票時，PDF 發票文件通常會在該日期提供。

Azure Cots Management

Azure cost management是一項協助客戶管理和最佳化多雲環境中的雲端支出的服務。儘管相關，但計費與成本管理不同。計費是向客戶開立服務發票以及管理商業關係的過程。

成本管理透過高階分析顯示組織成本和資源使用模式。成本管理中的報告顯示 Azure 服務和第三方市場產品使用基於資源的成本。我們可以使用成本分析來探索和分析組織成本。我們可以按組織查看整體成本，以了解成本在何處累積並確定成本支出趨勢。也可以查看一段時間內的累積成本，根據預算估算每月、每季甚至每年的成本趨勢。

計費資料

作為 FinOps專業人員，我們需要使用企業管理員權限直接透過 Azure Cost management網站或透過使用 API 存取以下成本和帳單資訊

資源使用詳細資訊 — 這是 Azure 資源使用情況和費用的每日細分
— 實際成本 — 顯示當月累積的總使用量和購買成本，並將顯示在您的帳單上
— 攤銷成本(Amortized cost) — 將預購(reservation)採購分解為每日區間，並將其分攤至預購期間內。這些成本也透過使用該資源的特定資源來重新分配和關聯。使用攤銷成本時可以看到未使用的攤銷成本。
發票 — 對於 EA 客戶，如果我們是帳戶管理員或EA管理員，我們將會有組織發票
組織的定價又稱為價格表 —
具有EA的 Azure 客戶可以在 Azure 入口網站中下載協商或折扣的定價
Marketplace 商店收費 — 外部服務由第三方軟體供應商在 Azure Marketplace 中發布，部分 Microsoft 產品也透過 Azure Marketplace 進行銷售
餘額和摘要 — 我們可以檢查計費帳戶的 Azure 信用餘額
零售價格 — 檢索所有 Azure 服務的零售價格

價格表:

作為 FinOps專業人員，我們將需要存取組織的協商價格。只有管理角色才能透過 ACM 入口網站或 API 存取 EA Pricing
價目表不包含Reserved instances discounts
Azure 客戶可以使用 Rest API 以程式設計方式擷取所有 Azure 服務的零售價格。這是取得所有 Azure 服務零售價的未經驗證的方式。我們可以僅過濾預購價格的API call。

Azure Spot VMs

與PAYG相比，Spot VM可讓我們以高達約 90%* 的幅折扣購買未使用的 Azure 運算容量 (VM)，用於可被中斷的工作負載。類似 AWS Spot instance或 GCP preemptible instances，但有些例外:

Azure 不為Spot VM 提供 SLA。
Azure spot instances會在 30 秒警告後關閉（而 AWS為 2 分鐘）。
可用容量可能會因地區、規模和一天中的時間而異，並且可能難以預測
Azure 目前不支援結合Spot VM 和On-Demand VM 來執行scale sets

Azure Burstable VMs

Burstable VMs（B 系列-跟AWS T系列一樣）適用於基於 CPU credit機制的不需要始終讓 CPU跑在100% 的工作負載（Web 伺服器、開發伺服器…）。當然，與通用系列 (D系列) 相比，它們的總體成本較低。然而，最大的折扣是 Windows 授權：無需混合！