The AWS Free Tier was historically aimed at providing a no-risk way for folks new to the AWS platform to test out various services. The idea was that some services would be free up to some arbitrary point so people wouldn’t have to pay to test things out.
This was a noble goal. But the reality has turned into something radically different that serves almost no one.
What’s free, what costs money?
First, there are some services that participate in the free tier, and there are some that don’t.
A lot of the higher-level managed services—or useful features that remove a lot of toil—don’t qualify.
This may seem like it’s not a big deal: Who cares if someone who’s self-teaching in their dorm room doesn’t spin up a VPC endpoint?
The trouble here is that if you train newcomers to not use services when they’re learning, they don’t revisit that approach or architecture once they’re employed somewhere and controlling environments where the cost for those services more than justifies itself.
“Begin as you mean to go on.” Very few folks go back to relearn more efficient ways of achieving things they’ve already solved in a satisfactory way the first time.
Free tears
Every month when the AWS bills come due, Twitter explodes with folks who are deeply upset that their “free account” cost them a couple hundred dollars.
Edge cases, lack of understanding, 12-month free trials ended so abandoned resources started costing money—all of those events lead to surprise bills, which in turn feeds into the tired trope that the cloud is too expensive, gouges you with unexpected credit card charges, or else becomes a clever trap to ensnare the unwary.
When you misunderstand a billing dimension, you generally feel dumb—and the charge for that oversight feels like a tax on taking AWS’s “free tier” at its word.
You want to encourage newcomers—not make them regret exploring your offering with bills that don’t matter to AWS. A $75 charge is nothing to AWS’s ~$40 billion behemoth. But suddenly some college kid in their dorm room has to decide between paying the cloud bill or eating this week.
That’s unfair—and I would go so far as to say that it’s not the college kid’s fault. You shouldn’t need to master a complex billing paradigm before you spin up a virtual machine!
“There’s no good way to solve the problem.”
I’m not saying that this is an easy problem to solve. But it’s certainly not unprecedented.
Google Cloud Platform has nailed this; their free tier offers a bunch of “always-free” offerings, they give new accounts $300 in credits, and when that credit limit is exhausted, services get stopped and (eventually) terminated.
Azure likewise offers $200 in credits, plus a 12-month free plan. Once you add a credit card to the account for billing purposes, limits are removed and you can exceed their free limits. But you don’t get a surprise bill.
Even Oracle—a company whose predilection for screwing its customers rises to a level where they need to register on a list and inform their neighbors—has a very well-done free tier (not to mention a surprisingly well built cloud offering).
In other words, AWS is the only large cloud provider that doesn’t offer any form of safeguard.
“But the console should warn you!”
The AWS console has gotten a lot better about telling you if you’re about to do something that isn’t covered by the free tier. The trouble is that those notifications aren’t universal. Also, given that there’s currently no good way to turn “something you did in the console” into something repeatable without resorting to acts of code terrorism, you really can’t depend upon everyone using the console for their explorations.
Additionally, tools like the Serverless Framework and the CDK mean that there are a lot of roads to deploying AWS infrastructure, which means there are ever more traps to catch the unwary.
Nobody wants to see a world in which newcomers are surprised. Yet we keep seeing it every month.
I get that these are hard problems to solve. Particularly with the proliferation of accounts under the auspices of AWS Organizations, there are two new account models that need to be differentiated.
The first is the learner account model that I’ve written about here. That account shouldn’t let the user provision billable resources without upgrading the account to paid, and should in fact stop resources when their free allotment has been exceeded. “My app just turned itself off” is a valuable lesson in cloud cost management without leaving scars that damage next semester’s tuition payment.
The second is a new account designed to run production workloads. “Here’s the billing information if it’s not linked to an AWS Organization, don’t even mention the free tier to me again, and whatever you do, make sure you don’t turn my app off since it’s making me money.”
Those two use cases are very much not the same customer persona—and it’s time the AWS Free Tier recognized the difference. Please fix this.
