AWS Savings Plans: How to Implement an Effective Chargeback Strategy

As organizations grow, managing cloud infrastructure can become increasingly complex, requiring advanced financial strategies to ensure cost optimization. AWS Savings Plans provide a flexible pricing model that offers significant savings on AWS services in return for a commitment to a consistent amount of usage, measured in USD per hour, over a one or three year term. In many cases, multiple Savings Plans are adopted, either by individual teams committing directly or by FinOps teams prioritizing specific accounts. While these strategies can lead to substantial savings, they also add complexity when ensuring a fair and effective chargeback process.

In this article, we will show you how to define a chargeback mechanism that allocates Savings Plans purchased in the management account, linked accounts or both to recipient accounts of Savings Plan discounts. You can identify accounts that received Savings Plans discounts and the appropriate amount to chargeback to them based on their specific usage.

Understanding Savings Plans Discount Sharing

AWS allows customers to share Savings Plan discounts across accounts that are part of the same AWS Organization. Savings plan hourly commitment fees are charged to the account that made the purchase, however, when sharing is enabled, the discounts may apply to multiple accounts within the organization. Savings Plan discounts are first applied to all eligible usage in the account the Savings Plan is purchased. If there is excess commitment for which there is no eligible on-demand usage, then the unused commitment is utilized by other linked accounts within the AWS Organizaiton.

While sharing maximizes savings, it may require additional efforts to properly allocate the shared benefit across the organization. Accounts that benefit from Savings Plan discounts are not responsible to pay a Savings Plan commitment fee. As a result, the account incurring the cost of the commitment may not be the sole beneficiary of the savings. This shared benefit requires careful cost allocation to ensure that accounts are charged fairly based on their actual usage of the Savings Plan.

Now that we understand how Savings Plans operate and how sharing affects them, let’s explore a chargeback strategy for using data from the Cost and Usage Report (CUR) 2.0.

Prerequisite

Create an AWS Data Export with CUR 2.0 and configure AWS Glue to catalogue the data. This allows you to use Amazon Athena to run queries and analyze the CUR 2.0 data. In order to accomplish this, you need to do the following:

1. Configuring CUR 2.0 with AWS Data Export

Sign in to the AWS Management console
Navigate to AWS Billing and Cost Management. Select Data Export and click on Create to begin setting up your export.

Figure 1. Create Data Exports
Choose Standard data export, provide your export a name and for select CUR 2.0 as the data table type.

Figure 2. Configure export
Enabling Include resource IDs and Split cost allocation data are optional
Select Time granularity as Hourly
Set Parquet as the compression format, and select the Overwrite existing data export file for file versioning.

Figure 3. Configure export delivery options
Specify the destination Amazon S3 bucket and a path prefix where CUR 2.0 data should be stored.
Complete the setup by selecting Create.

2. Configuring AWS Glue to query CUR Data

Navigate to AWS Glue console and select Data Catalog > Crawlers to initiate the process of cataloging the CUR 2.0 data.
Click on Create Crawler and assign a unique crawler name

Figure 4. Create AWS Glue Crawler
For the question Is your data already mapped to Glue tables? select Not yet
Click Add a data source, select S3 and specify the Amazon S3 location from Step 1.8, where your CUR 2.0 data is exported, using the format: s3://<bucket-name>/<prefix>/<export-name>/data/.

Figure 5. Create S3 data source to crawler CUR data
Click Add an S3 data source and then click Next
Click on Create new IAM role which will create the new AWS Glue role on your behalf. This role allows Glue to access the S3 bucket where CUR2.0 files are stored.
Create a target database by clicking Add database. Provide a database name and click Create database
Navigate back to the AWS Glue console and select the database created in the previous step. Set the crawler schedule to On demand to run only when required.
Confirm your settings and select Create Crawler.
Once the crawler is ready, select it and click Run. This will process and catalog the data, creating tables accessible by Amazon Athena.

Using CUR 2.0 for Savings Plans chargeback

Once the above per-requisites are configured, use the following query to identify the linked accounts that received Savings Plan discounts. The Effective Cost column provides the cost corresponding to the amount of the Savings Plan commitment that was used by linked accounts. This would be the amount that you would use to chargeback individual linked accounts.

Navigate to Amazon Athena console to run a query. Review details on running SQL queries in Athena.
Copy the below query into your Query editor. Ensure to update the Table Name in the query.

