The three Fs of cloud pricing
I'm not the first person to poke fun at cloud pricing, or point out how large the cloud providers really are. My hope is that you find this framework helpful if you're an engineer building stuff. If nothing else, since I'm Australian, I thought I would add a few swear-words into the discourse.
While I mention Amazon and AWS a lot in this post, I'm not trying to suggest that they are any worse (or better) than their competitors when it comes to pricing and their business model.
The free tier (as in 'first hit is...')
The free tier started out with good intentions. People were pretty skeptical of this whole cloud thing way back in 2006. Allowing people to play with the product for free was good for customers. But it was even better for cloud adoption. The free tier was part of their strategy of selling IT infrastructure directly, without having to go through finance and executives. This was a big (and profitable) step forward. I won't even mention that AWS borrowed their original go-to-market strategy from some Australians (Ok, I mentioned it once).
While it started out with good intentions, AWS has ushered in a trend in the industry of offering generous free tiers. I question whether this focus on 'free' is actually good for the rest of us. If you're a startup running some kind of cloud service on AWS, GCP, or Azure, who is profiting from your free tier? It's not you. Some people think of the costs of servicing the free tier as a marketing expense. But your marketing spend can be scaled up-and-down depending on your available cash, and how fast you want to grow. A free tier is a committment to serve some customers for free forever. This is the closest thing to a blank check you will find in business. If you realize your mistake and try to convert free-tier users to paid users, then you risk making your customers mad, or looking like an outright predator.
Free tiers are great for cloud-provider revenue, but less great for founders, investors, and even customers after things go sideways.
Even more scary than the free tier is the credits given out by cloud-providers to startups. These credits discourage early-stage startups from controlling their costs early. This whole startup caper might seem easy when the underlying cloud services are all free! But next year, when the credits expire, will your business know how to be frugal?
The F-you tier
The next tier of cloud pricing is where they reach into your wallet and take out all your money. Now that you have actual customers, and depend on your cloud provider then you don't want to risk getting your 'electricity' turned off. I define the F-you tier as where you're paying on-demand rates, but not getting volume discounts.
This is surely where AWS makes the majority of their profits. AWS has had steady 20-30% margins ever since they started breaking out AWS financial numbers.
The thing to remember about the F-you tier is that it goes on for a lot longer than you think. You need a really big bill to get to the next tier 1. You can dedicate engineering time to looking for efficiencies. But remember, the going rate for competitive engineering salaries in Seattle, the Bay Area, or New York can easily exceed $200,000. To manage cloud bills you probably want somebody with experience, who knows the names of at least 50% of the 200+ AWS services. If you want to be 'multi-cloud' then you will want to know the Azure, and GCP equivalents too.
As a thought exercise, if you were going to hire somebody full time to manage costs, capacity, reserved instances, savings plans, and advise your other engineers about optimizing costs; how big does your bill need to be to see payback?
If that person can save you 90% (impressive!), then you need a $220,000 annual, or $18,000 per month bill to see payback on their $200,000 salary. If they're going to save 50% (more realistic), then you need a $400,000 annual, or $33,000 monthly bill to get any payback.
I worked on some 'two pizza' teams at Amazon with hilariously large AWS bills. Think north of $1MM per year. Even with those massive bills, we usually couldn't justify significant investment in reducing our AWS bill. If something took 5 minutes, sure. But any re-architecting, messing around with reserved instances, or even taking advantage of the different S3 storage tiers was deemed not worth it for us at the time.
The F-off Tier
Say you succeed in scaling your business, and become a large customer. Now you think you're a big shot, so you can extract discounts from Amazon.
Your CFO (like Monica above) might be a little stressed after AWS tells you to F-off.
AWS had a $40 billion dollar run rate at the end of 2019, growing over 30% a year. Say you had a $120 million dollar annual AWS bill, and took your business to Azure or GCP. At 30% growth, AWS will have an extra $12 billion dollars in revenue next year. In other words, they would replace your $120 million a hundred times over. They won't miss you.
Take Dropbox, by many accounts a successful startup. A jewel in the crown of YCombinator. They migrated 500 petabytes of data off of AWS. Surely AWS will miss that?
Fortunately for this analysis, Dropbox gave us a few clues. They said in their blog post that they migrated to improve performance, and get better unit economics. I'm going to address the unit economics here. Another blog post says that their use case is optimized around cold storage.
Optimizing for cold storage tells us two things. Firstly, it means that the storage cost, not other costs, like network egress costs are dominating. Secondly, cold storage means data is infrequently accessed, so Dropbox could have been using the elegantly named2 Amazon Simple Storage Service - Infrequent Access (Amazon S3-IA), which costs $0.0149 per month for each gigabyte (GB) of data stored. If Dropbox had been using the right S3 tier, how much storage revenue did AWS lose when Dropbox migrated off?
$89 million dollars.
That sounds like a lot of money, but it was less than 1% of AWS revenue at the time (2016).
The second reason AWS might tell you to F-off rather than giving you a volume discount is they know how expensive it is to build cloud services. Dropbox says they migrated to save money, but this quote from the Wired article leads me to believe otherwise.
Over the last two-and-a-half years, Dropbox built its own vast computer network and shifted its service onto a new breed of machines designed by its own engineers, all orchestrated by a software system built by its own programmers with a brand new programming language.
The S3 team at AWS is probably a few hundred people at this point, but lets say Dropbox is able to build their own skunkworks version with a team size of only 10 people for two and a half years. At competitive industry compensation ($200,000), that would be a $5 million dollar investment (200,000 x 2.5 x 10). So they would need to be able to save at least 5% off of $100 million in costs to get payback in a year. Remember: AWS and S3 are much bigger, so have the advantage of economies of scale. Amazon has said publicly that they store exabytes. That's thousands of petabytes of data.
But as of 2019, Dropbox has more than 2000 employees. How many are devoted to maintaining and scaling their Magic Pocket storage? I think it would take at least 100, especially once you throw in the 'brand new programming language' and 'machines designed by its own engineers'! If it's 10%, 25%, or 50% of their 2,000 employees, then the annual cost would be $40, $100, or $200 million dollars respectively3.
We haven't even talked about the servers, data center space, networking gear, and peering agreements. Half an exabyte of hard drives at $0.03 per GB with 3x redundancy would be $45 million dollars. That's just the drives. Not cheap!
Having said all that, Dropbox migrating off of AWS for strategic reasons, and not saying their strategy out loud in public would make a lot of sense. As a storage company, it was probably sensible for Dropbox to migrate off AWS. I just don't agree with their public reasoning. I doubt they really improved their unit economics, or performance.
In summary, you probably can't build your own version of any AWS service for cheaper, and they know it. They would rather tell you to F-off than give you a volume discount, even if your cloud bill is many millions of dollars.
What to do?
If you're building a startup, and you're in the free tier, keep an eye on your costs. Try to track which things will grow with your revenue, and which things will grow with headcount.
If you're in the F-you tier, minimize costs now. Don't assume there's some magic engineering future where your utilization will go up. Big companies are not as efficient as they want you to think. You are unlikely to be more efficient in the future than you are now.
If you're in the F-off tier, I don't have much good advice for you. I've never been in this position.
But no matter what tier you're in, remember that: accelerating AWS revenue growth is good for their business, not your business.
What comes next?
If you think this is all a mess and want to do something about it, I'm building a company based on some of the ideas in this post. If you want to help, please get in touch! The endgame of computing doesn't have to be Jeff Bezos owning and operating every computer on earth4.
1: One interpretation of this blog post is that there actually is no mythical place beyond this second tier.
2: Making fun of AWS naming is patented by @QuinnyPig, but I couldn't resist here.
3: Again, using the $200,000 per year as a rough estimate. The actual cost for an engineer could be much higher once you factor in office space, and other costs.
4: Thanks to Bryan Cantrill for that phrasing.