1. The bill grows faster than the business
Revenue up 10%, cloud bill up 40%? Costs should track usage — customers, traffic, data. When they outpace it, you're usually paying for accumulation: environments spun up for experiments that never ended, snapshots multiplying quietly, services running for features that shipped and died. The bill has become a museum of past decisions, and museums charge admission monthly.
2. You pay 24/7 for things used 9-to-5
Development and staging environments that run nights and weekends, batch-job servers idling between runs, oversized instances "just in case" — the cloud's whole promise was paying for what you use, and the most common failure is renting capacity around the clock that works part-time. Scheduling and autoscaling are boring, solved problems that routinely cut meaningful percentages.
3. Nobody can explain the top three lines
Open your bill and look at the three biggest line items. If nobody on the team can say what each one is for — which feature, which customer-facing behavior — that's not a knowledge gap, it's a budget leak with excellent camouflage. Unexplained spend is unchallenged spend.
4. Storage only ever goes up
Data has a lifecycle; most storage configurations don't. Logs kept forever at premium tiers, database backups with no expiration, user uploads never archived to cold storage. And its quiet partner, egress — moving data out or between regions — which surprises teams because it's priced in a unit nobody visualizes. Lifecycle rules are an afternoon of work that pays monthly, forever.
5. The architecture is dressed for a job it doesn't have
Kubernetes clusters serving traffic a single small server could handle. Multi-region redundancy for an internal tool used in one office. An architecture copied from a conference talk by a company with a thousand times your load. Complexity isn't just an engineering cost — every layer bills you monthly and takes longer to debug at 2 a.m. The right architecture for most growing businesses is aggressively simpler than what they're running.
What right-sizing looks like
The fix is rarely a migration. In rough order of effort:
- Delete the museum — unused environments, orphaned volumes, forgotten snapshots. Pure savings, no risk to running systems.
- Schedule and resize — sleep non-production at night, size instances to observed load instead of optimism.
- Add lifecycle rules — logs and backups expire, old data moves to cheap tiers.
- Commit where usage is stable — reserved pricing on the baseline you know you'll use is a discount for a signature.
- Simplify the architecture — the deepest savings, and the only one that's a real project.
None of this requires heroics — it requires someone finally being responsible for the bill. Most teams find the first three items in a single afternoon of honest looking. The result isn't just a smaller number; it's a bill where every line has a reason, which is what makes the next creep visible early.