Savings Plan Bundling: A Change to the AWS Discount Model

Note: This is an educational post applicable to AWS customers with Enterprise Discount Program (EDP) and Private Pricing Agreement (PPA) discounts.

The AWS Discount Model

One unique benefit of AWS is that discounts stack (Azure and Google Cloud do not work this way). Consider the following simple example:

Notice how the EC2 instance first receives a 30% discount, after which it receives an additional 10% discount. This is discount stacking in action. This has several benefits:

• It generally results in more total savings. I will save the details for a future post comparing the AWS, Azure, and Google Cloud discount programs; suffice it to say, stacking allows discounts to be additive vs. taking the largest single discount.
• Savings Plans (SPs) and Reserved Instances (RIs) are always beneficial. This is true regardless of the EDP/PPA discount rate – whether you have no private discounts or are one of AWS’s largest customers.
• The outcomes of various rate optimization efforts are discretely measurable. In the example above, it’s clear that the SP saved $0.30/hr while the EDP/PPA added an additional $0.07/hr. In Cost Explorer and the Cost and Usage Report (CUR), AWS measures savings exactly this way, and the values are shown separately so the impact of each is discernable. Doing a better job of managing RIs/SPs will raise the former portion of savings, and negotiating a better EDP/PPA will improve the latter.

The Bundled Savings Plan Change

Regarding that final point, last year we started seeing a subset of customers where AWS “crossed the streams” and blended together SP and EDP/PPA discounts. The example above would now look like this:

In Cost Explorer and the CUR, savings values would change accordingly. The reported SP savings would increase, and the EDP/PPA savings would disappear.  We’ve come to call this Savings Plan Bundling. We’ve talked to the AWS product team about this change and there are valid reasons for it (which I won’t get into), but for those discretely measuring the impact of various rate optimization techniques, it is a contract-breaking change. 

For example, for those looking at the savingsPlan/RecurringCommitmentForBillingPeriod and savingsPlan/NetRecurringCommitmentForBillingPeriod columns in the CUR, data will shift. Historically, the difference between these values would represent the savings from the EDP/PPA discount. After SP bundling is enabled, the standard and net values are identical because the EDP/PPA discount has now been “bundled” into the SP.

Comparing the standard and net SP CUR values is a great way to determine if SP bundling is enabled for your AWS organization. If they match, SP bundling is active. In our experience, AWS will implement this change when a new EDP/PPA agreement is signed. This is ostensibly the new model going forward, where applicable.

Impact on Bundled Savings Plan Purchases

When SP bundling is active in your AWS organization, SPs are effectively “turbocharged” and provide higher-than-public SP discount rates. Perhaps the biggest change with bundled SPs is determining how much SP coverage to purchase. 

We’ve written before on the importance of determining SP purchase amounts based on post-discount and not on-demand cost. If you use on-demand cost instead, you’ll purchase more SP coverage than you want.

Here’s a simple example:

• You are running 100 EC2 instances on-demand, each costing $1.00/hr
• The public SP cost for this instance is $0.70/hr (a 30% discount)
• You want to cover at 80% 

The proper amount of SP coverage to purchase is 100 x 80% x $0.70/hr = $56/hr.  If instead you use the on-demand rate, you’d purchase 100 x 80% x $1.00/hr = $80/hr and would be overcommitted! Should this happen, AWS now has a 7-day SP return window (presumably because enough people were purchasing the wrong amounts) which is great, but better to get it right.

If your SPs are bundled, you have a similar but “second-order” challenge. Public SP discount rates are not applicable because your SPs are turbocharged (i.e. your EDP/PPA discounts are bundled in) and deliver higher savings. If you accidentally use public SP discount rates, in the same way as above, you will add more SP coverage than you intend. We have seen even sophisticated FinOps practitioners make this mistake with bundled SPs and overcommit.

Let’s redo the same example above with bundled SPs:

• You are running 100 EC2 instances on-demand, each costing $1.00/hr
• The public SP cost for this instance is $0.70/hr (a 30% discount)
• Your EDP/PPA discount is 10%
• SP bundling is active
• You want to cover at 80% 

The correct math for determining proper coverage with bundled SPs is 100 x 80% x $0.70/hr x (1 – 10%) = $50.40/hr. Note the SP cost has been adjusted to bundle in the EDP/PPA discount. 

To complicate matters, if your private pricing includes different discount rates for certain services, regions, instance families, etc. you will need to adapt this math based on the specific amounts of usage of each. This is incredibly complicated, particularly with cyclicality and as usage patterns shift between differently discounted usage. 🤯🤯

If SP bundling is active in your organization and you are relying on an SP purchase recommendation tool, you’ll want to make sure it is aware of SP bundling, otherwise, it will recommend excessive SP coverage. We aren’t sure whether native AWS tools support bundled SPs, but the docs (see the last point) and Ask AWS chat would imply they currently do not. If this applies to you, we recommend you reach out to AWS for clarification.

For ProsperOps customers, our platform is able to reverse engineer detailed private pricing and our SP purchase algorithms have been made SP bundling aware. In short, our Autonomous Discount Management for AWS Compute service can properly serve bundled SP customers.  

Separating Savings in the Bundled Savings Plan Model

Separating SP native and EDP/PPA savings once they’ve been bundled is extremely complicated. It involves determining what savings an SP would have generated if the EDP/PPA discount was not bundled in. This requires comparing current and historical public SP rates to bundled SP rates and backing out the bundled discounts, keeping in mind that each SP has its own rate card, which may differ from other SP rate cards, depending on when each was purchased. 🤯🤯🤯

For ProsperOps customers, we have done this work for you. Any customer with bundled SPs will now see adjustments in our console to account for this difference.

For example, our console provides deep links to Cost Explorer to validate our savings numbers with AWS. As mentioned earlier, the SP savings in Cost Explorer represent a bundled value, so our console adds an adjustment to back out the EDP/PPA portion (values have been partially blurred here to obscure the EDP/PPA discount rate).

Implications on Effective Savings Rate (ESR) when Saving Plans are Bundled

We provide a free Google sheet to help anyone calculate AWS service-specific ESRs using AWS CLI commands to query Cost Explorer APIs. This method scopes ESR upstream of any EDP/PPA discounts, which isolates measuring the performance of RI and SP management (independent of whether you negotiate a better EDP/PPA discount). This is an extremely useful view, and all our published AWS ESR benchmarks are relative to this scope. 

Because SP bundling “leaks” EDP/PPA discounts into the Cost Explorer values, SP savings are elevated which artificially inflates ESR. It’s important to note that RIs do not have a similar bundling concept, so if SP bundling is active in your environment, simply pulling Cost Explorer values for both RIs and SPs, without adjusting the SP savings value, will cause a blended and incorrect view of savings. 

Bottom line: if SP bundling is enabled, our Google sheet, and more broadly, using Cost Explorer APIs, will not work for calculating ESR.

If you are using a different method for calculating ESR, you should be aware of this change and make adjustments accordingly. In general, if your ESR looks too high relative to our benchmarks, be skeptical and check to see if SP bundling is enabled.

For ProsperOps customers, we automatically adjust ESRs in our console and data export feed to account for this adjustment.

Final Thoughts

Like the US tax code, cloud FinOps is complex and constantly evolving. It’s important to stay abreast of changes like this as they can have a significant impact on FinOps KPIs, cost optimization outcomes, and the accounting treatment of cloud spend. Moreover, this change affects larger AWS customers with private discounts, so the dollar impact can be all the more substantial.

This is a complicated topic, and we hope this post helps FinOps practitioners better understand it. If you have further questions, please reach out to our team.

Prosper On! 🖖
Erik