AWS的FinOps實踐工具
本文將介紹組織在AWS中實踐FinOps會使用到的相關工具，但不介紹FinOps相關的概念、準則、知識。若想了解這一些FinOps相關內容，請參閱本部落格FinOps相關文章。
AWS Organizations
根據組織架構或業務線建立帳號架構，例如以下範例。
AWS Control Tower
使用AWS Control Tower來對組織的帳號（最好是用公司的mail來註冊帳號）進行管理。Control Tower可以建立我們在雲端的Landing Zone（關於什麼是Lnading Zone請參閱本部落格＂設計，實現與管理多雲的著陸區＂一文）。例如限制某個團隊只能在某個Region使用某些雲端資源。
AWS Cost Explorer
此功能追蹤雲端資源清單與簡易的帳務查詢（最多往後推12個月），包含月報與日報，且該服務是免費的。主要的功能在於:
- 分析成本與用量(usage)
- 預測(forecast)費用(往前推12個月)
- 偵測費用的異常
例如，可以使用此服務來尋找最花錢的EC2。。
成本監控
提供基本的成本資訊，例如:
- Daily/Monthly costs by services
- 透過Linked Account的月費
- 或是客製自己的報表(透過tag篩選)
為了在Cost Explorer進行以tag的方式篩選資料，我們需要在AWS Billing中啟動Cost allocation tags(如下圖)。
在Cost Explorer中需要理解的詞彙是"未混和成本(unblended costs)"。未混和意思是，我們所使用的資源成本用量還沒有經過一些折扣費率的計算。例如我們使用的一台EC2，每一小時是100元台幣，未混和成本就是100元台幣。另一個詞彙是"攤銷成本(Amortized Cost)"，這是在一段時間內的實際發生成本。例如我們購買RI時的預付(unfront)費用。
除了以未混合成本的形式查看這些預付費用之外，我們還可以查看它們隨著時間攤銷成本的情況。 相比之下，與未混合成本相比，我們會看到攤銷成本會有相對較大的飆升，這可能反映出大量的預付成本，或者可以更改為攤銷視圖以查看每月攤銷的費用。
更多的未混和與攤銷成本及混和費率介紹，可以查閱本部落格FinOps相關文章。
AWS CUR(Cost and Usage Reports)
提供比Cost Explorer更精細（小時等級，與其他用量細項）的費用報告。另外由於實際資料是存放S3中所以會提比Cost Explorer更多的歷史資料，不過放資料在S3還是要算錢的。
由於可以看到精細的費用報告，所以我們可以結合Athena 與QuickSight來建立費用報告儀表板。運用QuickSight內建的機器學習功能，我們還可偵測其費用的異常。Management Account可以看到組織中所有 sub account的所有CUR，而每個sub account只能看到自己的CUR。
由於CUR提供比Cost Explorer更精細與更久的費用資料，所以有兩種方式讓我們呈現費用資料。
上圖架構的資料分析有兩種目的。如果我們是要使用SQL語法下達複雜且一次性的資料查詢，我們可以選擇S3 + Athena。如果使長期的資料分析且報表性的呈現，哪就選擇Redshift + QuickSight。
EC2 Global View
這是一個可以在Organization level中，查閱所有組織內所有sub account的使用’’ˋ狀況，包含EBS、VPC等基本資料（如下圖所示）。雖然Cost Explorer也可以看到類似的資料，但該服務比其Cost Explorer更聚焦組織在EC2的整體使用狀況。
AWS Resource Groups
該服務可以幫我們群組相關的雲端資源，但前提是資源必須要先有相關且正確的tag(key-value pair)設置。有了正確的tag，我們就可以查詢相關的雲端資產資料。可能是基於專案、部門、成本中心、系統等等標籤。
其中要特別提一下”Tag Editor”這一個功能，這是尋找依據一個以上的tag尋找單一雲端資源的工具。在某些情況下，團隊可能會配置一組與特定系統相關的資源。 也許這些資源都由特定的系統名稱標記，但技術人員人員忘記套用標籤。 透過Tag Editor，我們可以找到這組具有相似系統標籤的資源，並大量追溯系統所有者標籤。
所以這一個工具從另一方面來說也是我們探索沒有標籤的雲端資源。因為藉由此功能，我們可能可以定義出組織在雲端資源中的標籤策略。需要注意的是我們可能無法使用此方法查詢所有資源。 AWS 更新了可與tag editor一起使用的資源清單。
所以藉由此工具，我們可以尋找與修正沒有tag或tag不正確的雲端資源（如下圖）。但需要注意，如果我們已經有使用CUR然後更改了雲端資源的標籤，我們的帳單報表可能會產生資料不一致的狀況。
雖然Tag Editor可以讓我們做雲端資源佈署的事後修正，但這可能永遠補不完並會導致帳單報表的資料不一致性。
AWS Config
此服務可以幫我們追蹤與監控雲端資源的各種異動（依照我們給的規則）。例如下面的畫面呈現出EC2 subnet的不合規（根據規則）狀態。
AWS Cost Categories
此服務提供額外的資源管理和成本可見度的另一種層次。 在某些情況下，我們的標籤策略可能太細緻化或太粗略，無法提供所需的資訊。此服務可讓我們使用不同維度（例如account ID、資源類型和標籤）建立規則。
此將映射到 Cost Explorer 和 CUR 中。 這幫助我們了解雲端資源使用情況。 理想情況下，每個有意義的資源都應該被標記並分類為邏輯分組。 這將允許我們隔離沒有標籤的資源，假設無標籤資源不會為您的業務提供價值。
AWS CloudWatch
絕大部分的人都是用CloudWatch來當作各式各樣的系統監控與日誌分析。但卻很少用來作為雲端成本/用量的監控儀錶板(如下範例圖)，它的功能與Cost Explorer的成本異常偵測類似，但此服務是要收錢的。
Cloudwatch可以用來通知我們某個指標，如"Total Estimated Charge"超過一定閥值後發出告警通知(使用SNS)，或自動執行某些動作。
使用CloudWatch的異常偵測模型(機器學習)需要我們去指定一些我們想要觀察的指標來進行資料的訓練，它通常會花個幾周的時間模型才能開始運作。下面是一個範例，對EC2進行費用預估。
AWS Budgets
AWS Budgets 提供成本、使用量、RI和 Savings Plans 的預算。設定成本預算可讓我們追蹤成本並設定目標，以便了解每天/月/季/年的績效。並設定預算即將到達的告警。另外若是採購部門/財務部門甚至CFO想要有一個AWS每日費用報告，我們也可以使用AWS Budgets Reports來提供此服務(最多可以填50個email address)。
設立預算的三種方法
第一種是固定預算(Fixed budget)，這是一個特定週期設定一筆預算。例如每周一千美元的預算。使用這一個方法是可以針對整個組織或某個團隊一個總體費用。我們可以設定定期固定預算以在每個月計費週期的第一天續約。 或者，可以在特定時間讓預算過期，這在為我們知道將結束的特定專案設定預算時非常有用。 可以按每日/月/季/年設定固定預算。
第二種是計畫性預算(Planned budget)，這是設定不同的金額來監控每個預算期間。 這個方式無法設定每日預算。 只能每月/季/年設定計畫性預算。這一種方式的效益是它可以根據組織的業務性質或規劃來設定不同期間的預算。例如公司在下一季會有一個活動，該活動可能會讓費用增加(如下範例圖示)。
第三種是自動預算調整(auto-adjusting budget)，這讓我們不用去做未來費用的預估。而是依之前的使用情況自動給予預算數字，尤其當我們的雲端資源使用率波動很大時。
自動預算調整也會自動更新notifactions。之前我們提到，如果我們的費用超過一個閥值系統就會發出告警。 如果我們將自動預算調整納入預算流程，該功能將更新預算金額，包括所有預算告警通知。 訂閱者將收到變更通知以及基於變更的未來告警。
AWS Cost Anomaly Detection
Cost Explorer可以讓我們去尋找費用在哪裡發生異常或是某種異常模式，但這是手動作業是需要人手去執行。但AWS Cost Anomaly Detection使用機器學習的方式來協助我們找出費用的異常模式，而這些都是自動的也是免費的。
異常檢測的一個不良影響是假警報，它告訴我們某個事件是異常，但我們知道事實並非如此。 我們可以建立監控類型來減少這些誤報。 可以使用不同的選項來選擇監控類型，其中包括依 AWS service、linked account、成本類別和標籤進行監控。
