The five line items where cloud spend actually hides
Cloud cost reviews tend to produce a long list of recommendations and very little change. The reason is usually that the list has no owners, but a close second is that it starts with the wrong item. Almost every engagement finds the same five, in roughly the same order of value, and the first one blocks the other four.
1. Attribution, which is not a saving but enables all of them
If you cannot say which team or service a line item belongs to, every subsequent conversation is a negotiation with no facts. Someone proposes cutting an instance family and three teams claim it is critical.
Tagging is the boring prerequisite. Not perfect tagging — enough that the top eighty percent of spend maps to an owner. Enforce it at provisioning time through infrastructure as code rather than retroactively, because retroactive tagging is a project that never finishes.
Expect this to take longer than the actual cuts. It is still the right place to start.
2. Commitment coverage
Most estates run a surprising share of steady-state compute on demand. Savings Plans and reserved capacity are unglamorous and reliably worth double digits.
The reason teams avoid it is fear of committing to the wrong shape. That fear is usually mispriced: look at the trailing twelve months of baseline usage, commit to the floor rather than the average, and leave headroom on demand. Committing to sixty percent of a stable baseline is a low-risk decision that people defer for years.
3. Non-production running at production scale
Development, staging and QA environments running twenty-four hours a day for a team that works eight. Scheduled shutdown outside working hours is the single highest ratio of saving to effort in this entire list — often a scheduled scale-to-zero and a start-up hook.
The objection is always that someone might need it at night. The answer is a self-service way to bring it back up in two minutes, not leaving everything running for a case that occurs monthly.
4. Data transfer
The hardest line item to read and frequently larger than anyone expects. Cross-availability-zone traffic between chatty services, NAT gateway processing charges, egress to the internet that should be behind a CDN, and traffic to managed services routed over the public path instead of through endpoints.
This one rewards architecture more than configuration. Placing chatty services in the same zone, or routing to endpoints rather than over NAT, can move the number materially — but it is a design change, not a toggle, which is why it ends up in the structural half of the change list.
5. Storage lifecycle
Snapshots nobody deletes. Object storage in the standard tier that has not been read in a year. Log retention set to the default because nobody decided otherwise. Orphaned volumes from instances terminated months ago.
Lifecycle policies solve this permanently, which is the point — unlike a one-off cleanup, they keep working after the engagement ends.
Why the savings erode
The pattern is consistent: a review cuts spend by a third, and eighteen months later it is back. The cuts were real but nothing changed about how spend is created.
What holds the line is guardrails rather than vigilance. Budgets with alerts routed to the team that owns the spend, not to a central inbox. Tagging enforced in the provisioning path. Instance families and storage tiers constrained by policy. A monthly cost review that takes fifteen minutes because attribution already works.
None of that is exciting, and all of it is the difference between a saving and a dip.