You opened your AWS, GCP, or Azure invoice and the number is three times what it was six months ago. You are not alone. Cloud costs have a way of creeping up quietly and then hitting you all at once. Auto scaling provisions more capacity than needed. Developers spin up resources for testing and forget to tear them down. Storage accumulates because nobody has a retention policy. And the default configurations for most managed services are tuned for convenience, not cost efficiency.
The good news: you can typically reduce cloud costs by 40 to 70 percent without rearchitecting your application or switching providers. The bad news: it requires methodical work, not magic. We have done this for enough clients to have a reliable playbook.
Step 1: Get Visibility Into What You Are Actually Spending
Before optimizing anything, you need to understand where the money is going. Most teams we work with cannot answer the question "what is your most expensive service" without checking. That is the first problem.
Enable detailed billing and cost allocation tags. Every major cloud provider supports tagging resources by environment (production, staging, development), team, and purpose. If your resources are not tagged, start there. You cannot optimize what you cannot measure.
Set up a cost monitoring dashboard. AWS Cost Explorer, GCP Billing Reports, and Azure Cost Management all provide this. We also recommend third party tools like Vantage or Infracost for more granular analysis. Set up weekly email reports so that cost spikes are caught within days, not months.
Break costs down by category. The typical breakdown we see is:
- Compute (EC2, Cloud Run, App Service): 35 to 50 percent of total spend
- Databases (RDS, Cloud SQL, Cosmos DB): 15 to 25 percent
- Storage (S3, GCS, Blob Storage): 5 to 15 percent
- Data transfer: 5 to 15 percent
- Everything else (load balancers, DNS, monitoring, etc.): 10 to 20 percent
Knowing this breakdown tells you where to focus. Optimizing compute when storage is your real problem is a waste of time.
Step 2: Kill the Zombies
Every cloud account we audit has zombie resources: things that are running, costing money, and doing absolutely nothing. Here are the most common offenders:
Unused EC2 or VM instances. Development servers, old staging environments, servers from a proof of concept that ended 8 months ago. We routinely find 3 to 10 instances per account that nobody is using. At $50 to $500 per month each, this adds up fast.
Unattached storage volumes. When you delete an EC2 instance, the EBS volume often stays behind. We have seen accounts with dozens of unattached volumes totaling terabytes of storage that serves no purpose.
Old snapshots and backups. Snapshots are useful. Snapshots from 2 years ago of instances that no longer exist are not. Implement a retention policy: keep daily snapshots for 7 days, weekly for 30, monthly for 90, and delete everything older.
Idle load balancers. Application Load Balancers on AWS cost about $22 per month even with zero traffic. If you have load balancers with no targets or no traffic, delete them.
In our experience, zombie cleanup alone reduces cloud bills by 10 to 20 percent. It is the easiest win and requires no code changes.
Step 3: Right Size Your Compute
Over provisioned compute is the single biggest source of cloud waste. The pattern is predictable: someone chose a large instance type during development because performance was not great, the problem turned out to be a database query, but nobody went back to downsize the instance.
Check CPU and memory utilization. If your average CPU utilization is below 20 percent and memory utilization is below 40 percent, you are over provisioned. Most applications run fine at 60 to 70 percent average CPU with headroom for spikes.
Move from on demand to reserved or savings plans. If a workload runs 24/7 and is not going away, reserved instances or savings plans offer 30 to 60 percent discounts compared to on demand pricing. For a $10,000 per month compute bill, that is $3,000 to $6,000 in monthly savings.
Use spot or preemptible instances for fault tolerant workloads. Background jobs, batch processing, CI/CD runners, and development environments can all run on spot instances at 60 to 90 percent discounts. Yes, they can be interrupted, but if your workload can handle restarts, the savings are enormous.
Consider ARM based instances. AWS Graviton and GCP Tau T2A instances offer 20 to 40 percent better price performance than equivalent x86 instances for many workloads. If your application runs on containers or does not have x86 specific dependencies, this is a straightforward migration.
We wrote a detailed guide on reducing AWS cloud costs that covers these compute optimizations and more.
Step 4: Optimize Your Database Spend
Databases are often the second largest line item, and they are frequently over provisioned because nobody wants to be the person who under sized the production database.
Right size the instance. The same CPU and memory analysis applies here. If your RDS instance averages 15 percent CPU, you are probably running a db.r6g.xlarge when a db.r6g.large would suffice, saving roughly $200 per month.
Use read replicas strategically. If your application is read heavy (most are), offloading read traffic to cheaper read replicas can let you downsize the primary instance. This also improves performance.
Review your storage type. Many teams provision io1 or io2 storage (high performance SSD) when gp3 would work fine. The price difference is significant: gp3 costs $0.08 per GB per month versus $0.125 for io1, plus io1 charges per provisioned IOP.
Implement connection pooling. Applications that open and close database connections frequently waste resources. A connection pooler like PgBouncer (or Supabase's built in pooler) reduces the number of active connections your database needs to handle, which often lets you downsize the instance.
Step 5: Control Data Transfer Costs
Data transfer is the hidden killer of cloud budgets. Downloading data from the cloud (egress) is expensive: AWS charges $0.09 per GB for the first 10 TB of internet egress. If you are serving large files, streaming video, or running a CDN origin from S3, these costs accumulate.
Put a CDN in front of everything public facing. CloudFront, Cloudflare, or Fastly will cache your static assets and serve them from edge locations. This reduces both egress costs and latency. CloudFront data transfer is cheaper than direct S3 egress, so it often pays for itself even before the performance benefits.
Use VPC endpoints for internal traffic. Traffic between your services and AWS managed services (S3, DynamoDB, SQS) that crosses the public internet incurs data transfer charges. VPC endpoints route this traffic privately at no per GB cost.
Compress everything. Enable gzip or brotli compression on your web servers and API responses. This reduces data transfer volume by 60 to 80 percent for text based content.
Step 6: Implement Cost Governance
Optimization is not a one time project. Without governance, costs will creep back up within 6 months. Here is what we set up for clients:
Budget alerts. Set alerts at 50, 75, and 90 percent of your monthly budget. Better to get an annoying email at 50 percent than a terrifying one at 110 percent.
Automated shutdown of non production resources. Development and staging environments do not need to run 24/7. Scheduling them to shut down overnight and on weekends can cut those costs by 65 percent.
Tagging enforcement. Use cloud policies to require tags on all new resources. Untagged resources should trigger alerts and eventually be flagged for deletion.
Monthly cost reviews. Dedicate 30 minutes per month to reviewing cloud costs with your engineering lead. This small investment prevents the slow drift that turns a $5,000 monthly bill into a $15,000 one.
When to Consider Bigger Changes
Sometimes cost optimization is not enough. If your architecture is fundamentally wasteful, like running dedicated servers for workloads that could be serverless, or using a Kubernetes cluster for an application that gets 100 requests per minute, the right answer might be architectural changes.
The comparison between serverless and Kubernetes is relevant here. We have seen companies cut their hosting costs by 80 percent by moving bursty workloads from always on containers to serverless functions. Similarly, the choice between Vercel and AWS can dramatically affect costs for web applications.
But these are bigger decisions that require careful planning. Start with the optimization steps above. They require no architectural changes and deliver results within weeks, not months.
Getting Expert Help
Cloud cost optimization is a specialty. The engineers who build your application are focused on features and reliability, not on reading pricing pages and configuring savings plans. A focused engagement with a team that has cloud and DevOps expertise typically pays for itself within the first month through identified savings.
If your hosting bill has gotten out of control and you need it fixed without disrupting your application, reach out to us. We will audit your infrastructure, identify the quick wins, and give you a roadmap for sustainable cost management.