At a glance:
-
Cloud billing is a mix of raw compute and managed services, organized by service rather than workload. Getting to a workload-level cost takes days of allocation work and still produces a number with error bars wide enough to push back on.
-
The first vendor conversation is about what you're running and the questions that surface gaps in your own instrumentation
-
A fixed monthly quote against a specific hardware configuration and a cloud billing estimate are finally comparable numbers
-
The board model needs the infrastructure cost to be forecastable
Before any vendor was called
The CFO conversation happens at the planning cycle, not after a production incident. Someone has pulled three years of infrastructure spend to build the cost model for the board deck, and the compound growth rate in the cloud line is running at a multiple of ARR growth. The CFO wants to know whether this is the trajectory going forward, or whether there's a lever the team hasn't pulled yet.
The natural response is to make a comparison: what does it cost to stay on cloud versus what it costs to move baseline workloads somewhere else? That comparison turns out to be harder to build than it sounds.
Cloud billing is typically a mix of raw compute resources and managed services layered on top, organized by service. Getting from a cloud invoice to a workload-level cost takes several days and a cost allocation exercise that surfaces tagging inconsistencies going back two years. Egress costs are spread across services and regions in a way that makes workload-level attribution a judgment call as much as a calculation. By the time you have a number for the baseline workload cost, the error bars are wide enough that someone in finance can push back on the methodology. That's the beginning of a longer conversation about assumptions, not a cost case.
What the evaluation involves
The first vendor conversation doesn't start with pricing; it starts with what you're running. Specific workloads, compute requirements, egress patterns, geographic footprint. The questions are precise enough that you realize your answers have gaps. How much of your egress is inter-region replication versus customer-facing transfer? What's the ratio of always-on baseline compute to burst capacity?
Getting to those answers takes instrumentation work you probably should have done anyway. It also means mapping which managed services you’re currently using and what they look like on dedicated infrastructure: which ones have equivalents you’d run yourself, which ones you’d keep in the hyperscaler environment as part of a hybrid model, and what the total TCO looks like once you factor in the databases, queues, or stagy layers your team would now own and operate. The output isn’t just a hardware quote. Instead, it’s a workload profile that maps to specific CPUs, memory, storage, and bandwidth, alongside a clear picture of what moves, what stays, and what changes hands operationally. From that, a fixed monthly number with no methodology footnote attached.
When you put that number next to the figure you built from billing data, the two are finally on comparable terms: what it costs to run this specific workload for a month. The first is an estimate with caveats. The second is a quote against a specific configuration.
What the decision comes down to
The comparison the CFO needs for the board model isn't "cloud invoice vs. bare metal quote." It's what the cost structure looks like going forward under each model.
Under a usage-based model, the baseline workload cost grows with consumption, and the billing structure makes it genuinely difficult to separate baseline from burst or to commit to a forward number with any confidence. In a quarterly review, the best you can offer is a range. Under a fixed-cost model on dedicated hardware, the baseline is a line item with a specific number on it. Burst capacity stays on cloud where variable billing still makes sense.
That's a different story for a board model than a usage-based line that compounds. It doesn't require infrastructure costs to go down, it requires it to be forecastable.
What makes the decision move isn't finding a lower number. It's finding one you can put in a model and defend in a room.
