The cloud computing market has transformed the way organizations procure computer servers. Amazon Web Services (AWS), in particular, offers convenience and adaptability for any organization that needs a server to host a web application or perform some computing workload. In less than five minutes, and for a dollar a day, you can provision a server with 2 CPUs and 4 GB of memory. That is enough to handle light to moderate web traffic. Moreover, these servers, or virtual instances as they are called, come in a variety of configurations of CPU type and count, memory and networking capacity, to suit different customer needs.
However, there is a flip side to this ease of provisioning. Over time, or even in five minutes, a customer can launch expensive server configurations, or accumulate a large fleet of instances, and single dollars can become tens, hundreds or thousands of dollars per day. The monthly bill can significantly impact budgets or a business’s bottom line.
AWS Has a Plan
There is a way to reduce the server cost with AWS. To do so, a customer must commit to pay for a minimum amount of compute capacity for a fixed term of one or three years. The cost reduction comes in the way of a discounted price, which the customer cay pay either in full at the time of entering into the agreement, or monthly, or in a combination of upfront and monthly payments. AWS calls this a Savings Plan, and it can lead to a savings of around 28% to 72% of the compute cost, depending on the term and timing of the payments. To be clear, a savings plan only affects compute costs, which AWS defines as EC2, Fargate and Lambda. It does not reduce other managed service costs, such as for storage, data transfer, or databases.
While this article discusses savings plans, AWS also offers another discount program called Reserved Instances (RI). The purchase terms of an RI are similar to a savings plan, but a RI purchase will be limited to a specific instance type and region. The cost analysis is generally the same, but there may be specific situations where RIs make more sense.
Knowing about savings plans, this is the key question: if you use AWS compute instances, should you purchase a savings plan, and if so, when is the correct time to buy? The short answer, if you want to stop reading, is “Today!”.
Commitment Phobia
One common reason that customers hesitate to commit to a savings plan is because they know, or think, that they are over-provisioned. They reason that if they commit to their current spending level for a year, and at some later time they reduce their usage, they will pay for unnecessary capacity. However, this thinking is misguided. The best time to purchase a savings plan is right now (there may be exceptions). By not purchasing a savings plan today, the customer is leaving money on the table for Amazon to pick up. By purchasing a savings plan, the customer may come out ahead even if the usage goes down in the future.
Before diving into the math to understand why today is the right day, let’s consider what may cause compute usage to go down in the future. There can be two reasons. First, the business is facing a downturn, losing popularity or losing customers, and the compute load is decreasing. The other reason is that the business is planning to reduce over-provisioned capacity or to re-design its systems to use less compute-intensive processes.
Considering the first scenario, if a business is expecting a downturn, it would be better to reduce costs now rather than later, and a savings plan would do just that. The business can park the savings for a future date when it may not have the cash flow to cover the committed cost. Depending on the savings rate, it may break even on the cost before the downturn happens.
On the other hand, as an AWS customer, if you plan to reduce usage, and it is possible to do so today, just do it! Then you can purchase a savings plan for the usage that remains. However, most of the time, reducing usage is an objective that may be desired but is difficult to achieve. If it were easy, you would have done it already.
The challenges to reducing costs can be numerous. If the business is in growth focus, like a startup, then it does not have time or resources to make changes that are not adding new features. In mature organizations, existing systems may have grown organically into a complex architecture that will require time to restructure. If the systems serve business customers or are mission critical, changing them will require planning, approval, testing and careful rollout. Those activities take time. Meanwhile, the business is paying AWS full price for its compute usage.
As the analysis below shows, in most realistic cases, purchasing a savings plan today rather than waiting is the more cost-effective option.
The Pluses and Minuses
In the remainder of the article, I will consider and compare the cost results of purchasing a savings plan today with the results of purchasing a savings plan after some months spent on reducing compute usage. The outcome that I will use for the comparison is the total cost of operation (TCO) of AWS compute for the next 12 months. To make sense of the analysis in actual dollars, let’s suppose a monthly cost of $83,333, which adds up to almost $1 million over 12 months ($83,333 x 12 = $999,996). I am going to assume a savings rate of 28% for the savings plan, which is typical minimum savings for most instance types with a 1-year and no up-front commitment in the us-east-1 region. This purchase would result in a 72% TCO compared to doing nothing (not purchasing a savings plan), which would result in a 100% TCO at the end of 12 months. In dollars, a discount of 28% means 12 monthly payments of $60,000 ($83,333 * (1-0.28) = $60,000) for a total of $720,000 ($60,000 * 12 = $720,000), as compared to $1,000,000 for the full price.
With these assumptions in mind, would it be worth waiting one month to purchase a savings plan, and using that month to reduce compute usage by 5%? The TCO 12 months from now of this plan would be $83,333 + 11 * 0.95 * 0.72 * $83,333 = $710,333. So the answer is, yes, by the numbers, it would be worth waiting one month. It would be more cost efficient to wait 1 month to achieve any reduction in usage of more than 3.5%.
The difference between the TCO in the two scenarios (purchasing a savings plan today vs after 1 month with a 5% reduction in usage ) is under 1%. In dollars, it is just under $10,000, out of what was originally a $1 million expense. If a reduction in usage of 5% in one month requires little effort to achieve, and the probably of achieving it is high, it would make economic sense to wait one month and purchase the savings plan after the reduction. If the effort would divert resources from other initiatives, or the chances of achieving the reduction are low, it would be wiser to lock in the savings now.
Waiting for Go-Low
The more usage a customer thinks they can reduce, the longer they can afford to wait to purchase a savings plan. The chart below demonstrates this. If they can reduce usage by 10%, they can make the purchase after two months, and still end up with a lower TCO twelve months from today than if they purchase a savings plan today. For a reduction of 15% in compute usage, they can wait three months.
The truth about software and IT projects is that estimates of effort are often inaccurate, and complex projects usually take longer than estimated. If a project to reduce usage by 25% is expected to take 4 months, there is a chance that it may take 5 months. If it does take longer, waiting to purchase a savings plan may turn out to be a bad decision because the TCO 12 months from today would be 73% of the full cost, which is higher than the TCO of purchasing a savings plan today. As before, 1% is not much compared to the overall spend, but there is also the risk that the reduction falls short of 25%. If usage is reduced by 20% instead, then waiting 5 months will result in a TCO of 75%. It is also true that the reduction in usage would have benefits further down the road as well, but you need to consider the opportunity cost of taking on this work now.
One strategy to mitigate the effect of delay would be to purchase a saving plan for the targeted level of compute usage. This is illustrated in the last column of the chart above. If compute usage can be reduced by 50%, you can wait 6 months to purchase a saving plan to get a TCO of 68%. However, you could also purchase a savings plan today for 50% of your current compute, and evaluate the situation in 6 months. If you did indeed cut compute usage by 50%, then there is not need to take any further action, and the TCO 12 months from now would be 61%. If you did not reduce usage by 50%, then the TCO would be higher than 61%, and may be 79% if you did not reduce usage at all. Making a purchase today for 50% of your current usage would still be better than not purchasing a savings plan today.
Conclusion
In this article I show why purchasing an AWS Savings Plan today is the best decision. The starting-gate savings makes it worthwhile even if you think that you are currently over-provisioned. If you are sure that you can reduce your compute usage, it still makes sense to purchase a savings plan for the usage that you expect will remain after you make reductions.
Get in touch if you have a different view on this analysis, or you think this advice does not apply to your situation. I am eager to learn and refine my understanding!