Escaping surprise bills and over-engineered messes: Why I left AWS
travisbumgarner.dev
travisbumgarner.dev
It’s often the opposite, but most people don’t see that until after they’ve built their infrastructure around that, get locked in, and then start seeing the surprise bills, difficult to diagnose system failures, and hard-limitations start rolling in.
A bit of early skepticism, and alternative solutions with a long-term perspective in mind, often go a long way.
I've seen successful serverless designs but the complexity gets pushed out of code and into service configuration / integration (it becomes arch spaghetti). These systems are difficult to properly test until deployed to cloud. Also, yeah, total vendor lock in. It works for some teams but is not my preference.
Sometimes you have to do the (over) engineering part yourself, so that someone else isn't making the decisions on your behalf.
[Edit typo]
Taking a legacy application that runs on a single server and is struggling to scale with spaghetti of config files all over the box and security issues that have gone unpatched because no one wants to touch the box as it’s too dangerous to change anything, as everything is intertwined. No backups or unverified backups. No redundancy. No reproducible environments so things work on local but not on remote. Takes devs days to pin the issues.
Then break it down and replace with individual fully managed AWS services that can scale independently and I don’t need to worry about upgrades.
Yeah, the total bill for services is usually higher. But that’s because now there’s actually someone (AWS) maintaining each service, rather than completely neglecting it.
They key to all this is to use IaC such as AWS CDK to have code be the single source of truth. No ClickOps!
I’ve been working with AWS for about 8 years now and have worked on supporting dozens of projects across 5 different orgs ranging from small 5-person shops to 1000+ people. I have only seen a handful of cases where serverless makes sense.
> Taking a legacy application that runs on a single server and is struggling to scale with spaghetti of config files all over the box and security issues that have gone unpatched because no one wants to touch the box as it’s too dangerous to change anything, as everything is intertwined. No backups or unverified backups. No redundancy. No reproducible environments so things work on local but not on remote. Takes devs days to pin the issues.
All of these issues are easily possible with many serverless options. What it really sounds like is your org went from a legacy architecture that built up a ton of tech debt over the course of years and had no one owning the basics (ie backups) to a new one with less tech debt since it was built specifically around current issues you were facing. In 3-5 years I wouldn’t be surprised to hear the pendulum swinging back in the other direction as staffing and resources change hands and new requirements emerge.
I didn’t mean to say that serverless is the way. I was just talking about AWS in general.
Although serverless is a broad category that includes Aurora Serverless, which does has trade offs but it’s a good choice in some cases.
I also like Step Functions a lot.
EventBridge for an event bus.
I’d even put ECS into sort of serverless category. I don’t manage the underlying servers and only care about the abstraction at the container level.
The sweet spot for AWS seemingly is US$300-$3k/mth.
Side projects really need to optimize under this $5-50/mth and that's just too low on AWS. The expensive foot-guns are just too risky.
For that cost, you can get multiple production regions (for failover), dev/alpha/beta environments, a reasonable amount of CDN traffic, a bunch of databases and some halo services (like X-Ray/CloudWatch).
My past two previous projects have been on $5 vps with out issue. Some one really tried to bring one of them down with a ddos but gave up when it didn’t work.
A $5 VPS can take you very far if your project is well optimized.
The problem with frameworks/cms/etc is they are trying to solve everybody's problem but aren't really optimized to solve your specific problem if you have one.
If we had to have all of that on the cloud it would have been a lot more expensive.
Startups will benefit from the cloud, as it allows them to easily scale, and maintain infrastructure that would otherwise be very costly.
Then at some point, around 50-100 employees (depending on business), it makes more sense to have a server park sitting at home, and you probably have the revenue to hire a couple of system administrators to handle stuff.
Then you have enterprise customers with 500+ employees, who have compliance and governance to follow, who maybe has huge spikes during a month (banks for one experience a lot more load during payday), which you will have to pay for in your local server farm, but you can dynamically scale in a cloud data center.
Not that you can just "throw everything in the cloud", it still requires planning for the best cost optimizing, but once you reach enterprise level you can probably afford a couple of cloud architects or similar to facilitate this.
If you make a mobile game that becomes an overnight success and your DAU goes from 10k to 1M you need the capacity TO-DAY. Not in a week or two when you can get more servers to the colocation facility your stuff is in and get them configured and added to the cluster.
If your stuff is built on AWS, it'll just scale up automatically and most likely nobody notices except for your AWS bill - but the revenue from the game will more than make up for it.
It'll reliably cost exactly that and you'll be able to handle quite a lot of traffic. Probably enough that the same load would land you around 3k/month on AWS or GCP or whatever.
For 3k/month you can get hundreds of cores and 1-2 TB RAM on a couple of machines physically separated in a redundant data center setup. That's with markup from the data center selling it to you and the credit cost. After two-three years you own the hardware and can sell it if you want. A rig like this makes it rather easy to build HA-systems, have your devs experiment a bit with Ansible and keepalived and ProxySQL and they'll figure it out.
The beauty of Unix-like systems is that they're trivially discoverable and well documented. The clown platforms are not, and if your systems go down for whatever reason it's typically much harder and more labour intensive to get them back up again when they're clowned. This is especially the case if they get transfered to new management, e.g. due to bankruptcy proceedings. Paying a premium to get locked-in is a bad deal, unless you're the kind of organisation that is likely to also have mainframes in production.
That is super easy to do on AWS (and many other providers) but not so easy (or even impossible) anymore when you do things on-prem.
EDIT: due to the replies, let me clarify; this is not an argument for AWS specifically but for services that make it easy to spin up machines and that handle deployments and failover for you.
Also, there are more reasons to have more than one machine, e.g. being able to deploy with zero downtime and therefore without having to think when to deploy and what to do if a deployment fails etc.
You are absolutely correct
If someone has zero knowledge, then everything will take them a long time, including hosting on-prem or so.
Missing what point? You are apparently agreeing with me and disagreeing with the OP who said: "can run on a raspberry pi or mini PC".
This is what I objected to:
> And then, you probably want to do deployments in a way where you spin up 2 new machines and then, only once confirmed that the deployment works, shut down the old 2.
You don't need to spin up more machines or shut down machines. As long as you ensure you have the headroom you spin up containers and shut down containers. By doing that, it's also relatively easy to set up hybrid setups where you can handle load-spikes by scaling into EC2 or similar if you should ever need to.
Are you very sure you are not introducing potential additional problems with that approach? Because if you do, then I wouldn't say it's "not needed" to spin more additional machines - it would depend on those additional problems.
An hour? What happens if it breaks while I'm on vacation and no one is there to take care?
Nah, that argument might work sometimes but not in general.
What happens if you're on vacation and something breaks is that you call/email the DC and ask them to replace what's broken, same as if you were not on vacation. In my experience most DCs will have the replacement done in less than 30 min from receiving the ticket, good ones will do it in under 15. If the project is ran by more than one person, simply don't all take a vacation at the same time. Worst case scenario you point DNS to a free static page host that reads "Server broke. Working on a fix, check back tomorrow." (or the appropriate corporate-PR phrasing of the same if applicable) while you wait for the computer store to open so you can buy a new one.
Even if you are once-in-a-lifetime unlucky and the damn thing breaks while you're on vacation and for some reason your monitoring fails to notify you, big whoop. You can probably get away with just apologizing for the inconvenience and moving on. If a week long outage is enough to make or break your business, your business isn't gonna work out anyway.
This applies to practically all web projects from the home page of the pizza place on the corner of your street to 100-employee e-commerce sites. If a single machine can run it, it can probably run on a single machine. Use the dumbest tool that will get the job done, switch to a smarter tool when it won't.
If your business has an SLA with its customers, having a week long outage is going to break your business. Some contracts I saw had a 15 minute reaction time where you had to acknowledge the issue, and after 1 hour of downtime there are penalties. The same contract also required redundancy (of hardware, internet lines as well as location for the DCs). We could not have hosted that on a Raspi, or a single machine.
I don't think reducing the scale issue to "you ain't gonna need it" is right. Obviously to most projects it's not gonna be needed. But when it does and you need to grow, you'll be happy you have a redundant infrastructure that you can spin up/down easily instead of having to call your DC to ask for more hardware to be installed.
The answer might be to buy management services. Or an SLA for AWS.
If you're running an online shop/reservation system, a hour of downtime can be tens of thousands of lost revenue.
False. You can run kubernetes and/or some virtualisation engine as well and do the same on prem.
and overprovisioning physical hardware is much cheaper.
Can't do that with your own hardware unless it's also a Kubernetes cluster, which is a whole new set of crap you need to manage.
It’s as if an entire generation of tech workers are utterly unaware that these have been solved problems for decades.
You put two machines behind HAProxy with keepalived. If you want to do a new deployment, you can spin up new machines in the same manner, and cut them over (or any of the many other ways to accomplish this).
AWS isn’t inventing any of the HA stuff they offer; they’re taking existing technologies and packaging them.
I do agree that your projects should be designed to be well contained and easy to create a new instance of it, though.
Yet, for some reason, I see this repeated everywhere, always. Does it make the people who repeat it feel better? Are they actually informing anyone of anything? Who knows.
Granted, I'm sure the average engineer will be very relieved to find out they're paramount to production.
Go grab a similar server from Hetzner or something.
This is actually pretty apparent if you camp a web forum. People seem to either need a raspberry pi or a data center: this is the typical web-app vs mmorpg divide amongst possible computational fantasies people have. Questioning what motives people have is very sensible.
It's worth repeating, if only to raise awareness among devs that modern computers are _extremely_ fast. You can start a new one with commodity hardware and it will probably serve your needs for the lifetime of the project. If your project gets so popular/successful that you need more than a single machine, then I would hope by that point you know how to move it onto a cluster of machines, or into the cloud if the economics make sense.
I say "most web projects" because it's true - most web projects are simple CRUD apps in slightly different forms. Sure, there are some up-and-comers using AI to burn half a data center to produce fake comments and images for internet forums. Those won't run on a Pi or single mini PC. But people are making _so_ many web apps that will never see more than a few hundred or thousand users. Those don't need multi-instance load-balanced highly-available infinite-scaling systems to serve their users needs. That usually just adds cost and complexity until you're at a point where you _really_ need it.
The site was a blog with traffic of 1, load balancer, cloud run and storage bucket.
I shut it down. It was a nice exercise but not worth it to me long term.
Awesome, your 5 node Nutanix setup with 15 whole VMs is peaking at 5% of its total compute, 5% of its RAM, and 8% of its disk. Granted, I do work with medium sized businesses in the manufacturing sector, but so many get tricked into thinking they need 5 9s, when 3 is enough, and their setup isn't even providing 5 anyway because nothing else is downstream. Then 5 years later their warranty is up and they scrap it all and replace. It's crazy.
Kills me how many businesses contract this shit out and get tricked into spending a million on infra when they could just run 2 servers and pay a mid level engineer to manage it. "Not in the budget." Yeah, I wonder why.
(Started with proxmox but the installer’s kernel doesn’t have the Ethernet driver and they don’t provide WiFi because it’s stupid for the installed system - but they allow upgrading to a kernel which supports my adapter, so got a bit catch 22’d. Moved to Ubuntu server that would stop booting after creating a bridge interface because ‘waiting for network. no timeout’ and then a few more interesting issues.)
It has to do with the allround lunacy that surrounds the python ecosystem the moment you step outside the stdlib nursery. I picked up python because I wanted to contribute to a project. Was immediately met with ** of the first order.
After decades of C-like languages, I like (some of) the syntax. But I hate the ecosystem and having to ride a bullock cart after cruising in a plane. The language is slow. So all the critical work is done in C/Rust. And then you write python bindings for your library. Once that is available, you can "program in python."
The dependencies are a nightmare, particularly if you do anything LLM-related. Some libraries simply won't work with newer versions of the interpreter. After decades of Java, this came as a big surprise.
If it were not for uv, I might have given up on the language altogether.
I gave up on using GCP even though the products like BigQuery are way better just because I got burned too many times like with the Google Domains -> Squarespace transition.
I’m thinking of switching back to a bare metal provider now like Vultr or DO (would love to know what people are using these days I haven’t used bare metal providers since ~2012).
Also, completely unrelated does anyone know what the best scraping proxy is these days for side projects (data journalism, archiving etc.)?
Loving that German logic that even emergency maintenace has 2-week notification.
For "real" unplaned emergencies I had in total like 5min of downtime last year, when some other router died.
The article implicates AWS, but AFAICT the other major cloud, GCP, behaves similarly. The docs for "budget alerts"[1] do call it out directly,
> Setting a budget does not automatically cap Google Cloud or Google Maps Platform usage or spending. Budgets trigger alerts to inform you of how your usage costs are trending over time. Budget alert emails might prompt you to take action to control your costs, but they don't automatically prevent the use or billing of your services when the budget amount or threshold rules are met or exceeded.
But still. But wait, you say, those docs go on to suggest,
> One option to automatically control spending is to use budget notifications to programmatically disable Cloud Billing on a project.
And the linked page states,
> Following the steps in this capping example doesn't guarantee that you won't spend more than your budget.
sigh "Over-Engineered Messes", TFA hits it on the nose.
There's also limiting API usage, but that's on requests … not on cost.
I avoid it all for personal stuff.
At work, we pipe all these cloud bills into a BigQuery account which then pipes into graphs in Grafana, which all tells us that engineers have no idea what the actual horsepower of 3 GHz * 32 cores is when they request a bajillion more cores.
It's probably also reasonably categorized as an "Over-Engineered Mess".
(We also import Azure's billing data, and boy do they make that obnoxious. CSV files dumping into a bucket, and they might go back & edit CSVs, or drop new ones, and if there is there a schema for those CSV files … I've yet to find it. Some columns you might think were guaranteed non-"" are not. Dates in American. Severely denormalized. Etc.)
It works flawlessly for now, and costs almost zero, since the NAS is always on in any case, and Cloudflare is free.
These are all small projects of course, but two of them stayed on HN frontpage for a day and didn't break a sweat.
I agree with much of the sentiment, but I don't see how complex things you could possibly be making things if you're paying $1 a month ...
But it's also not really relevant to the main point of the article which is the risk of large surprise bills from eg runaway feedback loops and DoS attacks.
That said, I do wish you could hard shutdown at a certain budget limit.. but guess that is not in AWS’s best interested.
Making your payment method invalid doesn't absolve you of this debt and will just result in being sent to collections and/or sued if the total is large enough.
Couldn’t find an out-of-the-box solution, maybe, as you say because it’s not in their interest.
One day windows update bricks the system (hanging while trying to revert some security patch), and over a couple months from time to time I try random janky official azure recovery tools and voodoo from user forums with people who don't really know what they're doing either.
I notice my bill has crept up to several hundred dollars a month. Each of the recovery tools was cloning the system + disks, and I ended up with a bunch of disks that chewed up my bill.
I raised a support ticket and they refunded part of it with a bit of "you're a bad person", but wow... although the primary lesson I got here is that I never want to use windows again.
> I never want to use windows again.
Can't blame you :) I'm nearing the point of never wanting to use any computer again.
What I don't like about macOS is system components opacity, low UX customization (animation, windows management), The fact that UI elements are scaled as a whole with the desktop (can't change fonts to sensible values, unless the monitor is retina),... It's the console experience for a desktop computer.
For those who need AWS but want to avoid these surprises, there are ways to keep costs in check. Cost allocation tags, savings plans, and budget alerts help, but they require ongoing effort. Tools like SpendShrink.com can automate cost analysis and highlight savings opportunities before they become an issue.
It’s great to see more people looking for simpler hosting solutions, but for those who do need AWS, better cost visibility is a must.
No need to pay 9 cents per GB egress to the big clouds.
Still means the dynamic logic need to go elsewhere but for basic storage it works well for prepay
What kind of AWS setup leads to surprise bills? If your blog ends up on front page of HN how much is the traffic spike going to cost? $100? $1000? $10000?
Ofc I've seen the horror stories of recursive lambdas causing 1M+ in compute costs but for a small site I'm unsure what kind of issues we're talking about here...
If pages are mostly static doesn't a CDN make most of this go away?
You only need a single configuration wrong to get bankrupt overnight, and AWS has so many knobs that make a switchboard look like a toy.
I remember things like [1]. It’s very easy for something you don’t control go rogue, and AWS offers no protection for such scenarios.
1: https://www.behind-the-enemy-lines.com/2012/04/google-attack...
Wait! You just answered your own question, no?! Yes, the surprise is the amount on the bill. If I expect to pay 10$ for monthly, then 100 is about a year's worth I did not plan for, and 1000$ is a ton I never want to having to plan for.
After you factor that in most of the disasters of this type involving the cloud or home spun rust are easily explained away.
The former are missing skills that should have been beet into them by any decent education and the later is normally overwhelmed and in need of a team to replace them.
I’m a big AWS fan. I’d recommend any company of decent size to use AWS. But seriously, if your project is just a personal blog or some rails app you tinker with on the weekend, just get a $5/mo instance on Digital Ocean or a raspberry pi.
There are some mitigating things you can do, set limits on various resources and billing / budgeting alerts but fundamentally I don't think there's an easy way to avoid being on the hook for unexpected costs.
Theoretically you could have lambdas that react to billing alerts and shut things down but I've never seen anyone set that up.
Check out https://aws.amazon.com/free/
You’ll still need a Credit Card on file for overages.
It is similar with resume-driven architectures: let’s build an architecture of the place I want to work, instead of the one for where I do work.
[0] I won't go into detail here, but it mostly boils down to me working in a specialisation where what skills employers think they need is usually very different to what they actually utilise. If I get laid off tomorrow, I still need to pass an interview somewhere else.
I kinda want to move it to a self-hosted solution, but it's been working fine so far so why bother. Might need to log in and see if I need to update something someday.
So he doesn’t have the risk appetite for a DDOS attack nor the desire to figure out how to properly mitigate one. And this is AWS’s fault?
I'm also looking into using S3 glacier for my server backups. It appears to be the cheapest option.
On the other hand, doing single bare-metal boxes being much more complex and usually more expensive is a good reason to skip AWS for simple projects. In addition to the profusion of instance types and billing/usage options.
I also think the lack of options on limiting max billing for flexible services is pretty reasonable actually. For most of them, there's no single obvious reasonable thing to do when the money hits the limit. Storage costs money too, but I don't think much of anyone really wants to have their data get deleted when the cost hits the limit, for example.
It's really scummy. There's no reason not to allow me to set, eg, a 5-10x normal spend hard limit where they shut things off. For things like lambdas with accidental reflection (stop lambdaing), someone using your bandwidth to serve files (stop serving), a bug in a your Athena scripts that downloads a far broader date range than expected (stop all athena), etc.
That said while cost limiting vps option like lightsail exists on aws, they are on the high end of cost. Sure you get a good chunk of cpu time compared to the 15$ a year vps from questionable providers, but it's hard to beat that on price, especially for single user experiments.
I wouldn't store sensitive or pii data there, but most web sites aren't a ecommerce or a social either. And while I'm a huge aws fan, my minecraft and factorio servers and openwebui deployment are on some such cheap host at a discount provider. And never went down once. Or they did but I wasn't looking, which is the same tbh for single user stuff.
You can simply configure a single account, or multiple accounts, as you wish. You link sites to accounts so you can control both spending and risk (commonly you don't want site-A slashdotting to affect site-B). With a single account you can limit your financial exposure across multiple sites.
Perhaps refrain from commenting about things you are ignorant about.
I've been a NearlyFreeSpeech customer for many years and its a great service that I can highly recommend.