Put ninety minutes in the diary once a quarter, invite the person who owns the bill and the person who owns the code, and work through the same eight questions every time. That is the whole practice. You do not need a FinOps hire, a dashboard vendor or a reorganisation to stop a cloud bill drifting upwards, and for a team of under twenty people a quarterly review catches almost everything a monthly one would, at a quarter of the effort.

Why a quarter is the right rhythm
Monthly reviews sound more diligent. In practice they turn into a status meeting where nothing has changed enough to act on, and the agenda quietly shrinks until someone cancels it. A quarter is long enough that real drift shows up in the numbers and short enough that the drift has not compounded into an architecture problem.
There is a second reason. Most of the useful actions have a lead time. Rightsizing a database means a maintenance window. Buying a one-year commitment means a forecast you believe. Deleting old snapshots means asking three people whether they still need them. A quarterly cycle gives each action a sensible place to land, and gives you a baseline to compare against when the next review comes round.
The context is worth knowing before you start. Synergy Research Group reported that enterprise spending on cloud infrastructure services reached $143 billion in the second quarter of 2026, up 43% year on year, with AWS at 28% of the market, Microsoft at 20% and Google Cloud at 15%. Prices per unit keep falling slowly while total bills rise quickly. Nobody is going to send you a smaller invoice because the market got cheaper.
The five-item agenda
Run the same list in the same order. The order matters, because every item above changes the answer to the items below it.
- Delete. Unattached volumes, old snapshots, idle load balancers, test environments from a project that shipped in March, public IP addresses nothing answers on.
- Rightsize. Anything that has not passed 20% CPU or memory in the last 30 days is a candidate to drop one size. Do the database last and alone.
- Re-tier storage. Move cold objects and logs down the storage classes, and set a lifecycle rule so you never have to do it manually again.
- Re-check the commitment coverage. What percentage of your steady-state compute is on a discount, and does the forecast still support it?
- Read the top ten line items out loud. If nobody in the room can explain a line, that is this quarter’s investigation.
Each item gets an owner and a date, and the notes go somewhere both of you will find them again. If you want the vocabulary behind these levers, our guide to cloud service models explains why a managed database and a self-run one on a virtual machine behave so differently on the invoice.
What the waste numbers actually say
Flexera’s 2026 State of the Cloud Report surveyed 753 cloud decision-makers and put estimated wasted spend on infrastructure and platform services at 29%. That figure had been drifting down for five years; this is the first year it went back up, which Flexera attributes largely to AI workloads moving from experiment to production. The same report found 17% of organisations exceeded their public cloud budget in the past year, and 68% still rank optimising cloud costs as their top cloud initiative.
Treat 29% as a prompt rather than a target. Waste in a ten-person shop is rarely distributed evenly across a hundred services; it sits in two or three places, usually a staging environment that never scales down and a storage bucket nobody has opened in a year. Finding those two places is the entire exercise.
The FinOps Foundation’s State of FinOps 2026 is the other number to know, mostly because of what it says about scope. Respondents collectively manage more than $83 billion of spend, and the Foundation changed its own mission wording from managing the value of cloud to managing the value of technology. SaaS subscriptions, software licences and AI APIs are now in the same conversation as virtual machines. For a small team that is good news: one spreadsheet, one review, everything that bills monthly.