select
    DATE_FORMAT(bill_billing_period_start_date,'%Y-%m-%d') as "Date"
    , line_item_usage_account_id as "Account Id"
    , savings_plan_offering_type as "Savings Plan Type"
    , split_part(savings_plan_savings_plan_a_r_n, '/', 2) AS "Saving Plan ID"
    , savings_plan_payment_option as "Savings Plan Payment Option"
    , line_item_line_item_type as "Item Type"
    , sum(
        case
            when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0
            else savings_plan_recurring_commitment_for_billing_period
        end
    ) + sum(
        case
            when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0
            else savings_plan_amortized_upfront_commitment_for_billing_period
        end
    ) as "Savings Plan Fee"
    , sum(
        case
            when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0
            else savings_plan_recurring_commitment_for_billing_period
        end
    ) + sum(
        case
            when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0
            else savings_plan_amortized_upfront_commitment_for_billing_period
        end
    ) - sum(savings_plan_used_commitment)  as "Unused commitment"
    , sum(
        case
            when line_item_line_item_type = 'SavingsPlanRecurringFee' then 0
            else savings_plan_savings_plan_effective_cost
        end
    ) as "Effective Cost"
    , sum(
        case
            when line_item_line_item_type = 'SavingsPlanRecurringFee' then 0
            else line_item_unblended_cost
        end
    ) - sum(
        case
            when line_item_line_item_type = 'SavingsPlanRecurringFee' then 0
            else savings_plan_savings_plan_effective_cost
                end
    ) - ( sum(
        case
            when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0
            else savings_plan_recurring_commitment_for_billing_period
        end
    ) + sum(
        case
            when line_item_line_item_type = 'SavingsPlanCoveredUsage' then 0
            else savings_plan_amortized_upfront_commitment_for_billing_period
        end
    ) - sum(savings_plan_used_commitment) ) as "Savings"

from
    <Table Name>
where
    line_item_line_item_type in ('SavingsPlanCoveredUsage', 'SavingsPlanRecurringFee')
    and bill_billing_period_start_date = DATE_TRUNC('month', CURRENT_DATE) - INTERVAL '1' month
group by
    bill_billing_period_start_date
    , line_item_usage_account_id
    , savings_plan_offering_type
    , savings_plan_savings_plan_a_r_n
    , savings_plan_payment_option
    , line_item_line_item_type
order by
    sum(savings_plan_savings_plan_effective_cost) desc

To understand this better, let’s break down two critical components found in the AWS CUR 2.0:

SavingsPlanRecurringFee: This is the field in the output where Item Type = 'SavingsPlanRecurringFee'. It represents the cost that the purchasing account is obligated to pay for the Savings Plan commitment. This is a fixed cost, regardless of whether the full commitment was utilized. Depending on the Savings Plan type, this amount may be reflected as either unblended or amortized amount.
SavingsPlanCoveredUsage: This is the field in the output where Item Type = 'SavingsPlanCoveredUsage'. It represents the actual usage of the Savings Plan, showing how much of the committed Savings Plan has been applied to usage across the organization. This usage can be spread across multiple accounts, depending on the organization’s structure and workload distribution.

To perform Savings Plan chargebacks, it is crucial to use the Effective Cost column associated to each linked account. This column provides the cost that corresponds to the portion of the Savings Plan commitment that was used by each linked account. The goal is to ensure that each linked account receives a Savings Plan fee according to the benefits it received from the Savings Plan.

It is also important to validate the Unused Commitment column for rows with SavingsPlanRecurringFee. If the value in this column is greater than $0, it indicates that the Savings Plan is not fully utilized. While this under-utilization may indicate potential savings loss, it is important to validate. Organizations may deliberately purchase Savings Plan commitments that slightly exceed expected usage, as the overall savings from the discount can still outweigh the cost of the unused portion, providing a net savings benefit for the organization.

Examples

In the below table, the Savings Plan Type is No Upfront. The monthly recurring fee is charged to Account ID A as we see the associated ‘SavingsPlanRecurringFee’ field. Eligible usage in Account ID A gets the discount first as it is the account where the Savings Plan is purchased. Out of the $12,410.68 monthly commitment, $8,363.12 is the effective cost to be charged back to Account ID A. Account B used $1,361.26 out of the total recurring commitment, which would be Account B’s chargeback value. We can also observe that unused commitment is $0 and sum of effective cost matches with the recurring fee, which signifies that the Savings Plan is fully utilized.

Figure 6. Example report to show distribution of savings plans benefits among accounts

Let’s see another example:

In the below table, we observe that the Savings Plan Type is All Upfront, which corresponds to the amortized portion of the upfront payment for the billing period. The data shows that the Savings Plan was purchased in Account ID A and was fully utilized by Account ID A, as the ‘Unused Commitment’ is $0. In this case since there is only one account that is getting the benefit of the Savings Plan and the recurring fee matches with the effective cost.

Figure 7. Example report to show consumption of savings plans benefits by the purchasing account

Conclusion

In this article, we discussed the impact Savings Plan sharing has on it’s usage. When sharing is enabled, there can be accounts that receive the benefit of Savings Plan discounts without having to pay a Savings Plan fee. The account that makes the purchase is solely obligated to pay the Savings Plan fee.

We used a targeted query in AWS Cost and Usage report 2.0 to design a chargeback mechanism that allows us to identify all the beneficiaries of Savings Plan discounts and proportion of the recurring fee they can be charged. Using this strategy, you can now use internal company specific chargeback mechanisms to chargeback accounts accurately based on the usage and therefore the savings they received, rather than just charging the account that holds the Savings Plan. This method allows for a fair and transparent distribution of both the costs and the benefits of the Savings Plans, helping to align financial responsibility with actual usage.

This strategy fosters transparency, accountability, and encourages thoughtful cloud usage across teams. By ensuring that all accounts are charged according to the Savings Plan benefits they receive, you promote a cost-conscious culture within your organization.

Select your cookie preferences

AWS Cloud Financial Management