Work Hours
Monday to Friday: 10.00 - 19.00
Most cloud cost problems are treated as optimisation issues long after they have become architectural ones.
When optimisation is no longer enough
A platform engineering team spends months optimising a microservices environment. Autoscaling is tuned. Unused resources are gone. Utilisation metrics look healthy. Every operational lever has been pulled.
The cloud bill has not moved.
The FinOps team can see exactly where the spend is going. Cross-service data transfer, per-request charges on managed services, and baseline overhead across environments. But seeing it does not create a path to change it.
Most teams reach this point eventually. Early optimisation delivers real gains, but as systems grow, each round of improvement delivers less impact while the underlying cost remains.
This is where optimisation starts to plateau. Spend is visible and attributable, but largely structural.
The State of FinOps 2026 report from the FinOps Foundation echoes this pattern. For many organisations, the obvious waste has already been removed. Waste reduction remains important, but most teams now describe optimisation work as incremental and difficult to realise. Gains are smaller and require more effort to identify, validate, and implement.
At that point, optimisation is no longer the problem. Architecture is.
Optimisation improves efficiency within a system. Architecture determines how that system behaves in the first place.
The layer nobody audits: environment and control
Behind every workload is an environment. This includes the infrastructure provider, the pricing model, the managed services in use, and the level of control the team actually has over each layer.
These decisions are made early, often for speed and under pressure. A managed orchestration service is chosen because it reduces operational overhead at the time. A cloud provider is selected because the team is familiar with it. Defaults are kept because there is no immediate reason to revisit them.
Over time, those decisions become boundaries.
Most teams do not notice this until those boundaries start limiting what they can change.
Control exists across compute, storage, networking, and orchestration. Each layer introduces its own constraints, shaping what teams can change, optimise, or influence over time. In a fully managed environment, those constraints remain largely invisible until scale reveals them. In a more self-managed environment, the constraints are explicit, but the operational burden is higher.
Neither approach is wrong. But both need to be understood, not assumed.
These patterns often surface in specific ways. Storage grows quietly through logs and replication. Data transfer increases between services and regions. Per-request pricing accumulates at scale. None of these feel significant in isolation, but together they create cost behaviour that was never designed intentionally.
Why the same workload costs differently depending on where it runs
Consider two teams running a similar event-driven pipeline.
One runs it on a fully managed platform. Setup was fast. Operational overhead is low. But at volume, per-invocation pricing and data transfer costs create a spend profile that was never modelled at design time. The FinOps team can see the variance but cannot change it without significant re-architecting. The platform engineers know what would need to move but cannot justify the migration cost in the current quarter. The CTO is now making a reactive architectural decision under pressure.
The other team runs on a more controlled environment with a different pricing model. Operational overhead is higher. Management responsibility is greater. But cost behaviour is more predictable at scale. That trade-off was made deliberately at the start.
Same workload. Different structure.
This is what structural cost looks like in practice. It reflects earlier decisions about how the system was designed and where it runs.
Workloads are often placed where it is most convenient at the time, without clear ownership of how those decisions perform over time. Finance finds out six months later when the invoice arrives.
What this means for each team
For FinOps teams:
Visibility without control is a difficult position to be in. When costs are structural, the standard FinOps levers surface the problem accurately but do not create a path to change it. Architectural decisions determine what can actually be changed. That is why FinOps practitioners are now embedding financial requirements earlier in engineering and product lifecycles, as explored in our article on the hidden costs of DevOps inefficiencies. Pre-deployment cost awareness is becoming more important, with teams building pricing models and offering guidance before infrastructure is committed. FinOps insight needs to feed back into architectural reviews, not just reporting.
For DevOps and platform engineers:
The optimisation ceiling is a signal worth acting on. When tuning the same parameters stops producing meaningful results, the question shifts from how to run a system more efficiently to whether it is running in the right place. Shift-left FinOps reframes architecture decisions as economic decisions. Once waste is prevented upstream, it disappears from downstream reporting. Placement decisions sit with engineering, even when the impact shows up in finance.
For engineering leaders:
The risk that does not show up early is the one that compounds quietly. Decisions made for speed create constraints that become harder to reverse as systems grow. Vendor dependencies, data residency requirements, and pricing structures that made sense at one stage may not hold at the next. The State of FinOps 2026 report finds that FinOps practitioners with senior leadership engagement show significantly more influence over technology selection decisions. Architecture and financial governance are converging at the leadership level. That is not a FinOps trend. It is a strategic one.
Moving from optimisation to architecture
Recognising the ceiling is the first step. Knowing what to do next is the harder one.
The shift is not about abandoning optimisation. It is about asking different questions when optimisation stops producing answers:
- Where should this workload run?
- What level of control is actually required?
- Are the defaults chosen earlier still appropriate?
- What constraints are being introduced without being fully understood?
A useful trigger is when consecutive optimisation cycles produce diminishing returns without a change in underlying usage patterns. At that point, the conversation should move from tuning to placement.
Architecture is not a one-time design step. At scale, it becomes an ongoing consideration, as discussed in our overview of CloudOps and operational maturity. It shapes cost, performance, flexibility, and what a team can actually do when something needs to change.
Where this becomes difficult in practice
Most teams can see what they are spending, and they can often explain why. What they cannot easily do is evaluate whether workloads are running in the right environment to begin with.
Cost visibility is not the same as placement visibility.
Understanding cost at this level requires comparing environments, pricing models, and control trade-offs before decisions are locked in. It requires looking at how workloads behave across different setups, not just how they perform in the current one.
In some cases, this means introducing tools that help compare environments and understand how placement decisions affect cost behaviour before those decisions become difficult to change.
Final thoughts
The question is not whether your team is optimising well. Most are.
The question is whether the system being optimised was ever designed for where the business is trying to take it.
Costs that cannot be moved, performance issues without clear bottlenecks, and improvements that feel smaller over time are often symptoms of structural decisions made under different constraints, at an earlier stage of growth.
Recognising that distinction allows teams to make different decisions, not just better optimisations.
For teams navigating similar challenges, there’s more practical perspectives on workload placement, FinOps, and cloud architecture across our blog.
More on Cloud, FinOps, and DevOps at tardi.tech/blog