The International Data Corporation (IDC) estimates that up to 30% of cloud spend may be classified as waste, even as cloud adoption becomes more mature. Every unnecessary pound spent on cloud infrastructure is a pound that cannot be invested in product development, customer acquisition, operational resilience or future growth. Cloud cost optimisation is therefore not simply about reducing infrastructure costs. It is about improving operating margins while ensuring cloud investment continues to support business objectives.
For many UK enterprises, the challenge has moved beyond infrastructure optimisation. Rightsizing, reserved instances and auto-scaling remain important, but infrastructure optimisation alone rarely delivers sustainable cost reduction. Some of the largest opportunities come from architectural and delivery decisions made much earlier in the software lifecycle.
In many organisations, one of the largest sources of avoidable spend is the number and size of non-production environments needed to develop, test and release software. Tightly coupled architectures and traditional release processes often require multiple long-lived development, integration and end-to-end environments. Adopting more loosely coupled architectures and Continuous Delivery can reduce both the number and size of those environments, lowering infrastructure costs while also improving delivery speed and operational efficiency. Waste nevertheless persists because cloud cost governance often sits outside normal engineering, finance, procurement and risk decisions. Closing that operating gap is what turns cloud cost optimisation from a one-off saving exercise into a sustainable business capability.
What cloud cost optimisation actually means (and why most definitions stop too early)
Cloud cost optimisation is the ongoing alignment of cloud spend with business value. It is not a one-off cost-cutting exercise or the purchase of another optimisation tool. It combines visibility into how cloud resources are used, clear accountability for the decisions that drive spend and technical practices such as rightsizing, tagging, automation and selecting the most appropriate pricing commitments.
FinOps is the operating framework that enables that alignment. It brings engineering, finance, procurement and business leaders into a shared decision-making process, rather than leaving infrastructure decisions inside engineering and their commercial consequences inside finance. The objective is not simply to reduce cloud costs. It is to maximise the value created by every pound invested.
The distinction matters. Cost reduction is an event. Cost governance is a capability. Many organisations complete a rightsizing programme or reserved-instance initiative, only to see costs rise again because ownership, incentives and governance have not changed. Sustainable cloud cost optimisation comes from embedding accountability, measurement and continuous review into day-to-day operations, not from treating optimisation as a project with a defined end date.
Why the waste persists even in mature organisations
The FinOps Foundation’s 2025 State of FinOps survey, covering organisations responsible for more than $69 billion in public cloud spend, found that workload optimisation and waste reduction remained the discipline’s leading priority. If cloud waste were primarily a knowledge problem, it would not continue to dominate FinOps agendas year after year.
The underlying issue is usually organisational rather than technical. Engineering teams provision resources, finance teams approve invoices and procurement teams negotiate supplier commitments, but those functions often do not review demand, utilisation, business value and commercial outcomes together. As a result, ownership becomes fragmented, decisions are made in isolation and no single team is accountable for explaining why cloud costs are increasing or ensuring that savings are sustained.
Architecture and delivery practices can reinforce those organisational problems. Many organisations continue to operate multiple long-lived development, integration and end-to-end environments because their applications are tightly coupled and their release processes depend on sequential testing across increasingly large environments. Moving towards more loosely coupled architectures and Continuous Delivery can reduce both the number and complexity of environments required, lowering infrastructure consumption while simplifying software delivery. This demonstrates that sustainable cloud cost optimisation depends as much on engineering decisions as financial governance.
This is particularly evident after cloud migration. Many organisations expect migration itself to reduce costs, but moving workloads to the cloud does not eliminate inefficient architecture, duplicated services, idle environments or unclear ownership. It often makes those weaknesses more visible and more expensive because they now generate metered cloud consumption. As our Cloud Migration Assessment guide explains, effective cloud cost governance should begin before migration decisions are made and continue long after production cutover.
The regulatory blind spot. Cloud cost governance and operational resilience
For UK financial services firms, cloud cost decisions are not simply a spending issue. Material choices about cloud providers, regions, architecture and recovery capacity can also affect the resilience of important business services. Decisions that appear commercially attractive in isolation may introduce operational or third-party risks that have wider business consequences.
The FCA’s operational resilience transition period ended on 31 March 2025. In its March 2026 review of firms’ self-assessments, the FCA reported strong engagement but identified further work on dependency mapping, third-party vulnerabilities and using mapping outputs to guide testing and remediation.
The regulatory landscape tightened again in July 2026. From 13 July, Microsoft Ireland Operations Limited, Google Cloud EMEA Limited, Amazon Web Services EMEA SARL and Oracle Corporation UK Limited were designated as Critical Third Parties to the UK financial sector. The Bank of England, PRA and FCA can now oversee the critical services those providers provide to financial firms. The designation does not transfer responsibility, however. Firms remain accountable for understanding and managing the risks created by their own third-party arrangements.
The FCA does not regulate cloud costs. Its concern is whether firms can continue delivering important business services within defined impact tolerances during disruption. That said, operational resilience work can provide valuable inputs into FinOps. Dependency mapping identifies critical business services, technology components, service owners and third-party relationships, creating a foundation that cloud cost governance can build upon. The overlap is significant, but not complete. Effective cloud cost optimisation also requires billing allocation, usage data, tagging coverage, commitment utilisation, forecasting and unit-cost measures that resilience mapping alone does not provide.
What the resilience findings mean for cloud cost decisions
Not every cloud purchasing decision creates a new regulatory obligation. However, material changes affecting an important business service should be evaluated through both a commercial and resilience lens. For example, consolidating workloads onto a single cloud provider may improve committed-use pricing but increase supplier concentration risk. Conversely, a multi-cloud strategy may reduce dependency on a single provider while increasing operational costs, architectural complexity and the skills needed to manage it effectively.
Cloud spend that supports tested failover capability, backups, security logging, recovery environments or geographic redundancy is not automatically waste. Effective FinOps distinguishes oversized or under-utilised resources from deliberate resilience investment and records the business or regulatory outcome that investment supports. The objective is not to minimise cloud spend at any cost, but to remove expenditure that creates no measurable value while protecting the capabilities that keep important business services available during disruption.
The government angle. G-Cloud 15 and procurement control
For public sector organisations, many of the same principles apply through procurement rather than financial regulation. Long-term cloud costs are shaped not only by technical architecture but also by commercial decisions that determine supplier flexibility, pricing, competition and the ability to adapt as requirements change.
The official G-Cloud 15 tender estimates a framework value of £14 billion excluding VAT, with planned contract dates from 17 September 2026 to 16 September 2030. It is intended to replace G-Cloud 14, G-Cloud 14 Lot 4 and Cloud Compute 2. The comparison with G-Cloud 14 is not like-for-like. G-Cloud 14 Lots 1 – 3 had an official framework value of £6.5 billion, with a separate £1 billion value for Lot 4, while G-Cloud 15 also incorporates Cloud Compute services.
The larger framework value should therefore not be interpreted as simple market growth. The more important question for buyers is whether a procurement creates lasting commercial control. That means transparent consumption data, clear exit provisions, portable data, credible alternative suppliers and sufficient competition to maintain negotiating leverage throughout the life of the contract. As we have argued in our work on vendor lock-in, concentration becomes a commercial and cost problem when an organisation can no longer negotiate effectively, switch suppliers or redesign its architecture on its own terms.
What good cloud cost governance should measure
Cloud cost governance becomes effective when recurring problems are translated into measurable indicators, clear ownership and defined actions. The objective is not simply to report cloud spend, but to identify where costs are increasing, understand why and ensure someone is accountable for responding. A practical starting point looks like this:
| Recurring symptom | Measure | Accountable owner | First action |
|---|---|---|---|
| Spend cannot be traced to a service or team | Percentage of spend allocated to a product, service and owner | Platform or FinOps lead | Enforce ownership tags and report approved exceptions |
| Cloud cost rises faster than demand | Cost per transaction, customer or workload | Product owner with finance | Define a unit-cost baseline and investigate variance |
| Savings disappear after an optimisation sprint | Savings retained after 90 and 180 days | FinOps owner | Create a monthly review and prioritised optimisation backlog |
| Reservations or savings plans are underused | Commitment coverage and utilisation | Platform, finance and procurement | Right size before renewal or new commitment |
| Cost anomalies remain unresolved | Time to detect, assign and resolve anomalies | Named service owner | Route alerts into the existing incident workflow |
| Resilience capacity is labelled as waste | Spend linked to a tested resilience objective | Architecture and risk owner | Classify protected capacity and record the reason it exists |
Proof point. How architecture optimisation released infrastructure capacity
A global mobile network provider had consolidated multiple legacy systems onto a single platform. The resulting environment was oversized, under-tested and operationally unstable, contributing to 243 hours of lost trading time each week.
Catapult CX stabilised the platform through two complementary workstreams:
- Migrating Oracle databases to higher-performance storage
- Simplifying an over-engineered server architecture.
Billing performance improved by more than 1,000-fold, the planned release outage window reduced from 21 days to 30 minutes and 42 physical servers were released for other use. Read the global network provider case study.
This was a platform modernisation engagement rather than a standalone cloud cost optimisation project, but it illustrates an important principle.
Simplifying architecture frequently improves performance, resilience and infrastructure efficiency at the same time. It can also reduce the number and size of development, integration and test environments needed to support software delivery, particularly where loosely coupled architectures and Continuous Delivery replace traditional release models. Rather than treating cost reduction as a separate initiative, organisations should optimise the underlying architecture that drives service quality, delivery performance and resource consumption.
Where to start. A practical cloud cost governance checklist
Cloud cost optimisation does not require an immediate platform redesign or a large central FinOps function. Most organisations achieve meaningful improvements by establishing a small number of governance controls that make ownership, decision-making and accountability explicit. A practical starting point is:
- Assign one accountable owner. A committee can contribute, but one person or team should own cloud cost reporting, investigation and follow-through. That owner needs sufficient engineering context and organisational authority to challenge demand and drive action.
- Map spend to business services. Connect billing and usage data to products, important business services, teams and suppliers. Reuse operational resilience mapping where it is relevant, then supplement it with the financial, utilisation and unit-cost data FinOps requires.
- Separate waste from intentional capacity. Record why standby environments, recovery capability, security controls and geographic redundancy exist so optimisation efforts do not remove resources that support resilience or regulatory objectives.
- Right size before renewing commitments. Reserved instances, savings plans and other committed-use discounts lock in today’s baseline. Eliminate idle and oversized resources before entering longer-term commercial commitments.
- Embed cost into delivery and procurement. Make cloud cost visible within architecture reviews, engineering backlogs, procurement decisions, incident management and supplier renewals. Sustainable optimisation comes from integrating cost governance into day-to-day delivery rather than treating it as a finance reporting exercise.
If cloud costs have become difficult to explain, or the estate is too fragmented to assess internally, an independent review can establish a clear baseline and prioritise the highest-value improvements. Catapult CX’s DevOps Health Check is a 30-day embedded engagement that examines delivery performance, platform architecture, infrastructure efficiency and cloud cost governance together, helping organisations improve reliability, release performance and long-term cost control.
Frequently Asked Questions
What is cloud cost optimisation?
Cloud cost optimisation is the ongoing process of aligning cloud spend with business value. It combines governance, visibility and technical practices such as rightsizing, tagging, automation and pricing commitments to reduce unnecessary spend without compromising performance, security or operational resilience.
What is FinOps?
FinOps is an operating framework that brings engineering, finance, procurement and business teams together to make informed, accountable decisions about cloud spend. It treats cloud cost as a shared responsibility and links infrastructure investment to measurable business outcomes.
How much cloud spend is typically wasted?
According to International Data Corporation (IDC), up to 30% of cloud spend may be classified as waste that can potentially be optimised. This is an industry estimate rather than a guaranteed level of savings for every organisation.
Who should own cloud cost optimisation?
Cloud cost optimisation should have a single accountable owner, even though responsibility is shared across multiple teams. In many organisations this sits with a FinOps lead, cloud platform team or engineering function working closely with finance, procurement and product owners.
Does the FCA regulate cloud costs?
No. The FCA does not regulate cloud costs directly. Its operational resilience framework focuses on whether firms can continue delivering important business services within defined impact tolerances during disruption. Operational resilience work can support FinOps, but cloud cost governance also requires billing, utilisation, tagging and unit-cost data.
What changed with Critical Third Parties in July 2026?
From 13 July 2026, Microsoft, Google Cloud, Amazon Web Services and Oracle entities were designated as Critical Third Parties to the UK financial sector. The designation allows UK regulators to oversee the critical services they provide, but financial firms remain responsible for managing their own third-party risks.
What is G-Cloud 15?
G-Cloud 15 is the proposed successor to G-Cloud 14 and Cloud Compute 2. The official tender estimates a framework value of £14 billion (excluding VAT), with planned contract dates running from 17 September 2026 to 16 September 2030.
When should an organisation start cloud cost optimisation?
Cloud cost optimisation should begin before major migration or platform modernisation programmes, not afterwards. Establishing ownership, governance and cost visibility early helps prevent inefficient architecture, duplicated services and poor utilisation becoming embedded in the new environment.
How is cloud cost optimisation different from cost cutting?
Cost cutting is typically a one-off activity, such as a rightsizing exercise or contract renegotiation. Cloud cost optimisation is an ongoing organisational capability that combines governance, accountability, measurement and continuous improvement to ensure cloud investment continues to deliver business value over time.
