Real numbers. $42,983 saved · 17 servers · 141 days · 1,048 leases · 82% cut in compute spend
The client came to us needing to cut what they were spending on idle virtual machines in AWS. Seventeen servers and a team of engineers. They had tried building a chatbot in house, but in practice the implementation turned into chaos and never delivered the results they were expecting. Then they set up a cron job to shut everything down at 8pm. The cron lasted until the third time it took a machine down mid-release. After that the predictable reflex kicked in. The schedule was switched off "just for a week" and nobody ever came back to it.
Requirements:
- Automate the VM lifecycle so that it fits into the team's routine instead of becoming a job of its own.
- No loss of productivity. An engineer should not wait for access to a machine and should not have to go into the AWS console.
- No resource cuts. No downsizing instances, no changing instance types, no shrinking disks. The hardware under the workloads stays as it is.
- Security. Last on the list and first in importance. An external service gets access to a cloud account, and that access has to be verifiable, limited in permissions, and revocable in one click.
Idle VM management is a narrow topic, but it hides a lot of non-obvious details, and almost all of them surface in the second week of a rollout, not the first.
Step 1. Numbers first, action second
We have written separately about where to start when auditing virtual machines. Optimization without measurement turns into guesswork. Before switching anything off, you need to understand six things.
- When exactly the machines sit idle.
- How much money that idle time actually burns.
- Which instances are the main offenders.
- What automation can fix and what it cannot.
- How the load is spread across providers and regions.
- What it costs right now.
You do not need to pull an analyst and an engineer off their work for a week to get this. We start with the free Idle Audit. It reads 30 days of history across the infrastructure and prices every idle hour. It connects with read-only access, and nothing in the infrastructure has to change.
Step 2. Checking security
This is usually the longest stage of the conversation, and rightly so. Here is how access works.
There is no agent to install. Idlefy works through the cloud provider's API. Nothing goes onto the VMs themselves, no extra ports get opened, and we do not touch your network configuration.
Authentication without keys. By default this is OIDC federation on the AWS side (Web Identity Federation) and Workload Identity Federation on Google Cloud. No long-lived access keys are stored anywhere, because there are none. You can revoke the trust in your own console, and access ends immediately, without contacting us. A legacy mode with an encrypted key exists for older accounts, but we do not recommend it and we do not offer it to new clients.
There is almost no write access. Read access covers the whole account, otherwise the audit cannot price the fleet. Write access, meaning start, stop and reboot, works only on machines carrying the idlefy=enabled tag. On AWS that condition lives inside the IAM policy itself.
{
"Sid": "IdlefyVMManagement",
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:RebootInstances"
],
"Resource": "*",
"Condition": {
"StringEquals": { "ec2:ResourceTag/idlefy": "enabled" }
}
}
This is a shortened excerpt. The recommended policy also carries a read-only block for inventory, access to metrics and pricing, and a legacy capitalized spelling of the tag. The platform shows the full JSON during setup.
Here is the key point, the one that answered 90% of the client's questions. This restriction is enforced by AWS itself, not by our good behavior. A machine without the tag is physically out of reach for our calls, and you can confirm that in your own console instead of taking our word for it.
One honest difference on Google Cloud, which we always raise up front. IAM in GCP cannot scope start and stop by label, so the boundary is held by the Idlefy application. A machine comes under management only if it carries the right label at the moment Idlefy discovers it, and any of them can be switched off from the dashboard. That is a software check on our side, not a policy your cloud enforces. If you want a boundary that GCP itself is responsible for, move the managed machines into a separate project and grant the service account a role only on that project.
We stop machines, we do not delete them. A lease expiry performs an ordinary stop, the normal power-off carried out by the provider. Terminate is never called, under any circumstances.
The root disk and attached persistent disks stay where they are, so files, packages and cloned repositories will be exactly where you left them on the next start. The instance is preserved in full, along with its ID, type and tags, and the same machine comes back up, not a new one. The only thing that can change is a non-static public IP, and that is the cloud's behavior, not ours.
What is lost is exactly what is lost on any power-off. Memory and running processes, tmux sessions included, and anything sitting on local scratch disks, meaning instance-store on AWS and local SSD on GCP. Most GPU and ML instance families carry those disks, so we flag this with engineers during onboarding and ask them to sync anything important off scratch before the lease ends. Idlefy adds no extra risk here. The semantics are exactly the same as hitting Stop instance in your provider's console.
Step 3. Trying it free on one machine
We started with a single machine on the free plan.
Here is how it works.
- Machines are off by default.
- An engineer takes a lease. A fixed booking for an hour, for a workday, or for up to 72 hours on the Pro plan. From Slack, from the Telegram bot, or with one click in the web dashboard. The machine comes up in about a minute.
- At 20 minutes and at 5 minutes before the end a warning arrives in every connected channel.
- Extending happens right there, in the same place the warning arrived, with one tap. The timer moves and work continues.
- When the lease expires, Idlefy stops the machine. The shutdown is executed by the platform, but the time was always set by a person.
Pro also has the Safety System. If the lease has expired, the machine still looks busy, and nobody answered the warnings, the system grants one grace period of 30 minutes and pings you again. The scenario it was built for is a familiar one. Your Wi-Fi drops in the middle of a deploy. Activity can postpone the stop by that one window, but it can never cancel it.
This is the point where the client had that "wait, we could just do this?" moment. Not because the technology is complicated. It is extremely simple. A whole category of friction just disappears. You do not have to remember, you do not have to ask an admin, you do not have to scan the console for a forgotten machine.
Step 4. Rolling it out to the whole fleet
After that it was one day of routine. We put the idlefy=enabled tag on the relevant instances, connected the Slack workspace, and gave the team a five-minute walkthrough. That was it.
Here is what we did not have to do. We did not install agents, did not touch security groups, did not set up a VPN, did not change instance types and did not shrink disks. The fleet stayed exactly as it was. The only thing that changed was the default state.
In that time the team took 1,048 leases. Not a single ticket saying "I got shut down in the middle of my work" in all that time. The warnings at 20 and 5 minutes close that scenario completely, and the people working late simply extend from their phones.
Step 5. Voilà
Over 141 days the client saved $42,983, which is 82% of what the same fleet would have cost running around the clock. Not one instance was downsized, not one was deleted, the types and the disks stayed as they were. The only thing that changed was how many hours the machines spend powered on.
One caveat so nobody sets the wrong expectation. The saving is on compute. The disks of stopped machines keep billing at the provider's normal rate, because the data does not go anywhere. That is the price of starting your own machine in the morning instead of provisioning a new one.
The money that gets saved does not dissolve into the cloud budget. You can see it, and you can decide what to do with it. A six-figure sum per year is not a line in a FinOps report, it is three more engineers on the team. That is exactly what the client did with it, taking three people onto the payroll.
Want the same result?
There is nothing unusual about this case. If you have machines running around the clock that are needed a few hours a day, the savings will be in roughly the same range. The exact figure depends on your fleet, and you can see it in a couple of minutes without changing anything in your infrastructure.
And if you would rather not work it out yourself, book a demo. We will show what this looks like on your account, walk through the edge cases and answer any security questions. Free and with no obligation.
Run a free Idle Audit · Estimate your savings in the calculator
Top comments (0)