I was promised 15 years ago that cloud computing would avoid unexpected bills and provide consistent expenses that project managers love so much.
post
"Did you accidentally leave an unused function running? Too bad."
I enabled Cloudtrail to log all DynamoDB read/write data events when trying to troubleshoot an issue. Even though I only left this enabled for a few days, the Cloudtrail line item was $5k more than it should have been. My back of the napkin math with assumptions came out to be 100 times less than that, so I had a really awkward support email asking them to reverse the charges, which they did fortunately.
A lot of the times this comes down to a user error.
For example, very similar to your case, I knew someone that enabled Cloudtrail, and configured some things to have Cloudtrail logs dumped on S3. Guess what? Dumping things on S3 also creates a Cloudtrail that gets logged to S3 that Cloudtrail logs. Etc
Doing things like that and creating a loop can get you massive bills
Yeah, in my case, I wasn't familiar with the settings for Cloudtrail Data Events, and didn't realize you could select which events to log, based on the actor or resource, as opposed to all events in DynamoDB. That would have saved me a lot processing power to filter the logs to look for the actions I was looking for.
This is how I feel about vibe coding
“Claude can you help me with this”
“Sure, taking a look”
you’ve exceeded your allotted token limit
Oops.
I'm very new to programming and somehow have a job where I have to write Python scripts. Someone on my team mentioned that we use AWS and now I'm scared. Can someone explain how you accidentally rack up such a bill?
Just make sure whatever resources you spin up you're spitting down. This stuff though tends to happen when people accidentally let a a script that creates and destroys instances run over the weekend and it didn't appropriately clean up instances for you...
Or you thought you would try your hand at training in llm and then realized you spent way too much money on the infrastructure and resources
It's actually difficult. You can set a budget so AWS will alert you when you hit it.
They have a price calculator that'll calculate costs before you do anything.
Inbound Internet is free. Only outboard costs you anything.
Network transfers between VPC's using private links are free.
AWS accounts are free.
Lambda functions are ultra cheap as you only pay for the time you use it.
S3 is object storage with 11 9's of uptime and it's cheaper than any enterprise NAS.
Basically you'd have to setup something wrong and ignore it for weeks to incur a large bill.
You're gonna be fine. Honestly, if your team has given you permissions to do something accidental like this then it's on them. You're not gonna get stuck with the bill. You're not gonna get fired. It wouldn't be your fault.
It's really only scary when you're doing it solo with your own back information lol.
If you spin it up, fucking own it. When you're done with it, shut it down. I have long lost count of the number of times I've reached out to a team to ask about the coin miner they are running on some random EC2 instance only to find out that some jackass spun it up for a test, gave it a public IP, set the VPC to allow any inbound traffic, installed all kinds of random crap and then never updated it. Nor did it get shutdown when the test ended. So, a year and a half later, when the software was woefully out of date, someone hacked it and spun up a coin miner. Oh, and the jackass who set it up didn't bother to enable logging or security monitoring. But, they sure as hell needed the ability to spin stuff up on their own. Because working with IT to get it done right would be too hard for their fragile little ego.
AWS has a multitude of different offerings with confusing pricing structures. They have zero incentive to make them understandable.
That said, chances are your new company has people who understand this already and know how to manage it. Hopefully, they'll put up some guardrails that prevent you and others from running up a big bill. I wouldn't expect a junior programmer to know how to do this, but that's ok as long as the company is managed right. Granted, that can be a big if sometimes.
Can someone explain how you accidentally rack up such a bill?
For example: You can deploy your Python script as a Lambda. Imagine somewhere in the Python script you'd call your own lambda - twice. You basically turned your lambda into a Fork Bomb that will spawn infinite lambdas
That's why pay-as-you-go payment model is completely unfitting for the world of computers.
Prices can rack up dramatically without you noticing.
You can host your own AWS, Costs ALOTTTT LESS
You can't really host your own AWS, You can self-host various amalgamations of services that imitate some of the features of AWS, but you can't really self-host your own AWS by any stretch of the imagination.
And if you're thinking with something like localstack, that's not what it's for, and it has huge gaps that make it unfit for live deployment (It is after all meant for test and local environments)
Never used AWS but would it help to bake a daemon into your default OS image that shuts it down after 24 hours? That way you need to manually disable it for the ones you want to keep.
Usually what happens is people create lambda functions on AWS which are basically managed functions that get invoked when a request comes in (think a modern version of CGI), and then if there are a lot of requests then the user can easily end up with a huge bill.
Damn.
I suppose the obvious question of why Amazon doesn't have an intuitive way of rate limiting those can be answered by the huge bills people rack up.

all 31 comments