7 Cloud Cost Red Flags That Mean You're Overspending

What it looks like: Cloud spend increases month over month, but active user count, request volume, or data processed stays roughly flat. The bill has decoupled from business activity. This is one of the clearest signals in cloud finance — and one of the most commonly ignored.

Why it happens: New resources get provisioned for projects, experiments, or feature flags — and never cleaned up. Infrastructure added for a traffic spike or a launch keeps running long after the event ends. Nobody owns the cleanup because the cost is spread across many line items and no single number is large enough to trigger a review.

How to find it: Pull your last six months of billing data and plot total spend against a usage metric that matters to you: requests, active users, GB processed. If spend climbs while the usage line is flat, you have orphaned resources accumulating. AWS Cost Explorer's "cost by service over time" view makes this visible in about 5 minutes. No extra tools required.

How to fix it: Tag every resource with a project and owner at creation. Set up a monthly cost review comparing spend-per-unit across your key services. Any service where cost-per-unit rises without a business reason is a candidate for rightsizing or termination. The tagging step is the one most teams skip — and it is the one that makes everything else easier.

Estimated savings: Teams that implement resource tagging and monthly spend-per-unit reviews typically find 15–25% of their bill is attributable to resources with no active workload (Flexera, 2025).

What it looks like: When asked "what are we spending the most on?", the honest answer is "EC2, probably, and then... not sure." Nobody on the team has a clear, current picture of the cost breakdown by service, team, or workload.

Why it happens: According to Harness's 2025 FinOps in Focus survey, 55% of developers base cloud purchasing decisions on guesswork, and only 33% can identify which workloads are overprovisioned (Harness, 2025). Without cost allocation tags and a regular review cadence, the bill is a number — not actionable information. That gap between cost and clarity is where waste hides.

How to fix it: You should be able to name your top 3 cost drivers in under 60 seconds. If you cannot, that is the first thing to fix. Open AWS Cost Explorer or Azure Cost Analysis, group by service, sort by month-to-date spend. Do this once. Then schedule it as a 10-minute monthly habit — it does not need to be more complex than that.

Estimated savings: Teams that establish basic cost visibility consistently surface 10–20% in quick-win savings within the first 30 days — not because they do anything complex, but because awareness alone changes provisioning behavior.

What it looks like: Unexpected spend is discovered when the invoice arrives at month-end. No alerts are configured for daily spend anomalies, budget thresholds, or service-specific spikes.

Why it happens: Setting up billing alerts feels like overhead when moving fast. It is a one-time task that never feels urgent — until a runaway process, a misconfigured service, or an accidentally-public S3 bucket triggers an unexpected charge. By then the damage is done and the month has closed.

What a $20,000 surprise looks like: A developer leaves a GPU instance running over a long weekend. An API response gets accidentally cached to S3 in a loop. A NAT Gateway starts processing traffic from a misconfigured route. Without alerts, none of these are visible until the monthly bill closes.

How to fix it: AWS Budget alerts take 5 minutes to configure. Set three: a monthly budget alert at 80% and 100% of expected spend, plus an anomaly detection alert (AWS Cost Anomaly Detection is free). On Azure, use Cost Management budgets with email alerts. These do not prevent overspend — but they compress time-to-detection from 30 days to hours.

Estimated savings: Billing alerts do not directly save money. They reduce the blast radius of incidents. Teams with active anomaly detection catch runaway charges within hours instead of weeks — the difference between a $200 incident and a $20,000 one.

What it looks like: Your staging environment is a near-clone of production and runs around the clock, even though the team uses it for roughly 8 hours a day, 5 days a week. Dev environments spin up for feature branches and never get torn down. This pattern is nearly universal on teams that have not explicitly addressed it.

Why it happens: Always-on is the path of least resistance. Starting an environment takes time. Nobody wants to wait when they need to test something quickly. So environments stay running indefinitely. The cost is diffuse — spread across EC2, RDS, load balancers, and NAT Gateways — and no single line item is large enough to trigger a review.

The math: A staging environment mirroring a modest production setup — 4 x m5.xlarge instances, an RDS db.t3.medium, a load balancer — runs roughly $800–$1,200/month on-demand (AWS pricing docs, 2025). That same environment, scheduled to run only during business hours (Mon–Fri, 8am–6pm), costs about $240–$360/month. A 70% reduction for a one-time scheduler setup.

How to fix it: Use AWS Instance Scheduler or a Lambda + EventBridge rule to stop non-production instances outside business hours. For Kubernetes, tools like Kube-downscaler scale staging namespaces to zero on a schedule. The most effective long-term pattern is infrastructure-as-code with ephemeral environments per PR, torn down on merge — but the scheduler approach delivers most of the savings in one afternoon.

Estimated savings: 60–75% reduction in non-production environment costs. For teams spending $2,000+/month on staging and dev, that is $1,200–$1,500/month recovered from a few hours of setup.

What it looks like: Your production database, core application servers, and other baseline infrastructure have been running continuously for 6+ months — all on on-demand pricing. No Reserved Instances. No Savings Plans. No committed-use discounts. Every month you pay the highest possible rate for infrastructure that is not going anywhere.

