From d751750a2792790d84413bc00e05b61f45f342e2 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Fri, 23 Aug 2024 17:38:06 -0400 Subject: [PATCH 01/18] Initial draft --- specification/appendix/appendix.mdpp | 1 + .../appendix/commitment_discounts.md | 274 ++++++++++++++++++ 2 files changed, 275 insertions(+) create mode 100644 specification/appendix/commitment_discounts.md diff --git a/specification/appendix/appendix.mdpp b/specification/appendix/appendix.mdpp index 510b27ceb..5415ef856 100644 --- a/specification/appendix/appendix.mdpp +++ b/specification/appendix/appendix.mdpp @@ -2,5 +2,6 @@ *This section is non-normative.* +!INCLUDE "commitment_discounts.md",1 !INCLUDE "grouping_constructs_for_resources_and_or_services.md",1 !INCLUDE "origination_of_cost_data.md",1 diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md new file mode 100644 index 000000000..10a0de4e1 --- /dev/null +++ b/specification/appendix/commitment_discounts.md @@ -0,0 +1,274 @@ +# Commitment Discounts + +A commitment discount is a billing discount that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Within cost and usage datasets, commitment discounts typically consist of a set of purchases and usage records. + +## Purchases + +While customers are bound to the term of a commitment discount, cloud-service providers, or CSPs, offer various payment options before and/or during the term: + +* In-Advance - The commitment discount is paid in full before the term begins +* Monthly - The commitment discount is paid monthly over the term. +* Hybrid (In-Advance & Monthly) - Half of the commitment discount is paid in-advance and half is paid monthly over the term. + +For example, if a customer buys a spend-based commitment discount for 1 year, with a $1.00 hourly commitment, and pays with the hybrid option, their purchase schedule is: + +* In-Advance: $4,380 (24 hours \* 365 days \* $1.00 \* 0.5) +* Monthly: $182.50 (24 hours \* 365 days \* $1.00 / 12 months) + +## Usage + +Commitment discounts follow a "use-it-or-lose-it" model where the amortization of a commitment discount's purchase applies evenly over each charge period (typically hourly) over the term. + +For example, if a customer buys a spend-based commitment with a $1.00 hourly commitment in January (31 days), only $1.00 is eligible for amortization for each hourly charge period. This means that if I have eligible resources running during this charge period, some or all of the $1.00 allocated to the charge period will be also be allocated to one or more resources. Conversely, if I don't have eligible resources running during this charge period, the $1.00 allocated to the charge period is wasted. + +## Commitment Discounts in FOCUS + +Within the FOCUS specification, the following examples demonstrate how a commitment discount would appear across various payment and amortization scenarios. + +### Purchase Rows + +All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory:Committed`, and the commitment discount's id as both the `ResourceId` and `CommitmentDiscountId` value. In-advance purchases appear as a single record also with `ChargeCategory:Purchase`, `ChargeFrequency:One-Time`, and the commitment discount's entire purchased quantity, `CommitmentDiscountPurchasedQuantity`, and units, `CommitmentDiscountUnit` for the term. + +Monthly purchases are spread across all corresponding charge periods of the term also with `ChargeCateogry:Purchase`, `ChargeFrequency:One-Time`, and the commitment discount's purchase quantity, `CommitmentDiscountPurchasedQuantity`, and units, `CommitmentDiscountUnit` for the charge period. + +Using the same example as above, various purchase for a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023 can be seen as: + +#### In-Advance + +The entire commitment is billed _once_ during the first charge period of the term for $8,670 (24 hours \* 365 days \* $1.00). + +```json +[ + { + "BillingPeriodStartDate": "2023-01-01 00:00:00Z", + "BillingPeriodEndDate": "2023-02-01 00:00:00Z", + "ChargePeriodStartDate": "2023-01-01 00:00:00Z", + "ChargePeriodEndDate": "2024-01-01 00:00:00Z", + "ChargeCategory": "Purchase", + "ChargeFrequency": "One-Time", + "PricingCategory": "Committed", + "ResourceId": "", + "BilledCost": 8760.00, + "EffectiveCost": 0.00, + "CommitmentDiscountId": "", + "CommitmentDiscountPurchasedQuantity": 8760.00, + "CommitmentDiscountUnit": "USD" + } +] +``` + +#### Monthly + +The commitment is billed across all 8,760 charge periods of the term with $1.00 allocated to each charge period over the term. + +```json +[ + { + "BillingPeriodStartDate": "2023-01-01 00:00:00Z", + "BillingPeriodEndDate": "2023-02-01 00:00:00Z", + "ChargePeriodStartDate": "2023-01-01 00:00:00Z", + "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "ChargeCategory": "Purchase", + "ChargeFrequency": "Recurring", + "PricingCategory": "Committed", + "ResourceId": "", + "BilledCost": 1.00, + "EffectiveCost": 0.00, + "CommitmentDiscountId": "", + "CommitmentDiscountPurchasedQuantity": 1.00, + "CommitmentDiscountUnit": "USD" + }, + + /* ... more recurring purchase records ... */ +] +``` + +#### Hybrid (In-Advance & Monthly) + +Half of the commitment is billed _once_ during the first charge period of the term _and_ the other half is billed across each charge period over the term. Amortized costs incur half of the amount (i.e. $0.50) from the in-advance purchase and the other half from monthly purchase. + +```json +[ + { + "BillingPeriodStartDate": "2023-01-01 00:00:00Z", + "BillingPeriodEndDate": "2023-02-01 00:00:00Z", + "ChargePeriodStartDate": "2023-01-01 00:00:00Z", + "ChargePeriodEndDate": "2024-01-01 00:00:00Z", + "ChargeCategory": "Purchase", + "ChargeFrequency": "One-Time", + "PricingCategory": "Committed", + "ResourceId": "", + "BilledCost": 1.00, + "EffectiveCost": 0.00, + "CommitmentDiscountId": "", + "CommitmentDiscountPurchasedQuantity": 4380.00, + "CommitmentDiscountUnit": "USD" + }, + { + "BillingPeriodStartDate": "2023-01-01 00:00:00Z", + "BillingPeriodEndDate": "2023-02-01 00:00:00Z", + "ChargePeriodStartDate": "2023-01-01 00:00:00Z", + "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "ChargeCategory": "Purchase", + "ChargeFrequency": "Recurring", + "PricingCategory": "Committed", + "ResourceId": "", + "BilledCost": 0.50, + "EffectiveCost": 0.00, + "CommitmentDiscountId": "", + "CommitmentDiscountPurchasedQuantity": 0.50, + "CommitmentDiscountUnit": "USD" + }, + + /* ... more recurring purchase records ... */ +] +``` + +### Usage Rows + +Amortization of commitment discounts occur the same way no matter how a purchase(s) are made. The same fixed usage-based or spend-based amount is applied evenly across all charge periods to eligible resources. Continuing with the same one-year, spend-based commitment discount with a $1.00 hourly commitment as above, there are 4 possible types of scenarios that can occur with eligible resource(s) during a charge period: + +* Scenario 1: 1 resource runs for $1.00 (100% utilization) +* Scenario 2: No eligible resources run (0% utilization) +* Scenario 3: 1 resource runs for $0.75 (75% utilization) +* Scenario 4: 1 resource runs for over the $1.00 hourly commitment (100% utilization + overage) + +#### Scenario 1: 1 resource runs for $1.00 (100% utilization) + +In this scenario, one eligible resource runs for the full hour and costs $1.00. + +```json +[ + { + "BillingPeriodStartDate": "2023-01-01 00:00:00Z", + "BillingPeriodEndDate": "2023-02-01 00:00:00Z", + "ChargePeriodStartDate": "2023-01-01 00:00:00Z", + "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "ChargeCategory": "Usage", + "ChargeFrequency": "Usage-Based", + "PricingCategory": "Committed", + "ResourceId": "", + "ConsumedQuantity": 1, + "ConsumedUnit": "Hour" + "BilledCost": 0.00, + "EffectiveCost": 1.00, + "CommitmentDiscountId": "", + "CommitmentDiscountStatus": "Used", + "CommitmentDiscountConsumedQuantity": 1.00, + "CommitmentDiscountUnit": "USD" + } +] +``` + +#### Scenario 2: No eligible resources run (0% utilization) + +In this scenario, the entire, eligible amount was unused and remained allocated to the commitment discount. + +```json +[ + { + "BillingPeriodStartDate": "2023-01-01 00:00:00Z", + "BillingPeriodEndDate": "2023-02-01 00:00:00Z", + "ChargePeriodStartDate": "2023-01-01 00:00:00Z", + "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "ChargeCategory": "Usage", + "ChargeFrequency": "Usage-Based", + "PricingCategory": "Committed", + "ResourceId": "", + "ConsumedQuantity": null, + "ConsumedUnit": null, + "BilledCost": 0.00, + "EffectiveCost": 1.00, + "CommitmentDiscountId": "", + "CommitmentDiscountStatus": "Unused", + "CommitmentDiscountConsumedQuantity": 1.00, + "CommitmentDiscountUnit": "USD" + } +] +``` + +#### Scenario 3: 1 resource runs for $0.75 (75% utilization) + +In this scenario, one eligible resource runs for the full hour, costs $0.75, and leaves $0.25 as unused. + +```json +[ + { + "BillingPeriodStartDate": "2023-01-01 00:00:00Z", + "BillingPeriodEndDate": "2023-02-01 00:00:00Z", + "ChargePeriodStartDate": "2023-01-01 00:00:00Z", + "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "ChargeCategory": "Usage", + "ChargeFrequency": "Usage-Based", + "PricingCategory": "Committed", + "ResourceId": "", + "ConsumedQuantity": 1, + "ConsumedUnit": "Hour", + "BilledCost": 0.00, + "EffectiveCost": 0.75, + "CommitmentDiscountId": "", + "CommitmentDiscountStatus": "Used", + "CommitmentDiscountConsumedQuantity": 0.75, + "CommitmentDiscountUnit": "USD" + }, + { + "BillingPeriodStartDate": "2023-01-01 00:00:00Z", + "BillingPeriodEndDate": "2023-02-01 00:00:00Z", + "ChargePeriodStartDate": "2023-01-01 00:00:00Z", + "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "ChargeCategory": "Usage", + "ChargeFrequency": "Usage-Based", + "PricingCategory": "Committed", + "ResourceId": "", + "ConsumedQuantity": null, + "ConsumedUnit": null, + "BilledCost": 0.00, + "EffectiveCost": 0.25, + "CommitmentDiscountId": "", + "CommitmentDiscountStatus": "Unused", + "CommitmentDiscountConsumedQuantity": 0.25, + "CommitmentDiscountUnit": "USD" + } +] +``` + +#### Scenario 4: 1 resource runs for over the $1.00 hourly commitment (100% utilization + overage) + +In this scenario, one eligible resource runs for the full hour and costs $1.50. $1.00 was amortized from the commitment discount, and $0.50 was charge as standard, on-demand spend. + +```json +[ + { + "BillingPeriodStartDate": "2023-01-01 00:00:00Z", + "BillingPeriodEndDate": "2023-02-01 00:00:00Z", + "ChargePeriodStartDate": "2023-01-01 00:00:00Z", + "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "ChargeCategory": "Usage", + "ChargeFrequency": "Usage-Based", + "PricingCategory": "Committed", + "ResourceId": "", + "ConsumedQuantity": 1, + "ConsumedUnit": "Hour", + "BilledCost": 0.00, + "EffectiveCost": 1.00, + "CommitmentDiscountId": "", + "CommitmentDiscountStatus": "Used", + "CommitmentDiscountConsumedQuantity": 1.00, + "CommitmentDiscountUnit": "USD" + }, + { + "BillingPeriodStartDate": "2023-01-01 00:00:00Z", + "BillingPeriodEndDate": "2023-02-01 00:00:00Z", + "ChargePeriodStartDate": "2023-01-01 00:00:00Z", + "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "ChargeCategory": "Usage", + "ChargeFrequency": "Usage-Based", + "PricingCategory": "Standard", + "ResourceId": "", + "ConsumedQuantity": 1, + "ConsumedUnit": "Hour", + "BilledCost": 0.50, + "EffectiveCost": 0.00 + } +] +``` From 943efd7cc068763c94441d025ddb9e060893a8f9 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Fri, 23 Aug 2024 23:06:24 -0400 Subject: [PATCH 02/18] Update commitment_discounts.md --- .../appendix/commitment_discounts.md | 64 +++++++++---------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 10a0de4e1..e595e3e3c 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -1,25 +1,25 @@ # Commitment Discounts -A commitment discount is a billing discount that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Within cost and usage datasets, commitment discounts typically consist of a set of purchases and usage records. +A commitment discount is a billing discount that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Commitment discounts typically consist of a set of purchase and usage records within cost and usage datasets. -## Purchases +## Purchasing While customers are bound to the term of a commitment discount, cloud-service providers, or CSPs, offer various payment options before and/or during the term: -* In-Advance - The commitment discount is paid in full before the term begins -* Monthly - The commitment discount is paid monthly over the term. -* Hybrid (In-Advance & Monthly) - Half of the commitment discount is paid in-advance and half is paid monthly over the term. +* *Upfront* - The commitment discount is paid in full before the term begins +* *Monthly* - The commitment discount is paid monthly over the term. +* *Hybrid* (1/2 Upfront & 1/2 Monthly) - Half of the commitment discount is paid in advance and half is paid monthly over the term. -For example, if a customer buys a spend-based commitment discount for 1 year, with a $1.00 hourly commitment, and pays with the hybrid option, their purchase schedule is: +For example, if a customer buys a spend-based commitment discount for 1 year, with a $1.00 hourly commitment, and pays with the hybrid option, the commitment discount's payment consists of both: -* In-Advance: $4,380 (24 hours \* 365 days \* $1.00 \* 0.5) -* Monthly: $182.50 (24 hours \* 365 days \* $1.00 / 12 months) +1. *Upfront* - $4,380 (`24 hours * 365 days * $1.00 * 0.5`) +2. *Monthly* - $182.50 (`24 hours * 365 days * $1.00 / 12 months`) ## Usage -Commitment discounts follow a "use-it-or-lose-it" model where the amortization of a commitment discount's purchase applies evenly over each charge period (typically hourly) over the term. +Commitment discounts follow a "use-it-or-lose-it" model where the amortization of a commitment discount's purchase applies evenly over each charge period of eligible resources over the term. -For example, if a customer buys a spend-based commitment with a $1.00 hourly commitment in January (31 days), only $1.00 is eligible for amortization for each hourly charge period. This means that if I have eligible resources running during this charge period, some or all of the $1.00 allocated to the charge period will be also be allocated to one or more resources. Conversely, if I don't have eligible resources running during this charge period, the $1.00 allocated to the charge period is wasted. +For example, if a customer buys a spend-based commitment with a $1.00 hourly commitment in January (31 days), only $1.00 is eligible for amortization for each hourly charge period. This means that if a customer have eligible resources running during this charge period, some or all of the $1.00 that is allocated to the charge period will be also be allocated to some or all of these resources. Conversely, if a customer does not have eligible resources running during this charge period, the $1.00 allocated to the charge period is wasted. ## Commitment Discounts in FOCUS @@ -27,15 +27,15 @@ Within the FOCUS specification, the following examples demonstrate how a commitm ### Purchase Rows -All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory:Committed`, and the commitment discount's id as both the `ResourceId` and `CommitmentDiscountId` value. In-advance purchases appear as a single record also with `ChargeCategory:Purchase`, `ChargeFrequency:One-Time`, and the commitment discount's entire purchased quantity, `CommitmentDiscountPurchasedQuantity`, and units, `CommitmentDiscountUnit` for the term. +All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. Upfront purchases appear as a single record also with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term as `CommitmentDiscountPurchasedQuantity` and `CommitmentDiscountUnit`, respectively. -Monthly purchases are spread across all corresponding charge periods of the term also with `ChargeCateogry:Purchase`, `ChargeFrequency:One-Time`, and the commitment discount's purchase quantity, `CommitmentDiscountPurchasedQuantity`, and units, `CommitmentDiscountUnit` for the charge period. +Monthly purchases are allocated across all corresponding charge periods of the term when `ChargeCateogry` is "Purchase", `ChargeFrequency` is "One-Time". and the commitment discount's purchase quantity, `CommitmentDiscountPurchasedQuantity`, and units, `CommitmentDiscountUnit` are reflected only for that charge period. -Using the same example as above, various purchase for a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023 can be seen as: +Using the same commitment discount example as above, a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023, various purchase options can occur: -#### In-Advance +#### Scenario #1: Upfront -The entire commitment is billed _once_ during the first charge period of the term for $8,670 (24 hours \* 365 days \* $1.00). +The entire commitment is billed _once_ during the first charge period of the term for $8,670 (derived as `24 hours * 365 days * $1.00`). ```json [ @@ -57,7 +57,7 @@ The entire commitment is billed _once_ during the first charge period of the ter ] ``` -#### Monthly +#### Scenario #2: Monthly The commitment is billed across all 8,760 charge periods of the term with $1.00 allocated to each charge period over the term. @@ -83,9 +83,9 @@ The commitment is billed across all 8,760 charge periods of the term with $1.00 ] ``` -#### Hybrid (In-Advance & Monthly) +#### Scenario #3: Hybrid (1/2 Upfront & 1/2 Monthly) -Half of the commitment is billed _once_ during the first charge period of the term _and_ the other half is billed across each charge period over the term. Amortized costs incur half of the amount (i.e. $0.50) from the in-advance purchase and the other half from monthly purchase. +Half of the commitment is billed _once_ during the first charge period of the term for $4,380 (derived as `24 hours * 182.5 days * $1.00`), and the other half is billed across each charge period over the term, derived as (`$1.00 * 8,760 hours * 0.5`). Amortized costs incur half of the amount (i.e. $0.50) from the upfront purchase and the other half from the monthly purchase. ```json [ @@ -98,7 +98,7 @@ Half of the commitment is billed _once_ during the first charge period of the te "ChargeFrequency": "One-Time", "PricingCategory": "Committed", "ResourceId": "", - "BilledCost": 1.00, + "BilledCost": 4380.00, "EffectiveCost": 0.00, "CommitmentDiscountId": "", "CommitmentDiscountPurchasedQuantity": 4380.00, @@ -126,16 +126,16 @@ Half of the commitment is billed _once_ during the first charge period of the te ### Usage Rows -Amortization of commitment discounts occur the same way no matter how a purchase(s) are made. The same fixed usage-based or spend-based amount is applied evenly across all charge periods to eligible resources. Continuing with the same one-year, spend-based commitment discount with a $1.00 hourly commitment as above, there are 4 possible types of scenarios that can occur with eligible resource(s) during a charge period: +Amortization of commitment discounts occur the same way regardless of how one or more purchases are made. The same usage-based or spend-based amount is applied evenly across all charge periods and potentially allocated to eligible resources. Continuing with the same commitment discount example, a one-year, spend-based commitment discount with a $1.00 hourly commitment, 4 types of scenarios can occur during a charge period: -* Scenario 1: 1 resource runs for $1.00 (100% utilization) -* Scenario 2: No eligible resources run (0% utilization) -* Scenario 3: 1 resource runs for $0.75 (75% utilization) -* Scenario 4: 1 resource runs for over the $1.00 hourly commitment (100% utilization + overage) +* Scenario #1: Eligible resource(s) runs for $1.00 (100% utilization) +* Scenario #2: No eligible resources run (0% utilization) +* Scenario #3: Eligible resource(s) runs for $0.75 (75% utilization) +* Scenario #4: Eligible resource(s) runs for over the $1.00 hourly commitment (100% utilization + overage) -#### Scenario 1: 1 resource runs for $1.00 (100% utilization) +#### Scenario #1: Eligible resource(s) runs for $1.00 (100% utilization) -In this scenario, one eligible resource runs for the full hour and costs $1.00. +In this scenario, one eligible resource runs for the full hour, so one row allocated to the resource is produced. ```json [ @@ -160,9 +160,9 @@ In this scenario, one eligible resource runs for the full hour and costs $1.00. ] ``` -#### Scenario 2: No eligible resources run (0% utilization) +#### Scenario #2: No eligible resources run (0% utilization) -In this scenario, the entire, eligible amount was unused and remained allocated to the commitment discount. +In this scenario, the entire, eligible amount was unused, so one unused row, allocated to the commitment discount, was produced. ```json [ @@ -187,9 +187,9 @@ In this scenario, the entire, eligible amount was unused and remained allocated ] ``` -#### Scenario 3: 1 resource runs for $0.75 (75% utilization) +#### Scenario #3: Eligible resource(s) runs for $0.75 (75% utilization) -In this scenario, one eligible resource runs for the full hour, costs $0.75, and leaves $0.25 as unused. +In this scenario, one eligible resource runs for the full hour. One row shows $0.75 to a resource, and the other shows that $0.25 remained unused. ```json [ @@ -232,9 +232,9 @@ In this scenario, one eligible resource runs for the full hour, costs $0.75, and ] ``` -#### Scenario 4: 1 resource runs for over the $1.00 hourly commitment (100% utilization + overage) +#### Scenario #4: Eligible resource(s) runs for over the $1.00 hourly commitment (100% utilization + overage) -In this scenario, one eligible resource runs for the full hour and costs $1.50. $1.00 was amortized from the commitment discount, and $0.50 was charge as standard, on-demand spend. +In this scenario, one eligible resource runs for the full hour and costs $1.50. One row shows that $1.00 was amortized from the commitment discount, and the other shows that $0.50 was charged as standard, on-demand spend. ```json [ From f21c015c978745fabb8bfadf149d8c89cd954344 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Mon, 26 Aug 2024 20:39:29 -0400 Subject: [PATCH 03/18] Incorporated a few suggestions from Shawn Alpay --- specification/appendix/commitment_discounts.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index e595e3e3c..363cacda8 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -1,19 +1,19 @@ # Commitment Discounts -A commitment discount is a billing discount that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Commitment discounts typically consist of a set of purchase and usage records within cost and usage datasets. +A commitment discount is a billing discount model that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Commitment discounts typically consist of a set of purchase and usage records within cost and usage datasets. ## Purchasing While customers are bound to the term of a commitment discount, cloud-service providers, or CSPs, offer various payment options before and/or during the term: -* *Upfront* - The commitment discount is paid in full before the term begins -* *Monthly* - The commitment discount is paid monthly over the term. -* *Hybrid* (1/2 Upfront & 1/2 Monthly) - Half of the commitment discount is paid in advance and half is paid monthly over the term. +* *Upfront* - The commitment discount is paid in full before the term begins. +* *Recurring* - The commitment discount is paid on a repeated basis, typically over each billing period of the term. +* *Hybrid* - Some of the commitment discount is paid before the term begins, and the rest is paid repeatedly over the term. For example, if a customer buys a spend-based commitment discount for 1 year, with a $1.00 hourly commitment, and pays with the hybrid option, the commitment discount's payment consists of both: 1. *Upfront* - $4,380 (`24 hours * 365 days * $1.00 * 0.5`) -2. *Monthly* - $182.50 (`24 hours * 365 days * $1.00 / 12 months`) +2. *Recurring* - $182.50 (`24 hours * 365 days * $1.00 / 12 months`) ## Usage @@ -29,7 +29,7 @@ Within the FOCUS specification, the following examples demonstrate how a commitm All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. Upfront purchases appear as a single record also with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term as `CommitmentDiscountPurchasedQuantity` and `CommitmentDiscountUnit`, respectively. -Monthly purchases are allocated across all corresponding charge periods of the term when `ChargeCateogry` is "Purchase", `ChargeFrequency` is "One-Time". and the commitment discount's purchase quantity, `CommitmentDiscountPurchasedQuantity`, and units, `CommitmentDiscountUnit` are reflected only for that charge period. +Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCateogry` is "Purchase", `ChargeFrequency` is "One-Time". and the commitment discount's purchase quantity, `CommitmentDiscountPurchasedQuantity`, and units, `CommitmentDiscountUnit` are reflected only for that charge period. Using the same commitment discount example as above, a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023, various purchase options can occur: @@ -57,7 +57,7 @@ The entire commitment is billed _once_ during the first charge period of the ter ] ``` -#### Scenario #2: Monthly +#### Scenario #2: Recurring The commitment is billed across all 8,760 charge periods of the term with $1.00 allocated to each charge period over the term. @@ -83,9 +83,9 @@ The commitment is billed across all 8,760 charge periods of the term with $1.00 ] ``` -#### Scenario #3: Hybrid (1/2 Upfront & 1/2 Monthly) +#### Scenario #3: Hybrid -Half of the commitment is billed _once_ during the first charge period of the term for $4,380 (derived as `24 hours * 182.5 days * $1.00`), and the other half is billed across each charge period over the term, derived as (`$1.00 * 8,760 hours * 0.5`). Amortized costs incur half of the amount (i.e. $0.50) from the upfront purchase and the other half from the monthly purchase. +Half of the commitment is billed _once_ during the first charge period of the term for $4,380 (derived as `24 hours * 182.5 days * $1.00`), and the other half is billed across each charge period over the term, derived as (`$1.00 * 8,760 hours * 0.5`). Amortized costs incur half of the amount (i.e. $0.50) from the upfront purchase and the other half from the recurring purchase. ```json [ From e864bb57770d1ce4eba66df81bcb2847b052044d Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Mon, 26 Aug 2024 20:48:21 -0400 Subject: [PATCH 04/18] Ignore MD031: Fenced code blocks should be surrounded by blank lines (blanks-around-fences) --- specification/markdownlnt.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/specification/markdownlnt.cfg b/specification/markdownlnt.cfg index 1a2f234b2..6b2fae3d7 100644 --- a/specification/markdownlnt.cfg +++ b/specification/markdownlnt.cfg @@ -2,6 +2,7 @@ "plugins" : { "MD033" : { "enabled" : false }, "MD013" : { "enabled" : false }, + "MD031" : { "enabled" : false }, "MD041" : { "enabled" : false }, "additional_paths": "../custom_linter_rules/rule_md_990.py" } From 3fec018fea1b5e4bde4a44acb1917c4378d3fdd8 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Thu, 29 Aug 2024 11:20:44 -0400 Subject: [PATCH 05/18] Grammar fixes, calling out when Consumed{Quantity,Unit} are null, and a section on units for usage/spend commitments --- specification/appendix/commitment_discounts.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 363cacda8..f6a6cf50c 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -2,6 +2,10 @@ A commitment discount is a billing discount model that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Commitment discounts typically consist of a set of purchase and usage records within cost and usage datasets. +Usage-based commitment discounts obligate a customer to a total quantity of time of a preselected term, typically measured in "Hours". In some cases, usage-based commitment discounts allow similar resources of different size classifications to relatively benefit from commitment discount rates. This is typically known as "size flexibility", and is determined by multiplying the number of actual hours consumed by a resource by its predetermined normalization factor to derive the number of "Normalized Hours" consumed. + +Spend-based commitment discounts obligate a customer to total monetary quantity over a preselected term, typically denoted by the invoice's selected billing currency (ex: "USD"). + ## Purchasing While customers are bound to the term of a commitment discount, cloud-service providers, or CSPs, offer various payment options before and/or during the term: @@ -19,17 +23,17 @@ For example, if a customer buys a spend-based commitment discount for 1 year, wi Commitment discounts follow a "use-it-or-lose-it" model where the amortization of a commitment discount's purchase applies evenly over each charge period of eligible resources over the term. -For example, if a customer buys a spend-based commitment with a $1.00 hourly commitment in January (31 days), only $1.00 is eligible for amortization for each hourly charge period. This means that if a customer have eligible resources running during this charge period, some or all of the $1.00 that is allocated to the charge period will be also be allocated to some or all of these resources. Conversely, if a customer does not have eligible resources running during this charge period, the $1.00 allocated to the charge period is wasted. +For example, if a customer buys a spend-based commitment with a $1.00 hourly commitment in January (31 days), only $1.00 is eligible for consumption for each hourly charge period. This means that if a customer has eligible resources running during this charge period, some or all of the $1.00 that is allocated to the charge period will also be allocated to some or all of these resources. Conversely, if a customer does not have eligible resources running during this charge period, the $1.00 allocated to the charge period is wasted. ## Commitment Discounts in FOCUS -Within the FOCUS specification, the following examples demonstrate how a commitment discount would appear across various payment and amortization scenarios. +Within the FOCUS specification, the following examples demonstrate how a commitment discount would appear across various payment and usage scenarios. ### Purchase Rows All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. Upfront purchases appear as a single record also with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term as `CommitmentDiscountPurchasedQuantity` and `CommitmentDiscountUnit`, respectively. -Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCateogry` is "Purchase", `ChargeFrequency` is "One-Time". and the commitment discount's purchase quantity, `CommitmentDiscountPurchasedQuantity`, and units, `CommitmentDiscountUnit` are reflected only for that charge period. +Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCategory` is "Purchase", `ChargeFrequency` is "One-Time". and the commitment discount's purchase quantity, `CommitmentDiscountPurchasedQuantity`, and units, `CommitmentDiscountUnit` are reflected only for that charge period. Using the same commitment discount example as above, a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023, various purchase options can occur: @@ -79,7 +83,7 @@ The commitment is billed across all 8,760 charge periods of the term with $1.00 "CommitmentDiscountUnit": "USD" }, - /* ... more recurring purchase records ... */ + /* ... 743 more recurring purchase records for the billing period ... */ ] ``` @@ -120,7 +124,7 @@ Half of the commitment is billed _once_ during the first charge period of the te "CommitmentDiscountUnit": "USD" }, - /* ... more recurring purchase records ... */ + /* ... 743 more recurring purchase records for the billing period ... */ ] ``` @@ -149,7 +153,7 @@ In this scenario, one eligible resource runs for the full hour, so one row alloc "PricingCategory": "Committed", "ResourceId": "", "ConsumedQuantity": 1, - "ConsumedUnit": "Hour" + "ConsumedUnit": "Hour", "BilledCost": 0.00, "EffectiveCost": 1.00, "CommitmentDiscountId": "", @@ -162,7 +166,7 @@ In this scenario, one eligible resource runs for the full hour, so one row alloc #### Scenario #2: No eligible resources run (0% utilization) -In this scenario, the entire, eligible amount was unused, so one unused row, allocated to the commitment discount, was produced. +In this scenario, the entire, eligible amount was unused, so one unused row, allocated to the commitment discount, was produced. Most notably, ConsumedQuantity and ConsumedUnit are null while CommitmentDiscountConsumedQuantity is not because $1 was still drawn down by the commitment discount even though it was not consumed by a resource. ```json [ From 788c90cf3e7e2c36dbf8ce6ed9cf7bdee8875e30 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Thu, 29 Aug 2024 13:21:21 -0400 Subject: [PATCH 06/18] Update specification/appendix/commitment_discounts.md Co-authored-by: Shawn Alpay <77511110+salpaysenturus@users.noreply.github.com> --- specification/appendix/commitment_discounts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index f6a6cf50c..708856864 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -33,7 +33,7 @@ Within the FOCUS specification, the following examples demonstrate how a commitm All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. Upfront purchases appear as a single record also with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term as `CommitmentDiscountPurchasedQuantity` and `CommitmentDiscountUnit`, respectively. -Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCategory` is "Purchase", `ChargeFrequency` is "One-Time". and the commitment discount's purchase quantity, `CommitmentDiscountPurchasedQuantity`, and units, `CommitmentDiscountUnit` are reflected only for that charge period. +Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCategory` is "Purchase", `ChargeFrequency` is "One-Time", and `CommitmentDiscountPurchasedQuantity` and `CommitmentDiscountUnit` are reflected only for that charge period. Using the same commitment discount example as above, a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023, various purchase options can occur: From 93199b7ec0c7c244fa4cd2b8b98be766cba18909 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Thu, 29 Aug 2024 13:24:50 -0400 Subject: [PATCH 07/18] Specify that 1 resource is being modeled --- specification/appendix/commitment_discounts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 708856864..3cf7b632b 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -130,7 +130,7 @@ Half of the commitment is billed _once_ during the first charge period of the te ### Usage Rows -Amortization of commitment discounts occur the same way regardless of how one or more purchases are made. The same usage-based or spend-based amount is applied evenly across all charge periods and potentially allocated to eligible resources. Continuing with the same commitment discount example, a one-year, spend-based commitment discount with a $1.00 hourly commitment, 4 types of scenarios can occur during a charge period: +Amortization of commitment discounts occur the same way regardless of how one or more purchases are made. The same usage-based or spend-based amount is applied evenly across all charge periods and potentially allocated to eligible resources. Continuing with the same commitment discount example, a one-year, spend-based commitment discount with a $1.00 hourly commitment, and 1 resource, 4 types of scenarios can occur during a charge period: * Scenario #1: Eligible resource(s) runs for $1.00 (100% utilization) * Scenario #2: No eligible resources run (0% utilization) From e4bd7448a6dbde4800fea5651f682e1e586d4a2f Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Tue, 3 Sep 2024 07:20:06 -0400 Subject: [PATCH 08/18] Update commitment_discounts.md Co-authored-by: Irena Jurica --- specification/appendix/commitment_discounts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 3cf7b632b..c1da44c8e 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -33,7 +33,7 @@ Within the FOCUS specification, the following examples demonstrate how a commitm All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. Upfront purchases appear as a single record also with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term as `CommitmentDiscountPurchasedQuantity` and `CommitmentDiscountUnit`, respectively. -Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCategory` is "Purchase", `ChargeFrequency` is "One-Time", and `CommitmentDiscountPurchasedQuantity` and `CommitmentDiscountUnit` are reflected only for that charge period. +Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCategory` is "Purchase", `ChargeFrequency` is "Recurring", and `CommitmentDiscountPurchasedQuantity` and `CommitmentDiscountUnit` are reflected only for that charge period. Using the same commitment discount example as above, a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023, various purchase options can occur: From 167f67a672f59a4139d98f20d2604a52b04ea467 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Tue, 3 Sep 2024 10:36:08 -0400 Subject: [PATCH 09/18] Fix DateTime format --- .../appendix/commitment_discounts.md | 80 +++++++++---------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 3cf7b632b..4a574bd30 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -44,10 +44,10 @@ The entire commitment is billed _once_ during the first charge period of the ter ```json [ { - "BillingPeriodStartDate": "2023-01-01 00:00:00Z", - "BillingPeriodEndDate": "2023-02-01 00:00:00Z", - "ChargePeriodStartDate": "2023-01-01 00:00:00Z", - "ChargePeriodEndDate": "2024-01-01 00:00:00Z", + "BillingPeriodStartDate": "2023-01-01T00:00:00Z", + "BillingPeriodEndDate": "2023-02-01T00:00:00Z", + "ChargePeriodStartDate": "2023-01-01T00:00:00Z", + "ChargePeriodEndDate": "2024-01-01T00:00:00Z", "ChargeCategory": "Purchase", "ChargeFrequency": "One-Time", "PricingCategory": "Committed", @@ -68,10 +68,10 @@ The commitment is billed across all 8,760 charge periods of the term with $1.00 ```json [ { - "BillingPeriodStartDate": "2023-01-01 00:00:00Z", - "BillingPeriodEndDate": "2023-02-01 00:00:00Z", - "ChargePeriodStartDate": "2023-01-01 00:00:00Z", - "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "BillingPeriodStartDate": "2023-01-01T00:00:00Z", + "BillingPeriodEndDate": "2023-02-01T00:00:00Z", + "ChargePeriodStartDate": "2023-01-01T00:00:00Z", + "ChargePeriodEndDate": "2023-01-01T01:00:00Z", "ChargeCategory": "Purchase", "ChargeFrequency": "Recurring", "PricingCategory": "Committed", @@ -94,10 +94,10 @@ Half of the commitment is billed _once_ during the first charge period of the te ```json [ { - "BillingPeriodStartDate": "2023-01-01 00:00:00Z", - "BillingPeriodEndDate": "2023-02-01 00:00:00Z", - "ChargePeriodStartDate": "2023-01-01 00:00:00Z", - "ChargePeriodEndDate": "2024-01-01 00:00:00Z", + "BillingPeriodStartDate": "2023-01-01T00:00:00Z", + "BillingPeriodEndDate": "2023-02-01T00:00:00Z", + "ChargePeriodStartDate": "2023-01-01T00:00:00Z", + "ChargePeriodEndDate": "2024-01-01T00:00:00Z", "ChargeCategory": "Purchase", "ChargeFrequency": "One-Time", "PricingCategory": "Committed", @@ -109,10 +109,10 @@ Half of the commitment is billed _once_ during the first charge period of the te "CommitmentDiscountUnit": "USD" }, { - "BillingPeriodStartDate": "2023-01-01 00:00:00Z", - "BillingPeriodEndDate": "2023-02-01 00:00:00Z", - "ChargePeriodStartDate": "2023-01-01 00:00:00Z", - "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "BillingPeriodStartDate": "2023-01-01T00:00:00Z", + "BillingPeriodEndDate": "2023-02-01T00:00:00Z", + "ChargePeriodStartDate": "2023-01-01T00:00:00Z", + "ChargePeriodEndDate": "2023-01-01T01:00:00Z", "ChargeCategory": "Purchase", "ChargeFrequency": "Recurring", "PricingCategory": "Committed", @@ -144,10 +144,10 @@ In this scenario, one eligible resource runs for the full hour, so one row alloc ```json [ { - "BillingPeriodStartDate": "2023-01-01 00:00:00Z", - "BillingPeriodEndDate": "2023-02-01 00:00:00Z", - "ChargePeriodStartDate": "2023-01-01 00:00:00Z", - "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "BillingPeriodStartDate": "2023-01-01T00:00:00Z", + "BillingPeriodEndDate": "2023-02-01T00:00:00Z", + "ChargePeriodStartDate": "2023-01-01T00:00:00Z", + "ChargePeriodEndDate": "2023-01-01T01:00:00Z", "ChargeCategory": "Usage", "ChargeFrequency": "Usage-Based", "PricingCategory": "Committed", @@ -171,10 +171,10 @@ In this scenario, the entire, eligible amount was unused, so one unused row, all ```json [ { - "BillingPeriodStartDate": "2023-01-01 00:00:00Z", - "BillingPeriodEndDate": "2023-02-01 00:00:00Z", - "ChargePeriodStartDate": "2023-01-01 00:00:00Z", - "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "BillingPeriodStartDate": "2023-01-01T00:00:00Z", + "BillingPeriodEndDate": "2023-02-01T00:00:00Z", + "ChargePeriodStartDate": "2023-01-01T00:00:00Z", + "ChargePeriodEndDate": "2023-01-01T01:00:00Z", "ChargeCategory": "Usage", "ChargeFrequency": "Usage-Based", "PricingCategory": "Committed", @@ -198,10 +198,10 @@ In this scenario, one eligible resource runs for the full hour. One row shows $0 ```json [ { - "BillingPeriodStartDate": "2023-01-01 00:00:00Z", - "BillingPeriodEndDate": "2023-02-01 00:00:00Z", - "ChargePeriodStartDate": "2023-01-01 00:00:00Z", - "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "BillingPeriodStartDate": "2023-01-01T00:00:00Z", + "BillingPeriodEndDate": "2023-02-01T00:00:00Z", + "ChargePeriodStartDate": "2023-01-01T00:00:00Z", + "ChargePeriodEndDate": "2023-01-01T01:00:00Z", "ChargeCategory": "Usage", "ChargeFrequency": "Usage-Based", "PricingCategory": "Committed", @@ -216,10 +216,10 @@ In this scenario, one eligible resource runs for the full hour. One row shows $0 "CommitmentDiscountUnit": "USD" }, { - "BillingPeriodStartDate": "2023-01-01 00:00:00Z", - "BillingPeriodEndDate": "2023-02-01 00:00:00Z", - "ChargePeriodStartDate": "2023-01-01 00:00:00Z", - "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "BillingPeriodStartDate": "2023-01-01T00:00:00Z", + "BillingPeriodEndDate": "2023-02-01T00:00:00Z", + "ChargePeriodStartDate": "2023-01-01T00:00:00Z", + "ChargePeriodEndDate": "2023-01-01T01:00:00Z", "ChargeCategory": "Usage", "ChargeFrequency": "Usage-Based", "PricingCategory": "Committed", @@ -243,10 +243,10 @@ In this scenario, one eligible resource runs for the full hour and costs $1.50. ```json [ { - "BillingPeriodStartDate": "2023-01-01 00:00:00Z", - "BillingPeriodEndDate": "2023-02-01 00:00:00Z", - "ChargePeriodStartDate": "2023-01-01 00:00:00Z", - "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "BillingPeriodStartDate": "2023-01-01T00:00:00Z", + "BillingPeriodEndDate": "2023-02-01T00:00:00Z", + "ChargePeriodStartDate": "2023-01-01T00:00:00Z", + "ChargePeriodEndDate": "2023-01-01T01:00:00Z", "ChargeCategory": "Usage", "ChargeFrequency": "Usage-Based", "PricingCategory": "Committed", @@ -261,10 +261,10 @@ In this scenario, one eligible resource runs for the full hour and costs $1.50. "CommitmentDiscountUnit": "USD" }, { - "BillingPeriodStartDate": "2023-01-01 00:00:00Z", - "BillingPeriodEndDate": "2023-02-01 00:00:00Z", - "ChargePeriodStartDate": "2023-01-01 00:00:00Z", - "ChargePeriodEndDate": "2023-01-01 01:00:00Z", + "BillingPeriodStartDate": "2023-01-01T00:00:00Z", + "BillingPeriodEndDate": "2023-02-01T00:00:00Z", + "ChargePeriodStartDate": "2023-01-01T00:00:00Z", + "ChargePeriodEndDate": "2023-01-01T01:00:00Z", "ChargeCategory": "Usage", "ChargeFrequency": "Usage-Based", "PricingCategory": "Standard", From a0d27bc456b3c9d372591c739de1f7d592f9b10c Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Wed, 11 Sep 2024 07:59:45 -0400 Subject: [PATCH 10/18] Small term/wording updates based on the evolution of pr: https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/pull/400 --- .../appendix/commitment_discounts.md | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 8d95e98c8..11781fdae 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -2,9 +2,9 @@ A commitment discount is a billing discount model that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Commitment discounts typically consist of a set of purchase and usage records within cost and usage datasets. -Usage-based commitment discounts obligate a customer to a total quantity of time of a preselected term, typically measured in "Hours". In some cases, usage-based commitment discounts allow similar resources of different size classifications to relatively benefit from commitment discount rates. This is typically known as "size flexibility", and is determined by multiplying the number of actual hours consumed by a resource by its predetermined normalization factor to derive the number of "Normalized Hours" consumed. +Usage-based commitment discounts obligate a customer to a predetermined amount of usage over a preselected term, typically measured in "Hours". In some cases, usage-based commitment discounts allow similar resources of different size classifications to relatively benefit from commitment discount rates. This is typically known as "commitment flexibility", and can be derived by multiplying the number of actual hours consumed by a resource by its predetermined *normalization factor* or *ratio* to derive the number of normalized hours consumed. -Spend-based commitment discounts obligate a customer to total monetary quantity over a preselected term, typically denoted by the invoice's selected billing currency (ex: "USD"). +Spend-based commitment discounts obligate a customer to a predetermined amount of spend over a preselected term, typically denoted by the invoice's selected billing currency (ex: "USD"). ## Purchasing @@ -31,9 +31,9 @@ Within the FOCUS specification, the following examples demonstrate how a commitm ### Purchase Rows -All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. Upfront purchases appear as a single record also with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term as `CommitmentDiscountPurchasedQuantity` and `CommitmentDiscountUnit`, respectively. +All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. Upfront purchases appear as a single record also with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term as `CommitmentDiscountQuantity` and `CommitmentDiscountUnit`, respectively. -Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCategory` is "Purchase", `ChargeFrequency` is "Recurring", and `CommitmentDiscountPurchasedQuantity` and `CommitmentDiscountUnit` are reflected only for that charge period. +Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCategory` is "Purchase", `ChargeFrequency` is "Recurring", and `CommitmentDiscountQuantity` and `CommitmentDiscountUnit` are reflected only for that charge period. Using the same commitment discount example as above, a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023, various purchase options can occur: @@ -55,7 +55,7 @@ The entire commitment is billed _once_ during the first charge period of the ter "BilledCost": 8760.00, "EffectiveCost": 0.00, "CommitmentDiscountId": "", - "CommitmentDiscountPurchasedQuantity": 8760.00, + "CommitmentDiscountQuantity": 8760.00, "CommitmentDiscountUnit": "USD" } ] @@ -79,7 +79,7 @@ The commitment is billed across all 8,760 charge periods of the term with $1.00 "BilledCost": 1.00, "EffectiveCost": 0.00, "CommitmentDiscountId": "", - "CommitmentDiscountPurchasedQuantity": 1.00, + "CommitmentDiscountQuantity": 1.00, "CommitmentDiscountUnit": "USD" }, @@ -89,7 +89,7 @@ The commitment is billed across all 8,760 charge periods of the term with $1.00 #### Scenario #3: Hybrid -Half of the commitment is billed _once_ during the first charge period of the term for $4,380 (derived as `24 hours * 182.5 days * $1.00`), and the other half is billed across each charge period over the term, derived as (`$1.00 * 8,760 hours * 0.5`). Amortized costs incur half of the amount (i.e. $0.50) from the upfront purchase and the other half from the recurring purchase. +With a 50/50 split, half of the commitment is billed _once_ during the first charge period of the term for $4,380 (derived as `24 hours * 182.5 days * $1.00`), and the other half is billed across each charge period over the term, derived as (`$1.00 * 8,760 hours * 0.5`). Amortized costs incur half of the amount (i.e. $0.50) from the upfront purchase and the other half from the recurring purchase. ```json [ @@ -105,7 +105,7 @@ Half of the commitment is billed _once_ during the first charge period of the te "BilledCost": 4380.00, "EffectiveCost": 0.00, "CommitmentDiscountId": "", - "CommitmentDiscountPurchasedQuantity": 4380.00, + "CommitmentDiscountQuantity": 4380.00, "CommitmentDiscountUnit": "USD" }, { @@ -120,7 +120,7 @@ Half of the commitment is billed _once_ during the first charge period of the te "BilledCost": 0.50, "EffectiveCost": 0.00, "CommitmentDiscountId": "", - "CommitmentDiscountPurchasedQuantity": 0.50, + "CommitmentDiscountQuantity": 0.50, "CommitmentDiscountUnit": "USD" }, @@ -158,7 +158,7 @@ In this scenario, one eligible resource runs for the full hour, so one row alloc "EffectiveCost": 1.00, "CommitmentDiscountId": "", "CommitmentDiscountStatus": "Used", - "CommitmentDiscountConsumedQuantity": 1.00, + "CommitmentDiscountQuantity": 1.00, "CommitmentDiscountUnit": "USD" } ] @@ -166,7 +166,7 @@ In this scenario, one eligible resource runs for the full hour, so one row alloc #### Scenario #2: No eligible resources run (0% utilization) -In this scenario, the entire, eligible amount was unused, so one unused row, allocated to the commitment discount, was produced. Most notably, ConsumedQuantity and ConsumedUnit are null while CommitmentDiscountConsumedQuantity is not because $1 was still drawn down by the commitment discount even though it was not consumed by a resource. +In this scenario, the entire, eligible amount was unused, so one unused row, allocated to the commitment discount, was produced. Most notably, ConsumedQuantity and ConsumedUnit are null while CommitmentDiscountQuantity is not because $1 was still drawn down by the commitment discount even though it was not consumed by a resource. ```json [ @@ -185,7 +185,7 @@ In this scenario, the entire, eligible amount was unused, so one unused row, all "EffectiveCost": 1.00, "CommitmentDiscountId": "", "CommitmentDiscountStatus": "Unused", - "CommitmentDiscountConsumedQuantity": 1.00, + "CommitmentDiscountQuantity": 1.00, "CommitmentDiscountUnit": "USD" } ] @@ -212,7 +212,7 @@ In this scenario, one eligible resource runs for the full hour. One row shows $0 "EffectiveCost": 0.75, "CommitmentDiscountId": "", "CommitmentDiscountStatus": "Used", - "CommitmentDiscountConsumedQuantity": 0.75, + "CommitmentDiscountQuantity": 0.75, "CommitmentDiscountUnit": "USD" }, { @@ -230,7 +230,7 @@ In this scenario, one eligible resource runs for the full hour. One row shows $0 "EffectiveCost": 0.25, "CommitmentDiscountId": "", "CommitmentDiscountStatus": "Unused", - "CommitmentDiscountConsumedQuantity": 0.25, + "CommitmentDiscountQuantity": 0.25, "CommitmentDiscountUnit": "USD" } ] @@ -257,7 +257,7 @@ In this scenario, one eligible resource runs for the full hour and costs $1.50. "EffectiveCost": 1.00, "CommitmentDiscountId": "", "CommitmentDiscountStatus": "Used", - "CommitmentDiscountConsumedQuantity": 1.00, + "CommitmentDiscountQuantity": 1.00, "CommitmentDiscountUnit": "USD" }, { From 821d926c0e2bbea4ee193a5f96d200c3f23d82fd Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Mon, 16 Sep 2024 07:51:21 -0400 Subject: [PATCH 11/18] Rearrange property in JSON block --- specification/appendix/commitment_discounts.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 11781fdae..9e52e5bf9 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -157,8 +157,8 @@ In this scenario, one eligible resource runs for the full hour, so one row alloc "BilledCost": 0.00, "EffectiveCost": 1.00, "CommitmentDiscountId": "", - "CommitmentDiscountStatus": "Used", "CommitmentDiscountQuantity": 1.00, + "CommitmentDiscountStatus": "Used", "CommitmentDiscountUnit": "USD" } ] @@ -184,8 +184,8 @@ In this scenario, the entire, eligible amount was unused, so one unused row, all "BilledCost": 0.00, "EffectiveCost": 1.00, "CommitmentDiscountId": "", - "CommitmentDiscountStatus": "Unused", "CommitmentDiscountQuantity": 1.00, + "CommitmentDiscountStatus": "Unused", "CommitmentDiscountUnit": "USD" } ] @@ -211,8 +211,8 @@ In this scenario, one eligible resource runs for the full hour. One row shows $0 "BilledCost": 0.00, "EffectiveCost": 0.75, "CommitmentDiscountId": "", - "CommitmentDiscountStatus": "Used", "CommitmentDiscountQuantity": 0.75, + "CommitmentDiscountStatus": "Used", "CommitmentDiscountUnit": "USD" }, { @@ -229,8 +229,8 @@ In this scenario, one eligible resource runs for the full hour. One row shows $0 "BilledCost": 0.00, "EffectiveCost": 0.25, "CommitmentDiscountId": "", - "CommitmentDiscountStatus": "Unused", "CommitmentDiscountQuantity": 0.25, + "CommitmentDiscountStatus": "Unused", "CommitmentDiscountUnit": "USD" } ] @@ -256,8 +256,8 @@ In this scenario, one eligible resource runs for the full hour and costs $1.50. "BilledCost": 0.00, "EffectiveCost": 1.00, "CommitmentDiscountId": "", - "CommitmentDiscountStatus": "Used", "CommitmentDiscountQuantity": 1.00, + "CommitmentDiscountStatus": "Used", "CommitmentDiscountUnit": "USD" }, { From 3a50e6c660a720a48061edf57cbd18a707fe2e92 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Wed, 18 Sep 2024 21:13:48 -0400 Subject: [PATCH 12/18] Replace 'hybrid' with 'partial' --- specification/appendix/commitment_discounts.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 9e52e5bf9..ad4de906f 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -12,9 +12,9 @@ While customers are bound to the term of a commitment discount, cloud-service pr * *Upfront* - The commitment discount is paid in full before the term begins. * *Recurring* - The commitment discount is paid on a repeated basis, typically over each billing period of the term. -* *Hybrid* - Some of the commitment discount is paid before the term begins, and the rest is paid repeatedly over the term. +* *Partial* - Some of the commitment discount is paid before the term begins, and the rest is paid repeatedly over the term. -For example, if a customer buys a spend-based commitment discount for 1 year, with a $1.00 hourly commitment, and pays with the hybrid option, the commitment discount's payment consists of both: +For example, if a customer buys a spend-based commitment discount for 1 year, with a $1.00 hourly commitment, and pays with the partial option, the commitment discount's payment consists of both: 1. *Upfront* - $4,380 (`24 hours * 365 days * $1.00 * 0.5`) 2. *Recurring* - $182.50 (`24 hours * 365 days * $1.00 / 12 months`) @@ -87,7 +87,7 @@ The commitment is billed across all 8,760 charge periods of the term with $1.00 ] ``` -#### Scenario #3: Hybrid +#### Scenario #3: Partial With a 50/50 split, half of the commitment is billed _once_ during the first charge period of the term for $4,380 (derived as `24 hours * 182.5 days * $1.00`), and the other half is billed across each charge period over the term, derived as (`$1.00 * 8,760 hours * 0.5`). Amortized costs incur half of the amount (i.e. $0.50) from the upfront purchase and the other half from the recurring purchase. From 49c03894d1063ba0aa0143e8dd844832d7501f5b Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Thu, 19 Sep 2024 08:23:16 -0400 Subject: [PATCH 13/18] Additional grammar edits/fixes --- .../appendix/commitment_discounts.md | 50 +++++++++---------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index ad4de906f..bfa264579 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -2,44 +2,44 @@ A commitment discount is a billing discount model that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Commitment discounts typically consist of a set of purchase and usage records within cost and usage datasets. -Usage-based commitment discounts obligate a customer to a predetermined amount of usage over a preselected term, typically measured in "Hours". In some cases, usage-based commitment discounts allow similar resources of different size classifications to relatively benefit from commitment discount rates. This is typically known as "commitment flexibility", and can be derived by multiplying the number of actual hours consumed by a resource by its predetermined *normalization factor* or *ratio* to derive the number of normalized hours consumed. +Usage-based commitment discounts obligate a customer to a predetermined amount of usage over a preselected term, typically measured in "Hours". In some cases, usage-based commitment discounts allow similar resources of different size classifications to relatively benefit from commitment discount rates. This is typically known as *commitment flexibility*, and can be derived by multiplying the number of actual resource hours consumed by a predefined SKU-based coefficient, sometimes referred to as a *normalization factor* or *ratio*, to derive the number of normalized hours consumed. Spend-based commitment discounts obligate a customer to a predetermined amount of spend over a preselected term, typically denoted by the invoice's selected billing currency (ex: "USD"). ## Purchasing -While customers are bound to the term of a commitment discount, cloud-service providers, or CSPs, offer various payment options before and/or during the term: +While customers are bound to the term of a commitment discount, cloud-service providers offer some or all of the following payment options before and/or during the term: * *Upfront* - The commitment discount is paid in full before the term begins. * *Recurring* - The commitment discount is paid on a repeated basis, typically over each billing period of the term. * *Partial* - Some of the commitment discount is paid before the term begins, and the rest is paid repeatedly over the term. -For example, if a customer buys a spend-based commitment discount for 1 year, with a $1.00 hourly commitment, and pays with the partial option, the commitment discount's payment consists of both: +For example, if a customer buys a 1-year, spend-based commitment discount with a $1.00 hourly commit and pays with the partial option, the commitment discount's payment consists of 1 upfront purchase in the beginning of the term *and* monthly recurring purchases with the following totals: 1. *Upfront* - $4,380 (`24 hours * 365 days * $1.00 * 0.5`) 2. *Recurring* - $182.50 (`24 hours * 365 days * $1.00 / 12 months`) ## Usage -Commitment discounts follow a "use-it-or-lose-it" model where the amortization of a commitment discount's purchase applies evenly over each charge period of eligible resources over the term. +Commitment discounts follow a "use-it-or-lose-it" model where the amortization of a commitment discount's purchase applies evenly to eligible resources over each charge period of the term. -For example, if a customer buys a spend-based commitment with a $1.00 hourly commitment in January (31 days), only $1.00 is eligible for consumption for each hourly charge period. This means that if a customer has eligible resources running during this charge period, some or all of the $1.00 that is allocated to the charge period will also be allocated to some or all of these resources. Conversely, if a customer does not have eligible resources running during this charge period, the $1.00 allocated to the charge period is wasted. +For example, if a customer buys a spend-based commitment with a $1.00 hourly commitment in January (31 days), only $1.00 is eligible for consumption for each hourly charge period. If a customer has eligible resources running during this charge period, an amount of up to $1.00 will be allocated to these resources. Conversely, if a customer does have eligible resources running that fully take advantage of this $1.00 during this charge period, then some or all of this amount will go to waste. ## Commitment Discounts in FOCUS -Within the FOCUS specification, the following examples demonstrate how a commitment discount would appear across various payment and usage scenarios. +Within the FOCUS specification, the following examples demonstrate how a commitment discount appears across various payment and usage scenarios. ### Purchase Rows -All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. Upfront purchases appear as a single record also with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term as `CommitmentDiscountQuantity` and `CommitmentDiscountUnit`, respectively. +All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and with the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. Upfront purchases appear as a single record with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term reflected as `CommitmentDiscountQuantity` and `CommitmentDiscountUnit`, respectively. Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCategory` is "Purchase", `ChargeFrequency` is "Recurring", and `CommitmentDiscountQuantity` and `CommitmentDiscountUnit` are reflected only for that charge period. -Using the same commitment discount example as above, a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023, various purchase options can occur: +Using the same commitment discount example as above with a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023, various purchase options are available: #### Scenario #1: Upfront -The entire commitment is billed _once_ during the first charge period of the term for $8,670 (derived as `24 hours * 365 days * $1.00`). +The entire commitment discount is billed _once_ during the first charge period of the term for $8,670 (derived as `24 hours * 365 days * $1.00`). ```json [ @@ -63,7 +63,7 @@ The entire commitment is billed _once_ during the first charge period of the ter #### Scenario #2: Recurring -The commitment is billed across all 8,760 charge periods of the term with $1.00 allocated to each charge period over the term. +The commitment discount is billed across all 8,760 (`24 hours * 365 days`) charge periods of the term with $1.00 allocated to each charge period over the term. ```json [ @@ -83,7 +83,7 @@ The commitment is billed across all 8,760 charge periods of the term with $1.00 "CommitmentDiscountUnit": "USD" }, - /* ... 743 more recurring purchase records for the billing period ... */ + /* ... 8,759 more recurring purchase records for the term ... */ ] ``` @@ -124,22 +124,22 @@ With a 50/50 split, half of the commitment is billed _once_ during the first cha "CommitmentDiscountUnit": "USD" }, - /* ... 743 more recurring purchase records for the billing period ... */ + /* ... 8,759 more recurring purchase records for the term ... */ ] ``` ### Usage Rows -Amortization of commitment discounts occur the same way regardless of how one or more purchases are made. The same usage-based or spend-based amount is applied evenly across all charge periods and potentially allocated to eligible resources. Continuing with the same commitment discount example, a one-year, spend-based commitment discount with a $1.00 hourly commitment, and 1 resource, 4 types of scenarios can occur during a charge period: +Amortization of commitment discounts occur similarly regardless of how commitment discount purchases are made. The same usage-based or spend-based amount is applied evenly across all charge periods and potentially allocated to eligible resources. Continuing with the same commitment discount example, a one-year, spend-based commitment discount with a $1.00 hourly commitment and 1 resource yields 4 types of scenarios that can occur during a charge period: -* Scenario #1: Eligible resource(s) runs for $1.00 (100% utilization) -* Scenario #2: No eligible resources run (0% utilization) -* Scenario #3: Eligible resource(s) runs for $0.75 (75% utilization) -* Scenario #4: Eligible resource(s) runs for over the $1.00 hourly commitment (100% utilization + overage) +* Scenario #1: An eligible resource fully consumes the allocated amount (100% utilization) +* Scenario #2: No eligible resource consumes the allocated amount (0% utilization) +* Scenario #3: An eligible resource partially consumes the allocated amount (75% utilization) +* Scenario #4: An eligible resource fully consumes the $1.00 hourly commitment with an overage (100% utilization + overage) -#### Scenario #1: Eligible resource(s) runs for $1.00 (100% utilization) +#### Scenario #1: An eligible resource fully consumes the allocated amount (100% utilization) -In this scenario, one eligible resource runs for the full hour, so one row allocated to the resource is produced. +In this scenario, one eligible resource runs for the full hour and consumes $1.00, so one row allocated to the resource is produced. ```json [ @@ -164,9 +164,9 @@ In this scenario, one eligible resource runs for the full hour, so one row alloc ] ``` -#### Scenario #2: No eligible resources run (0% utilization) +#### Scenario #2: No eligible resource consumes the allocated amount (0% utilization) -In this scenario, the entire, eligible amount was unused, so one unused row, allocated to the commitment discount, was produced. Most notably, ConsumedQuantity and ConsumedUnit are null while CommitmentDiscountQuantity is not because $1 was still drawn down by the commitment discount even though it was not consumed by a resource. +In this situation, the full eligible, $1.00 amount remained unutilized and results in 1 unused row. In this scenario, it is important to note that while `CommitmentDiscountQuantity` is not because $1 was still drawn down by the commitment discount even though, no resource was allocated, so `ConsumedQuantity` and `ConsumedUnit` are null. ```json [ @@ -191,9 +191,9 @@ In this scenario, the entire, eligible amount was unused, so one unused row, all ] ``` -#### Scenario #3: Eligible resource(s) runs for $0.75 (75% utilization) +#### Scenario #3: An eligible resource partially consumes the allocated amount (75% utilization) -In this scenario, one eligible resource runs for the full hour. One row shows $0.75 to a resource, and the other shows that $0.25 remained unused. +In this scenario, one eligible resource runs for the full hour and consumes $0.75 of the $1.00 allocation. One row shows $0.75 to a resource, and the other shows that $0.25 was unused. ```json [ @@ -236,9 +236,9 @@ In this scenario, one eligible resource runs for the full hour. One row shows $0 ] ``` -#### Scenario #4: Eligible resource(s) runs for over the $1.00 hourly commitment (100% utilization + overage) +#### Scenario #4: An eligible resource fully consumes the $1.00 hourly commitment with an overage (100% utilization + overage) -In this scenario, one eligible resource runs for the full hour and costs $1.50. One row shows that $1.00 was amortized from the commitment discount, and the other shows that $0.50 was charged as standard, on-demand spend. +In this scenario, one eligible resource runs for the full hour and is charged $1.50. One row shows that $1.00 was amortized from the commitment discount, and the other shows that $0.50 was charged as standard, on-demand spend. ```json [ From 9d669b4c3d5e7624420a6128880b1bef066a8416 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Thu, 19 Sep 2024 15:19:18 -0400 Subject: [PATCH 14/18] Change to Upfront terminology --- .../appendix/commitment_discounts.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index bfa264579..1d73ff857 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -10,13 +10,13 @@ Spend-based commitment discounts obligate a customer to a predetermined amount o While customers are bound to the term of a commitment discount, cloud-service providers offer some or all of the following payment options before and/or during the term: -* *Upfront* - The commitment discount is paid in full before the term begins. -* *Recurring* - The commitment discount is paid on a repeated basis, typically over each billing period of the term. -* *Partial* - Some of the commitment discount is paid before the term begins, and the rest is paid repeatedly over the term. +* *All Upfront* - The commitment discount is paid in full before the term begins. +* *No Upfront* - The commitment discount is paid on a repeated basis, typically over each billing period of the term. +* *Partial Upfront* - Some of the commitment discount is paid before the term begins, and the rest is paid repeatedly over the term. -For example, if a customer buys a 1-year, spend-based commitment discount with a $1.00 hourly commit and pays with the partial option, the commitment discount's payment consists of 1 upfront purchase in the beginning of the term *and* monthly recurring purchases with the following totals: +For example, if a customer buys a 1-year, spend-based commitment discount with a $1.00 hourly commit and pays with the partial option, the commitment discount's payment consists of a one-time purchase in the beginning of the term *and* monthly recurring purchases with the following totals: -1. *Upfront* - $4,380 (`24 hours * 365 days * $1.00 * 0.5`) +1. *One-Time* - $4,380 (`24 hours * 365 days * $1.00 * 0.5`) 2. *Recurring* - $182.50 (`24 hours * 365 days * $1.00 / 12 months`) ## Usage @@ -31,13 +31,13 @@ Within the FOCUS specification, the following examples demonstrate how a commitm ### Purchase Rows -All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and with the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. Upfront purchases appear as a single record with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term reflected as `CommitmentDiscountQuantity` and `CommitmentDiscountUnit`, respectively. +All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and with the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. One-time purchases appear as a single record with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term reflected as `CommitmentDiscountQuantity` and `CommitmentDiscountUnit`, respectively. Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCategory` is "Purchase", `ChargeFrequency` is "Recurring", and `CommitmentDiscountQuantity` and `CommitmentDiscountUnit` are reflected only for that charge period. Using the same commitment discount example as above with a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023, various purchase options are available: -#### Scenario #1: Upfront +#### Scenario #1: All Upfront The entire commitment discount is billed _once_ during the first charge period of the term for $8,670 (derived as `24 hours * 365 days * $1.00`). @@ -61,7 +61,7 @@ The entire commitment discount is billed _once_ during the first charge period o ] ``` -#### Scenario #2: Recurring +#### Scenario #2: No Upfront The commitment discount is billed across all 8,760 (`24 hours * 365 days`) charge periods of the term with $1.00 allocated to each charge period over the term. @@ -87,9 +87,9 @@ The commitment discount is billed across all 8,760 (`24 hours * 365 days`) charg ] ``` -#### Scenario #3: Partial +#### Scenario #3: Partial Upfront -With a 50/50 split, half of the commitment is billed _once_ during the first charge period of the term for $4,380 (derived as `24 hours * 182.5 days * $1.00`), and the other half is billed across each charge period over the term, derived as (`$1.00 * 8,760 hours * 0.5`). Amortized costs incur half of the amount (i.e. $0.50) from the upfront purchase and the other half from the recurring purchase. +With a 50/50 split, half of the commitment is billed _once_ during the first charge period of the term for $4,380 (derived as `24 hours * 182.5 days * $1.00`), and the other half is billed across each charge period over the term, derived as (`$1.00 * 8,760 hours * 0.5`). Amortized costs incur half of the amount (i.e. $0.50) from the one-time purchase and the other half from the recurring purchase. ```json [ From 98442c559450c6fa5f842e896dc301b37a5f9047 Mon Sep 17 00:00:00 2001 From: AWS-ZachErdman <157180770+AWS-ZachErdman@users.noreply.github.com> Date: Thu, 19 Sep 2024 20:59:44 -0700 Subject: [PATCH 15/18] Dedicated SKU column (for issue #495) (#516) **Lead Maintainer**: Zach ### Documents: * Folder #495 : [SKU Properties & Providers Alignment](https://drive.google.com/drive/u/0/folders/11CDin-7o7KNGrdCzgq7gdVwQFcJ2l8aq) by Zach moved to folder #495 * Document: [SKU Details from Providers (FOCUS)](https://docs.google.com/document/d/1PdF8VQ5Ad4kDmrTlSEzWGOitwyEeQHR5B13hPWArMg0/edit#heading=h.ezdq0hltg6) * Spreadsheet: [24.08.08 - Alternative-Column-Names-for-UsageType](https://docs.google.com/spreadsheets/d/1-n_-z1bWKKwEbSXfiICHl0ff-uC9qAdDaDYhQGsagEM/edit?usp=sharing) * PR [#516](https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/pull/516) Initial Draft of UsageType * Approval date: Sep 05 --------- Co-authored-by: Christopher Harris Co-authored-by: Joaquin Co-authored-by: Karl <133434112+kk09v@users.noreply.github.com> Co-authored-by: Udam Dewaraja --- specification/columns/columns.mdpp | 1 + specification/columns/skumeter.md | 43 +++++++++++++++++++++++++ supporting_content/columns/skumeter.md | 44 ++++++++++++++++++++++++++ 3 files changed, 88 insertions(+) create mode 100644 specification/columns/skumeter.md create mode 100644 supporting_content/columns/skumeter.md diff --git a/specification/columns/columns.mdpp b/specification/columns/columns.mdpp index aac55c69a..c1dc78124 100644 --- a/specification/columns/columns.mdpp +++ b/specification/columns/columns.mdpp @@ -46,6 +46,7 @@ The FOCUS specification defines a group of columns that provide qualitative valu !INCLUDE "servicename.md",1 !INCLUDE "servicesubcategory.md",1 !INCLUDE "skuid.md",1 +!INCLUDE "skumeter.md",1 !INCLUDE "skupricedetails.md",1 !INCLUDE "skupriceid.md",1 !INCLUDE "subaccountid.md",1 diff --git a/specification/columns/skumeter.md b/specification/columns/skumeter.md new file mode 100644 index 000000000..6b642abe2 --- /dev/null +++ b/specification/columns/skumeter.md @@ -0,0 +1,43 @@ +# SKU Meter + +The SKU Meter describes the functionality being metered or measured by a particular SKU in a charge. + +Providers often have billing models in which multiple SKUs exist for a given service to describe and bill for different functionalities for that service. For example, an object storage service may have separate SKUs for functionalities such as object storage, API requests, data transfer, encryption, and object management. This field helps practitioners understand which functionalities are being metered by the different SKUs that appear in a FOCUS dataset. + +The SkuMeter column adheres to the following requirements: + +* SkuMeter MUST be present in the billing data when when the provider includes a [SkuId](#skuid). +* SkuMeter MUST be of type String. +* SkuMeter MUST be null when SkuId is null. +* SkuMeter SHOULD NOT be null when SkuId is not null. +* SkuMeter SHOULD remain consistent over time for a given SkuId. + +## Examples + +Compute Usage, Block Volume Usage, Data Transfer, API Requests + +## Column ID + +SkuMeter + +## Display Name + +SKU Meter + +## Description + +Describes the functionality being metered or measured by a particular SKU in a charge. + +## Content Constraints + +| Constraint | Value | +|:----------------|:-----------------| +| Column type | Dimension | +| Feature level | Conditional | +| Allows nulls | True | +| Data type | String | +| Value format | \ | + +## Introduced (version) + +1.1 diff --git a/supporting_content/columns/skumeter.md b/supporting_content/columns/skumeter.md new file mode 100644 index 000000000..4806f91d9 --- /dev/null +++ b/supporting_content/columns/skumeter.md @@ -0,0 +1,44 @@ +# Column: SkuMeter + +## Example provider mappings + +Current column mappings found in available data sets: + +| Provider | Data set | Column | +|-----------|--------------------------|------------------------------------| +| AWS | CUR | line_item_usage_type | +| GCP | Big Query Billing Export | service.description | +| Microsoft | Cost details | MeterName | +| OCI | Cost reports | TBD | + +## Background + +Cloud Services, such as managed databases, virtual machines for compute, and object storage, have billing models in which the usage of that service is metered and then charged based on multiple parameters. For example, Amazon S3 charges customers for Storage, API requests, Data transfer, Encryption, Object management, Replication, and custom API requests, and ALL of these functionalities are metered and billed under the service name “Amazon S3”. + +Cloud providers use different SKUs to differentiate between these different types of usage of a given service, but the SKU is a GUID that does not have any semantic meaning to a FinOps practitioner. This is problematic because as a FinOps practitioner, I want to be able to understand what the breakdown is of how I am being charged for a particular service so that I can use this information to report what the primary cost drivers are for a particular service and so that I can make optimization decisions. For example, I might want to understand what my data transfer costs within all of my Amazon S3 charges so that I can recommend my development team to change their storage access patterns in order to achieve cost savings. + +Research across cloud providers suggests that there are 4 main categories of attributes that contribute to a SKU. They are: +Product: What is the public name of the thing (eg the resource or service) being sold? +Region: Where is the thing being sold? +Function: What is the functionality being measured and sold? +Size: How big is the thing (eg the resource or service) being sold (if applicable)? + +This column addresses the "Function" attribute of a SKU by making it a first class part of the FOCUS schema. + +## Problem + +Today, FOCUS does not have any columns that enable FinOps practitioners to understand the meaning of different SKUs that appear and group them (such as with SQL GROUP BY) in order to better understand the main contributors to the cost of a given service. + +As a practitioner, I want to be able to write a SQL query that easily breaks down my charges for a given service so that I can understand how each kind of "Function" is contributing to the overall cost of a service. + +## Solution Discussion + +**Short term (V1.1):** +Given that these data may not be readily available immediately from providers, we are starting with a single column which providers can populate with as much useful data as they can that helps meet this need. + +We believe it will be OK for providers to decide how to populate this column with the data they have available today. This means the data within this column may cover more than just the "Function" attribute described above. When populating this column, Providers should keep in mind that it will be painful for practitioners if the provider decides to change it in the future. + +**Longer term (timeframe TBD):** +In the future we would like to move to separate columns, one for each of Product, Region, Function, Size, and have each of these columns be populated with only this data. + +There may be an opportunity for some of these values to be normalized, or at least the format standardized, but some values will need to be provider-specific. This is similar to how the Unit Attribute works today where the most common units are normalized across providers (such as Hours), while other units are provider specific. \ No newline at end of file From 387d326516a3ec6eaea070062941dfa85afc63af Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Fri, 20 Sep 2024 12:44:58 -0400 Subject: [PATCH 16/18] First consistency review changes including: - Adding glossary links, italics to key terms - Removing declaration of CommitmentDiscountUnit for usage-based commitment discounts - Rephrasing the spend-based usage examples to specify that unit is chosen --- .../appendix/commitment_discounts.md | 68 +++++++++---------- specification/glossary.md | 2 +- 2 files changed, 35 insertions(+), 35 deletions(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 1d73ff857..459f28eee 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -1,45 +1,45 @@ # Commitment Discounts -A commitment discount is a billing discount model that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Commitment discounts typically consist of a set of purchase and usage records within cost and usage datasets. +A [*commitment discount*](glossary:commitment-discount) is a billing discount model that offers reduced rates on preselected [SKUs](#glossary:sku) in exchange for an obligated usage or spend amount over a predefined [*term*](glossary:term). *Commitment discounts* typically consist of a set of purchase and usage records within cost and usage datasets. -Usage-based commitment discounts obligate a customer to a predetermined amount of usage over a preselected term, typically measured in "Hours". In some cases, usage-based commitment discounts allow similar resources of different size classifications to relatively benefit from commitment discount rates. This is typically known as *commitment flexibility*, and can be derived by multiplying the number of actual resource hours consumed by a predefined SKU-based coefficient, sometimes referred to as a *normalization factor* or *ratio*, to derive the number of normalized hours consumed. +Usage-based *commitment discounts* obligate a customer to a predetermined amount of usage over a preselected *term*. In some cases, usage-based *commitment discounts* also feature [*commitment flexibility*](glossary:commitment-flexibility) which may expand the types of *resources* that a *commitment discount* can cover. It is important to note when mixing *commitment discounts* with and without *commitment flexibility*, the `CommitmentDiscountUnit` should reflect this difference. -Spend-based commitment discounts obligate a customer to a predetermined amount of spend over a preselected term, typically denoted by the invoice's selected billing currency (ex: "USD"). +Spend-based commitment discounts obligate a customer to a predetermined amount of spend over a preselected *term*. In the usage examples below, each [*row*](glossary:row) measures the monetary amount of the hourly commit consumed by the *commitment discount*, so the `CommitmentDiscountUnit` chosen is "USD", or the [*billing currency*](glossary:billing-currency). ## Purchasing -While customers are bound to the term of a commitment discount, cloud-service providers offer some or all of the following payment options before and/or during the term: +While customers are bound to the *term* of a *commitment discounts*, [*cloud-service providers*](glossary:cloud-service-provider) offer some or all of the following payment options before and/or during the *term*: -* *All Upfront* - The commitment discount is paid in full before the term begins. -* *No Upfront* - The commitment discount is paid on a repeated basis, typically over each billing period of the term. -* *Partial Upfront* - Some of the commitment discount is paid before the term begins, and the rest is paid repeatedly over the term. +* *All Upfront* - The *commitment discounts* is paid in full before the *term* begins. +* *No Upfront* - The *commitment discounts* is paid on a repeated basis, typically over each [*billing period*](glossary:billing-period) of the *term*. +* *Partial Upfront* - Some of the *commitment discounts* is paid before the *term* begins, and the rest is paid repeatedly over the *term*. -For example, if a customer buys a 1-year, spend-based commitment discount with a $1.00 hourly commit and pays with the partial option, the commitment discount's payment consists of a one-time purchase in the beginning of the term *and* monthly recurring purchases with the following totals: +For example, if a customer buys a 1-year, spend-based *commitment discount* with a $1.00 hourly commit and pays with the partial option, the *commitment discount's* payment consists of a one-time purchase in the beginning of the *term* *and* monthly recurring purchases with the following totals: 1. *One-Time* - $4,380 (`24 hours * 365 days * $1.00 * 0.5`) 2. *Recurring* - $182.50 (`24 hours * 365 days * $1.00 / 12 months`) ## Usage -Commitment discounts follow a "use-it-or-lose-it" model where the amortization of a commitment discount's purchase applies evenly to eligible resources over each charge period of the term. +Commitment discounts follow a "use-it-or-lose-it" model where the [*amortization*](glossary:amortization) of a *commitment discount's* purchase applies evenly to eligible *resources* over each [*charge period*](glossary:charge-period) of the *term*. -For example, if a customer buys a spend-based commitment with a $1.00 hourly commitment in January (31 days), only $1.00 is eligible for consumption for each hourly charge period. If a customer has eligible resources running during this charge period, an amount of up to $1.00 will be allocated to these resources. Conversely, if a customer does have eligible resources running that fully take advantage of this $1.00 during this charge period, then some or all of this amount will go to waste. +For example, if a customer buys a spend-based *commitment discount* with a $1.00 hourly commit in January (31 days), only $1.00 is eligible for consumption for each hourly *charge period*. If a customer has eligible *resources* running during this *charge period*, an amount of up to $1.00 will be allocated to these *resources*. Conversely, if a customer does have eligible *resources* running that fully take advantage of this $1.00 during this *charge period*, then some or all of this amount will go to waste. ## Commitment Discounts in FOCUS -Within the FOCUS specification, the following examples demonstrate how a commitment discount appears across various payment and usage scenarios. +Within the FOCUS specification, the following examples demonstrate how a *commitment discount* appears across various payment and usage scenarios. -### Purchase Rows +### Purchase *Rows* -All commitment discount purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and with the commitment discount's id populating both the `ResourceId` and `CommitmentDiscountId` value. One-time purchases appear as a single record with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for commitment discount's term reflected as `CommitmentDiscountQuantity` and `CommitmentDiscountUnit`, respectively. +All *commitment discount* purchases appear with a positive `BilledCost`, `PricingCategory` as "Committed", and with the *commitment discount's* id populating both the `ResourceId` and `CommitmentDiscountId` value. One-time purchases appear as a single record with `ChargeCategory` as "Purchase", `ChargeFrequency` as "One-Time", and the total quantity and units for *commitment discount's* *term* reflected as `CommitmentDiscountQuantity` and `CommitmentDiscountUnit`, respectively. -Recurring purchases are allocated across all corresponding charge periods of the term when `ChargeCategory` is "Purchase", `ChargeFrequency` is "Recurring", and `CommitmentDiscountQuantity` and `CommitmentDiscountUnit` are reflected only for that charge period. +Recurring purchases are allocated across all corresponding *charge periods* of the *term* when `ChargeCategory` is "Purchase", `ChargeFrequency` is "Recurring", and `CommitmentDiscountQuantity` and `CommitmentDiscountUnit` are reflected only for that *charge period*. -Using the same commitment discount example as above with a one-year, spend-based commitment discount with a $1.00 hourly commitment purchased on Jan 1, 2023, various purchase options are available: +Using the same *commitment discount* example as above with a one-year, spend-based *commitment discount* with a $1.00 hourly commit purchased on Jan 1, 2023, various purchase options are available: #### Scenario #1: All Upfront -The entire commitment discount is billed _once_ during the first charge period of the term for $8,670 (derived as `24 hours * 365 days * $1.00`). +The entire *commitment discount* is billed _once_ during the first *charge period* of the *term* for $8,670 (derived as `24 hours * 365 days * $1.00`). ```json [ @@ -63,7 +63,7 @@ The entire commitment discount is billed _once_ during the first charge period o #### Scenario #2: No Upfront -The commitment discount is billed across all 8,760 (`24 hours * 365 days`) charge periods of the term with $1.00 allocated to each charge period over the term. +The *commitment discount* is billed across all 8,760 (`24 hours * 365 days`) *charge periods* of the *term* with $1.00 allocated to each *charge period* over the *term*. ```json [ @@ -83,13 +83,13 @@ The commitment discount is billed across all 8,760 (`24 hours * 365 days`) charg "CommitmentDiscountUnit": "USD" }, - /* ... 8,759 more recurring purchase records for the term ... */ + /* ... 8,759 more recurring purchase records for the *term* ... */ ] ``` #### Scenario #3: Partial Upfront -With a 50/50 split, half of the commitment is billed _once_ during the first charge period of the term for $4,380 (derived as `24 hours * 182.5 days * $1.00`), and the other half is billed across each charge period over the term, derived as (`$1.00 * 8,760 hours * 0.5`). Amortized costs incur half of the amount (i.e. $0.50) from the one-time purchase and the other half from the recurring purchase. +With a 50/50 split, half of the commitment is billed _once_ during the first *charge period* of the *term* for $4,380 (derived as `24 hours * 182.5 days * $1.00`), and the other half is billed across each *charge period* over the term, derived as (`$1.00 * 8,760 hours * 0.5`). Amortized costs incur half of the amount (i.e. $0.50) from the one-time purchase and the other half from the recurring purchase. ```json [ @@ -124,22 +124,22 @@ With a 50/50 split, half of the commitment is billed _once_ during the first cha "CommitmentDiscountUnit": "USD" }, - /* ... 8,759 more recurring purchase records for the term ... */ + /* ... 8,759 more recurring purchase records for the *term* ... */ ] ``` -### Usage Rows +### Usage *Rows* -Amortization of commitment discounts occur similarly regardless of how commitment discount purchases are made. The same usage-based or spend-based amount is applied evenly across all charge periods and potentially allocated to eligible resources. Continuing with the same commitment discount example, a one-year, spend-based commitment discount with a $1.00 hourly commitment and 1 resource yields 4 types of scenarios that can occur during a charge period: +*Amortization* of *commitment discounts* occur similarly regardless of how *commitment discount* purchases are made. The same usage-based or spend-based amount is applied evenly across all *charge periods* and potentially allocated to eligible *resources*. Continuing with the same *commitment discount* example, a one-year, spend-based *commitment discount* with a $1.00 hourly commit and 1 *resource* (for simplicity) yields 4 types of scenarios that can occur during a *charge period*: -* Scenario #1: An eligible resource fully consumes the allocated amount (100% utilization) -* Scenario #2: No eligible resource consumes the allocated amount (0% utilization) -* Scenario #3: An eligible resource partially consumes the allocated amount (75% utilization) -* Scenario #4: An eligible resource fully consumes the $1.00 hourly commitment with an overage (100% utilization + overage) +* Scenario #1: An eligible *resource* fully consumes the allocated amount (100% utilization) +* Scenario #2: No eligible *resource* consumes the allocated amount (0% utilization) +* Scenario #3: An eligible *resource* partially consumes the allocated amount (75% utilization) +* Scenario #4: An eligible *resource* fully consumes the $1.00 hourly commit with an overage (100% utilization + overage) -#### Scenario #1: An eligible resource fully consumes the allocated amount (100% utilization) +#### Scenario #1: An eligible *resource* fully consumes the allocated amount (100% utilization) -In this scenario, one eligible resource runs for the full hour and consumes $1.00, so one row allocated to the resource is produced. +In this scenario, one eligible *resource* runs for the full hour and consumes $1.00, so one *row* allocated to the *resource* is produced. ```json [ @@ -164,9 +164,9 @@ In this scenario, one eligible resource runs for the full hour and consumes $1.0 ] ``` -#### Scenario #2: No eligible resource consumes the allocated amount (0% utilization) +#### Scenario #2: No eligible *resource* consumes the allocated amount (0% utilization) -In this situation, the full eligible, $1.00 amount remained unutilized and results in 1 unused row. In this scenario, it is important to note that while `CommitmentDiscountQuantity` is not because $1 was still drawn down by the commitment discount even though, no resource was allocated, so `ConsumedQuantity` and `ConsumedUnit` are null. +In this situation, the full eligible, $1.00 amount remained unutilized and results in 1 unused *row*. In this scenario, it is important to note that while `CommitmentDiscountQuantity` is not because $1 was still drawn down by the *commitment discount* even though, no *resource* was allocated, so `ConsumedQuantity` and `ConsumedUnit` are null. ```json [ @@ -191,9 +191,9 @@ In this situation, the full eligible, $1.00 amount remained unutilized and resul ] ``` -#### Scenario #3: An eligible resource partially consumes the allocated amount (75% utilization) +#### Scenario #3: An eligible *resource* partially consumes the allocated amount (75% utilization) -In this scenario, one eligible resource runs for the full hour and consumes $0.75 of the $1.00 allocation. One row shows $0.75 to a resource, and the other shows that $0.25 was unused. +In this scenario, one eligible *resource* runs for the full hour and consumes $0.75 of the $1.00 allocation. One *row* shows $0.75 to a *resource*, and the other *row* shows that $0.25 was unused. ```json [ @@ -236,9 +236,9 @@ In this scenario, one eligible resource runs for the full hour and consumes $0.7 ] ``` -#### Scenario #4: An eligible resource fully consumes the $1.00 hourly commitment with an overage (100% utilization + overage) +#### Scenario #4: An eligible *resource* fully consumes the $1.00 hourly commit with an overage (100% utilization + overage) -In this scenario, one eligible resource runs for the full hour and is charged $1.50. One row shows that $1.00 was amortized from the commitment discount, and the other shows that $0.50 was charged as standard, on-demand spend. +In this scenario, one eligible *resource* runs for the full hour and is charged $1.50. One *row* shows that $1.00 was *amortized* from the *commitment discount*, and the other shows that $0.50 was charged as standard, on-demand spend. ```json [ diff --git a/specification/glossary.md b/specification/glossary.md index f3b4b56ce..70f761ea9 100644 --- a/specification/glossary.md +++ b/specification/glossary.md @@ -54,7 +54,7 @@ A billing discount model that offers reduced rates on preselected SKUs in exchan Commitment Flexibility -A feature of [*commitment discounts*](#glossary:commitment-discount) that may further transform the predetermind amount of usage purchased or consumed based on additional, provider-specific requirements. +A feature of [*commitment discounts*](#glossary:commitment-discount) that may further transform the predetermined amount of usage purchased or consumed based on additional, provider-specific requirements. Cloud Service Provider (CSP) From 53fa7044e0a197dd0b20bfde4152b0a7269d1ee4 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Fri, 20 Sep 2024 12:49:11 -0400 Subject: [PATCH 17/18] Update specification/appendix/commitment_discounts.md Co-authored-by: Udam Dewaraja --- specification/appendix/commitment_discounts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 1d73ff857..4eca634cf 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -8,7 +8,7 @@ Spend-based commitment discounts obligate a customer to a predetermined amount o ## Purchasing -While customers are bound to the term of a commitment discount, cloud-service providers offer some or all of the following payment options before and/or during the term: +While customers are bound to the term of a commitment discount, providers offer some or all of the following payment options before or during the term: * *All Upfront* - The commitment discount is paid in full before the term begins. * *No Upfront* - The commitment discount is paid on a repeated basis, typically over each billing period of the term. From 7dda9b2453ceb16bab053e87e3b52f483c8d6fa0 Mon Sep 17 00:00:00 2001 From: Christopher Harris Date: Fri, 20 Sep 2024 12:49:40 -0400 Subject: [PATCH 18/18] Update specification/appendix/commitment_discounts.md Co-authored-by: Udam Dewaraja --- specification/appendix/commitment_discounts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/appendix/commitment_discounts.md b/specification/appendix/commitment_discounts.md index 4eca634cf..63a0586a7 100644 --- a/specification/appendix/commitment_discounts.md +++ b/specification/appendix/commitment_discounts.md @@ -1,6 +1,6 @@ # Commitment Discounts -A commitment discount is a billing discount model that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Commitment discounts typically consist of a set of purchase and usage records within cost and usage datasets. +A commitment discount is a billing discount model that offers reduced rates on preselected SKUs in exchange for an obligated usage or spend amount over a predefined term. Commitment discounts typically consist of purchase and usage records within cost and usage datasets. Usage-based commitment discounts obligate a customer to a predetermined amount of usage over a preselected term, typically measured in "Hours". In some cases, usage-based commitment discounts allow similar resources of different size classifications to relatively benefit from commitment discount rates. This is typically known as *commitment flexibility*, and can be derived by multiplying the number of actual resource hours consumed by a predefined SKU-based coefficient, sometimes referred to as a *normalization factor* or *ratio*, to derive the number of normalized hours consumed.