BlueArch
Labor, capital, land. The three pillars of every econ 101 textbook. A Slack thread this week added a fourth — data — and pointed out that energy is the thread tying all four together. The question that followed: can we borrow simulation methods from building and grid energy planning to forecast and optimize cloud architectures?
That question deserves a serious answer, because most FinOps tooling still treats cost as accounting, not as a system to simulate.
Pan et al., "Building energy simulation and its application for building performance optimization"
Summary. The 2023 review in Advances in Applied Energy is a peer-reviewed survey of building energy simulation as a discipline.
Authored by Yiqun Pan, Mingya Zhu, Yan Lv, Yikun Yang, Yumin Liang, Ruxin Yin, Yiting Yang, Xiaoyu Jia, Xi Wang, Fei Zeng, Seng Huang, Danlin Hou, and Lei Xu
Published as Advances in Applied Energy, Volume 10, June 2023, article 100135
Covers methods, tools, and case studies for building performance simulation
Scope spans design, retrofit, operations, and urban-scale energy planning
Includes digital-twin approaches
Use case. The paper itself is a reference, not a deployable tool. But for FinOps practitioners, it reads like a parallel-universe playbook: the energy-engineering world has spent decades doing what cloud cost teams are only starting to attempt — simulating a stock of assets against time-varying demand, with retrofit options scored against a status quo. Imagine you are forecasting next year's spend across regions, instance families, and reserved-vs-spot mix. With a simulation-first frame borrowed from this literature, you would treat your fleet the way energy engineers treat a building stock: model the loads, model the supply curve, model the retrofits, then run the policy against "weather" — traffic patterns, seasonal demand, AI workload bursts.
Why energy is the binding input
Labor pays the engineers. Capital buys the hardware and the reservations. Data is the product. Energy is what makes the data move — and on GPU-heavy workloads, it is increasingly what dominates the marginal cost of an inference call or a training step.
Most cost dashboards still treat compute as the unit and ignore the watt. That was defensible when watts were buried inside the EC2 price and somebody else's problem. It is less defensible when accelerator pricing is explicitly energy-shaped and hyperscaler regions vary in carbon intensity by an order of magnitude. A FinOps practice that cannot reason about kilowatt-hours per workload is going to mis-forecast both the dollar and the carbon line.
This is the point the Slack thread was driving at. If you accept data as the fourth input, energy is what connects all four. Engineers consume energy. Capital expenditure is recouped over an energy-consuming life. Data is produced by burning watts. The economic geometry of cloud is starting to look much more like the economic geometry of a grid.
What grid-style simulation actually buys you
The Pan review is worth reading end-to-end, but the broad strokes that translate cleanly to cloud:
Bottom-up load modeling. Building simulators model at the zone and equipment level, not the meter level. The cloud equivalent is modeling at the service, pod, or queue level — not the account level. Most FinOps reports still aggregate at the account.
Weather-driven scenarios. Energy engineers run a typical meteorological year against a building. Cloud engineers should run a representative year of traffic and request mix against a fleet plan. The data exists in CloudWatch and the billing export. Almost nobody uses it that way.
Retrofit vs new-build comparison. Energy modelers compare keeping a chiller against replacing it, with payback periods. FinOps should compare keeping a Reserved Instance footprint against committing to Savings Plans, against migrating to Graviton, against re-architecting to serverless — using the same payback discipline.
Co-simulation. Buildings co-simulate HVAC, lighting, and occupancy because they interact. Cloud workloads should co-simulate compute, storage, egress, and queue depth — because those interact too, and pricing the parts in isolation gives you the wrong answer.
Digital twins. A live model that updates against telemetry, instead of a quarterly spreadsheet. The cloud equivalent is the gap between a static forecast and a model wired to actual usage data.
What this changes about FinOps tooling
The honest answer: most FinOps tools today are reporting tools, not simulators. They tell you what you spent, what you will spend next month if nothing changes, and which resources are idle. They mostly do not let you ask "what if traffic doubles, 40% of inference moves to a smaller instance family at off-peak hours, and we move the batch job to a lower-carbon region."
A grid engineer would call that a missing capability, not a power feature. It is the basic question their tools answer.
There is an opening here for OSS. The energy world has open simulators — EnergyPlus and its lineage — built over decades of public investment. The cloud world has Kubecost, OpenCost, Cloud Carbon Footprint, and a long tail of vendor dashboards, but no widely adopted equivalent of a co-simulation engine. The thesis the Slack note implies is that someone is going to build it, and the methods will look a lot like the ones Pan et al. survey.
One decision this week
Read the Pan review — or at least the methods section — and then pick your single largest workload and write down its demand curve as if you were handing it to a simulation engineer. Hour of day on the x-axis, requests or GPU-seconds on the y-axis. Everything grid-style planning does starts from that one artifact, and almost no FinOps team has it written down.