Most Australian businesses we speak to are not concerned that they have moved too much to the cloud — they are concerned that the bill keeps growing without a clear story explaining why. FinOps is the discipline that closes that gap. It is not a tool; it is a way of running cloud spend that pairs engineering with finance.

Why cloud bills drift

Cloud platforms are designed to make consumption easy. That is exactly the property that erodes cost discipline over time. Resources get provisioned for a project and then orphaned. Development environments stay running overnight. Backups accumulate without retention policy. Storage tiers stay at the most expensive setting because no one revisited the choice after launch.

None of this represents bad engineering. It represents the absence of a feedback loop between the people incurring the cost and the people accountable for the budget.

The three FinOps phases

The FinOps Foundation describes three phases that organisations cycle through: Inform, Optimise, and Operate. The model is useful because it sequences work in the order that actually delivers value.

Inform is about visibility. You cannot manage what you cannot see. The first work is tagging discipline, cost allocation, and a single shared view of spend by team, environment, and workload. For Australian businesses with workloads in AWS Sydney or Azure Australia East, that view should also separate egress, support, and Marketplace items, which often hide significant spend.

Optimise is the work most engineers think of as “FinOps” — rightsizing instances, switching to reserved or savings-plan pricing, identifying orphaned resources, moving cold data to cheaper storage tiers, and addressing the long tail of small services that quietly add up.

Operate is where the discipline becomes durable. Cost is no longer something checked once a quarter when finance asks awkward questions. It becomes a non-functional requirement at design time, alongside security and availability.

Where Australian businesses tend to find quick wins

  • Idle compute. Non-production environments running 24/7 typically yield 40–70% savings when scheduled to business hours.
  • Storage tiering. Backups, log archives, and compliance copies rarely belong on hot storage. Moving them to cool or archive tiers usually pays for the migration work within a quarter.
  • Egress. Egress charges are the silent line item. Patterns that pull data out of the cloud unnecessarily — including some backup-to-on-premises designs — often have lower-cost alternatives.
  • Commitments. Predictable baseline workloads should be on reserved or savings-plan pricing. Pure on-demand is the right answer only for genuine unpredictability.

What to avoid

The most common FinOps mistake is treating it purely as a cost-cutting exercise. The point is not to spend less; the point is to spend deliberately. Aggressive cuts that compromise reliability, performance, or developer velocity tend to be reversed within a year — usually with the original waste plus a new layer of patches on top.

The second common mistake is buying a FinOps platform before the organisation has tagging discipline. The platform will faithfully render whatever it is given. If your tagging is incoherent, the dashboard will be incoherent.

Where Asset Hosting fits

For most of our clients, FinOps is not a standalone project — it is part of a broader cloud operating model that we help establish and run. If your cloud spend has grown faster than your business and you would like an independent view of where the savings actually are, we would be glad to start that conversation.