Cloud cost reviews often arrive as bad news. Someone exports a dashboard, circles a spike, and asks engineers to spend less. That format creates defensiveness because it treats cost as a finance problem with engineering blame attached.
Better reviews connect spend to architecture choices.
Start with unit economics
Look at cost per customer, request, build, workspace, document, or inference. Absolute spend matters, but unit cost shows whether the system is becoming more efficient as it grows.
A rising bill with falling unit cost may be healthy. A flat bill with rising unit cost may hide a scaling problem.
Review the top movers
Do not review every line item. Pick the services that changed most since the last review and ask what product or system behavior moved them. New workload? Forgotten preview environments? Larger artifacts? More retries?
The meeting should produce engineering hypotheses, not vague anxiety.
Make savings an architecture backlog
Cost work competes with product work, so size it like product work. Some savings are one-line config changes. Others require caching, lifecycle policies, query changes, or product constraints.
Engineers attend cost reviews when the conversation helps them make better systems, not when it asks them to feel bad about graphs.
