There has been a lot of excitement with the launch of AWS' new discount instrument Savings Plans (SP). Let's quickly cover how they are different than traditional discounting with reserved instances (RI) and then dive deeply into billing implications.
A quick comparison to RIs:
- The discount rates are identical between EC2 Instance SPs and Standard RIs, and between Compute SPs and Convertible RIs.
- With Savings plans for the first time you are able to make a commitment above the service and region level (in the case of compute savings plans). This has major implications for how you plan and governance of your cloud bill.
- Probably the biggest difference is that instead of committing to instance hours you are now committing to dollar hours. It's worth noting the dollars per hour you are committing to are the after Savings Plan discount dollars or the 'net' cost.
A deep dive into billing implications:
There are some major differences between how Savings Plans and RIs are handled in the detailed billing (CUR file) which we'll cover in detail here. For background on how RIs historically have behaved checkout this post.
- The usage hours covered by SPs are largely represented as "On Demand" hours.
- The item description looks like "$0.156 per On Demand Linux..."
- The standard cost metrics Unblended Cost and Unblended Rate are based on the On Demand figures. This is in contrast to RIs where the figures are heavily reduced.
- Whereas the recurring costs for RIs (in the case of no-upfront or partial upfront) appeared as one line item at the beginning of each month for SPs the recurring costs are broken into individual lines for each hour in the month. All the lines for the month load as the month begins meaning that you have future cost reporting in the CUR file.
- There is a brand new type of billing line "SavingsPlanNegation" that allows for the regular cost metrics to accurately represent your bill at the monthly level.
Let's take a look at how this holds together for one SP being consumed over one hour. This is a very reduced down, for illustration purposes, example from the CUR file for a no-upfront EC2 Instance Savings Plan.
(note the first two lines are the actual EC2 instance usage hours which fully consume the SP for that hour)
There are some very interesting things happening in the table above. You'll notice that the unblended cost nets out to the recurring fee, which is of course our discounted rate. This is a result of the negation line completely negating the two usage lines. However neither the negation or recurring lines include the resourceId or important information like tags. This means that if you are allocating costs based on tags or resource IDs you are going to get the On Demand cost for hours covered by SPs and heavily reduced costs for hours covered by RIs. What to do?
Cost (Amortized) and Cost (List) to the rescue
Cloudability gives you two straightforward ways to fairly allocate cost in a world where RIs and SPs are impacting cost line items. Like any line item you can use the Cost(List) metric which completely removes the impact of any commitment based discounting. Teams like this as it removes the unpredictable nature of discounts being applied. If you prefer to pass on the benefits to your teams while making sure there is consistent behaviour between RIs and SPs Cloudability provides the Cost (Amortized) metric. This metric can be used throughout Cloudability and associates the full cost - including upfront component - of RIs and SPs at the resource level. This allows for a complete True Cost roll up.
Review your Saving Plan usage with reporting in Cloudability
You can filter down to your Savings Plan usage using the Lease Type dimension in Cloudability reporting. In a report similar to below you can surface interesting details with regular dimensions and metrics about your SP usage.