I still remember the Slack message. It just said, “did anyone see this month’s AWS invoice?” with a screenshot attached, and three separate people replied with the skull emoji. We had launched six weeks earlier, things were going fine, and somehow our bill had went up by nearly 40% without anyone doing anything that felt like a decision. Nobody had approved this. It just… happened.
That’s the thing nobody tells you about cloud costs — they don’t jump up all at once; they slowly increase. and by the time you notice, you’re three months into paying for stuff you forgot existed. So, we spent a weekend (a real weekend, coffee and mild dread) going through everything, and honestly, most of the extra costs were super easy to avoid. Here’s what actually worked for us.
We were paying full price for an instance doing nothing
It’s so easy to buy bigger, more expensive servers “just in case.” You get worried about your app crashing when lots of people visit at once—kind of like the heavy traffic you’d see on a live-streaming app or a busy casino online platform.
We fell right into this trap. We were running a beefy m5.xlarge server for a background service that barely used 15% of its brain power, even on its busiest days. Once we realized this, we switched to a smaller t3.medium instance and set it to scale up only when needed. Just like that, we cut that cost by more than half, and the app ran just as fast as before.
The funny thing is, AWS has a free tool called Compute Optimizer that was telling us to do this all along. But like most people, we completely ignored the warning until a huge bill forced us to pay attention.
Savings Plans felt like something “real companies” did
I thought long-term discounts were only for huge companies, not a four-person team. I was wrong. Signing up for a 1-year Savings Plan cut our main database and API costs by about 30% overnight. Just make sure you only pay ahead for what you always use. Don’t guess your highest traffic— buy only for your lowest daily usage.
S3 has more than one setting, apparently
This one made me feel a little dumb. We had months of old logs and backups stored in S3 Standard—the highest cost option—simply because it was the default setting and nobody ever changed it. Setting up a quick rule to move files to cheaper storage after 30 days, and deep archive after 90, took under five minutes. It’s been quietly saving us cash ever since. Set it up once and really forget it.
Tagging is boring until it saves your afternoon
For a long time, our tag system was just whatever an engineer felt like writing. That meant our cost reports basically said, “you spent money somewhere on something.” Super helpful. Once we started using clear tags for teams, environments, and projects, we realized our test environment was costing more than our actual live app. Nobody noticed because nobody could see it. Do this early, before fixing hundreds of messily tagged resources becomes a nightmare.
Zombie resources are real and they are everywhere
Old EBS volumes with nothing attached to them. A load balancer nobody remembers creating. A network gateway from a proof-of-concept that shipped eight months ago and was never cleaned up. None of these show up as “big” line items individually, which is exactly why they survive so long. We now do a monthly check— thirty minutes, one person, Cost Explorer and Trusted Advisor open side by side— and it consistently turns up a few hundred dollars a month in stuff that’s just… sitting there, billing us, for no reason.
None of this was hard. We just weren’t looking.
That’s honestly the main lesson. We don’t need to hire experts or buy extra tools to fix this. We just need to check our costs regularly, just like you check for app errors or slow speeds, rather than waiting for a scary invoice.
We still run into unexpected costs occasionally. But it’s much rarer now, and it’s a small issue instead of a panic moment. The goal isn’t perfection—it’s just staying informed so our monthly bill doesn’t catch you off guard.
