Cloud bills don't spiral overnight — they creep. A forgotten dev environment here, an over-provisioned database there, a "temporary" on-demand instance that's been running for two years. By the time finance sends the escalation email, you're already six months into the problem. Here are five signs your cloud spend has gotten away from you.
1. Your Cloud Bill Surprises You Every Month
If your first response to seeing the monthly AWS or GCP invoice is to open a spreadsheet and try to figure out what changed, your cloud spend is already out of control. Not because surprises are inherently bad — but because they signal a fundamental lack of visibility into your own infrastructure.
Predictable cloud bills don't come from luck. They come from understanding your cost drivers well enough to project them forward. When teams can't do that, it's usually because resources aren't tagged consistently, nobody owns the cost review process, or both.
The practical result: engineering ships a feature that provisionally spins up five new ECS tasks "for testing," the tasks never get torn down, and $2,000/month in compute silently appears on the bill three weeks later. By the time anyone notices, they've forgotten the feature launch entirely.
Stratocraft's cost analysis identifies exactly these patterns — untagged resources, orphaned compute, cost anomalies — and surfaces them in the same report as your security and reliability findings.
2. Nobody Knows Which Team Owns Which Resources
Scan your AWS resource inventory right now. How many EC2 instances, S3 buckets, or RDS clusters would your engineering leads struggle to attribute to a specific team or product? If the answer is more than a handful, you have an ownership problem — and ownership problems directly cause cost problems.
Resources without owners don't get optimized. They don't get right-sized. They don't get deleted when the project they supported wraps up. They just keep running, billing you at on-demand rates, until someone trips over them during a cost review or a compliance audit.
The fix isn't complicated — consistent resource tagging with team, environment, and project tags is the minimum viable solution — but enforcing it retroactively across a sprawling multi-account environment is painful. Most organizations know they have a tagging problem. Very few have fixed it.
When you paste your infrastructure config into Stratocraft, the analysis flags untagged resources and resources that appear orphaned — not because they're unused per the billing data (we don't have your billing data), but because their configuration patterns match what abandoned resources typically look like: no recent deploys, no load balancer target group membership, no meaningful connections to the rest of your architecture.
3. You're Paying for Idle Compute 16+ Hours a Day
Development and staging environments that run 24/7 are one of the largest sources of preventable cloud waste. An m5.2xlarge running continuously costs roughly $280/month. That same instance running only during business hours (8am–6pm, weekdays) costs about $85/month — a 70% reduction for the same capability, just on a smarter schedule.
Most engineering teams know this. Most don't implement it, because "nobody has time" or "we're not sure what depends on it." Meanwhile, the dev environment keeps burning $280/month, month after month, because the fix lives permanently on the "nice to have" list.
The same dynamic plays out with over-provisioned instances. A team provisions an m5.4xlarge for a new service "to make sure we have headroom," runs it at 8% CPU utilization for six months, and never re-evaluates. The right-sizing analysis is sitting in some past architecture review nobody looks at anymore.
This is one of the most reliably identifiable patterns in infrastructure configs. Stratocraft's cost analysis specifically calls out over-provisioned instances and idle compute clusters, with concrete right-sizing recommendations and estimated monthly savings.
4. Your Reserved Instance Coverage Is Below 50%
If more than half of your steady-state compute is running on on-demand pricing, you're paying a significant premium for resources you're going to use anyway. Reserved Instances and Savings Plans can reduce EC2 and RDS costs by 40–60% for predictable workloads — not through any architectural cleverness, just by committing to what you're already running.
The hesitation is usually one of two things: either the team doesn't have visibility into which workloads are actually steady-state (vs. bursty or temporary), or there's organizational friction around making 1- or 3-year commitments when engineering roadmaps are uncertain.
Both are legitimate concerns. The answer to the first is better infrastructure visibility. The answer to the second is Compute Savings Plans rather than instance reservations — Savings Plans are applied flexibly across instance types and sizes, so they don't lock you into specific hardware choices. A $1,000/month Compute Savings Plan commitment will reduce your bill by roughly $400/month regardless of which instance types you use, as long as your total compute spend stays above that level.
If your overall cloud spend is above $5,000/month and your Savings Plan coverage is near zero, that's a recoverable $1,500–$2,500/month sitting on the table. Stratocraft's cost analysis flags this specifically — reserved instance coverage is one of the first things its cost scoring evaluates.
5. You Haven't Done a Cost Review in 6+ Months
This one isn't about a specific anti-pattern. It's about the cumulative effect of all the other patterns compounding without any checkpoint. Cloud infrastructure left unreviewed for six months almost always surprises you. The question is how badly.
What typically happens: engineering ships 10–15 features over six months. Each one adds a handful of new resources. Nobody goes back and removes the infrastructure that supported the features that were rolled back or deprecated. Nobody updates the tagging on the resources that moved between teams when the org restructure happened in Q2. Nobody right-sizes the database that turned out to serve 1/5th the traffic originally projected.
Six months later, your cloud bill is 40% higher than it was when the last review happened, and the engineering team can't immediately explain why. Forensic cost analysis follows. Someone builds a spreadsheet. Three weeks later you have a partial answer and a backlog of cleanup tasks that will take another two months to work through.
The alternative is continuous analysis — not a quarterly spreadsheet exercise, but infrastructure that's analyzed against current best practices every time it changes. That's what Stratocraft is built for.
The Diagnosis Is Free
If any of these five signs ring true, the fastest way to understand your current exposure is to analyze your infrastructure right now — not schedule a review for next quarter.
Paste your Terraform config, CloudFormation template, or Kubernetes manifests into Stratocraft's free infrastructure audit tool and get a complete cost, security, and reliability assessment in 30 seconds. No account required, no sales call, no commitment.
You'll see your cost efficiency score, a prioritized list of cost issues with estimated savings, and an actionable fix plan — the same output your team would get from a senior architect doing a full architecture review, delivered in the time it takes to read this article.
Want to see what that looks like before you try it? Read the sample report for a typical mid-market AWS deployment. The cost analysis section alone identifies $1,200+/month in recoverable savings from a stack most engineers would consider "pretty standard."
Also worth reading: Why Your Cloud Architecture Review Is Already Outdated — on why the problem compounds between review cycles.