DigiUsher Briefing May 21, 2026

Board-Level Cloud and Data Centre ROI: Governing the Full Technology Estate in 2026

Cloud waste runs at 29-35% of spend. GPU idle time hits 30-60%. Data centre costs surpass $650B in 2026. Here is the board-level governance framework that connects every infrastructure dollar to measurable business value.

Author

DigiUsher

Read Time

26 min read

board technology reporting FinOps Operating System owned data centre governance

Cloud waste runs at 29–35% of spend. GPU idle time hits 30–60% on most enterprise ML pipelines. Data centre spending is crossing $650 billion globally in 2026. And the vast majority of enterprise boards are receiving a financial report that covers, at best, the public cloud bill.

The governance gap between what enterprises are investing in technology infrastructure and what they can account for at board level has never been wider — because the estate has never been more complex. Public cloud across five or more hyperscalers. Kubernetes clusters running on two or three of them. Nvidia GPU hardware servers in company-owned data centres. Rack space in third-party colocation facilities. Private cloud infrastructure carrying workloads that never completed their migration. Every one of these categories is growing. Every one carries its own cost behaviour, depreciation profile, and waste pattern. And in most large enterprises, only one of them — public cloud — has anything approaching board-level financial governance.

Gartner’s February 2026 forecast projects worldwide IT spending at $6.15 trillion in 2026, with total data centre spending expected to increase 31.7%, surpassing $650 billion — up from nearly $500 billion the previous year. Server spending is projected to accelerate at 36.9% year-over-year. These are capital deployment numbers that audit committees govern for any other asset class on the balance sheet. The question is why the governance architecture for technology infrastructure has not kept pace with the capital commitment it is meant to account for.

This briefing answers that question — and sets out the framework that closes it.

Executive Summary

Total data centre spending is expected to increase 31.7%, surpassing $650 billion in 2026 — making the full technology estate a material capital allocation programme requiring board-level governance. Cloud waste persists at 29–35% of IaaS and PaaS spend — estimated at $44.5 billion globally — despite rising FinOps adoption, because governance architecture has not kept pace with estate complexity. What was once a cloud-focused practice is now definitively multi-technology: 90% of respondents now manage SaaS or have plans to, alongside licensing (64%, up 15%), private cloud (57%, up 18%), and data center (48%, up 12%). GPU idle time runs at 30–60% for most enterprise ML pipelines, meaning owned Nvidia GPU hardware frequently consumes its full three-year TCO of $711,950–$947,730 per 8x H100 server while generating partial or no productive output. On-premises GPU infrastructure can deliver up to an 18x cost advantage per million tokens compared to Model-as-a-Service APIs for sustained, high-utilisation workloads — but only above a utilisation threshold most organisations do not consistently reach. Organisations using structured FinOps frameworks are 2.5x more likely to meet or exceed their cloud ROI expectations.

The Full Estate Accountability Problem — and Why Public-Cloud-Only Governance Fails Boards

The average large enterprise in 2026 operates technology infrastructure across at least four structurally different cost categories: public cloud, private cloud or owned data centre, third-party colocation, and AI or GPU hardware that exists in combinations of all three. Each has a different capital structure, cost-per-unit behaviour, depreciation treatment, and waste profile. A CFO governing only the public cloud bill is answering a partial question — and boards are increasingly aware of the difference.

The FinOps Foundation’s State of FinOps 2026 confirms the structural reality. What was once a cloud-focused practice is now definitively multi-technology. AI management has become nearly universal at 98%. An emerging 28% are beginning to or plan to include labour costs, signalling continued expansion toward total technology value management.

FinOps is now firmly anchored in technology leadership, with 78% of practices reporting into the CTO/CIO organisation, up 18% vs 2023 data. The expansion is not a FinOps community trend — it is a board governance requirement arriving from the top. CFOs who cannot report on the full technology estate cost surface are being asked why, in direct terms, by audit committees that have started treating technology capital deployment as equivalent to any other material asset class.