The commitment decision, and how far you can unwind it
Once you have deleted and rightsized, commit to what is left. The published discounts are substantial and all three large providers document them openly. What varies, and what matters far more for a small team, is how easily you can get out again.
On AWS the two relevant instruments are documented plainly. Compute Savings Plans trade a dollar-per-hour commitment for prices up to 66% below on-demand, and they follow your usage across instance families, sizes, regions and on into Fargate and Lambda. EC2 Instance Savings Plans go deeper, up to 72%, in exchange for pinning yourself to one instance family in one region. Azure and Google Cloud have close equivalents, and we compare all of them side by side in Reserved Instances, Savings Plans and Committed Use Discounts Compared.
The part worth knowing before you click buy is how little room there is to change your mind. An AWS Savings Plan can be returned only if the hourly commitment is $100 or less, only within seven days of purchase, and only inside the same calendar month. After that you are paying the commitment whether or not you use it, which is a perfectly reasonable trade as long as you made it deliberately.
The practical rule for a team under twenty people: cover your genuinely steady baseline with one-year commitments, leave the spiky part on demand, and only look at three-year terms for something you would struggle to switch off, like the database behind your main product. A three-year commitment at 55% off is a worse deal than a one-year commitment at 37% if you re-architect in month fourteen.
The honest way to describe a commitment purchaseCoverage is a forecast you are signing, not a discount you are claiming.
Storage is the cheapest win in the room
Storage classes are the one lever with almost no operational risk, and the gap between tiers is wide. These are AWS’s own published prices for N. Virginia, taken from the S3 price list dated 28 September 2026.
| S3 storage class | Price per GB-month | Cost of 2 TB per month | Sensible use |
|---|---|---|---|
| Standard (first 50 TB) | $0.0230 | $47.10 | Live application data |
| Intelligent-Tiering, frequent access | $0.0230 | $47.10 | Mixed access patterns |
| Standard-Infrequent Access | $0.0125 | $25.60 | Backups you might need this month |
| One Zone-Infrequent Access | $0.0100 | $20.48 | Reproducible data, single zone is fine |
| Glacier Instant Retrieval | $0.0040 | $8.19 | Archives read a few times a year |
| Glacier Flexible Retrieval | $0.0036 | $7.37 | Compliance copies, minutes to hours |
| Deep Archive access tier | $0.00099 | $2.03 | Seven-year retention nobody reads |
Moving two terabytes of old backups from Standard to Glacier Flexible Retrieval saves about $40 a month. That is not a transformation. It is also five minutes of work and a lifecycle rule, and it compounds quietly for years, which describes most good cost work.
The small meters nobody watches
Small per-hour meters are where surprise bills come from, because none of them is big enough to notice and all of them run continuously. A public IPv4 address on AWS costs $0.005 per hour in N. Virginia whether it is attached to something or sitting idle, which is $3.65 a month per address. Ten forgotten addresses from an old load balancer experiment is $438 a year for nothing.
- Public IPv4 addresses: $0.005 per hour each, in use or idle (AWS price list, N. Virginia).
- Unattached block storage volumes, which bill at full price with no instance running.
- Snapshots with no retention policy, which grow for as long as the account exists.
- Cross-zone traffic at $0.01 per GB each way, which chatty microservices generate quietly.
None of these needs a tool. They need somebody to open the billing console once a quarter with the intent to cancel something. If you want to go further on the data transfer side, our piece on how the major providers compare covers where their pricing models diverge most.
Getting the data into one place
The reason cost reviews stall is usually that the numbers live in three places: the cloud bill, a SaaS card statement and somebody’s memory. The FinOps Foundation’s FOCUS specification exists to fix the first part of that. FOCUS 1.4 was ratified on 4 June 2026 and added two datasets and 47 columns, continuing to normalise billing exports so the same query works across providers.
You do not need to implement a specification to benefit from the idea behind it. Pick one tag key, apply it to everything, and insist that anything untagged is somebody’s problem by the end of the quarter. Two tags is better than ten: an owner and an environment will answer most questions you will actually ask.

A worked example: twelve instances and a database
Here is the shape of a first review for a small product team: twelve general-purpose instances, one managed database, three terabytes in object storage and a few load balancers. The pattern repeats across almost every client we see.
The deletions came first: a staging stack from a finished integration, two unattached volumes and six public IP addresses nobody could account for. Rightsizing dropped four web instances one size after a month of CPU graphs never crossing 15%. Then, and only then, the remaining eight instances went onto a one-year commitment, because committing before the deletions would have locked in the waste at a discount.
That sequence is the single most important thing in this article. Commitment discounts applied to idle capacity are the most expensive kind of saving: they feel like progress and they remove your ability to fix the actual problem for twelve months. If you are at the very start of this, the introduction to cloud technology sets out the building blocks these bills are made of.

Eudora Technology runs these reviews remotely for teams in Europe, the Middle East, Asia and North America, including the unglamorous part where somebody has to find out who owns an untagged instance. Our cloud solutions page sets out how that engagement normally works.
Frequently asked questions
Is quarterly often enough if our spend is growing fast?
If your bill is growing more than about 15% a quarter, add a short monthly check on the top five line items and keep the full review quarterly. The monthly check is a glance at a graph, not a meeting. What you are watching for is a new service appearing in the top five, which is usually how a surprise starts.
Should we buy a three-year commitment to get the deepest discount?
Only for workloads you are confident will exist in that form in three years. Google Cloud publishes up to 55% for resource-based commitments on most machine series, and AWS publishes up to 66% for Compute Savings Plans and up to 72% for the less flexible EC2 Instance Savings Plans. The extra saving is real, but so is the risk of paying for capacity you re-architected away in year two.
We use SaaS more than infrastructure. Does FinOps apply?
Yes, and the FinOps Foundation’s 2026 survey reflects that: the discipline has formally widened from cloud to technology spend generally, with SaaS and licensing now inside scope. The same agenda works. Cancel unused seats, downgrade tiers nobody uses, and check renewal dates before they auto-renew rather than after.
Do we need a cost management tool?
Not at first. The native cost explorers from AWS, Azure and Google Cloud are free and good enough to find the first two or three problems. Buy a tool when you have more than one cloud account per team or when somebody is spending a day a month exporting data by hand, and not before.
What is a realistic saving from a first review?
For a team that has never done one, somewhere between 15% and 30% of the bill is typical, which lines up with Flexera’s 29% waste estimate. The second review usually finds far less, and that is the point: the first one clears the backlog, and after that the review exists to stop the backlog returning.
If your cloud bill has grown faster than your usage and nobody has had the time to find out why, we can run the first quarterly review with you and leave you the agenda. Get in touch with Eudora Technology to talk about your project.



