The pattern: an SMB sets up AWS five years ago to host one application. The application works. The bill is reasonable. Over time, services get added — a database, some storage, a couple of additional servers, monitoring, logs. Each addition is small. Nobody is alarmed.
Five years later the bill is $1,800/month and nobody can fully explain why. The application is roughly the same as it was. Traffic hasn't grown 4x. Yet the bill has. This is "cloud cost creep" and it's nearly universal among SMBs that have been on AWS or Google Cloud for more than two years.
The fix is finding and cutting the bloat. It's not one big thing — it's usually 5–10 small things that compound. After cleanup, most SMBs cut their cloud bill by 25–40% with no operational impact. This article is how to find that money.
Why cloud bills creep
Three main forces, in rough order:
1. Orphaned resources. Things that were created and then never deleted. An EBS volume from a server that was terminated three years ago. A load balancer for an app that was decommissioned. An S3 bucket from a developer who's left. Each costs $5–50/month, individually small. Cumulatively significant.
2. Logs and snapshots accumulating. Every cloud service generates logs. Every database has snapshot retention policies. Without explicit retention rules, these grow forever. A database that took 2GB to back up in year 1 might be holding 80GB of snapshots by year 3.
3. Auto-scaling that scaled up but never scaled back down. During a traffic spike six months ago, your application auto-scaled from 2 servers to 8. The traffic spike ended. The auto-scale-down policy was misconfigured (or never configured). You've been paying for 8 servers ever since.
These three causes account for 80% of cloud cost creep. The remaining 20% is over-provisioning, expensive service tiers no one questioned, and inefficient architectural choices made when the application was different.
How to use Cost Explorer
Cost Explorer is AWS's free tool for understanding your bill. Most SMB owners have never opened it. Even if you don't normally touch AWS, Cost Explorer is readable.
To get there: AWS Console → Billing → Cost Explorer.
Three views to look at:
View 1: Last 12 months by service
This shows what services are costing you money, broken down by month. Look for:
- Which services are the top cost lines? (Usually EC2, RDS, S3, then a long tail)
- Which services have grown the most over 12 months?
- Are there services you don't recognise?
The "services I don't recognise" line is often where money is leaking. If you see DataTransfer, NAT Gateway, or VPN charges that make no sense for your application, something is misconfigured.
View 2: Last 12 months by linked account
If you have multiple AWS accounts (common as projects sprawl), this shows which accounts are costing what. Sometimes the bill creep is concentrated in one account everyone forgot about.
View 3: Daily by service for the last 30 days
This catches anomalies. A service that's costing $40/day every day except for 3 days where it cost $400/day is interesting — figure out what happened on those days.
You don't need to be technical to use these views. Just look for patterns and anomalies.
The five things to cut first
In rough order of how often they're the biggest source of waste:
1. EBS volumes attached to terminated instances
When you terminate an EC2 server, AWS asks if you want to delete the attached storage volume. If you click no (or don't change defaults), the volume persists. It costs $0.10/GB/month for the most common type. A 100GB volume costs $10/month forever, doing nothing.
Where to look: AWS Console → EC2 → Volumes. Filter by state = available (means: not attached to any running server). Anything in this list is a candidate for deletion. Verify it's not attached to a running instance, then delete.
A typical SMB has 10–30 orphaned volumes accumulating $50–300/month.
2. RDS snapshots without retention policies
RDS (managed databases) automatically takes daily backups. The default retention is 7 days. But manual snapshots, snapshots from restored databases, and snapshots from deleted databases stick around forever.
Where to look: AWS Console → RDS → Snapshots. Look at the Manual tab. Anything older than 6 months that you don't have a specific reason to keep is waste. Delete after confirming.
A typical SMB has 20–100 unnecessary RDS snapshots costing $30–200/month.
3. Old S3 buckets and unused storage
S3 storage is cheap per GB but adds up. Common waste:
- Old log buckets that have collected gigabytes over years.
- Backup buckets where data was meant to be moved to Glacier (cheaper) but never was.
- Buckets created by old projects that are no longer needed.
- Versioning enabled on buckets where every save creates a new version, accumulating forever.
Where to look: AWS Console → S3. Sort buckets by storage size. The largest ones get scrutiny first. Set lifecycle policies to move old data to Glacier or Deep Archive (1/4 to 1/16 the cost), or delete entirely if you don't need it.
A typical SMB saves $30–200/month from S3 cleanup.
4. Load balancers and Elastic IPs not in use
Application Load Balancers and Network Load Balancers cost ~$20/month each just to exist, before any traffic. Elastic IPs cost $4/month each if not associated with a running instance.
Where to look:
- AWS Console → EC2 → Load Balancers. List all of them, identify which are actually in front of running services.
- AWS Console → EC2 → Elastic IPs. Filter by
Association ID = none. Each one is $4/month for nothing.
A typical SMB has 1–5 unused load balancers ($20–100/month) and 2–10 unassociated Elastic IPs ($8–40/month).
5. Over-provisioned EC2 instances
Servers that are larger than they need to be. A t3.large running at 5% CPU utilization could be a t3.small at 20% CPU utilization, paying half as much.
Where to look: AWS Console → EC2 → Instances. For each instance, click and look at the CloudWatch CPU metric. If average CPU is consistently below 20%, the instance is too big.
This is the riskiest item to cut — under-provisioning has consequences. The right approach: use AWS's Compute Optimizer (free, in the console) to get specific recommendations. Apply only after testing in a non-production environment.
A typical SMB saves 20–40% on EC2 by right-sizing, which is often $200–800/month at SMB scale.
What to leave alone
Some "savings" are traps:
Reserved Instances and Savings Plans. AWS pushes these heavily — commit to 1 or 3 years of usage in exchange for 30–60% discount. Tempting math, but only worth it if your usage is truly predictable. SMBs whose usage might change as the business pivots can lose more than they save by committing. Don't buy Reserved Instances for less than 80% confidence on a 12-month forward usage.
Switching providers entirely. "We could move from AWS to DigitalOcean and save 50%" is sometimes true but rarely net-positive after factoring migration cost, learning curve, missing services, and operational risk. Switch providers only when current provider is genuinely failing you, not just to save money.
Reducing redundancy. Cutting backups, removing replicas, moving from multi-AZ to single-AZ. Yes, these save money. They also dramatically increase your risk of data loss or outage. The savings aren't worth the risk for production systems.
Going serverless to "save money". Lambda + DynamoDB + API Gateway can be cheaper than EC2 for some workloads. They can also be dramatically more expensive for others. Migrating to serverless to save money is an architectural project, not a billing optimization, and it has high failure modes.
How to prevent recurrence
The cleanup catches up to where you are. Prevention keeps it from creeping back:
Set budget alerts
In AWS Billing, create a budget alert at 110% of your normal monthly spend. When you exceed it (which means something has changed), you get an email immediately, not at month-end when the bill arrives.
Tag everything
Every resource (EC2, RDS, S3) can have tags. Tag with Project, Environment, Owner. When you see a cost line, you can immediately tell what it's for and who owns it. Tag enforcement can be set up so untagged resources can't be created.
Quarterly cost reviews
15-minute review every 3 months. Cost Explorer → "What changed this quarter?" Catch anomalies before they compound.
Lifecycle policies on storage
S3 buckets should have lifecycle rules. Move logs older than 30 days to Glacier. Move logs older than 1 year to Deep Archive or delete. RDS snapshots: keep 30 days, delete older. EBS snapshots: keep 7 days unless tagged for retention.
Auto-scaling with proper scale-down
If you use auto-scaling groups, verify scale-down policies are working. After a traffic spike, do you actually scale back to baseline? Test it.
When to hire help
Cloud cost optimization scales with how much you're spending:
- Under $500/month total: cleanup is mostly self-service. The five steps above will catch most waste.
- $500–$5,000/month: a few hours of L3 help can save 25–40%. ROI is clear within a single bill cycle.
- $5,000+/month: a real cost optimization engagement (8–20 hours) often saves 30–50% with structured analysis. AWS partners specialize in this.
If you're in the second category, the Lead Steer monthly retainer covers L3 work including cost optimization. Most engagements pay for themselves in the first month's reduced bill.
What to do next
The companion articles cover other recurring L3 problems:
- Email Deliverability for SMBs
- Domain and DNS Disasters
- Building an L3 Tech Stack — including the monitoring that catches cost creep
---
Part of the Level 3 Tech Support pillar guide.