The FinOps Foundation’s 2026 Framework update introduced Executive Strategy Alignment as a new Capability in the Manage the FinOps Practice Domain, connecting technology-related value to the organisation’s business strategy and priorities, helping leaders compare options, make tradeoffs, and govern investment for value. The framing is significant: FinOps is no longer positioned as a cost-cutting discipline for engineering teams. It is positioned as the technology value management function that boards need to make infrastructure capital allocation decisions.

Technology Value Management is the enterprise discipline of governing the full technology cost surface — public cloud, private cloud, owned data centres, third-party colocation facilities, GPU hardware, SaaS, and AI workloads — as a single, integrated capital portfolio with consistent attribution, unit economics measurement, and board-level ROI accountability across every infrastructure category. It represents the maturation of FinOps from a cloud-cost optimisation practice into a strategic financial governance function that connects every technology investment to measurable business outcomes, enabling CFOs and boards to make technology capital allocation decisions with the same rigour applied to any other material asset class.

The governance challenge is not that boards are asking new questions. It is that the estate has expanded faster than the financial infrastructure built to account for it.

What Cloud Waste Actually Costs at Board Scale

Cloud waste is one of the most widely cited statistics in enterprise technology management — and one of the least acted upon, because it is consistently presented as a utilisation metric rather than a financial impact.

Flexera’s 2026 State of the Cloud Report shows dedicated FinOps teams have climbed to 63% adoption, and Cloud Centers of Excellence are now present at 71% of organisations. Yet Flexera’s 2026 data puts the waste rate at 29% of IaaS and PaaS spend — a figure that has hovered between 27% and 32% since 2019. CloudZero’s survey of 475 senior leaders puts the figure higher at 35%, noting that the decline in cloud efficiency is not a laggard problem — the top quartile of operators all moved in the same direction. A Harness FinOps in Focus report projects roughly $44.5 billion in infrastructure cloud waste globally, driven by a persistent disconnect between FinOps strategy and developer behaviour.

The persistence of this waste rate despite significant FinOps investment is structural rather than operational. Most cloud cost management platforms govern the resources they can see — tagged resources in well-governed accounts. The ungoverned portion of the estate — Shadow IT, developer-deployed resources that bypass cost allocation policies, Kubernetes workloads running without namespace attribution — continues to generate waste outside the governance perimeter. That ungoverned waste does not appear in the FinOps team’s weekly optimisation report. It appears in the quarterly cloud bill as a number that cannot be fully explained to an audit committee.

For boards, the consequence is an accountability gap that no volume of rightsizing recommendations resolves. A cloud cost reduction from £40M to £36M is a 10% improvement in a number the CFO cannot fully account for. It does not tell the board what the £36M is returning in business outcomes.

The metric that changes the board conversation is not waste percentage — it is attribution coverage: the proportion of total cloud spend assigned to a responsible cost owner with a unit economics target. Organisations using structured FinOps frameworks are 2.5x more likely to meet or exceed their cloud ROI expectations. The differentiator is not spending less. It is spending with accountability at the workload and business-unit level.

The FinOps Cloud+ Governance Requirement

FinOps Cloud+ is the operational model in which FinOps governance practices — cost attribution, unit economics, anomaly detection, chargeback, commitment management, and waste elimination — are extended beyond public cloud infrastructure to cover the full enterprise technology estate: private cloud, owned data centres, third-party colocation, GPU hardware, SaaS, AI workloads, and marketplace transactions. FinOps Cloud+ recognises that enterprise boards hold CFOs accountable for the total technology spend, not just the public cloud bill, making single-scope governance frameworks structurally insufficient for board-level reporting in 2026.

In practice, the movement from public-cloud FinOps to FinOps Cloud+ requires governance architecture that can ingest, normalise, and attribute cost data from fundamentally different billing formats: hyperscaler cost exports, colocation invoices, depreciation schedules for owned hardware, power and cooling utilisation from building management systems, and GPU utilisation telemetry from hardware monitoring platforms. Without a single normalised data model across all of these — FOCUS 1.x provides that standard at the specification level — cross-category unit economics comparisons remain manual, inconsistent, and impossible to present with confidence at board level.

