Open cnharris10 opened 2 months ago
We just need to be clear the goal here isn't for the practitioner to use the value as a direct coverage calculation (e.g. Lines that are covered by a commitment-based discount over those lines that are eligible for a commitment-based discount).
However, that isn't the right approach to "coverage" calculations just because a single line charge could be covered by a commitment, does not mean it is financially sensible to have it covered. While I see the value in this field I think we need to be clear on how the practitioner should use the column correctly.
We just need to be clear the goal here isn't for the practitioner to use the value as a direct coverage calculation (e.g. Lines that are covered by a commitment-based discount over those lines that are eligible for a commitment-based discount).
However, that isn't the right approach to "coverage" calculations just because a single line charge could be covered by a commitment, does not mean it is financially sensible to have it covered. While I see the value in this field I think we need to be clear on how the practitioner should use the column correctly.
@mike-finopsorg
100%. The goal is to expose what is eligible for coverage by commitments, because it's hard enough figuring out what is/is not eligible. We should definitely clarify that we're not giving an opinion on a coverage strategy based on aspects like target rates, on-demand fluctuation percentages, or similar.
I envision people doing roughly the following:
1. Determining their coverage percentage.
(SELECT SUM(ChargePeriodEnd - ChargePeriodStart) FROM <table> WHERE CommitmentDiscountCategory IS NOT NULL AND ChargeSubCategory = 'Used')
/
(SELECT SUM(ChargePeriodEnd - ChargePeriodEnd) FROM <table> WHERE CommitmentDiscountCategory IS NOT NULL AND ChargeSubCategory IN ('Used', 'On-Demand'))
* 100
2. If above coverage rate target, query rows (or rollups), drill down further into coverage rates above where coverage is higher than expected.
3. If below coverage rate target, query rows (or rollups) with on-demand spend with a CommitmentDiscountCategory
value to determine what to do next.
SELECT * FROM <table> WHERE ChargeCategory = 'Usage' AND ChargeSubCategory = 'On-Demand' AND CommitmentDiscountCategory IS NOT NULL
Type
Dimensions Normalized? Yes
Description
Commitment coverage is calculated as:
# of running hours of committed usage / # of hours of committed + on-demand usage
. This ratio helps practitioners determine how much savings potential still exists across their platform. Based on their coverage goal(s), practitioners can determine if they want to purchase additional commitments or not.For even the most advanced practitioner, it is a non-trivial task to determine whether an on-demand usage-based charge is eligible for a commitment (and which commitment) or not. While practitioners likely know that spot/preemptible VM's across clouds are not available for commitments, identifying and excluding these resources to exclude from commitment coverage calculations is non-trivial.
More so, attempting to exclude SKU-specific rows from coverage calculations is much more tedious as a practitioner must ensure that they understand cloud or SaaS-based documentation perfectly to achieve an accurate calculation. See below more details.
The goal of this column is to:
--
For visibility around some of these restrictions, the following are few restrictions across AWS, Azure, and GCP:
AWS a. Spot instances b. P5 instance family c. Mac instance families d. Ubuntu OS
Azure a. Spot VM's b. VM series - A-series, Av2-series, or G-series
GCP a. Preemptible VM's b. n1 shared-cost, or extended memory VM's