Why Your Cloud Bill Goes Up Every Month (Even When Traffic Doesn't)

Zombie resources account for a significant share of the 27% average cloud waste (Flexera, 2025). A zombie is anything provisioned for a purpose that no longer exists: a staging environment for a feature that shipped six months ago, an Elastic IP attached to a terminated instance, an RDS snapshot from a database you migrated away from, a load balancer pointing at nothing.

They were never explicitly deleted — just forgotten. Cloud providers charge for existence, not use. An unattached 100 GB EBS volume costs around $10 per month (AWS EBS pricing, 2025) whether it holds critical data or a three-year-old test database nobody remembers.

Most teams add two or three new zombie resources per sprint. Almost none audit for them regularly. After six months without a cleanup, you can easily have 15–20 idle resources adding $50–$150/month for no reason. The cost compounds every sprint you skip the audit.

The fix: Run a zombie audit monthly. In AWS, filter EC2 Volumes by "State = available" (unattached). Check EC2 → Elastic IPs for any address not associated with a running instance. In Azure, filter resources by tag and flag anything missing an "owner" or "project" tag. Delete what you can't justify keeping.

CloudWatch Logs default retention is "Never expire" — every log line your application has ever written is sitting in storage, accruing charges at $0.03 per GB per month (AWS CloudWatch pricing, 2025). That sounds trivial. It isn't. A moderately active application generates 5–20 GB of logs per month. After one year with no retention policy, one log group alone might cost $3.60–$7.20/month. Multiply across ten services and it's real money.

EBS snapshots follow the same pattern. Snapshot frequently for disaster recovery — correct practice. But if you keep 90 daily snapshots of a 500 GB volume without a deletion policy, you may be paying for 50–100 GB of stored snapshot data at $0.05 per GB per month (AWS EBS pricing, 2025). A snapshot policy without a deletion policy is a slow, quiet money leak.

The fix: Set a retention policy on every CloudWatch Log Group. 30 days works for most application logs; 90 days for audit-relevant logs. Bulk-apply via the AWS CLI: aws logs put-retention-policy --log-group-name /your/group --retention-in-days 30. For EBS snapshots, use AWS Data Lifecycle Manager to automatically expire snapshots beyond your retention window.

Data transfer costs grow as your product matures — more API calls, more cross-service communication, more data flowing between regions and out to users. Nobody notices because per-request cost is fractions of a cent. The aggregate moves the bill $20–$80 per month over the course of a year.

AWS charges $0.09/GB for internet egress (after the first 100 GB/month free). Cross-AZ traffic is $0.01/GB each direction. That second number looks small. It isn't. A service making 10 million small API calls across availability zones daily — 2 KB per response — generates about 20 GB of cross-AZ transfer per day, roughly $6/month. Add a second service and you're at $12/month. Add database replication across AZs and it's a genuine line item.

The fix: Open AWS Cost Explorer, group by "Usage Type," filter for "DataTransfer." Find which services generate the most transfer. Common wins: place services in the same AZ as their primary dependencies, use S3 Gateway Endpoints to bypass NAT Gateway fees, cache aggressively to reduce downstream call volume. For a deeper look, see our cloud egress costs guide.

In February 2024, AWS began charging $0.005 per hour for every public IPv4 address, whether attached to a running instance or not — $3.65 per IP address per month (AWS, 2024). This is the clearest example of how provider price changes silently inflate bills: they don't announce them prominently, and they don't require any action on your part to start paying.

A small team with four or five services, each with its own Elastic IP or load balancer public IP, saw $14–$18 appear on the February 2024 bill and every bill since — for zero change in infrastructure. Ten public IPs: $36.50/month of pure price increase.

Google Cloud made a similar move in 2024, charging for external IPs on stopped VMs. Azure has charged for unattached public IPs for years. All three major providers are now taxing IPv4 use to encourage IPv6 migration. That migration isn't fast or free, so most teams absorb the cost without realizing it arrived.

The fix: Audit your public IPs. In AWS, EC2 → Elastic IPs — any IP not associated with a running instance costs the same as an attached one. Release what you don't need. Services behind a load balancer typically don't need individual public IPs. Subscribe to your provider's pricing announcements so the next change doesn't catch you off guard.

Most teams configure scale-up policies carefully and treat scale-down as an afterthought. The result: infrastructure that adds capacity aggressively during load spikes and then holds it indefinitely.

A real example: an ECS service configured to scale from 2 tasks to 8 when CPU exceeds 70%. Traffic spikes during a product launch. Service scales to 8 tasks. Launch ends. Traffic normalizes. But the scale-down policy requires CPU below 30% for 15 consecutive minutes before reducing, with a 300-second cooldown. The service stays at 8 tasks far longer than needed. Over a month of periodic spikes, average running tasks stay at 5–6 instead of the optimal 2–3. That's 3–4 extra tasks running every hour, every day.

At $0.04048 per vCPU-hour for Fargate, two extra 1-vCPU tasks cost about $58/month. Four extra tasks: about $116/month (AWS Fargate pricing, 2025). This happens automatically and invisibly. Most teams don't notice until they compare month-over-month spend during an engineering review.

The fix: Review both scale-up and scale-down thresholds. Check CloudWatch metrics for your scaling groups — look at actual utilization vs. provisioned capacity. Switch to target tracking scaling policies instead of step scaling. They adjust in both directions based on a target metric, making scale-down behavior automatic and predictable.

Dev and staging environments are only useful when someone is actively working. They almost always run 24/7 anyway — turning them off is annoying, and there's a small fear of forgetting to restart them. The cost of that friction is substantial.

A typical staging environment: 2x t3.medium EC2 ($60/mo) + 1x db.t3.medium RDS ($55/mo) + 1x cache.t3.micro ElastiCache ($15/mo) = roughly $130/month for an environment that sits idle 60–70% of the time. Four engineers with persistent dev environments at similar scale: $200–$400/month on infrastructure used fewer than 40 hours a week.

The fix: Use AWS Instance Scheduler or a Lambda cron to stop non-production EC2 instances and RDS databases outside business hours. Stopping at 7pm and restarting at 8am on weekdays cuts runtime from 720 hours/month to about 240 hours — a 67% reduction in compute costs for those resources. For short-lived feature testing, ephemeral environments created by CI/CD and destroyed when a PR closes are the most cost-efficient option.

Most cloud free tier benefits expire after 12 months. The services that cost nothing in year one quietly start billing on month 13 — no warning email, no bill spike with an obvious label.

AWS Free Tier includes 750 hours/month of t2.micro EC2, 750 hours/month of db.t2.micro RDS, 5 GB of S3 standard storage, and 1 million Lambda invocations — all for 12 months. On month 13, EC2 hours start billing at roughly $8.50/month, RDS at roughly $13/month, S3 at $0.023/GB. The same setup that cost nothing in year one can suddenly cost $25–$50/month more, with no architectural change (AWS Free Tier terms, 2025).

Azure free tier: 750 hours/month of B1S Linux VMs, 250 GB of SQL Database — free for 12 months, then standard rates. Google Cloud's "Always Free" tier has no expiration, but their 90-day $300 credit runs out mid-project, creating a sudden jump teams often attribute to usage growth.

The fix: Note your cloud account creation date. Set a calendar reminder for month 11. Review which services you rely on under the time-limited free tier. Either optimize to stay within Always Free limits (AWS Lambda's 1 million requests/month never expires) or budget for the increase before it hits. AWS provides a Free Tier usage tracker in the billing console showing how close you are to each limit.

None of the seven causes are hard to fix individually. The challenge is that they require ongoing attention. You need to catch zombie resources before they accumulate, set retention policies before logs spiral, and review auto-scaling behavior before it runs unchecked for three months. That means building a regular review habit — or using tooling that does it for you.

Monthly: the 20-minute review

Once a month, before your invoice closes, run four checks. (1) Cost Explorer grouped by Service, compared to the prior month — investigate any service with more than 10% unexplained growth. (2) EC2 Volumes filtered for unattached, and Elastic IPs for unassociated addresses. (3) CloudWatch Log Groups — confirm every group has an explicit retention policy. (4) Spot-check your largest auto-scaling groups and verify actual utilization tracks close to provisioned capacity.

Set budget alerts that actually fire

AWS Budgets is free. Set alerts at 80%, 100%, and 120% of your expected monthly spend. Most teams set one threshold and forget it. The 80% alert is informational. The 100% alert confirms you're on budget. The 120% alert is the one that catches the creep. Calibrate thresholds to your actual expected spend — an alert set to $5,000 on a $500/month account will never fire until it's far too late.

Tag everything with an owner and expiry

The most effective defense against zombie resources is a mandatory tagging policy. Every resource gets an "owner" tag and an "expires" or "project" tag. Resources missing an owner tag get flagged for review. Resources with an "expires" date in the past get deleted automatically. Implement this with AWS Config Rules or Azure Policy. The teams that do this consistently report far lower zombie accumulation over time.

Schedule non-production environments off

Stop non-production instances at 8pm, restart at 7am on weekdays. That cuts runtime from 720 hours/month to about 250 hours — a 65% reduction in compute costs. AWS Instance Scheduler is a free CloudFormation template. Takes about an hour to set up. Pays for itself in the first month.

Cloud bill creep is predictable and preventable. Infrastructure runs until you tell it to stop, and most teams don't have a systematic process for doing that. Building one is the difference between a bill that reflects actual usage and one that grows $50–$200/month for no reason. For AWS-specific diagnosis, see our guide to diagnosing a high AWS bill. For warning signs of overspending, see our post on cloud cost red flags.

To put dollar figures behind these checks, SpendArk's free cloud cost calculator lets you model your setup across AWS, Azure, and GCP and see what trimming waste would save — before you change anything. It's free and needs no account.