The Cost Was Set Before FinOps Ever Saw the Bill

Ask most infrastructure leaders whether their organization has a handle on cloud costs, and the honest answer in 2026 is “better than we used to, worse than the board thinks.” Tagging is in place. A dashboard exists. Someone reviews spend every month and flags the obvious waste. And the bill keeps growing anyway, often faster than the business it supports. 

That’s not a failure of FinOps. It’s a ceiling FinOps was never built to break through. 

The reporting layer has done what it can 

Cost management matured fast this decade. What started as ad hoc spreadsheets became a real discipline: tagging taxonomies, chargeback models, anomaly detection, and rightsizing recommendations. The FinOps Foundation’s own 2026 research captures how far the practice has come — and, more tellingly, how it’s now being pulled into conversations it never used to be part of. Holori’s read on that report frames it as FinOps getting “a promotion,” moving out of pure reporting and into earlier engineering decisions. Rack2Cloud has been making a similar argument for over a year: cost is turning into a design constraint, not a monthly report card. 

That’s the practitioners themselves saying it, not a vendor. The reporting model — watch, flag, recommend — has a hard ceiling. Once a workload is live, you can rightsize it, retier it, or shut it off if it’s idle. You cannot undo the architecture it was built on. And the architecture is where most of the cost was actually decided. 

Where the money gets committed 

Here’s the uncomfortable sequence, and it plays out almost identically whether the workload runs on AWS, Azure, or Google Cloud. An application team picks a storage tier because it’s the fastest path to production, not because anyone modeled it against the workload’s real access pattern. A database gets sized for a peak load that happens a handful of days a year, and that peak becomes the permanent baseline. A platform decision gets made under a deadline, and “we’ll revisit it once we’re live” quietly becomes “we never revisit it.” 

None of that shows up as an anomaly on a cost dashboard. It shows up as the baseline — the number every future optimization effort gets measured against and never quite closes the gap to. 

This isn’t a hypothetical problem getting easier to ignore. It’s getting worse, faster, because the pace of infrastructure decisions has accelerated well ahead of the pace at which most organizations debate them. Global cloud infrastructure spending jumped 43% to $143.4 billion in a single recent quarter as GenAI cloud services surged 165%, and that kind of growth doesn’t leave much room for careful design reviews. More irreversible architecture decisions are being made per quarter than at any point in the last decade, often with less scrutiny than the decisions they’re replacing. 

The market is already answering this, just not out loud 

A few things happening right now suggest the industry has quietly reached the same conclusion, even if nobody’s framed it as one story. 

Analyst coverage is starting to treat cost as its own architectural discipline rather than a subset of general IT financial management — Gartner has stood up dedicated Hype Cycle coverage specifically for strategic cost approaches, a category that didn’t warrant its own name a few years ago. Separately, a growing number of enterprises are re-architecting mission-critical workloads specifically to regain control over unit economics. Volico’s analysis of the 2026 repatriation wave ties the trend directly to cost and control, not just compliance — organizations moving data-intensive systems off configurations that were never designed with cost as a variable in the first place. 

The hyperscalers are living this pattern too, in real time. In the first half of 2026 alone, AWS doubled EBS performance ceilings on its newest EC2 instances at no extra cost, Google rolled out major Hyperdisk performance upgrades aimed at AI workloads, and Microsoft formally retired Azure Unmanaged Disks while repositioning Azure Storage for agentic-scale workloads. Each of those reads as a performance upgrade. Each is also a fresh round of architeture decisions – new tiers, higher ceilings, forced migrations – made under exactly the deadline pressure described above, for the workloads that are hardest to unwind once they’re live. 

Neither of these is a FinOps story. Both are architecture stories. That’s the tell. 

What this means for the workloads that matter most 

Mission-critical, data-intensive systems are exactly where this plays out hardest, because they’re the hardest to re-architect after the fact. A stateless web tier can be redeployed on a Friday afternoon. A production database underneath a core enterprise application cannot — the switching cost is real, the risk tolerance is low, and so the original architecture decision tends to stick around for years, cost and all. 

That argues for a different kind of design review. Not “can we afford to run this,” which gets asked after the architecture is already locked and answered with whatever budget happens to be available. The better question is whether the cost of this system, over its full lifecycle, was a deliberate choice or an accident of whoever was in the room and how much time they had. Most organizations are only set up to ask the first question. 

It also argues for giving infrastructure and storage architects a seat earlier in the process — not to slow delivery down, but because the decisions made in that room are the ones a FinOps team will spend the next several years only partially undoing. 

Where Silk fits into this 

Silk builds software-defined storage for mission-critical enterprise applications on the premise that the cost of a workload is set at the architecture stage, not the optimization stage. The goal is to decouple performance and capacity from any single cloud — AWS, Azure, Google Cloud, or on-premises infrastructure — so a database or application can run on whichever platform and tier actually fits it, not the worst case assumed under deadline or whichever tier was easiest to provision. 

Get that decision right, and there’s less for a cost tool to go looking for later, because the waste was never built in. That’s a different job than monitoring spend. It’s reducing how much monitoring has to matter in the first place. In a Forrester Total Economic Impact study of Silk, organizations that made this architectural change saw 50% lower cloud storage costs, a 60% performance improvement, and a 139% ROI over three years, with payback in under six months. Those aren’t the results of a better dashboard. They’re the return on a different decision, made earlier, about how the system was built in the first place. 

The pattern shows up in specific customer enviornments, not just in averages. Sentara Healthcare cut EMR replication time from 840 minutes to 15 and eliminated $28K in disaster recovery costs – not by watching a legacy setup more closely, but by changing the architecture underneath it. Franciscan Health grew its storage footprint 20% while holding cost growth to 3.8%, decoupling capacity growth from cost growth entirely. Neither result came from a better dashboard; both came from a different decision, made earlier.  

Silk was named a Sample Vendor in Gartner’s 2026 Hype Cycle covering strategic cost management approaches — a useful external data point for anyone trying to figure out whether this is a real shift or a vendor talking point. We’d make the same argument with or without it. The pattern was visible in customer environments before the category had a name. 

The takeaway 

Every dollar of avoidable cloud spend gets approved twice: once quietly, in an architecture decision nobody scored for cost, and again loudly, when finance asks why the number went up. FinOps has gotten very good at catching the second approval. The organizations that get ahead of their infrastructure economics over the next few years will be the ones that finally start paying attention to the first one. Want to see the numbers for yourself? Download the Gartner Hype Cycle report.