Why it happens: Reservations feel risky. Teams assume they might scale down, switch instance types, or migrate providers. So they stay on on-demand "for flexibility" indefinitely. According to Harness (2025), 58% of developers have not adopted reserved pricing at all. The flexibility rationale is real — but AWS Compute Savings Plans largely nullify it.

The actual risk is low: AWS Compute Savings Plans apply to any EC2 instance regardless of family, size, OS, or region. You are not locked into a specific instance type. If your baseline compute spend has been stable for 3 months, a 1-year no-upfront Compute Savings Plan is a commitment with minimal downside. Break-even is immediate from month one.

How to fix it: In AWS, go to Cost Explorer → Savings Plans recommendations. It shows exactly how much you can save based on your last 30 days of usage and suggests a commitment amount. The typical recommendation for a stable workload: a 1-year no-upfront Compute Savings Plan covering 80% of baseline. On Azure, use Reserved VM Instances or Azure Savings Plan for Compute. On GCP, sustained-use discounts apply automatically — but committed-use discounts add another 55–70% for 1-year commitments (GCP pricing docs, 2025).

Estimated savings: 1-year reserved pricing saves 30–40% over on-demand. 3-year commitments save 60–72% (AWS pricing docs, 2025). For a team spending $3,000/month on stable EC2, that is $900–$1,200/month recovered with no architectural changes.

What it looks like: Your AWS console has EBS volumes in the "available" state (not attached to any instance), load balancers with zero healthy targets, Elastic IP addresses not associated with running instances, and RDS snapshots from databases that no longer exist.

Why it happens: Cloud resources outlive the workloads they were created to serve. An EC2 instance is terminated but its EBS volume persists. A deployment switches to a new load balancer but the old one is not deleted. A database is replaced but the manual snapshots remain. Each individual resource is inexpensive. Collectively, they accumulate into meaningful monthly charges.

The per-unit costs that stack up (AWS pricing docs, 2025):

• EBS gp3 volume: $0.08/GB/month — a 100 GB orphaned volume costs $8/month and does nothing
• Application Load Balancer: $0.008/LCU-hour + $16.43/month minimum — an idle ALB with no targets costs ~$20/month
• Elastic IP (unassociated): $0.005/hour = $3.65/month per address
• NAT Gateway (idle): $0.045/hour = $32.40/month even with zero traffic

None of these individually triggers alarm. A team with 20 orphaned EBS volumes, 3 idle load balancers, 5 stray Elastic IPs, and 2 idle NAT Gateways is paying roughly $300–$500/month for nothing.

How to fix it: AWS Trusted Advisor (free tier) flags unattached EBS volumes and idle load balancers. AWS Cost Explorer's resource view surfaces Elastic IPs not associated with running instances. For a deeper sweep, tools like Cloud Custodian or a monthly Terraform state audit will catch resources that have drifted out of IaC management entirely. For a detailed breakdown of how overprovisioning compounds over time, see our guide on cloud waste and overprovisioning.

Estimated savings: Teams doing a first-time idle resource sweep typically find $200–$800/month in recoverable costs. A quarterly sweep after that keeps this category close to zero.

What it looks like: You open your billing breakdown and see "Data Transfer" or "Bandwidth" at 15%, 20%, or more of total monthly spend. It may be spread across EC2 data transfer, NAT Gateway processing charges, inter-region replication, or CloudFront origin pulls.

Why it happens: Data transfer pricing is complex. AWS alone has dozens of transfer pricing tiers depending on source, destination, and direction (AWS pricing docs, 2025). Traffic between Availability Zones costs $0.01/GB in each direction — a small number that compounds fast in microservice architectures where services in different AZs call each other on every request. NAT Gateway adds $0.045/GB processed on top of standard egress. The combination is rarely anticipated at design time.

Common sources of excess data transfer cost:

• Cross-AZ traffic in microservices: Services in different AZs calling each other on every request. At $0.02/GB round-trip, a service handling 10 TB/month of inter-AZ traffic pays $200/month just for that leg.
• NAT Gateway processing large payloads: If your workloads pull large objects from the internet through a NAT Gateway (S3 via NAT instead of a Gateway Endpoint, for example), you're paying $0.045/GB to process traffic that could be free.
• Egress to users without a CDN: Serving assets directly from EC2 or S3 costs $0.09/GB. CloudFront's first 10 TB/month costs $0.085/GB — marginally cheaper, but the real saving is from caching, which can reduce origin egress by 60–80%.
• Cross-region replication: Replicating S3 data, RDS snapshots, or DynamoDB tables across regions for DR purposes at full egress rates.

How to fix it: Run a VPC Flow Logs analysis to identify your top traffic flows. The two highest-ROI fixes are: (1) add VPC Gateway Endpoints for S3 and DynamoDB — free to use, eliminates NAT Gateway processing charges for those services immediately; and (2) co-locate services that call each other heavily in the same AZ, or use AZ-aware routing. See our cloud egress costs guide for a full breakdown.

Estimated savings: Adding VPC Gateway Endpoints for S3 and DynamoDB is free and takes effect immediately. Reducing cross-AZ traffic through AZ-aware service placement cuts inter-AZ charges by 50–80%. Teams with data transfer above 15% of their bill typically recover 8–12% of total monthly spend from these two changes alone. Once you have identified these red flags, our cloud cost optimization checklist gives you a step-by-step process to work through each one.