Owned data centres and third-party colocation facilities represent a fundamentally different financial management challenge to public cloud — and in most large enterprises, they are governed with significantly less rigour than the cloud infrastructure sitting alongside them.

The difference begins with capital structure. Public cloud spend is operational expenditure that flows through the P&L on a monthly basis, is visible in billing dashboards, and generates alerts when it deviates from forecast. Owned data centres carry capital assets — servers, networking, power and cooling infrastructure — that sit on the balance sheet with multi-year depreciation schedules, and operational costs — power, maintenance, staffing — that land in facilities budgets rather than technology budgets. The cost of running a workload in an owned data centre is never presented as a single number in the way a cloud compute instance is. It requires an allocation model that spans asset depreciation, power consumption, cooling overhead, physical space, network connectivity, and staffing. Most enterprise FinOps functions have not built that model.

Third-party colocation sits between the two extremes. The enterprise owns its hardware but pays the facility for physical infrastructure services — power, cooling, physical security, and connectivity. Rack space in a colocation facility adds $1,000 to $5,000 per month for a four to eight GPU system. An 8-GPU H100 server cluster in high-density configuration requires multiple racks. At typical colocation rates, that represents $48,000–$480,000 per year in facility costs alone, before hardware capital cost, networking, staffing, and software stack are included — a material cost centre that does not appear in any cloud billing dashboard and rarely appears in any FinOps governance report.

Most enterprise FinOps functions do not include any of this in their board reporting. The cloud team reports on cloud spend. The facilities team reports on data centre operating costs. The two numbers never appear in the same financial model, and boards that want to understand whether a workload should run on cloud or in the company’s owned data centre cannot get a defensible answer — because no one has built the attribution model that makes those two environments comparable on a unit economics basis.

The Three Infrastructure Categories That Boards Need to Govern Separately

Owned data centres carry the full ownership burden: capital investment in building and infrastructure, long-term power contracts, staffing for operations and security, and the depreciation cliff that arrives when hardware generations turn. The primary governance risk is stranded capacity — hardware purchased for projected workload growth that did not materialise, or that has been partially migrated to cloud without full decommission of the underlying physical infrastructure. Enterprises that migrated aggressively to cloud between 2020 and 2024 frequently discovered that owned data centre costs were not materially reduced by the migration, because fixed infrastructure costs continued regardless of server utilisation.

Third-party colocation provides more flexibility than owned facilities while retaining equipment control that cloud does not. Many organisations report that managing cloud spend is their top challenge; egress fees and associated patterns affect a growing share of firms, and the FinOps community places unit economics and allocation at the centre of cost accountability. The governance risk is contractual commitment to rack space and power capacity that may not match actual utilisation — and the same depreciation exposure on owned servers that exists in owned facilities, compounded by egress costs when data moves between the colocation facility and cloud services.

GPU hardware in both environments creates a distinct governance challenge because it combines the highest capital cost per unit of any enterprise computing hardware with the most variable utilisation profile of any workload category. A single 8x H100 SXM5 server carries a three-year TCO of between $711,950 and $947,730, according to GMI Cloud’s infrastructure analysis. Staff costs alone account for $225,000 to $300,000 over three years for 0.5 FTE of infrastructure engineering time. At that capital commitment per server, GPU idle time is not a utilisation metric — it is a capital destruction figure that belongs in the board report.

The Nvidia GPU Capital Decision — and Why Most Boards Are Getting It Wrong

The decision to own versus rent Nvidia GPU hardware is the most consequential technology capital allocation question most large enterprises will face in 2026. It is also one of the most commonly made without adequate financial modelling.

The case for owning GPU hardware is compelling under the right conditions. According to Lenovo Press’s 2026 Generative AI TCO report, on-premises infrastructure can deliver up to an 18x cost advantage per million tokens compared to Model-as-a-Service APIs for sustained, high-utilisation workloads. The upside: once hardware is paid off, on-prem delivers a five-year operational saving of approximately $3.4 million compared to equivalent sustained cloud usage for high-utilisation workloads.

