How to Run a Quarterly Cloud Cost Review That Actually Cuts the Bill

The cost review meeting most teams never actually have

Every cloud team I have worked with eventually realizes that cost does not improve on its own. Tags drift, instances grow, idle resources accumulate, and the bill quietly creeps. The single highest-leverage cost intervention is not a tool or a dashboard. It is a recurring quarterly review where the right people sit down, look at the actual bill, and make decisions that stick for the next ninety days.

This article is the playbook I wish I had when I started running these reviews. It covers who needs to be in the room, what to bring, which decisions belong there, and the operational follow-through that keeps the savings from leaking back. The math sources for this article are AWS, Azure, and GCP pricing pages read on 2026-05-28.

Who needs to be in the meeting

Three roles are non-negotiable. First, an engineering decision maker who can commit the team to architectural changes. Without someone empowered to say "yes, we will refactor the egress path this quarter," the review produces opinions and no action. Second, finance or a budget owner who understands what numbers actually matter to the business. Engineers naturally optimize for operational elegance; finance keeps the focus on dollars. Third, a platform or FinOps lead who has spent time with the bill and can answer "what is this $14,000 line item" without scrambling.

Optional but useful: a security or compliance representative if any line items touch regulated workloads (you cannot just turn off audit logging to save money), and a product owner for any consumer-facing service whose performance budget is part of the cost conversation.

What to bring

A useful review packet has four documents and not much else. Slides are optional. The documents are:

1. Last quarter's bill, by service and by team / tag. On AWS this comes from Cost Explorer grouped by Tag plus Service. On Azure it is Cost Analysis filtered by Resource Group plus Service. On GCP it is the billing export grouped by Project plus SKU. The deliverable is a one-page table sorted by spend descending, with quarter-over-quarter change in a side column.
2. Top ten line items in dollars. Whatever the top ten are, by absolute spend. Often two or three of these are surprises, especially in the smaller-team tier where one expensive NAT Gateway or one chatty inter-region data transfer dominates.
3. Forecasted spend for next quarter at current trajectory. If trajectory is "flat", say so. If trajectory is "growing 12 percent per month," that is the number that should drive most of the conversation.
4. The action list from the previous review. Every item, with status: done, in progress, blocked, deprioritized. If you do not bring the prior list, the review will produce a new list that looks suspiciously like it.

The decisions worth making at the table

Not every cost decision belongs in a quarterly review. Two filters help. First, it has to be reversible or low-risk; you do not finalize a major architectural shift around a conference room table. Second, it has to have a clear deadline; "we should look into Savings Plans someday" is not a decision.

Decisions that work well in a review meeting:

• Commitment level for the next 12 months. Savings Plans on AWS, Committed Use Discounts on GCP, Reservations on Azure. Picking a coverage percentage (typically 60 to 75 percent for steady-state workloads) is exactly the kind of decision that benefits from finance plus engineering in the room.
• Which workloads to turn off or downsize. The dev environment that has been running production-class instances for a year. The proof-of-concept that never went anywhere. The replication target nobody has tested in months. Decide in writing, give it a deadline, assign an owner.
• Which storage classes to migrate. Logs older than thirty days that are still on Standard storage. Snapshots older than ninety days that have no recovery requirement. Backups that could move to Glacier or Archive without affecting the recovery objective. These migrations save real money and rarely break anything.
• Network architecture changes worth chasing this quarter. Egress is the cost most teams underestimate. Moving from per-instance NAT Gateways to a single regional VPN, putting high-volume traffic through a VPC endpoint instead of public egress, or restructuring inter-region replication patterns are all decisions that fit the review format if scoped correctly.

Decisions that do not belong at the table

Architectural rewrites need their own design review with the engineering team, not a finance-mediated decision in a 60-minute slot. Vendor evaluations need a structured procurement process, not a side conversation. Compensation conversations should be nowhere near this meeting. Trying to do these things in the review compresses the agenda and ends with nothing decided.

The follow-through that matters

Most cost reviews produce a list of actions. Few teams treat that list as a real commitment. The fix is mechanical:

1. Every action gets an owner and a date. "We will migrate the dev RDS to a smaller instance class by 2026-06-15." Not "we will look at the dev RDS."
2. The action list lives in the same place the team's other engineering work lives: Linear, Jira, GitHub Issues, whatever. Spreadsheet-only action lists evaporate.
3. Mid-quarter, the FinOps lead sends one update: percent of actions complete, percent on track, percent at risk. Five lines of text. That single email saves the next review from feeling like a do-over.
4. The next review opens with the prior list. Items that did not get done either get explicitly deprioritized (with reasoning recorded) or they roll over with a new deadline. Items that did get done get a sentence about the realized savings.

A reasonable cadence

For most teams, quarterly is the right interval. Monthly creates decision fatigue and rarely produces enough new data to be useful. Annual is too slow for cost trajectories that move materially quarter-over-quarter. The exception is the very early growth stage, where monthly may be necessary because the bill is changing shape every few weeks.

The meeting itself should run sixty to seventy-five minutes. Longer means you tried to make too many decisions at once. Shorter means you did not actually look at the bill.

What good looks like over six months

After two cycles, a team running this process well has:

• A predictable spend trajectory with no surprises in the top ten line items.
• A commitment posture that matches actual steady-state usage (typically 60 to 75 percent commitment coverage on AWS Savings Plans, similar on GCP Committed Use Discounts, and a portfolio of one and three-year Reservations on Azure).
• A storage and snapshot lifecycle that does not accumulate forever.
• An action list with a 70+ percent completion rate quarter over quarter.
• A bill that engineers do not feel embarrassed by when finance asks questions.

None of this requires expensive tooling. The first two reviews can be done with the provider-native cost reports, a spreadsheet, and one hour of preparation. If after six months you still want a dedicated FinOps platform, you will know exactly what you need it to do.