For a moment, pretend that you're robbing a house. You've come prepared with a flashlight in one hand, an extra-large pillowcase in the other, and dressed from head to toe in black ready for your spot in an ADT commercial. You creep lithely through an unlatched window and fall quietly onto the kitchen floor. Donning some night vision goggles (that you can apparently get overnighted on Prime), you take a look around and — much to your surprise — this family keeps all their valuables in the kitchen. How convenient! Expensive watches, jewelry, treasure chests full of pirate's gold, and a top-of-the-line Roomba are just a few of the treasures in sight. All this won't fit into your pillowcase, so what do you take to maximize your profits without overloading yourself?
This conundrum is known as the Knapsack Problem, a famous combinatorial optimization problem that's been worked on for more than a century. The official Wikipedia definition is “given a set of items, each with a weight and a value, determine the number of each item to include in a collection so that the total weight is less than or equal to a given limit and the total value is as large as possible.” It's an NP-Complete problem, meaning that there is "no known polynomial algorithm which can tell, given a solution, whether it is optimal.” That's a bit of a mouthful, so more simply put: for each item you are considering adding to the bag, your total number of possible combinations to consider goes up exponentially to find the optimal combination.
This just so happens to be the problem that AWS gives their customers when it comes to optimizing their pricing. But how? And more importantly, why? To understand how this problem manifests itself in AWS's pricing, we'll need to go back to 2006 when you had a Blackberry in your pocket and a second desk in the server room for when it got too cold in the office.
Pre-AWS was, in some respects, a simpler time when it came to pricing and costs. Needed to run an enterprise-scale application? Order some servers, procure your licenses, and let Accounting amortize that out for the lifetime of the hardware. Granted, this could all take many months to complete especially when procurement got involved, but what other reliable options did you have? Fast forward to 2006 and enter AWS and On-Demand compute! Suddenly, standing up servers took a matter of seconds and with no lengthy ordering or procurement process needed. You'd pay what's now known as On-Demand pricing for the ability to scale up compute resources whenever your heart desires with all physical hardware managed by AWS in some far-flung data center. The best part was how easy all this was to accomplish; give Bezos the company card, tell accounting you'll be saving time and money because you'll only be using resources when you need them (sure...) and get rid of all those dusty servers along with the intern playing Runescape in the server room to boot.
While this solved one problem for the engineering team, another was born for finance and accounting. Purchasing physical, on-premise servers was relatively easy to account for as Capital Expenditures (Capex), amortizing their value over their projected lifetime. But renting server capacity from another company? Not only was this now an Operational Expenditure (Opex), but matching costs to the resources consumed and then to revenues required a deep understanding of cloud computing. Admittedly, this problem was easier to solve when AWS only provided a few services, but that's no longer the case for any cloud provider (AWS currently provides over 175 services and counting). So for most organizations that began to move partially or fully to the cloud this new accounting schema became a necessary evil underpinned by the promise of a lower Total Cost of Ownership (TCO).
As the number of services that AWS provided grew and new cloud providers entered the fray, we began to catch wind of cautionary tales of cloud migration; enterprises spending $30M on on-premise servers fully migrating to the cloud, only to spend $80M five years later post-migration (that's a true story and not a unique one). Not quite the cloud promised land, but we thought those organizations must have been doing something wrong... until these stories became commonplace across every size of business. Of course, there were success stories of huge migrations resulting in millions of dollars of savings, but more commonly we heard of smaller businesses able to operate at scale, providing and selling globally without having to put tens of thousands of dollars upfront to purchase on-premise servers. Hosting on AWS/GCP/Azure became a familiar budget line item for CEO's and CFO's of small and medium-sized businesses, but one that was entirely too complex to do much about. Constrained resources like developer and engineering time were better spent on customer-facing, or "green-dollar", projects than having them figure out the invoice from AWS and how to optimize it.
The promise of spending less on the cloud seemed too good to be true. Why? Turns out that paying for something when you aren't sure what you're getting isn't a great idea, particularly when you have a margin-obsessed business on the other end sending you the bill.
The Setup and Crew
In case you haven't peeked out from under your rock yet, cloud adoption has skyrocketed with the COVID-19 pandemic as a historical number of businesses of every size look to support a remote worker base and provide services online. Still, the same problem we started with persists: engineers have to take time to understand their AWS bill and how to optimize it because AWS hasn't made their invoice very intuitive for the business stakeholders. While enterprises are increasingly multi-cloud (utilizing multiple cloud providers at once), trying to understand where they can get the best bang for their buck is an exercise in futility when you can't make heads or tails of your bill. Valiant efforts have been made to simplify and solve this problem in developing areas like FinOps, or Cloud Financial Operations, where the discipline's entire purpose is understanding the business impact of cloud usage and weighing the cost and benefits. These folks are cloud experts with a deep understanding of cloud architecture across many providers, often with a background in finance and/or economics. We're seeing amazing results from businesses that are hiring FinOps professionals or creating them from within, providing the business owners with unparalleled insights into cloud costs and where their money is being spent. So there you have it, problem solved! Go find one of the 1,000 FinOps professionals on LinkedIn, poach them, and leave all your worries in the clouds (I'm sorry).
Not so fast! We're missing an important variable. Remember the key benefit of the cloud being On-Demand and how that's charged at an On-Demand price? Let's circle back to that. As larger enterprises made the switch to the cloud, committing tens of millions and sometimes hundreds of millions of dollars to AWS, Azure, and GCP, some of those cloud providers began to offer formalized discounts on pricing called “Reservations”. A Reservation is simply a financial commitment or contract between the customer and cloud provider which commits the customer to pay a specific amount per hour/year for use of a specific resource. It’s important to note that Reservations are not the cloud provider reserving servers for a customer, which is known as “Reserved Capacity.”
Reservations can yield great discounts on your use of AWS services but there’s a catch: which Reservations do you pick? To get a taste of how many options you have, here’s the Reservation options just for AWS’s EC2 (Elastic Compute Cloud) current generation of servers, also known as instance types. That’s a 491-page table, so have fun printing that out and sending it to your FinOps, FP&A, or Engineering team to figure out what they should commit to. And that’s for just one AWS service! Currently, AWS offers reservations for EC2, Fargate, Lambda, Redshift, RDS, Elasticache, Elasticsearch, DynamoDB, and some storage, with coverage per type of service depending on the cloud provider. The discounts AWS gives for committing to paying them aren’t paltry, either: you can receive up to a 62% discount on on-demand prices. This is not something to pass over, but because of how complex it can be many organizations don’t even spend time trying to figure it out and either pay fully on-demand or commit to a holistic Savings Plans with modest discounts and okay flexibility in terms of where the discounts can be applied.
How will you decide which discounts do you choose? For the math nerds out there, this is the NP-Hard problem that AWS is giving their customers. If you were running 400 instances in your environment, the Big-O notation for all possible combinations would be f(x)=O(400^x). For everyone else, that means you have to choose from
different options. Will a lone engineer at a small or medium business take the time to solve this problem? No. Will a FinOps professional at an enterprise take the time to solve this problem? No. Will entire Cloud Centers of Excellence teams with over 50 team members at Fortune 500 companies solve this problem? Rarely. Believe me, we’ve talked to them. In fact, our co-founder is one of the guys that led this team at the 9th largest company in the world. This problem is one that AWS gives all their customers, regardless of how big they are, but only the largest seem to have the resources to even partially address it. Other cloud providers are beginning to do the same when it comes to pricing complexity and who can blame them; AWS accounted for 73% of operating profits in 2018 across the entire Amazon family of businesses! Those margins are too good to pass up, and pricing complexity makes up more than a couple threads in the wool that’s being pulled over the cloud customer’s eyes. Is there any hope for the businesses that don’t have the time or engineering resources to solve this problem or will they continue to be victims to AWS’s margin? Lucky for you, Danny Ocean is out there and for hire; except he’s a robot, so more like “Heistotron” from Rick and Morty.
What exactly is Heistotron, our friendly Heist AI, doing differently than you to solve this problem? It turns out there are more than a few ways to solve this problem, but with one solution yielding significantly better results than all others (for now): the dynamic programming solution. If you’d like a full explanation of this solution, I’d recommend watching this tutorial video. Simply put, this solution reduces the amount of overall calculations that one has to make. So instead of you rummaging around this poor family’s kitchen, trying to fit all sorts of things in your sack while furiously checking eBay for how much you can get for a Roomba, Heistotron is calculating and recording all possible combinations in seconds, giving you the exact mix of valuables to put into your sack and walk out of the house in record time.
Who is Heistotron in the context of cloud costs and AWS pricing? That’s Reserved.ai. When the above solution is applied to AWS pricing: it takes seconds to solve. Combined with 1-Click or programmatic execution, what was once a 6-week process between engineering and finance becomes completable in a few hours. Not to mention combining the above with some cleverly-applied machine learning around forecasting and reservation flexibility, the results are unbelievable for businesses of all sizes.
Is your balaclava still on? Let’s get back to this robbery. Now, with what we know about the Knapsack problem, AWS, and Reservations, and Reserved.ai at your side, let’s look at this situation a little bit differently:
- You, the burglar, are a customer of AWS.
- The house you’re robbing is AWS.
- All the home’s valuables are all the potential reservations, or discounts, you could choose.
- Only one discount, or valuable, can be applied to the usage of one server at any one time.
- You have limited dollars / resources you can cover with these reservations.
Let’s throw Reserved.ai into the mix and see what we get.
The Heist and Getaway
What kind of results are enterprises seeing that using Reserved.ai and the dynamic programming solution to this problem? Here’s a few examples:
- $10,000/year AWS Spend Customer with 22% Reservation Coverage: Saved an extra 35% after one hour.
- $300,000/year AWS Spend Customer with 45% Reservation Coverage: Saved an extra 27% after two hours.
- $3,000,000/year AWS Spend Customer with 56% Reservation Coverage: Saved an extra 18% after three hours and reduced upfront spend by $400,000.
- $24,000,0000/year AWS Spend Customer with 80% Reservation Coverage: Saved an extra 15% after four hours and reduced upfront spend by $12,900,000.
These were businesses that spent weeks planning out rightsizing activities and reservation purchases, having countless meetings and exchanging countless emails with finance to figure out exactly what kind of commitments made sense for them. Or worse, they said “screw it” and threw their money into Savings Plans, only getting a fraction of the savings that they could achieve.
Now, with Reserved.ai finding the optimal combination of Savings Plans, Reserved Instances, and On-Demand, those wasted hours are a thing of the past. Reach out to us at email@example.com if you’d like to see how much you could save with only fifteen minutes of your time needed.Subscribe to our Newsletter