The problem is that the “sustained, high-utilisation” condition is harder to achieve than most GPU capital proposals acknowledge. The break-even threshold for on-premises hardware is sustained utilisation above 60–70%. Below that, cloud rental is almost always cheaper once you factor in operational overhead. Idle GPU time runs at 30–60% utilisation for most ML pipelines. When that idle fraction is included in the TCO calculation, the on-premises economics deteriorate significantly.

A significant change happened to GPU cloud economics in June 2025: AWS cut H100 pricing on P5 instances by 44%, dropping from approximately $7.57 per GPU-hour to $3.90. GCP and Azure followed with comparable reductions. On-demand H100 rental rates across the three major hyperscalers now range from $3.00 to $6.98 per GPU per hour as of April 2026. Any enterprise making a GPU hardware ownership decision based on 2024 cloud pricing comparisons is using stale inputs that structurally favour the on-premises case against a market that has moved significantly.

GPU TCO Decision Framework: Board-Ready Cost Comparison
─────────────────────────────────────────────────────────────────────────
Configuration: 8x H100 SXM5 server cluster
─────────────────────────────────────────────────────────────────────────
OWNED HARDWARE (3-Year TCO, fully loaded)
─────────────────────────────────────────────────────────────────────────
Hardware acquisition (8x H100 SXM5 server)       $711,950–$947,730
Colocation facility costs (est. 3yr)             $144,000–$432,000
  └─ Rack space ($1,000–$5,000/rack/month)
  └─ Power and cooling (700W/GPU x 8)
Engineering operational overhead                  $225,000–$300,000
  └─ 0.5 FTE infrastructure engineering (3yr)
NVMe storage + InfiniBand networking              +30–50% HW cost Yr1
─────────────────────────────────────────────────────────────────────────
TOTAL 3-YEAR OWNED TCO (est.)                    ~$1.1M–$1.7M
─────────────────────────────────────────────────────────────────────────
CLOUD RENTAL (3-Year at April 2026 market rates)
─────────────────────────────────────────────────────────────────────────
Hyperscaler on-demand (avg ~$4.50/GPU-hr, 24/7)  ~$951,120 (3yr)
Reserved 1-year commitment (30–40% discount)      ~$570,000–$665,000
Specialised GPU provider (~$2.50/GPU-hr, 24/7)   ~$526,000 (3yr)
─────────────────────────────────────────────────────────────────────────
BREAK-EVEN UTILISATION THRESHOLD
─────────────────────────────────────────────────────────────────────────
Owned hardware becomes cost-competitive:          >60–70% sustained util.
Typical enterprise GPU idle rate:                 30–60%
─────────────────────────────────────────────────────────────────────────
BOARD QUESTION: What is the current GPU fleet utilisation rate?
If below 60%, the ownership case requires scrutiny at board level.
─────────────────────────────────────────────────────────────────────────

The board governance requirement is not to choose one model — it is to make the choice with a defensible, utilisation-grounded financial model rather than a procurement preference or vendor relationship. Enterprises that have purchased GPU hardware based on projected utilisation that has not been achieved are carrying a capital position that does not match its financial case. That discrepancy needs to be surfaced at board level, not managed silently through a utilisation improvement target buried in a technology roadmap.

The Three Hidden Costs That Routinely Break GPU TCO Models

Three cost categories are systematically excluded from enterprise GPU TCO models, and their exclusion is the primary reason GPU capital proposals underestimate long-term cost.

Data egress is the first. When AI training data lives in cloud object storage and inference results return to cloud applications, an on-premises or colocation GPU cluster incurs data transfer costs between the facility and the cloud environment. Data egress on AWS runs $0.09/GB above 10 TB/month; 1 PB of data transfer generates $92,000 in egress costs annually. This line item appears in no GPU hardware procurement proposal.

