AWS Billing Part 2: Savings Plans
Jack McClary - Member of Technical Staff, CloudNatix
In the last blog post in this series on AWS billing (https://www.cloudnatix.com/company-blog/aws-billing-part-1) we began looking at AWS billing and CUR files. In that post we discussed the intricacies of how AWS calculates an instance’s usage, and in this post we want to continue talking about these files, but this time, focus on savings plans.
A cursory summary is that Savings Plans allow AWS users to commit to an hourly usage over a larger period of time for a discount in price. There are a handful of parameters that combine to create 326,849 types of Savings Plans (1), but essentially a Savings Plan boils down to “I will commit to x amount of usage for a 1 or 3 year term, if you discount the rate”.
How do Savings Plans appear in CUR files?
A cursory level of understanding is great when discussing concepts, but as a cloud optimization company, at CloudNatix we care about the details too. Once a CUR file is filtered down, the application of Savings Plans in billing is fairly straightforward, but filtering can be difficult. The most important LineItemTypes associated with Savings Plans are “SavingsPlanRecurringFee”, “SavingsPlanCoveredUsage”, “SavingsPlanNegation”, and “Usage”. With these four categories, you can see how much your Savings Plan is costing you, how usage is being attributed to your plan, and how much usage is happening outside of your plan. For more detail:
SavingsPlanRecurringFee
This row type represents the agreed upon charge for Savings Plans independent of anything else. For each hour long time period that a Savings Plan is active, you should expect to see one row of this type. You can find the Savings Plan associated with this row via the “savingsPlan/SavingsPlanARN” column.
SavingsPlanCoveredUsage and SavingsPlanNegation
These two row types are equal and opposite. SavingsPlanCoveredUsage rows, as the name suggests, represents an instance’s usage in a given hour that is being attributed to a given Savings Plan. This allows you to identify what instances are actually being used and the cost of them. But because the cost of the Savings Plan is already captured in the SavingsPlanRecurringFee line item, this double counting needs to be fixed.
The SavingsPlanNegation rows fix this over counting. They have a negative cost that corresponds to the CoveredUsage lines. However, this negation happens at an AZ level, so you may see fewer SavingsPlanNegation lines, but the “UsageAmount” column on them can be greater than one.
An interesting detail that can trip you up when looking at these rows is that the lineItem/BlendedRate for these row types is actually equivalent to the on-demand cost for the associated instance type. The rate after the Savings Plan is applied is under the savingsPlan/SavingsPlanRate column. As is SavingsPlanRecurringFee lines, both of these types can find the associated SavingsPlan via the “savingsPlan/SavingsPlanARN” column.
Usage
While Usage doesn’t explicitly relate to Savings Plans, all instances running with this LineItemType effectively represent the usage that was in a given region that exceeds the commitment of all Savings Plans, and thus is helpful to be aware of.
Example
To incorporate all of this information let’s take the example of running 4 instances for a full hour in us-east-2 at a rate of $X/hr. Instances A and B will run in us-east-2a, and instances C and D will run in us-east-2b. With no Savings Plan this example would appear as the following:
Now suppose we run the same scenario with a SavingsPlan commitment of 3 instances in us-east-2 at a discounted rate $Y/hr. A simplified version of the CUR file would hold the following:
Adding the Savings Plan makes the information more complex, but we will take it step by step from top to bottom.
The SavingsPlanRecurringFee line represents the commitment we made of spending 3Y. This is charged independent of any usage.
The colored cells represent the rest of the lines directly associated with the Savings Plan, and are further grouped by Availability Zone (AZ). Looking at the us-east-2a AZ, the CoveredUsage lines show the instances attributed to the Savings Plan, and the SavingsPlanNegation line finds the total usage of all instances covered by the Savings Plan in the AZ. Looking at the second colored section, you can see that only instance C is covered and negated. This is because the Savings Plan only covers 3 instances.
Finally, the Usage line at the end is there because the Usage is in excess of the Savings Plan. Because it falls outside of the Savings Plan, this is billed normally.
By taking the total sum of the cost, you can see that it comes out to 3Y + X which is equivalent to Committed cost of the Savings Plan + Cost of uncovered usage.
Conclusion
At the end of the day, while it may seem complex, by giving customers information about covered usage in CUR files and negating the cost, AWS enables better visibility into what is happening than if they only included the SavingsPlanRecurringFee. For the sake of brevity we decided to stop here, but in our next article in this series we will look into how this Savings Plan behavior interacts with the Usage calculation mechanics that we discussed in the last article to explore even more unexpected behavior.