Most organisations meet FinOps through an invoice. The bill arrives higher than the business case, finance asks why, and someone is asked to "do FinOps": find the waste, buy some discounts and produce a dashboard. That work is useful. It is also late, because the bill it is investigating was designed long before it was printed.
A cloud bill is the sum of thousands of small engineering decisions: which region, how many copies of the data, how long logs are kept, whether test environments sleep at night, how chatty two services are with each other across a network boundary. Finance cannot change any of those. It can only see their consequences, a month later, in a currency the decisions were never expressed in.
This part is about moving the cost conversation to where the cost is created. Bushbuck Brands is fictional, and its systems and figures are illustrative. Bushbuck, the South African FMCG distributor we follow through this series, rehosted 46 applications in its first migration wave and found its monthly bill running at about R1.9 million against a business case of R1.3 million. Part 1 traced that gap to oversized machines, always-on test environments, duplicated backups, long log retention and nightly data transfer. Fixing those once is the easy part. Making sure the next 94 applications do not repeat them is the subject of this part.
What FinOps actually is
The FinOps Foundation defines FinOps as "an operational framework and cultural practice which maximizes the business value of technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams" (FinOps Framework).
Two words in that definition do most of the work. The first is value: the goal is not the lowest bill but the most value per rand spent, which sometimes means spending more. The second is collaboration: engineering, finance and the business each hold part of the answer, and none of them can produce it alone. The Foundation's own principles say the same thing in plainer terms: teams need to collaborate, business value drives technology decisions, and everyone takes ownership for their technology usage.
The framework describes three repeating phases, Inform, Optimize and Operate: make cost visible and allocated, improve it, then build the improvement into how the organisation runs. Notice that none of those phases begins with the invoice. Inform starts with deciding who owns what before anything is deployed, because cost that cannot be allocated cannot be owned.
Architecture creates the bill
In a data centre, an architecture decision mostly affected how much hardware to buy, and that conversation happened once every few years. In the cloud, the same decisions set a monthly meter running:
- Region and availability design affect runtime and data transfer. Running across zones or regions improves resilience and multiplies some costs.
- Data models affect storage, the number of requests and how much data moves. A report that scans a whole table every hour is a recurring charge.
- Observability choices affect ingestion and retention. Logging every request at debug level, kept for two years, is a storage product you did not mean to buy.
- Release practices affect how many environments exist and for how long. Every long-lived test environment is a second, smaller production.
- Resilience decisions affect capacity, backup copies and replication. Each copy is justified individually and rarely reviewed together.
- Model and API choices affect per-use consumption. AI services in particular are priced per request or per token, so behaviour, not capacity, drives the bill. Our FinOps for AI piece covers that meter in detail.
Data transfer deserves a specific mention, because it surprises almost everyone moving from a data centre. On AWS, Azure and Google Cloud, data coming in is generally free and data going out to the internet is charged, and movement between zones and regions can carry its own charges. A design that sends large volumes out of the cloud every night, as Bushbuck's reporting server did, turns a network diagram into a monthly invoice line.
The practical consequence is simple: cost belongs in the architecture review, as a non-functional requirement with the same standing as security and availability. A design that cannot say roughly what it will cost at expected volume, and what drives that cost up, is not finished.
Choose a unit of value
A total bill tells you how much you spent. It does not tell you whether the spending was good. For that you need a unit of value: a measure of the thing the business actually produces, against which cost can be divided.
Useful units depend on the organisation: cost per claim processed, per citizen transaction, per active customer, per build, per API call or per resolved contact. The best unit is one the business already counts and cares about, and that moves when the service is used more or less.
Bushbuck chose cost per order line shipped as its main unit, because order lines are what the business is paid for and what its warehouses, routing and systems exist to move. For the trade ordering portal, which serves about 9,000 independent retailers, it added cost per active trade customer. Both are calculated monthly from the allocated cloud bill and the volumes the business already reports.
The unit changes the conversation immediately, because it separates two very different stories that a total bill blurs together:
- A falling bill can be bad news. If the bill fell because order volumes dropped, cost per order line may have risen, and the business is now carrying fixed platform cost over less work.
- A rising bill can be healthy. If the bill rose 6% while order lines grew 15%, each order is cheaper to serve. Cutting that spend to hit a budget line would be the wrong decision.
- Both rising together is the signal to act. If unit cost climbs with volume, waste is scaling with the business.
The unit also gives engineers a number they can influence. "Reduce the cloud bill" is an instruction nobody owns. "Bring the cost per order line for route planning down by moving the nightly job off two always-on servers" is a piece of work with an owner and a measurable result.
The currency problem
South African organisations carry a cost driver that most FinOps material written elsewhere ignores: the major cloud providers price in US dollars, and the business budgets and earns in rand. A month in which nothing changed technically can still produce a materially different rand bill.
Two habits help. First, report unit cost in both currencies: the dollar figure tells engineering whether its decisions improved efficiency, and the rand figure tells finance what the business actually paid. Second, agree how exchange-rate movement is handled in the budget before the first surprise, whether through a budget band, a hedging decision by treasury, or a rule that variance caused purely by the rate is reported separately from variance caused by usage. Otherwise every weak-rand month becomes an argument about engineering discipline that engineering cannot win.
Minimum controls before the next wave
None of this needs a large FinOps team. Bushbuck applied seven controls before moving its next wave, and none of them required new tooling:
- A named owner for every material account, subscription or resource group. Not a team mailbox: a person who can answer for the cost and change it.
- Cost allocation tags or labels enforced through policy. Bushbuck required owner, application, environment and cost centre on every resource, and its landing-zone policy rejects deployments without them. Our cloud cost governance framework covers tagging and budget design in more depth.
- Budgets and anomaly alerts routed to someone who can act. An alert sent to finance about a runaway test environment helps nobody at 2am. Alerts go to the application owner first.
- Non-production shutdown and lifecycle policies. Test environments sleep outside working hours by default; teams opt out with a reason, not in with a request.
- Commitment decisions based on measured, stable demand. AWS Savings Plans, Azure reservations and savings plans, and Google committed use discounts are generally one- or three-year commitments. Bushbuck waited for 90 days of post-migration data before committing, and committed only for the stable baseline: the warehouse management system and the core databases. Committing on the rehosted, oversized estate would have locked in the waste.
- Architecture review for high-transfer and high-retention designs. Any design that moves large volumes out of the cloud, or keeps data or logs beyond policy, needs an explicit cost estimate before approval.
- A monthly unit-economics review shared by finance and engineering. Bushbuck's is chaired jointly by the financial controller and the head of platform, takes an hour, and looks at unit cost first and the total second.
The seventh control is the one that makes the others stick. Tags, alerts and policies decay unless someone looks at what they produce and acts on it.
Shift the estimate left
The highest-leverage moment for cost is before deployment, so Bushbuck added a short cost section to its design template for every application in the remaining waves:
- the expected volume in business terms (orders, users, transactions);
- the main cost drivers and how each scales with that volume;
- a rough monthly estimate at expected and at double volume, with the pricing assumptions written down;
- the unit cost the design is expected to achieve;
- the owner who will receive the budget alerts.
The estimate does not need to be precise. It needs to exist, so that the first real month can be compared with something, and so that a design whose cost doubles with volume is noticed while it can still be changed cheaply. The providers' own pricing calculators are adequate for this, as long as the assumptions are recorded alongside the number.
Common mistakes
- Starting FinOps when the invoice arrives. By then the design decisions that created the bill are already in production and expensive to change.
- Optimising the total instead of the unit. Cutting spend that is growing more slowly than the business can damage the business.
- Buying commitments on unrightsized estates. A three-year discount on a machine that should be half its size is a three-year commitment to waste.
- Sending cost alerts to finance. Finance can see the problem but cannot fix it. Route alerts to the owner who can.
- Treating exchange-rate movement as engineering variance. Report rate effects separately, or engineering will be blamed for the rand.
- Letting tagging be optional. Unallocated cost has no owner, and cost without an owner does not go down.
A decision you can defend
We will measure Bushbuck's cloud spend by cost per order line shipped, and cost per active trade customer for the portal, reviewed monthly by the financial controller and the head of platform. Every resource must carry owner, application, environment and cost-centre tags, enforced by policy, and every new design must include a cost estimate at expected and double volume. We will buy commitments only for the stable baseline after 90 days of measured data. We accept that some savings will arrive later than a blanket commitment would have delivered them. We will review the units and controls after two further migration waves, or sooner if the unit cost rises for two consecutive months.
What to take from this part
Architecture creates the bill. Finance cannot optimise a design it does not control, so cost belongs in the design review.
Measure a unit of value, not only the total. The total tells you what you spent; the unit tells you whether it was worth it.
Allocate before you deploy. Cost that cannot be attributed to an owner will not be reduced.
Commit on evidence. Discounts on measured, stable demand save money; discounts on a rehosted estate preserve waste.
Separate the rand from the engineering. Report exchange-rate effects apart from usage effects.
Next in the series: The operating model must move too.
How CloudNala can help
We help organisations put cost into the design process rather than the month-end report: choosing a unit of value the business recognises, setting up tagging, ownership and alerting that hold up under policy, adding cost estimates to architecture reviews, and running the first unit-economics reviews with finance and engineering in the same room until the habit sticks.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Review or write to us at consult@cloudnala.co.za