Hardware obsolescence is the second. NVIDIA’s H200 and B200 GPUs are already available on select platforms, with 2–2.5x the performance of the H100 for LLM training. As these newer instances gain availability, H100 pricing will likely drop further. NVIDIA’s next generation, Vera Rubin, is expected to deliver 10x inference throughput per watt. Enterprises that committed to owned H100 hardware on a five-year depreciation schedule are now holding hardware whose cloud-equivalent cost is falling every quarter — meaning the ownership premium grows over the life of the asset rather than diminishing.

Lock-in cost is the third. 45% of IT leaders report that vendor lock-in has already prevented them from adopting better tools, in a 2025 survey of 1,000 enterprise technology decision-makers. For GPU infrastructure, lock-in manifests as CUDA dependencies and model frameworks optimised for specific hardware generations that make workload migration expensive enough to defer even when the financial case for migration is clear.

The Technology Value Management Framework: What Board-Ready Infrastructure Reporting Looks Like

The board report that CFOs need to produce for a $650 billion infrastructure market cannot be the public cloud bill with data centre costs appended as a footnote. It requires a framework that makes every infrastructure category comparable through unit economics, identifies financial waste in each category separately, and supports the workload placement decisions that determine whether capital is allocated to the right infrastructure type.

The Technology Value Management framework for board reporting has five components, each producing a board-usable financial signal rather than an operational metric.

The first component is a full estate cost inventory. Every infrastructure category — public cloud spend, private cloud infrastructure, owned data centre costs, colocation facility charges, and GPU hardware depreciation and operating costs — appears in the same financial model, normalised to a consistent unit of analysis through a FOCUS-compatible data schema rather than left in its native billing format. The question “what does it cost to run Product X” has a defensible answer across every infrastructure layer on which that product runs.

The second component is cross-category unit economics. Unit economics are calculated for each infrastructure category using the same methodology — cost per transaction, cost per application, cost per workload hour — so the board can compare the efficiency of public cloud versus colocation versus owned hardware on a like-for-like basis. A workload running on owned GPU hardware at 40% utilisation can be compared, in financial terms, to the same workload running on reserved cloud capacity at current April 2026 market rates, and the board can see which placement is generating the better return.

The third component is waste quantification by category.

Full Estate Waste Quantification: Board Reporting Template
─────────────────────────────────────────────────────────────────────────
CATEGORY          WASTE TYPE              QUANTITY    £ IMPACT  PRIORITY
─────────────────────────────────────────────────────────────────────────
Public Cloud      Idle compute             XX%        £X.XM     High
                  Over-provisioned         XX%        £X.XM     High
                  Untagged / ungoverned    XX%        £X.XM     Critical
Private Cloud     Stranded capacity        XX%        £X.XM     Medium
                  Shadow workloads         XX%        £X.XM     High
Owned DC          Unused server racks      XX%        £X.XM     Medium
                  Stranded post-migration  XX%        £X.XM     High
Colocation        Unoccupied rack space    XX%        £X.XM     Medium
                  Idle GPU capacity        XX%        £X.XM     Critical
GPU Hardware      Fleet idle time          XX%        £X.XM     Critical
                  Model / token waste      XX%        £X.XM     High
─────────────────────────────────────────────────────────────────────────
TOTAL WASTE EXPOSURE                                  £XX.XM
  of which: Immediately recoverable                   £XX.XM
  of which: Structural / architecture-driven          £XX.XM
─────────────────────────────────────────────────────────────────────────

Presenting waste by category and type gives the board a governance prioritisation framework rather than a single waste percentage. The distinction between recoverable waste (idle instances, over-provisioned resources) and structural waste (architecture decisions requiring remediation rather than optimisation) is the distinction between a short-term P&L recovery and a medium-term investment decision. Both belong in the board report, separated rather than aggregated.

The fourth component is workload placement analysis. The placement question — should this workload run on public cloud, private cloud, owned data centre, or colocation — is a financial question that most enterprise technology functions answer as an engineering question. The Technology Value Management framework makes it financial, using cross-category unit economics to assign each workload category to its optimal placement at current market rates.

