The Night My AWS Bill Almost Broke Me — And Why I’d Do It Again

Last Tuesday at 11:47 PM, I stared at the AWS Billing dashboard like it was a ticking bomb.
I’d just deployed a tiny AI-powered study buddy using Lambda, DynamoDB, and Bedrock, and somewhere in my code a loop was calling Claude every 3 seconds.
My free tier was suddenly very, very silent.

But before we get to my panicked console clicks, let me rewind.

I wanted something simple. I dump my messy engineering notes into a database, and an AI helps me revise — summarises, quizzes me, explains concepts I’ve scribbled half-asleep during lectures.
The architecture seemed straightforward: an API endpoint, a serverless function, a database, and Claude’s brain. I sketched it on the back of a notebook (the same notebook I should have been studying from) and thought, I’ll be done by dinner.

Dinner came and went. Then breakfast. Then dinner again.

My Lambda function kept failing with AccessDeniedException. I’d forgotten to give it permission to talk to Bedrock. Fixed that. Then DynamoDB threw the same tantrum. I’d allowed writes but not reads. Rookie mistake, but here’s what no tutorial taught me: IAM isn’t a setting you configure once. It’s the silent architect of your entire app. Every time two AWS services shake hands, IAM has to be invited to the handshake. Once that clicked, I started adding permissions like a paranoid parent locking doors.

But the real horror came when the app finally worked. I opened the frontend, asked a question about distributed systems, and got a beautiful answer. I was so excited that I left the tab open, testing again and again.

An hour later, my phone buzzed with a billing alert. I’d accidentally created a loop in the frontend that kept calling the API. Lambda was running, DynamoDB was reading and writing, and Bedrock was happily charging me for every token. I killed the endpoint at 11:52 PM, hands shaking.

Total damage? ₹47. Eighty cents.
But the fear was worth a million.

The next morning, I rebuilt the project with a throttle, a proper IAM role, and a sleep-deprived understanding of event-driven flow. And for the first time, I wasn’t just using AWS services — I was thinking with them.
Why Lambda instead of EC2? Because I wanted zero server management and didn’t want a machine idling when nobody was studying. Why DynamoDB? Because my data was simple key-value pairs and I didn’t need the overhead of a relational database. Why API Gateway? Because I knew I’d eventually need rate limiting and didn’t want to hack it into the Lambda itself.

Earlier projects had felt like following a recipe: “Add 1 EC2, a pinch of SSH, bake at port 80.” This time, I was the chef. And the dish was delicious — even if it nearly burned the kitchen down.

Chasing certifications and service counts is a trap. Nobody will ever ask you to list 200 AWS services in an interview. They’ll ask, “How would you build a low-cost, scalable API that uses AI to summarise notes?” And if your brain immediately starts picking services based on tradeoffs — not flashcards — you’re already ahead of 90% of graduates.

My note explainer is live now. A few friends use it during exam prep. It’s not perfect, it’s not pretty, but it’s mine — built, broken, and rebuilt by someone who finally understands that cloud isn’t about the services. It’s about stitching them together with purpose.