Accounting can be complicated. Even for bona fide “numbers people," the various ways to track, attribute, and charge back business costs leaves a lot of room for error, interpretation, and individual preferences.
But when it comes to calculating costs of AWS Reserved Instances (RIs) and AWS Savings Plans (SPs), I’m here to argue that there's only one way to properly account for them: amortization by usage.
First, let’s take a step back.
What is amortization?
Amortization is a way to spread out a capital expense over the period of time that your business will benefit from that expense. For example, let’s say your business has to buy an expensive piece of equipment that costs $120,000. You have to pay for this capital expense in full up front, but you'll use this piece of equipment for 10 years. Your accountant may amortize this cost over that 10-year period, showing an expense of $12,000 per year.
Amortizing capital expenditures allows you to better represent your profits and losses each year. You may have had a huge expense in year one, but that doesn’t mean your business was performing poorly that year. Normalizing expenses with amortization makes it easier to understand the health of your business.
Why do I need to amortize Reserved Instances and Savings Plans?
AWS offers significant savings (up to 72% off) on popular services when you commit to a certain amount of usage or spending on that service via the purchase of a Reserved Instance or Savings Plan. Eligible cloud services include EC2, RDS, ElastiCache, Redshift, DynamoDB, Elasticsearch, Lambda, and Fargate.
There are three ways to pay for Reserved Instances and Savings Plans: all upfront, partial upfront, and no upfront. Paying all upfront saves the most money in total, but means you’ll need to have cash in-hand to pay for everything on day one. Since all upfront and partial upfront payment terms require paying some amount of capital expense up front, they are both candidates for amortization.
What are my options for amortization?
There are two ways to amortize the upfront cost of Reserved Instances and Savings Plans. Amazon Web Services (AWS) takes one approach and CloudHealth takes another. However, there's a significant drawback to the AWS approach.
To see why CloudHealth’s approach is preferred, you need to understand the concept of reservation “float.” Float simply means that the savings garnered from Reserved Instances and Savings Plans flow from the account that purchased them to other linked or consolidated accounts in your organization.
A best practice when buying Reserved Instances and Savings Plans is to purchase them from a top-level account in your organizational hierarchy in order to maximize usage of the reservation. If the purchasing account does not have eligible services to use up the commitment, other linked accounts will reap the benefits. But this means that the account that purchases the reservation may not be the account benefitting from the reservation (or at least not all of it).
And herein lies the problem with the AWS approach. If reservations float, but the cost of those reservations is not attributed to the groups they floated to, how do we properly charge back?
With the AWS approach, you simply have no way to know which groups received a discount. This is why CloudHealth amortizes the costs of upfront Reserved Instances and Savings Plans costs by usage rather than purchase.
Amortize by usage to enable chargeback
Amortization of capital expenses is critical to get an accurate look into the health of your business, but cloud financial managers also need to be able to charge CAPEX costs back to the groups that benefited from them. Here, AWS leaves you hanging. CloudHealth’s amortization report breaks down upfront reservation costs by usage, and accounts for reservations that haven't been used yet.
If you’d like to learn more about how to properly allocate benefits and amortize upfront costs, see our eBook: The Ultimate Guide to AWS Savings Plans