Workload Category	Cloud	Private / Colo	Owned Hardware
Elastic, variable demand	✅ Optimal	🔄 Consider reserved	✗ Over-committed capital
Steady-state, predictable	🔄 Reserved	✅ Optimal	✅ If util >60%
Regulated data perimeter	🔄 Sovereign cloud	✅ Preferred	✅ Preferred
GPU training (bursty)	✅ Optimal	🔄 Partial	✗ Idle cost between runs
GPU inference (high vol.)	🔄 Reserved	✅ If util >60%	✅ If util >60–70%
Dev / test / experimental	✅ On-demand / spot	✗ Over-committed	✗ Capital waste

The placement framework is not static. AWS’s 44% H100 price cut in June 2025 changed the economics for GPU inference workloads. New GPU generations arriving at two to 2.5x performance improvement per dollar change the obsolescence calculation for owned hardware commitments. Placement decisions made on 2024 data need re-evaluation against 2026 market rates, and a board reporting function needs to schedule that re-evaluation as a governance activity, not leave it to ad hoc engineering review.

The fifth component is attribution coverage as a leading board KPI. Attribution coverage — the proportion of total technology spend assigned to a responsible cost owner with a quantified unit economics target — is the leading indicator of Technology Value Management maturity. Mature practices focus on value capabilities: unit economics, AI value quantification, and influencing technology selection. The centre of gravity is spreading as teams take responsibility for increasing technology value, not just reducing technology cost. Attribution coverage as a board KPI formalises that shift — from cost reduction target to investment accountability metric.

How DigiUsher Governs the Full Technology Estate

DigiUsher operates as a FOCUS 1.x-native FinOps Operating System — not a public cloud cost tool with data centre reporting added on. The distinction is architectural. FOCUS-native means the data model is built from the ground up to normalise cost signals from structurally different billing formats: hyperscaler APIs, colocation invoices, hardware depreciation schedules, and GPU utilisation telemetry from owned server fleets. Every cost signal becomes comparable across infrastructure categories without manual reconciliation — which is the prerequisite for cross-category unit economics that Technology Value Management reporting requires.

Across public cloud, DigiUsher provides full multi-cloud cost attribution at the workload, namespace, and application level across AWS, Azure, GCP, OCI, and Alibaba Cloud. Kubernetes governance covers EKS, AKS, GKE, and OKE with namespace-level attribution that connects container workload costs to the product lines and business units consuming shared cluster capacity. Commitment coverage management optimises reserved instance and savings plan coverage across all cloud providers, with real-time anomaly detection that surfaces cost deviations at the service and workload level before they become quarterly budget events.

For private cloud, owned data centres, and third-party colocation, DigiUsher ingests infrastructure cost data from data centre management systems and colocation billing — normalising power, cooling, rack space, hardware depreciation, and staffing overhead into the same unit economics framework used for public cloud. A CFO can see the cost per workload across an owned data centre, a colocation facility, and AWS eu-west-1 in the same dashboard, with the workload placement comparison that identifies whether each workload is in its financially optimal location at current market rates and what the cost of moving it would be against the economic gain.

For Nvidia GPU hardware servers — in owned data centres, colocation facilities, or hybrid deployments — DigiUsher tracks GPU utilisation at the fleet and individual server level, calculates cost-per-inference and cost-per-token metrics for owned hardware, and surfaces GPU idle time as a quantified capital waste figure rather than a utilisation percentage. The GPU placement analysis module compares fully-loaded owned-hardware TCO against equivalent reserved or on-demand cloud capacity at current market rates — including egress costs, hardware obsolescence trajectory, and engineering overhead — to produce a defensible, board-ready answer to the ownership question. The European energy utility that achieved €1M in savings within 45 days using DigiUsher did so in part through GPU and infrastructure cost attribution that identified capital deployed against workloads with inadequate return.

