雲端費用帳單的解析
在我們與組織中跟所有雲端使用相關的團隊有共同的語言之後，接下來就是要來拆解我們雲端帳單的明細了。
假設我們收到以下的AWS月結帳單。這張帳單"明細"有近200欄位，數百萬行的資料，有時大型企業的資料可能到數億行都有。哪我們該怎麼做呢?
帳單的格式與屬性
雲端的帳單的檔案或系統中的每一行(row)都列舉了使用的某類資源的使用量我們可以拆解成以下幾個部分:
- 各種成本維度的識別屬性 — 例如 Region, Instance ID, Item descriptions, Date/Time, Tags/Metadata等。
- 成本計價的量測標準 —
* 用時間(Time)計價: 例如虛擬機的CPU/Memory的租用時間．在雲端中，時間永遠是重要的因素．
* 用使用量(Usage Quantity)計價:例如CDN流量，Serverless功能的呼叫次數
* 費率(Rates) - 基本算式:
* Time x Rate(費率)= Cost
* Usage(volume) X Rate = cost
在這些資訊中我們可以看到有兩類的行動類型是我們可以做的
- 使用的時間 = 優化的使用(Usage)是分散的 (這屬於FinOps六項原則中的第三項)。這也稱為 “avoiding cost”，我們可能可以進行如下的行動：終止閒置資源，調整超大資源的規模，減少在非高峰時間運行的資源數量，或者在晚上和周末完全關閉資源。
- 使用的費率=優化的費率是需要集中的(這屬於FinOps六項原則中的第五項)。如果我們的要使用的資源是確定的，我們的行動可能是購買 RI(AWS/Azure)或 CUD(GCP)．或是基於用量的volume discount，例如 SUD(GCP)，或是直接跟雲端平台商談費率(例如一個月用到100萬美元)．也或者是使用spot instances/preemptible instances．
從帳單細節中獲得有意義的見解是一項艱鉅的任務，並且需要 FinOps 團隊的技能在適合組織業務需求的自動化工具的幫助下進行處理。
各家雲端平台的帳單
雲端帳單的格式(欄位)或計算費率永遠都在變化。今日的格式與費率不代表下個月也可能如此．另外雖然各家雲端平台都有提供基本或進階的帳單服務分析，但如果組織是使用多雲策略，哪麼這些分散的雲端帳單分析服務反而就變成一種阻礙了．
AWS亞馬遜
通常有Invoice加上本身的資料分析工具(AWS Cost Explorer)，另外還有CUR(Cost and Usage Reports)的檔案。
AWS 將其每月的 CUR 檔案拆分並存儲在 S3 bucket中，以便每個檔案都小於某些機器上的最大檔案大小限制。所以 CUR 甚至不能一次全部組合成一個 Excel 檔。這個檔案會太大我們的電腦無法打開。
但本質上，雲端帳單是以非常基本的模型呈現資訊。它包含有關費用（metadata或維度）的屬性，例如region或instance ID 或運行時間、tags、描述、大小等。指標包括運行的時間量或使用量，以及費率。並且可能會引用多個費率、混合費率、非混合費率、攤銷費率等。
需要注意的是，一台虛擬機可能會以不同的費率計費，它的一些使用時間可能會被Reservations給cover到，一些是on-demand提供的。每個 費率x 使用量或費率 x 時間的組合將是單獨的一行。一些服務還包括多種類型的費用/計量 — — usage, storage, iops, read/write units, data transfer等。
如果我們想為自己改變成本，我們有 2 個槓桿可以使用
1. 可以改變使用量（分散式）
2. 可以更改支付的費率（集中式）
AWS 擁有最成熟的計費流程，但是 Invoice 和 CUR 來自不同的系統，很少 100% 匹配一塊錢(尤其以美元計價)。並且一直在進化，CUR 已經是第三代帳單格式。CUR 由AWS內各個service team提供，內部也不完全一致
Azure微軟
一樣有Invoice加上本身的資料分析工具(Azure Cost management)。另外也可以下載Azure Billing files — 每日資料，但不包括牌價成本、攤銷、預付 RI 成本、特定資源資訊、資源使用率。
“Invoice”季度雖然也提供月度發票，但很大程度上取決於合約關係。2020 年之前通過Billing API 的計費資料不包括牌價成本、預付款攤銷、預付 RI 成本、特定資源資訊（例如scales set等）。
Google Cloud Platform
Invoice一樣也有。帳單的明細資料可以即時的導出到GCP的Data warehouse中自行分析整理。詳請可參閱本部落格的使用BigQuery來分析GCP費用文章。GCP是三朵雲中需要自行耗費最多的時間來建立帳單資料(對組織是有意義且可用的)。
雲端運作的新思維
以小時計費的資料
我們可能想知道為什麼需要考慮以小時計費（或以秒計費）的資料和資源等級的細緻度。tag level 的每日或每週資細緻度還不夠嗎？簡單回答是：不。
我們需要用每小時為區間的資料來執行更高階的 FinOps 能力，例如 RI planning。 RI 採購是基於我們在特定時段內運行的特定類型資源的數量，相對於)On-Demand資源的收支平衡點。如果我們統計以月為區間的資源，我們無法得到那個重要的細節。要確定我們需要多少資源，我們必須查看每小時（或每秒）運行多少資源，以及使用的底線。
我們的月結帳單不是雲端的月結
假設我們在年初採用了一項新的成本優化計劃。它從 今年的1 月 1 日開始，列出了一系列削減成本的行動：“我們關閉了用不到的VM，我們調整了一些東西，我們購買了一些 RI。”接下來的一個月，雲端帳單費用下降了20%。成功！
可是等等。如果將 2 月份的天數除以 1 月份的天數，則得到 80%。這似乎很明顯，但我們甚至無法計算 2 月和其他月份之間的不同月份天數讓團隊我們相信已經有效地降低了成本。然後，在 3 月 31 日成本還比二月份上漲了 20%。
我們要再重複強調一次，雲端的計費就是時間。雲端計費不像地端機房哪樣計費，在地端機房的模式中，財務團隊習慣用月份來拆帳。雲端細緻度要比地端細得多，如果要Apple to Apple，則需要查看相同的時間長度，無論是 10 天還是 10 小時。
當我們從瀑布式(waterfall)攤銷計劃的世界中走出來時，這是一個巨大的改變，我們將一年的支出平均分配 12個月。而且舊習慣很難改掉。我們實際上已經看到財務部門批評正確計算的以小時計費攤銷減少了 10%，因為他們將攤銷除以 12，而此時他們應該將每秒（或每小時）的攤銷成本乘以小時數的使用時間。
我們的一塊錢不是雲端的一塊錢
當我們討論Apple to Apple的主題時，需要記住，特定行(row)中特定資源類型的費率可能與不同資源時間段中的相同資源類型不同。與地端機房不同，我們可以在一段時間內為資源設置一致的費率，雲端費率可能會根據雲端平台商是否要買預訂或批量折扣而有很大差異。
此外，RI 或 CUD 早期預付款的攤銷可能會進一步改變費用的算式，我們需要決定是否將這些因素計入使用者看到的費率中。我們建議要包含它們，因為這意味著顯示的金額將清楚的呈現我們之後要收取的金額。
如果我們選擇不包括攤銷的預付款項目，我們的團隊可能會認為他們的支出低於實際支出，尤其是在 AWS 和 Azure 提供的前期 RI(預付款) 的情況下。如果不包括這些，則計費資料中使用到的部分的使用量最終為 0.00 元。我們會使用雲端的團隊對他們的成本降低感覺很好，但我們也會給他們一種效率的錯誤感覺。
請記住，無需使用團隊對基礎架構進行任何更改，費率和支出就會發生變化。
兩種槓桿會影響帳單
我們之前有提到，雲端費用最基本的算式:
Usage(volume) X Rate = Cost
第一個槓桿是減少雲端使用。 這稱為成本避免(Cost avoidance)，我們可以透過終止閒置資源、調整超大資源規模、減少非尖峰時段運作的資源數量，或在夜間和週末完全關閉資源來實現這一點。
第二個槓桿是減少使用的費用。 這稱為費率降低(Rate reduction)，我們可以透過利用雲端計費結構（例如 Savings Plans（AWS 或 Azure）、RI（AWS 或 Azure）和CUD (GCP)）來實現這一點。 還有基於使用情況的批量折扣（例如，GCP 的SUD）或一些雲端提供者向大規模消費者提供的自訂定價計劃。 最後，一些公司還使用spot instance或preemptible instance，如果他們願意圍繞潛在的動態資源進行設計，這可能會很有用。 無論選擇哪種方式，它們都會減少我們使用的費用。
而不論是誰來執行這些省錢的行動，成功的FinOps最成功的實踐應該是:
"去中心化地減少使用量(avoiding costs)並集中化支付(reducing costs)"
結論
雲端計費方式很複雜，但這種複雜性讓我們有很大的能力分析推動支出的因素，並讓我們的團隊擁有自己的優化決策。即使我們使用 FinOps 平台(自動化報告和洞察)，我們也需要了解雲端平台商資料的格式，以便從我們所看到的內容中得出正確的結論。我們還應該在組織中使用一致的成本度量格式標準化。這可能是一個未混合和攤銷的費率，它考慮了我們可能與我們的雲端平台商協商後的折扣以及它收取的支援成本。如果沒有這種標準化，我們將有很多困惑，因為我們組織中的所有團隊將以不同的方式看待這些數字。
總結一下：
- 在幾乎所有情況下，計費資料都是用時間來計費的。
- 只有深入了解計費資料，才能對該資料進行詳細分析。
- 雲端帳單中的微小變化會很快累積起來，因此使用自動異常偵測和差異報告來追踪變化，以確定我們雲端的費用趨勢是什麼。
- 帳單的簡單公式是“支出 = 使用率 × 費率”。這我們提供了兩個優化帳單的行動：Useing less and Paying less for what you use。
- 分散式的減少使用量（Using less），同時集中式的減少費率（Paying less）。
- 中央集權式的團隊能夠更好地管理 RI 和 CUD ，因為他們能夠查看整個雲端資產以及管理批發購買產品組合的複雜性。
- 去中心化團隊獲得中央團隊的使用優化建議，因為這些去中心化應用程式的管理者最有能力做出基礎設施變更決策。
