This is the fifth chapter in Aimably’s six-part Definitive Guide to the AWS Budget, designed to provide all the education required for engineering leaders to set (and meet) cloud spend goals.
After reading this chapter you will be able to:
- Select cost optimization contracts for appropriate business scenarios
- Describe all the current cost optimization techniques available in the AWS ecosystem
- Implement a series of technical cost optimization techniques ideal for your infrastructure
- Model the impact of your selected cost optimizations into your AWS budget
Get to know all your options
There are a wide variety of tools you could start using, or expand your usage of, in order to best optimize your total cost of ownership for AWS infrastructure.
Below, we’re going to cover all the ways you might take advantage of each of the cost optimization tools offered by AWS to generate a smaller scale budget for the same planned usage. We’ll describe how these tools work and help you spot ways where they could optimize your own usage. Specifically, we’ll cover:
While this chapter can be read in isolation, we strongly recommend that you read and complete the exercises outlined in Chapter 3: Building a world-class AWS operating budget using historical spend analysis first. In explaining each of these options, we’ll use the categorizations and calculations performed in that chapter to help you make an informed decision on implementing each strategy.
But first, let’s discuss how your financial situation can influence whether some of these strategies are the right choice for your business.
Your company’s cash position is incredibly important
In this chapter of our Definitive Guide to the AWS Budget, we’re going to go into some depth describing each of the cost optimization techniques available to you in the AWS ecosystem. Each of them is a ‘great deal’ for certain businesses, but to others, they aren’t great choices.
Why? It all boils down to your company’s cash position. When we use that term, we’re referring to the amount of available cash your company currently has in the bank as well as the certainty you have over your company having a stable amount of cash for months into the future.
A seed-stage startup has a risky cash position: while they may currently have plenty in the bank as a result of an investment round, there is no stable and predictable revenue planned to replenish the bank account anytime soon.
Conversely, a heavily-leveraged company under private equity ownership may not have much cash at all, despite excellent sales performance, as cash gets regularly diverted to pay off loans incurred to complete acquisitions and accelerate growth, yet their cash rates are highly predictable and stable from month to month.
How does this cash position affect your decision-making? Many of these cost optimization tools involve a contractual commitment, which means you’re legally required to pay at some point no matter how you end up using AWS and no matter if you’re out of cash a year in the future. Further, some of these commitments exchange upfront payments for an overall reduction in total cost, which means you need a fair amount of cash available immediately.
Before expanding your company’s contractual commitments, we recommend you learn more about your company’s cash position, including bringing your CFO into your thinking as you propose cost optimization alternatives. Together, you’ll make the right decisions.
The cost optimization strategies
Credits: Delete spend off your bill
AWS credits are a simple financial tool that AWS uses to offer generic discounts or refunds without any contractual requirement, making them incredibly easy to implement. Credits can often be attained through program membership, like a credit card, professional network, or investor relationship.
Simply put, a single AWS credit is equal in value to one US dollar (Fun fact: while you may pay your bill in a variety of currencies, all AWS billing is generated natively in US dollars!). Most credits are applied regardless of usage, resources, and timing, and serve as a dollar value deletion off your total bill prior to the application of taxes. (Some credits are service-specific, so it’s important to read the fine print.)
The lower your total AWS spending, pursuing AWS credits can be a no-brainer way to optimize total spending. Yet this does take time and effort. Once you reach a higher level of monthly spending, the potential AWS credits you could apply can’t make a real dent in the total bill, making the time and effort it may take you to source credits simply too expensive for the reward.
Credits are applied at the end of the month, on the first month following their assignment to your AWS account. Any excess unused credits are rolled over onto future bills until they’re exhausted.
To reflect any credit programs you intend to add to your AWS organization for the upcoming fiscal year in your draft AWS budget, you’ll want to apply the total value of the credits to the months in which you expect to receive the credits. If the value of the credits exceeds any month’s projected spending, carry the difference forward to the next month.
Storage Tier Optimization: Let AWS downgrade your spending automatically
AWS offers a wide range of storage solutions optimized for varying levels of need to access the data in storage. Across the tiers, as the potential delivery delay and cost to retrieve data goes up, the cost to store goes dramatically down. As a result, the ‘deeper’ storage tiers are far more economical for data you’ll rarely access, while the more ‘available’ storage tiers are far more economical for data you’ll frequently access.
One option for storage tier cost optimization is to review every S3 bucket to determine its purpose and availability needs, then assign it to the proper tier based on your expectations. Yet, if you apply the Amazon S3-Intelligent Tiering offering to all buckets that you aren’t certain need to be constantly available, you can let AWS do the work of assigning the right tier for you.
For budgeting purposes, it’s easy to find the list price of the tier you’d like to move to and replace it in your calculations for the list price of the tier you’re currently using. However, the very ‘intelligent’ nature of the intelligent tiering offering means you can’t actually predict how each bucket will be billed for the months to come. Therefore we don’t recommend making a budgetary adjustment just yet; it will take a few months of analysis to determine which tier your buckets settle down on. We recommend implementing intelligent tiering as a way to help your team outperform your budget and gain a bit of flexibility in spending throughout the year.
Auto Scaling: Bring resources online only when you need them
The principle behind Auto Scaling is that adding whole resources to an environment on a permanent basis is overkill when typically the load that demands these resources ebbs and flows by the minute and by the hour. The very nature of the public cloud, where resources are merely rented and not purchased, means that you may temporarily borrow resources for use when necessary, and return them when no longer needed.
When you have Auto Scaling configured, new resources are added programmatically when existing resources become overloaded, and are then removed when utilization rates decline. Implementing auto scaling is an excellent way to stave off the cost and effort required to bring additional resources online manually once current resources become overutilized, not to mention it reduces the overall cost of keeping those resources online permanently.
In the AWS ecosystem, there are multiple native tools available for configuring Auto Scaling, such as Application Auto Scaling, multiple third-party tools available, such as Karpenter, and many native AWS services offer proprietary built-in configurable autoscaling logic, such as AWS Elastic Beanstalk. While each is implemented somewhat differently, all typically feature controls such as minimum and maximum resource counts as well as utilization thresholds that should trigger the scale up and scale down actions.
If you choose to employ Auto Scaling, you’re not agreeing to a contract, paying for usage upfront, or even receiving any sort of discount. Rather, Auto Scaling is a technical implementation that dramatically reduces the likelihood that you will pay for more resources than you need at any given moment.
If you reflect back on the AWS budget you created in the previous chapters of this guide, the implementation of Auto Scaling will move resources currently assigned to the Expandable Systems category of your budget to the Scaling Usage category. All of a sudden, a planned, permanent doubling of resources intended for mid-year may actually result in a few hours of doubled resources during each month, a potential 50%+ reduction in cost for that resource type.
When thinking about applying Auto Scaling to your AWS Budget, consider that every system you implement Auto Scaling on moves that system into the Scaling Usage category of budgeting. It can be incredibly hard to model the financial impact of Auto Scaling prior to implementation because the actual frequency of scale up and scale down is unknown. Therefore, their effect on your Unit Cost is unknown.
As a result, selecting to implement Auto Scaling should be a tool in your toolbelt to help your team outperform your budget, offering up available cash to be deployed elsewhere. After about three to six months, you can re-run a budget analysis and build a reliable go-forward estimate.
Resource Scheduling: Don’t let idle resources waste your money
Do you really need all your resources activated and incurring charges right now? While you can be certain your SaaS production environment needs to be available for use twenty-four hours a day, seven days a week, the rest of your AWS resources rarely need the same level of availability.
The majority of SaaS companies leverage vast numbers of AWS resources to operate development, testing, and staging environments for their products, not to mention data science, sales engineering, customer implementation environments, and more. Unless each of these environments is shared with teams in every time zone, they do not all need to be always available. Many only need to be available during their assigned teams’ work hours.
Using a third-party tool, like Aimably Reduce, to perform resource scheduling can introduce meaningful savings into your operating budget, whether you are simply adding back the cost associated with an extra few hours while the developers are asleep to weeks or gaining months of savings between data science projects. Aimably Reduce offers the ability to set calendar-based resource stop and restart, with the ability to override when a resource is necessary for use.
What’s additionally convenient about implementing Resource Scheduling is that your budget can be easily adjusted to account for your planned schedules. When you performed your budget analysis, one of the steps we recommended was the analyze the operational variable that might cause growth in the utilization of a resource. This will be your best asset for making determinations about which resources should be scheduled, and who should be able to manage or override the schedule.
Let’s work with an example: QA engineers. Any resource that was identified as dependent on QA engineer count for planning scale can also be seen as an excellent candidate for scheduling in accordance with your QA engineers’ work hours. Simple!
Once you’ve actually implemented a Resource Scheduling program, you can easily calculate how many hours out of the month each resource will no longer be online, and you can factor in an estimated percentage reduction in cost into your budget as a result of each of these calculations.
Spot Instances: Pay less for short-duration resources
Simply put, a Spot Instance is a virtual server resource that is created dynamically from excess capacity in the AWS cloud, which also means that the instance is available for use for an undefined and limited period of time. Spot Instances are also always cheaper than their conventional EC2 counterparts, though the pricing does fluctuate with market demand.
Stated another way: if your infrastructure can handle a compute resource stopping and being replaced with another relatively quickly, you can save an extraordinary amount of money on that compute resource if you replace it with a Spot Instance.
Which resources can be replaced with Spot Instances? Luckily enough, we just discussed a few categories that are perfect fits. Due to the very nature of Auto Scaling, where resources are intended to be brought online for limited periods of time, any group of resources that have been configured for scaling represents a group of great Spot Instance candidates (in some cases, like with containers, you can leave at least one resource alone as a more ‘dependable’ resource and let the others leverage spot instances). Furthermore, if you already intend to stop and start resources under a Resource Scheduling program, you can absolutely consider using Spot Instances for all of these without major concern.
As we consider AWS Budget impacts, it’s important to note that every Spot Instance has its own pricing structure dependent on resource availability. As a result, it’s very hard to model before you get started, but rather easy to project from once you’ve implemented a program. Just as with Auto Scaling, we recommend getting a Spot Instance program dialed into your functional expectations, then letting it run for 3-6 months before generating future spending models. Also, keep in mind that the use of Spot Instances will drive compute spending into the Unit Costs analysis, as these resources may be added and deleted throughout the day or week.
Reserved Instances: Commit to compute resource usage in exchange for a discount
When you think of Reserved Instances, it helps to think about cell phone plans. Take a moment to think back to the first cell phone plans where fixed prices bought a consumer a set amount of minutes at a discounted rate instead of having to pay for each minute at much higher rates. Just like with these early cell phone plans, when you purchase a Reserved Instance (RI), you commit to paying a discounted rate for the use of that instance over a fixed period of time, plus an overage fee for any utilization in excess of the original contract.
While somewhat recently superseded by the AWS Savings Plan program, RIs remain a well-loved and well-used approach to AWS cost optimization because they allow companies to set up more conventional purchasing relationships with AWS featuring predictability and (usually) some cost savings.
RIs share the drawbacks of cell phone plans: they’re usage-type specific. Remember: you could use up all the data in a cell phone plan to the point where you need to pay overages, but never touch the minutes. Similarly, you could buy two Reserved Instances for two different types of EC2 servers, using one far above and beyond your commitment while never touching the other. You don’t get to roll over the purchase credit from one instance type to cover your overages on another.
In fact, if you bought a boatload of RIs and then chose to reassign all your compute workloads to new instance types, you have just cost your company a whole lot of cash (though you can resell those contracts – we’ll get to that in a few paragraphs). As a result, RIs take a lot of planning. First, you need to figure out how many of each type should be bought, then, you need to weigh the costs and benefits of payment methods, next, you’ll want to consider how to de-risk any purchases, and finally, you’ll need to model these costs forward into your AWS budget.
When it comes to selecting RIs, the longer you have relied on a particular EC2 category, the more likely you will benefit from purchasing RIs for that category. Do you still need to analyze your workloads against the EC2 categories to be certain they are aligned correctly? Do you have any re-architecture plans for the upcoming year that could result in the selection of alternative EC2 resource types (or even the decision to go serverless)? Assuming the answer to the previous two questions is ‘No,’ it’s time to start identifying which resources are good targets for RI purchase and how many to buy.
The resources that fell under the Fixed Systems category for your AWS Budget process are prime targets for Reserved Instance selection. Similarly, any Auto Scaling group for which you have a good baseline of 3-6 months of historical usage, is an excellent target. Resources that run new products and features are likely to be worse selections because your choice of resource type may change as you become more familiar with the behavior of the workloads.
Now that you’ve decided on how many Reserved Instances of each type you’ll be purchasing, you need to be absolutely certain of your company’s preference of cash conservation against total expense reduction. No matter how simple the interface appears, paying for your fleet of RIs upfront results in a major cash outlay in exchange for a large reduction in the overall cost, whereas paying for each as you go cuts the savings and conserves the cash. Talk to your CFO first before clicking through to agree to any purchase. The RI selection process may not feel like signing a contract, but the liability is the same.
Now that you’re considering a Reserved Instance, it’s important to talk about de-risking. Due to the sunk cost of having committed to an RI of a particular type, AWS built an entire Reserved Instance Marketplace to facilitate the auction-based resale of unused and unwanted RIs. While there’s no guarantee that you’ll get a buyer for an RI you’ve posted on the marketplace, nor is there a guarantee that you’ll get the price you’d like, there is a theoretical opportunity to unload these purchases as long as you’re willing to expend the effort. Plus, there’s a growing number of companies willing to broker purchases and resales on your behalf.
Finally, let’s talk about budget impact. Assuming that your company is not going to either record RI purchases as assets or amortize the purchase across its serviceable life, your AWS budget will need to be altered when introducing or adding more Reserved Instances to your organization. Luckily, it’s quite straightforward. Updating the budget simply requires pulling out the list price line items associated with matching EC2 types up to the amount you committed from the budget calculation and replacing these line items with the terms of your RI agreement, aligning partial or full upfront payments with the months expected and distributing the rest.
Savings Plans: Commit to dollar usage of compute resources in exchange for a discount
Introduced in 2019 to combat the limitations of Reserved Instances, AWS Savings Plans are a contractual agreement with AWS where, in exchange for a discount on your resources, you commit to spending a minimum amount on computing power over a fixed time period. When you move from Reserved Instances to Savings Plans, gone are the resource type limitations and the need to sell back unused resources. If only cell phone plans worked that way!
Because your Savings Plan can apply to all computing workloads, you don’t need to be nearly as choosy about implementing these as you would with RIs. In fact, AWS offers a recommendation tool that can analyze your past usage and generate a recommendation for a Savings Plan.
Pro Tip: implement all your programmatic cost-changes first (Auto Scaling, Resource Scheduling, and Spot Instances), then examine your savings plan options at least 30 days later, to get a reliable estimate of your actual projected spending for a reasonable Savings Plan recommendation.
Just like with RIs, you will need to address the cash vs. expense question with your CFO before you determine whether upfront payments will behoove your business or not, but once that decision is made, implementing Savings Plans into your budget is even easier than with RIs. Simply pull the On-Demand dollar value of your Savings Plan out of the budget on a monthly basis and replace it with the upfront and monthly payments for your Savings Plan commitments on their projected dates. Easy!
Private Pricing Term Sheets: Commit to dollar spending overall in exchange for a discount
While little is communicated by AWS itself about the Private Pricing Term Sheet (PPTS, the newest incarnation of the Enterprise Agreement or Enterprise Discount Program), many other sources reveal that a PPTS is like a Savings Plan that is not limited to just computing workloads related to EC2, but rather any item that shows up on the AWS bill, Ancillary Purchases included!
In exchange for an across-the-board discount on the entire AWS price list (ballparked beginning at 9%), a company commits to a minimum dollar amount of spending for a fixed period of time. What’s even better is this discount can apply above and beyond all the previously mentioned cost optimizations. The only caveat is that companies are eligible for this program only once they exceed a threshold of annual AWS spending (some sources say the threshold is as low as $500K while others cite $3M).
If you spend this much, getting signing an Enterprise Agreement for a Private Pricing Term Sheet is an absolute no-brainer. Plus, if your major sources of spend include non-EC2 costs, such as storage or data egress, this is one of your only ways to optimize your AWS costs. The only questions in front of you are: how long and how much?
Once you have your AWS budget in hand, a year-long PPTS is a breeze. Simply use your pre-tax spending estimates to feed in total spending for your commitment and tack on your negotiated percentage discount for an updated budget. Of course, this gets a lot more complicated when you could benefit from even greater savings over a multi-year plan, when you don’t yet know what strategic initiatives will come your way in those years.
The truth is, it’s a safe bet to assume that after you’ve done reasonable cost optimizations, your costs aren’t going to go down. That’s because you’re always going to be focused on growing your customer base and improving your product. Generally, the conversation to have with your CFO and CEO in advance of a purchase like this will be about macro trends: do they expect to continue to pursue growth rates at the same level or will the business shift to a profitability focus?
Given that AWS costs at SaaS companies grow the fastest as more customers are brought on, a conservative approach to multi-year agreements might be to apply the general growth rate trends projected in these conversations to your monthly projected AWS spending multiple years in the future, then bring those potential commitments back to your fellow executives for evaluation before signature.
Reseller Discounts: Take advantage of the economy of the many, not the few
The majority of the cost savings options listed above take time to analyze and evaluate. Sometimes, you don’t have the time and you need a simple approach to shave off some extra cash from the budget. If this applies to you, it might be time to consider an AWS reseller.
AWS resellers typically are consulting companies who offer a custom price book for their clients alongside a series of professional services that could be of interest to you. Because they handle a large volume of clients, their direct pricing with AWS is so reduced that they are able to offer a 2-5% discount to any of their clients, just for signing with them.
No brainer, right? Perhaps. First, if you are eligible for a Private Pricing Term Sheet, you will always get better pricing directly from AWS than you will from a reseller. Next, due to the historical limitations of AWS organization structure, be prepared for some unforeseen consequences.
What do we mean by consequences? Specifically, your AWS accounts are likely to be migrated to a parent organization, removing any organization-level hierarchies or access controls that you might have had in place. Additionally, organization-level analysis programs, such as Cost Explorer and the Cost and Usage Report critical for budgeting, become unavailable to you. As a result, the reseller has to offer you an alternative third-party cost management tool to understand your actual spending, and for the partner to properly calculate your billing. This can spell billing delays as well as frustration due to the need to use tools you didn’t choose.
If you do sign a reseller agreement as part of a cost optimization strategy, applying your discount to your AWS budget is quite simple. Just apply the percentage discount pre-tax to all expected monthly charges, after applying all other cost optimizations.
Congratulations! You’ve completed Chapter 5 of the Aimably Definitive Guide to the AWS Budget.
Are you ready to learn more? Up next is Chapter 6: Guarantee on-budget performance by implementing these 7 processes, where you will learn the processes we use for successfully meeting the spending expectations established by the AWS budget, keeping your engineering organization happy and productive throughout.
Remember, we’re here to help. The Aimably team has extensive experience serving as the embedded AWS financial planning, reporting, and analysis group for software companies. We regularly develop and maintain cloud financial maturity for our clients, ensuring total preparation through acquisitions and beyond.
We can take on the AWS budget process for you.
Let's Talk