For enterprises in financial services, healthcare, and government — where infrastructure cost attribution data contains sensitive operational and commercial information — DigiUsher deploys as a self-hosted instance within the client’s own cloud perimeter using its Secure Relay Proxy architecture. No infrastructure cost data leaves the governed environment. This deployment model was validated at institutional scale for a leading private bank requiring full data residency governance alongside complete cross-estate cost attribution — covering owned server infrastructure, colocation, and multi-cloud workloads within a single contained deployment.

DigiUsher is listed on AWS Marketplace through the AWS ISV Accelerate Partner programme and on Azure Marketplace as an Azure ISV Co-Sell Ready solution with MACC eligibility. Global delivery is supported by a partner ecosystem that includes four of the top ten global systems integrators, with Infosys and Wipro actively delivering DigiUsher implementations at enterprise scale. DigiUsher’s flat enterprise licensing model does not scale as a percentage of infrastructure spend — which matters specifically when the scope of governance expands from a single cloud bill to the full technology estate. The governance cost stays constant as the governed estate grows, which is the only pricing model that does not create a structural incentive to govern less.

Frequently Asked Questions

What is board-level cloud and data centre ROI and why does it matter in 2026?

Board-level cloud and data centre ROI is the financial accountability discipline in which an organisation demonstrates, at board level, that its full technology infrastructure investment generates measurable returns commensurate with the capital deployed. Gartner’s February 2026 forecast projects total data centre spending exceeding $650 billion in 2026, up 31.7% year-on-year. At that investment scale, infrastructure spending meets the materiality test for board-level capital governance, and CFOs without a unified Technology Value Management framework are answering a partial version of the board’s question.

What is Technology Value Management?

Technology Value Management is the enterprise discipline of governing the full technology cost surface as a single, integrated capital portfolio with consistent attribution, unit economics, and board-level ROI accountability across every infrastructure category. The FinOps Foundation’s 2026 State of FinOps confirms the transition: 48% of FinOps teams now manage data centre spend and 57% manage private cloud, with the Foundation’s 2026 Framework update introducing Executive Strategy Alignment as a core capability connecting technology cost governance to board-level strategy.

How much cloud spend is wasted in a typical large enterprise?

Cloud waste persists at 29% of IaaS and PaaS spend per Flexera’s 2026 data, and a Harness FinOps in Focus report projects roughly $44.5 billion in infrastructure cloud waste globally. CloudZero’s survey of 475 senior leaders found organisations running cloud infrastructure at 35% waste on average. The persistence reflects a governance architecture gap rather than an optimisation failure: FinOps teams govern the spend they can see, but significant portions of the estate remain outside the attribution perimeter. Organisations using structured FinOps frameworks are 2.5x more likely to meet or exceed their cloud ROI expectations.

When does on-premises Nvidia GPU hardware deliver better ROI than cloud rental?

On-premises GPU infrastructure can deliver up to an 18x cost advantage per million tokens for sustained high-utilisation workloads, with a five-year operational saving of approximately $3.4 million compared to equivalent sustained cloud usage. However, the break-even threshold for on-premises hardware is sustained utilisation above 60–70%. Idle GPU time runs at 30–60% utilisation for most ML pipelines, and a significant change happened in June 2025: AWS cut H100 pricing by 44%, dropping from approximately $7.57 per GPU-hour to $3.90, with GCP and Azure following with comparable reductions. Any enterprise making a GPU hardware ownership decision on 2024 cloud pricing comparisons is using stale inputs.

What is the difference between owned data centres, colocation, and cloud for board governance?

Owned data centres carry capital assets with multi-year depreciation schedules and fixed costs that continue regardless of server utilisation — making stranded capacity the primary governance risk. Colocation provides facility infrastructure while the enterprise owns its hardware. Rack space adds $1,000 to $5,000 per month for a four to eight GPU system. Contractual commitment to unoccupied capacity is the primary risk. Cloud is pure OpEx with maximum elasticity but with persistent 29–35% waste and vendor pricing discretion as the primary governance risks. A board-ready framework governs all three separately, with workload placement decisions driven by cross-category unit economics.

What FinOps governance model covers the full technology estate?

