Imagine a large house where the lights are on 24/7. In every room, hallway, pantry, closet and basement. When the electricity bill arrives, you start thinking about how to cut it. Swap the bulbs for more efficient ones? Keep reminding everyone to turn the lights off? The situation sounds absurd, and the fix is obvious.
What do light bulbs have in common with virtual machines?
In the world of light bulbs this problem barely exists. In cloud infrastructure it is the norm.
Why do dev VMs sit idle most of the week?
Take an ordinary dev environment. An engineer sits down to work at 9:00 and closes the laptop at 18:00. Five days a week.
That’s 45 working hours. A week has 168.
The other 123 hours the server just runs. At night, on weekends, while nobody is there. And you pay for all 168.
45 h — 27% · Engineer at work (9:00–18:00, Mon–Fri)
123 h — 73% · Nights, weekends, nobody there
168 h — 100% · Total billed
Now what if there are ten such environments? Twenty?
The solution is simpler than it seems. Development servers should sit powered off until someone actually needs them. The point is not to hunt for idle machines after the fact, when the money is already gone, but to change the default itself. The machine is off. An engineer leases it for a session, and it comes up. The session ends, and it shuts itself down.
What do AWS and Google Cloud recommend?
This isn’t some homegrown idea. Both platforms say it in their own documentation.
AWS wrote it straight into the design principles of the Cost Optimization pillar of the Well-Architected Framework. The wording is specific: development and test environments are typically used eight hours a day during the work week, and stopping them the rest of the time gives potential savings of around 75%, or 40 hours of runtime instead of 168. Not “consider the option”, but a basic principle on par with choosing the right instance type.
Google Cloud says the same thing in almost the same words. A Google Cloud blog post states outright that production usually runs around the clock, while dev and test machines are only needed during working hours, and keeping them on at night or on weekends serves no purpose. Then comes the point that makes the whole paragraph worth reading: stopping and starting large groups of machines by hand every day is tedious, and getting an entire organization to do it is next to impossible. The official Cloud Scheduler tutorial walks through exactly this: a 09:00–17:00, Monday to Friday schedule for machines labeled dev.
So what’s the takeaway?
Cloud cost optimization doesn’t scale through manual intervention. It scales through automation. That’s essentially what Google wrote: the problem isn’t that engineers don’t know about the stop button, it’s that nobody is going to press it every evening.
Is idle compute still a FinOps priority in 2026?
Yes. The State of FinOps 2026 report from the FinOps Foundation shows that workload optimization and waste reduction remain the top current priority for FinOps teams. Idle VMs fall squarely into that category.
That finding comes with a caveat worth stating honestly. Optimization really is in first place, but practitioners report diminishing returns. The report puts it this way: the big rocks of waste have already been picked up, and what’s left is a high volume of smaller opportunities that take more effort to capture. And if you add up governance, scope expansion beyond cloud, forecasting and organizational alignment, together they outweigh optimization.
What does that mean in practice? Manually hunting for idle machines is exactly that kind of small opportunity that takes effort. Automation turns it back into a big one.
This matters especially for dev and staging environments. If a team works mostly during business hours, there is little sense in paying for the same infrastructure at night, on weekends, over holidays and during vacations. The most effective optimization here may not be picking a cheaper VM, but cutting down the time it spends running at all.
What should an idle VM audit include?
As one practitioner quoted in the same report put it: “Dashboards are table stakes of yesterday — reactive. You have to move to proactive, real-time, automation.” But you can’t automate what you can’t see.
So here is what’s worth understanding about how your VMs run before you take on cloud cost optimization:
When exactly the machines sit idle. Not “roughly at night”, but hour by hour across the week.
How much money actually burns. Not how much you could theoretically save, but how much has already been spent.
- Which instances are the main offenders. Usually it’s a few heavy machines, not an even layer across the whole fleet.
What automation can fix and what it can’t. Stopping a Kubernetes node that the scheduler will bring right back up saves you nothing.
How the load is spread across providers and regions. If both AWS and GCP are connected, look at them separately. Idle patterns and prices differ.
The real cost right now. Idle time isn’t a one-off finding, it’s a continuous process. It needs monitoring, not a check-in once a quarter.
You can write your own scripts to answer these six questions. Or you can get the same picture from your account’s real data in a couple of minutes with the free Idle Audit.
Originally published at idlefy.com on September 4, 2026.
Top comments (0)