How AWS Pads Profits Through Pricing Complexity

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! What do you take to maximize your ill-gained 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.” More simply put, for each item you are considering adding to the bag, your total number of possible combinations to consider goes up exponentially.

This also 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 minutes or 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 platform/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, rarely deprecating any service). 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). Did that promise deliver? Sometimes. 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.

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.

In case you haven't peeked out from under your rock yet (which no one would blame you for), it's 2021. 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 and Developers have to take time to understand the AWS bill and figure out how to optimize it. AWS hasn't made their invoice much more explanatory for the business stakeholders alongside tremendous service growth and adoption. Enterprises are increasingly multi-cloud (utilizing multiple cloud providers at once), trying to understand where they can get the best bang for their buck. Valiant efforts have been made to simplify and focus solving this problem in developing areas like FinOps or Cloud Financial Operations, where the 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 for use of a specific resource. It’s important to note that Reservations are not the cloud provider reserving servers for a customer, also 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 server or instance types. 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 Plan 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 permutations would be f(x)=O(400^x). For everyone else, that means you have to choose between 45,035,996,270,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 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 address it. Other cloud providers are beginning to do the same 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 with pricing complexity making up more than a couple threads in the wool that’s being pulled over the cloud customer’s eyes. So 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.

But what exactly is Heistotron, our friendly Heist AI, doing differently than you? 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 Archera. 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 Archera at your side, let’s look at this situation a little bit differently:

Let’s throw Archera into the mix and see what we get.

What kind of results are enterprises seeing that using Archera and the dynamic programming solution to this problem? Here’s a few examples:

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 Archera finding the optimal combination of Savings Plans, Reserved Instances, and On-Demand, those wasted hours are a thing of the past. Reach out if you’d like to see how much you could save with only fifteen minutes of your time needed.