FinOps Cloud+ is the operational model in which FinOps governance practices extend beyond public cloud to cover private cloud, owned data centres, colocation, GPU hardware, SaaS, and AI workloads. It requires a FOCUS-normalised data model making unit economics comparable across all categories, attribution assigning costs to responsible owners everywhere, waste quantification by category type, cross-category workload placement analysis, and attribution coverage as a leading board KPI. The FinOps Foundation’s 2026 Framework update reflects this model, updating Governance, Policy and Risk and Automation, Tools and Services capabilities to address the full range of technology categories rather than cloud-specific defaults.

How should enterprises approach the cloud repatriation decision in 2026?

Cloud repatriation means relocating selected workloads from hyperscale public cloud to private infrastructure or managed colocation when economics, performance, jurisdiction, or exit constraints make that the better placement. It is not a retreat from the cloud. A practical assessment over a 12 to 36 month horizon classifies workload elasticity, models total cost of ownership with sensitivity to egress, cross-zone traffic, managed service premiums, software, facilities, people, and exit effort, and then compares unit economics before and after commitments.

How does DigiUsher govern the full technology estate across cloud, data centres, and GPU hardware?

DigiUsher operates as a FOCUS 1.x-native FinOps Operating System ingesting and normalising cost data from public cloud (AWS, Azure, GCP, OCI, Alibaba Cloud), Kubernetes (EKS, AKS, GKE, OKE), private cloud, owned data centres, third-party colocation, and Nvidia GPU hardware servers into a single, consistent attribution framework. GPU governance includes fleet-level utilisation tracking, cost-per-inference and cost-per-token metrics for owned hardware, GPU idle quantification as a capital waste figure, and workload placement analysis comparing owned TCO against current cloud market rates including egress, obsolescence trajectory, and engineering overhead. For regulated environments, DigiUsher deploys as a self-hosted instance within the client’s own perimeter, with flat enterprise licensing that does not scale as the governed estate grows.

References

Every enterprise infrastructure capital decision reduces to one question: is this asset deployed where it generates the best risk-adjusted return at current market rates? Technology Value Management is the governance discipline that answers that question — across every infrastructure category, every quarter, in the financial language boards require.

Ready to bring board-level Technology Value Management to your full infrastructure estate?

DigiUsher governs the complete technology cost surface — public cloud across AWS, Azure, GCP, OCI, and Alibaba Cloud; Kubernetes; private cloud; owned data centres; third-party colocation; Nvidia GPU hardware; SaaS; and AI workloads — through a single FOCUS 1.x-native FinOps Operating System with flat enterprise licensing. Deployable within your own cloud perimeter for regulated environments.

Request a 30-minute full-estate governance demonstration

Available on AWS Marketplace and Azure Marketplace. MACC-eligible. Delivered globally by Infosys, Wipro, and leading GSI partners. SOC 2 Type II certified. GDPR compliant. AWS ISV Accelerate Partner. Azure ISV Co-Sell Ready.

Related reading

Board-Level AI ROI: Why $600B in Investment Is Delivering Single-Digit Returns (15 May 2026) — The companion piece governing AI infrastructure cost within the full Technology Value Management framework.
Why FinOps Is Now a Board-Level Discipline (18 Mar 2026) — Strategic context for why Technology Value Management has become a board governance requirement.
Cloud Cost Optimisation Is Dead. Long Live Technology Value Management. (14 Jan 2026) — Why single-scope cloud FinOps is no longer sufficient for board-level technology governance.
The FinOps OS Missing Layer: Why Enterprises Need a Platform That Governs Everything (5 Feb 2026) — The architectural gap between cloud-native FinOps tools and full-estate governance.
AI Unit Economics: The CFO Guide to Governing the Token Economy (22 Apr 2026) — Unit economics for AI workloads on both owned and cloud GPU infrastructure.

Request a Demo

See how these ideas translate into measurable cloud and AI savings.

Book a tailored DigiUsher walkthrough to connect the strategy in this article to your team's cost visibility, governance, and optimization priorities.

Request a strategy demo Built for teams managing spend, scale, and accountability.