Stop Wasting Money on Cloud Cost Optimization

I had a client call me in a panic last Tuesday. Their AWS bill had doubled month-over-month. They hadn't changed traffic levels, they hadn't launched new features, but suddenly they were staring at a $12,000 bill for a month where they usually pay $6,000.

They asked me to do a deep dive into Cost Explorer. They wanted Reserved Instances. They wanted to talk to their account manager about discounts. They were ready to spend three weeks implementing a spot-instance orchestration layer.

I told them to turn off three ECS services. The bill dropped back to normal.

This is the trap I see engineering teams falling into constantly. We treat cloud cost optimization as a FinOps problem—something to be solved with spreadsheets, alerts, and complex purchasing strategies. We ignore that it is fundamentally a software architecture problem.

The Complexity Tax

We are building systems that are too complex for their actual workload. I see this constantly in the Bangkok startup scene. Founders read about microservices on HackerNews, and suddenly a team of three developers is managing thirty distinct services.

Every service you deploy has a hidden cost. It’s not just the compute. It’s the logging pipeline, the monitoring dashboards, the CI/CD pipelines, and the developer cognitive load. When you have fifteen microservices chattering over a network, you aren't just paying for the CPU cycles. You are paying for the latency, the retries, and the data transfer out of your VPC.

I recently took over a project where the previous team had architected a separate service just to generate PDF invoices. It was running on a t3.medium instance 24/7. I moved that logic into a Lambda function triggered by a database event. The cost went from $25 a month to literally pennies.

We didn't optimize the cost of the server. We deleted the server.

The 'Free Tier' Trap

Developers are addicted to managed services because they are easy to start with. Need a cache? Spin up ElastiCache. Need a queue? SQS. Need a pub/sub system? SNS.

These are great tools, but they are expensive at scale. A standard Redis instance on AWS might cost you $50/month minimum. A single-node RDS instance is easily $100+.

At Thea Tech Solutions, I default to Supabase for almost everything. Why? Because it gives me a Postgres database, Auth, and Edge Functions in a single package. I don't pay for data transfer between my database and my auth provider. I don't pay for the overhead of managing VPC endpoints.

But even within Supabase, I see people over-provisioning. They spin up a 4GB RAM instance for a blog that gets ten visitors a day. Just because it's scalable doesn't mean you need to scale it immediately.

Developer Productivity vs. Cloud Bills

There is a narrative that cloud costs are the price of developer velocity. "Let us use the expensive managed K8s cluster so we can ship faster."

This is often a lie.

I find that complex architectures slow me down. Debugging a distributed race condition across three Lambda functions and a queue takes ten times longer than debugging a monolithic function. When I build a Next.js app, I try to keep the logic close to the UI. If I can handle it in an API route instead of an external function, I do it. It keeps the codebase tighter and the cloud bill lower.

I was optimizing a React Native app recently that was polling an API every 5 seconds. The developer said it was necessary for "real-time" updates. We switched to WebSockets (via Supabase Realtime). The data transfer dropped by 90%, and the battery life on the test phones improved.

Optimizing for performance usually optimizes for cost.

My Practical Checklist

When I review a stack, I look for three things before I ever look at a pricing calculator.

Go to your console. Find resources that haven't received traffic in 30 days. Turn them off. If nobody complains in a week, delete them. You will be shocked at how many "dev" environments are left running at production capacity.

Do you really need a separate search service? Or can Postgres full-text search handle it for now? Do you need a dedicated CDN, or is Vercel's edge network enough? Every distinct service adds overhead.

This is the silent killer. Moving data from AWS to Cloudflare, or from your database to a client, costs money. I cache aggressively at the edge using Cloudflare Workers to prevent hits to my origin. It's significantly cheaper to serve a static asset from a cache than to query a database and render a view.

The Takeaway

If your cloud bill is high, don't start by tweaking your Reserved Instances. Don't install a cost-optimization bot. Start by looking at your architecture.

The most efficient code is the code you don't write. The most cost-effective server is the one you don't deploy. Simplify your stack, delete unused services, and keep your logic close to your data. Your wallet will thank you.