Cloud bills are often treated as an operational surprise. The finance function sees a monthly total, the platform function sees a set of services, and nobody can explain why the unit cost of the product changed. By the time a report is produced, the architectural decisions that created the cost are already embedded.
The bill is a lagging indicator
Cost optimisation usually starts with rightsizing, storage lifecycle and commitment planning. Those actions matter, but they address the symptoms of decisions made earlier: how workloads share a platform, how data moves between services, how environments are separated and how capacity is provisioned.
A workload designed around chatty service calls and continuous data replication will remain expensive even after every instance is correctly sized. The architecture determines the cost floor; operational tuning determines how close you get to it.
Four architectural cost drivers
Data movement. Egress, cross-zone replication and repeated extracts can dominate a bill. The cheapest data is data that does not move.
Idle capacity. Over-provisioned environments and always-on non-production estates are common. The question is not only how to shrink them, but whether the environment model requires them to exist.
Concentration risk. A small number of high-volume services can distort the entire cost base. Understanding unit economics by product or tenant is more useful than a single account total.
Managed-service premium. Managed services reduce operational effort but carry a unit-cost premium. The trade-off should be explicit, not discovered through the invoice.
Design for unit economics
We prefer to model cost per transaction, per tenant or per active user before the architecture is fixed. That model exposes which design choices create variable cost and which create fixed cost.
It also changes the conversation with the business. A product decision that increases data retention or introduces a new integration has a cost consequence. Making that visible at design time is more effective than a monthly optimisation meeting.
What FinOps can and cannot fix
FinOps is valuable for visibility, accountability and operational discipline. It cannot retroactively change a data-heavy architecture, remove a mandatory cross-region replication requirement or simplify a service boundary that creates excessive calls.
The most effective cost programme connects architectural decisions, product decisions and financial reporting. Without that connection, optimisation becomes a sequence of local savings that do not change the unit cost.
What we recommend
- Model cost per unit of value before finalising the architecture.
- Treat data movement and environment strategy as design decisions, not operational settings.
- Give each workload a named owner and a cost allocation that reflects its actual consumption.
- Review commitments only after the workload shape is stable; commitments lock in a design as well as a price.
- Report cost alongside reliability and performance, not as a separate monthly exercise.
Where we disagree
We do not believe the cheapest architecture is always the right one. Resilience, security and delivery speed have a cost, and a design that ignores them to minimise the bill is likely to be more expensive over its life. The goal is an informed trade-off, not the lowest possible invoice.
A practical test
Before the next optimisation review, pick one workload and calculate its cost per transaction, per tenant or per active user. Then ask which architectural decisions create that number: data movement, environment duplication, capacity model, managed-service premium or licensing. The answer is usually more useful than a percentage saving on a service line, because it shows where the next design decision will change the cost.