Every organisation that has scaled its cloud footprint eventually arrives at the same meeting: finance presents a chart of rising spend, a FinOps tool is procured, tagging discipline is tightened, and idle resources are switched off. Costs dip briefly and then resume their climb, because the tooling addressed waste, not design. Waste is the smallest part of most cloud cost problems.
The larger part is architectural, and it was decided long before the first invoice arrived: where data lives relative to where it is processed, how tightly services are coupled to each other, and whether workloads share infrastructure efficiently or each carry their own dedicated, underused footprint. None of that is visible on a cost dashboard, and none of it is fixable by a finance team acting alone.
Data gravity dictates the bill
Data has gravity: the more of it accumulates in one place, the more expensive and inconvenient it becomes to move, and the more other services get built to sit near it rather than move it. This is efficient in the short term and expensive in the long term, because it locks architecture decisions in around the historical location of data rather than the current shape of the workload.
Cross-region and cross-cloud data transfer charges are one of the most persistent, least visible cost lines in a cloud estate precisely because they are a side effect of an old data placement decision rather than a line item anyone actively chose. Reviewing where data actually sits, and why, is a more productive first move than tightening tagging policy.
A FinOps dashboard tells you what something costs. It does not tell you why, and why is an architecture question.
Coupling turns architecture into cost
Services that are tightly coupled tend to scale together even when their actual demand patterns are unrelated, which means paying for peak capacity across a whole cluster of services to satisfy the demand of one. Loosely coupled, independently scalable services cost less precisely because they let cost follow demand rather than following the busiest neighbour.
This is why cost optimisation efforts that stop at the infrastructure layer plateau quickly. Rightsizing an instance or negotiating a better reserved rate saves a fixed amount once. Decoupling a system so it scales on its own terms saves a compounding amount for as long as the system exists.
- 路Map where data actually lives against where it is processed
- 路Identify which services scale together that do not need to
- 路Review tenancy: shared infrastructure against dedicated, underused footprint
- 路Treat FinOps dashboards as a symptom tracker, not a fix
Tenancy choices are cost choices
Multi-tenant architectures spread infrastructure cost across many workloads or customers and generally cost less per unit of work. Single-tenant architectures, often chosen for genuine reasons around isolation, compliance or customer preference, cost more per unit and that premium is defensible only when the reason for it is deliberate and understood, not inherited from an early decision nobody has revisited.
The organisations with the best cost discipline are not the ones with the tightest FinOps process. They are the ones that revisit tenancy and coupling decisions on a cadence, treating them as live architectural choices rather than settled facts from the original build.
None of this argues against FinOps discipline, tagging hygiene or right-sizing exercises. They are necessary and they are the easy part. The harder, more valuable conversation is the one that puts architects and finance in the same room to ask why the estate is shaped the way it is, and whether that shape still matches the workload it now serves.
Cost that is genuinely under control looks less like a monthly spreadsheet review and more like an architecture review board with a cost mandate. Organisations that build that habit stop chasing the bill after the fact and start shaping it before it arrives.