FinOps / Guide 1
How cloud cost works
Pay-as-you-go versus buying hardware, the default-plan trap, and why you can resize at any time.
Moving to the cloud changes how infrastructure is paid for, not just where it runs. Instead of buying servers every few years and hoping they last, you rent capacity by the second or hour and get an invoice every month. That is a big advantage, but only if someone keeps an eye on what is running and why. This guide explains the basics that the rest of the FinOps guides build on. The examples cover Azure, AWS and Google Cloud side by side.
No hardware to buy up front
In a data centre, capacity is a capital purchase. You size servers for the peak you expect over the next three to five years, pay for them on day one, and live with the result. If you guessed too big, the money is already spent. If you guessed too small, you wait weeks for new hardware.
In the cloud there is no up-front purchase. You pay for what you provision, for as long as it exists. That gives you three things a data centre can't:
- Start small. Begin with a modest size and grow when real usage tells you to, instead of buying for a guess.
- Resize at any time. Moving a VM to a bigger or smaller size is usually a restart, not a hardware project. The decision you make today isn't locked in.
- Stop paying when you stop using. Delete a test environment on Friday and its cost stops on Friday. Power off a VM at night and you stop paying for its compute.
The catch is the other side of the same coin: nothing stops paying on its own. A VM that nobody uses still bills every hour, and a disk left behind after a server is deleted bills every month. Cloud cost is something you manage continuously, not once a year.
Pay-as-you-go is the default plan
Every new account starts on pay-as-you-go: list price, billed per second or hour, no commitment. It's the most flexible way to pay and also the most expensive per hour. That's fine while you learn how a workload behaves. Once usage is steady, the same resources can cost a lot less with a commitment (see guide 05).
| Azure | AWS | Google Cloud | |
|---|---|---|---|
| Default pricing | Pay-as-you-go | On-Demand | On-demand, with sustained use discounts applied automatically to some machine types |
| Automatic discount without committing | None | None | Up to 30% for VMs that run most of the month (N1, N2, N2D, C2 and some others) |
A sensible path for any new workload: run it on pay-as-you-go for a month or two, measure what it really uses, right-size it, and only then commit to the steady part.
The default-plan trap
Portals and templates are designed to work first time, not to be cheap. The defaults are often bigger, faster or more redundant than a workload needs, and nobody goes back to change them. Common examples:
| Default that costs more than it needs to | Azure | AWS | Google Cloud |
|---|---|---|---|
| VM size picked from the first screen | General-purpose D-series suggested even for light workloads | Instance type copied from an old template | n2-standard machine type where e2 would do |
| Premium disks on non-production | Premium SSD on a dev VM | io1/io2 or gp2 instead of gp3 | pd-ssd where pd-balanced is enough |
| Geo-redundant storage for data you could re-create | GRS or RA-GRS storage accounts | Cross-Region Replication on test buckets | Dual-region or multi-region buckets for test data |
| Hot storage tier for files nobody reads | Account default tier Hot | S3 Standard for backups and archives | Standard class for archives |
| Logs kept forever | Long retention on every Log Analytics table | CloudWatch log groups default to never expire | Custom log buckets with long retention |
None of these is wrong for production that needs it. The waste comes from applying production defaults to everything. Make the cheaper option the default in your templates and let teams opt up when they have a reason.
The FinOps loop
FinOps is the practice of making cloud spend visible, owned and optimised, together with finance. The FinOps Foundation describes it as three repeating phases. In plain terms:
- Inform: see where the money goes, by team, application and environment. This needs consistent tags or labels (see the Azure, AWS and Google Cloud guides).
- Optimise: remove waste, right-size, schedule non-production, and commit to the steady baseline.
- Operate: make it routine: budgets, alerts, a monthly review, and cheaper defaults in templates.
The guides in this section follow that loop: measure (02), right-size (03), schedule (04), commit (05), stop the leaks (06) and review every month (07).
Who owns the bill
Cost optimisation fails when everyone assumes someone else is watching. Give every subscription, account or project an owner, tag every resource with an owner and cost centre, and send each owner their own numbers every month. Engineers make the changes; finance sees the trend; the owner decides what is worth paying for.