What Enron’s Fat Boy scheme still teaches cloud teams about manufactured demand
On 17 January 2001, California declared a state of emergency and started rolling blackouts across the state. Wholesale electricity prices had climbed from an average of $45 per megawatt hour to over $1,400 in under a year. The state’s grid had 45 gigawatts of installed capacity against 28 gigawatts of demand at the height of the blackouts: there was more than enough power on paper. The shortage that shut off traffic lights and hospital backup systems was manufactured: a handful of traders had worked out how to get paid for congestion that never existed.
Cloud cost governance runs on the same kind of signal. Usage triggers spend, and spend is assumed to reflect genuine demand. Flexera’s 2026 State of the Cloud report found that assumption is getting more expensive to hold: wasted cloud spend rose to 29% of IaaS and PaaS budgets this year, the first increase in five years, and 17% of organisations blew through their public cloud budget entirely. Seventy-six percent of large enterprises are now spending more than $5 million a month on public cloud, so a small gap between reported signal and real demand stops being a rounding error fairly quickly.
I want to be careful with the comparison. Most engineers aren’t running an Enron-style fraud out of their Terraform repo, and I’m not claiming they are. What they share with the California traders isn’t intent, it’s the shape of the system they’re operating inside: one that pays out on a reported signal and rarely checks whether the signal was true before the money moves.
Fat Boy, Death Star and Get Shorty ran a real business model
Federal investigators later named the internal Enron trading strategies that helped drive the crisis: Fat Boy, Death Star, Get Shorty, Ricochet. The names sound like a joke. The mechanics weren’t, and they show up in internal Enron memos released years later as part of the FERC investigation, written by traders who knew exactly what they were doing and gave it a nickname anyway.
Fat Boy worked by overstating expected demand on paper, then getting paid to “correct” a shortfall that only existed in the schedule. Death Star exploited the grid operator’s congestion payments: traders scheduled transmission through routes they knew would be congested, collected a fee to relieve the congestion, and in some documented cases never delivered any power at all. Ricochet moved electricity out of state and straight back in, dodging California’s retail price caps by briefly making it “out of state” power. None of it required a real shortage. It only required a system that paid out on a reported signal instead of a verified one.
That’s the part that should make a DevSecOps lead uncomfortable. Autoscaling policies, chargeback models and budget exception workflows are all, structurally, systems that pay out on a reported signal. A CPU spike triggers a scale-out event. A team cites an “incident” to get an emergency capacity exception approved. A spend anomaly gets waved through because reconciling it properly would take longer than the invoice cycle. FERC’s own investigation found the California shortage wasn’t a supply failure at all: it was a rules-based market that assumed good-faith actors and paid regardless of whether the triggering condition was real. Most cloud cost governance makes the identical assumption.
Cost governance is having the wrong argument
The conversation most platform teams are having about cloud cost is a visibility conversation: better tagging, better dashboards, rightsizing recommendations, reserved instance coverage. That’s a real conversation and it’s worth having. It’s also not the one that would have stopped Enron.
The conversation few teams are forcing is about signal integrity: whether the event that triggered the spend was ever independently verified, or whether the system simply trusted whoever (or whatever) reported it. Energy markets had exactly this argument after 2001. FERC rewrote market-based rate authority rules, mandated independent system operators to flag anomalous bidding in real time, and forced generators to prove physical capability behind every schedule they filed. The fix wasn’t more dashboards for regulators. It was verification moved to the point where money changed hands.
Cloud cost governance is at the start of the same reckoning, and AI workloads are forcing the pace. Unpredictable inference costs, agentic workflows that spin up and tear down infrastructure on their own judgement, and scraper traffic from AI crawlers are all signals a naive system will treat as legitimate demand. None of them get independently verified before the bill arrives.
Not every gap between reported signal and real demand is worth chasing. A team that occasionally over-provisions ahead of a genuine product launch isn’t running a Fat Boy scheme, and treating every spend anomaly as a suspect signal will burn more engineering time than it saves. The FERC reforms after 2001 didn’t scrutinise every single trade either. They targeted the handful of mechanisms, congestion payments and out-of-market scheduling among them, that carried the most exposure. The GRID Protocol below is built the same way: find where your system pays out on trust, not where it pays out on a genuinely small number.
You don’t have to go back 25 years to find the same gap. Transport for London raised the Blackwall and Silvertown tunnel charges again from 21 September 2026, and told registered drivers the increase would help balance the flow of traffic through both tunnels. The actual figure comes from RPI inflation between December 2024 and March 2026, rounded to the nearest 5p, a calculation that has nothing to do with how much traffic moved through either tunnel in that window. The charge is marketed as congestion management. The number that sets its level is a retail price index. It’s the same gap between what a signal is called and what actually drives it, just smaller and entirely legal.
Map every signal your system pays out on, not the demand it represents
This is the first pillar of what I’m calling the GRID Protocol: Gaming-vector mapping, Rate-trigger verification, Isolation of synthetic load, Disbursement audits. Treat it as a checklist for finding the places your cost model behaves like California’s congestion market, not a compliance framework to file away.
Start by listing every place your organisation pays money because a system, a person, or a third party reported a condition, without an independent check on whether that condition was real. Autoscaling triggers off a single metric are on the list. So is any budget exception process that runs on a Slack message and a “trust me.” So is any internal chargeback dispute that gets resolved by whoever escalates loudest rather than whoever’s telemetry is correct.
Most teams have never actually written this list down. It usually runs longer than expected, and it’s rarely symmetric: one or two of these gaming vectors typically account for most of the exposure, while the rest are minor. Find the one or two that matter before spending effort on the rest.
The action: audit every automated or semi-automated spend trigger in your environment and classify each one as independently verified or self-reported. Anything self-reported is a Fat Boy scheme waiting to happen, whether anyone’s doing it deliberately or not.
Verify the trigger before you trust the bill
Death Star worked because the grid operator paid for congestion relief without confirming the congestion existed independently of the trader’s own claim. The cloud equivalent is an autoscaling event that fires off a single, easily manipulated or easily confused metric, request count, CPU load, queue depth, with no cross-check against a second, independent source.
Teams regularly discover, after the fact, that a “traffic spike” driving a big autoscaling bill was a misconfigured retry loop, a load test someone forgot to tear down, or a scraper bot indistinguishable from real users at the metric level the autoscaler was watching. The bill doesn’t care which one it was. The autoscaler paid out on the report, not the reality.
Flexera’s 2026 report found cloud-based AI workloads are now the single biggest driver of the reversal in cloud waste, precisely because their usage patterns are the hardest to forecast and the easiest for a naive trigger to misread.
The action: require at least one independent, correlated signal before any autoscaling or budget-exception trigger executes automatically at scale. A single metric should never be allowed to authorise spend on its own.
Synthetic load needs its own ledger
Ricochet worked by making power briefly “someone else’s” to dodge a price cap. Cloud environments have their own version of laundering, and it’s less deliberate but just as expensive: synthetic load blending into the same budget as genuine customer demand until the two are impossible to tell apart.
AI crawler traffic is the clearest current example. Origin servers are absorbing meaningfully more request volume from AI training and retrieval bots than they were two years ago, and in most environments that traffic hits the exact same autoscaling and CDN cost meters as a real customer would. A load test left running over a long weekend does the same thing on a smaller scale. So does an internal batch job that quietly started scaling with production traffic instead of its own dedicated capacity.
None of these three examples are equally expensive, and it’s worth resisting the urge to treat them as three equal bullet points on a slide. In most environments I’ve looked at, one of them dominates, usually the crawler traffic, because it’s continuous rather than a one-off event like a forgotten load test. Find your dominant vector first. The other two matter, but they’re a rounding error next to the one that never stops running.
The action: route and tag synthetic, bot and internal test traffic into its own cost bucket with its own alerting, before it ever reaches the metric your autoscaler or your chargeback model actually watches.
Reconcile more often than once a quarter
PG&E and Southern California Edison were paying wholesale electricity rates in real time, under a retail price cap, with no mechanism to catch the mismatch until it had already put PG&E into Chapter 11 with $8.9 billion in debt. Reconciliation happened after the damage, not before it.
Plenty of cloud environments run the same way. The chargeback report lands monthly or quarterly, well after the autoscaling events, the exception approvals and the “just this once” capacity requests that actually drove the number. By the time anyone reconciles what was billed against what was real, the team that caused it has moved on to the next sprint, and the invoice is just a fact of life.
This is where I’ll say something a lot of FinOps practitioners will disagree with: most cloud waste isn’t inefficiency in the sense the dashboards imply. Framing it purely as unused reserved instances and idle volumes is comfortable because it doesn’t implicate anyone. Some meaningful share of it is closer to Fat Boy: a system paying out on a signal that was never checked, whether the person behind that signal meant to game it or not. Calling it “waste” lets everyone off the hook the way “unforeseen shortage” let Enron off the hook for six months in 2000.
The action: move disbursement reconciliation from quarterly to weekly for any spend category above your organisation’s material threshold, and assign it to someone who didn’t approve the original trigger.
The person who benefits from the trigger shouldn’t approve the trigger
There’s a structural detail in the FERC findings that gets skipped over in most retellings: Enron’s traders weren’t hiding what they were doing from the grid operator. The California Independent System Operator’s own market design let a single participant both schedule the congestion and get paid to relieve it. The conflict of interest was built into the rules, not smuggled past them.
Plenty of cloud environments have the same conflict baked in without noticing. The engineer who configured an autoscaling policy is frequently the same person who reviews whether it fired correctly. The team requesting a budget exception is often the one approving similar exceptions for peers, on the understanding that the favour gets returned. None of this is malicious. It’s just the same design flaw California had: the party who benefits from a trigger firing is also the party judging whether it should have fired.
The action: route sign-off for any spend-triggering exception or unusual autoscaling event through someone outside the team that benefits from it, even if that just means a peer team’s on-call engineer rather than a dedicated function.
The only question that matters
California’s grid never actually ran short of power during the worst of the 2000 to 2001 crisis. The capacity was there the entire time. What failed was a pricing system built to assume the signals it received were true.
Most cloud environments are running the same architecture of trust, just with autoscaling policies instead of congestion payments. The infrastructure usually isn’t the problem. The question is whether anything downstream of a trigger checks if the trigger was real before the money moves.
Look at your last unexplained cost spike. Was it demand, or was it a signal somebody, or something, learned how to trigger?
The full GRID Protocol breakdown, including the verification checklist referenced above, is published at blog.ogunlana.net.
Bola Ogunlana is a Senior DevSecOps Engineer with 25+ years in cloud infrastructure, UK Government delivery, and financial services. He writes at blog.ogunlana.net.