Azure VM Hibernation: Same Bill as Stopped, Faster to Come Back
Hibernating an Azure VM costs exactly what stopping it does. The real trade-off is a bigger OS disk and losing Azure Backup, Spot, and Availability Sets, not the monthly bill.
Search “Azure VM hibernation” and half the cost-optimization content out there implies it’s a cheaper way to turn off a VM than stop/deallocate. It isn’t. A hibernated VM and a stopped-deallocated VM cost exactly the same: nothing for compute, full price for the OS disk, data disks, and any static IPs still attached. If you just want a cheaper way to turn a VM off, stop/deallocate already does that, for free, today.
Hibernation, generally available for general-purpose VMs since May 2024, solves a different problem: getting back to exactly where you were, fast, without relaunching every app or reloading every dataset into memory. That’s worth real money in the right scenario. In the wrong one, it’s just extra disk cost and a shorter list of features you’re allowed to use.
What hibernation actually does
Trigger hibernation and Azure signals the guest OS to do a suspend-to-disk, the same S4 sleep state a laptop uses. The VM’s memory contents get written to the OS disk, then the VM deallocates. Start it back up and that memory gets read back in. Whatever was running when you hibernated is running again, in the same state, without a fresh boot.
Stop/deallocate skips all of that. It just shuts the VM down. Nothing in memory survives. Next boot is a cold boot, every app starts from scratch, every dataset reloads.
The bill doesn’t change
Once a VM is off, hibernated or stopped, you stop paying for compute either way. You keep paying for storage and networking: the OS disk, any data disks, static IPs. That’s the whole billing model for both states. There’s no hibernation surcharge and no hibernation discount.
The actual savings come from turning the VM off at all, not from which off-state you pick. A D4s_v5 (4 vCPU, 16 GB RAM) runs $0.192 an hour. Run it 24/7 and that’s about $140 a month in compute. Run it 50 hours a week, roughly a workday’s worth of hours, and hibernate or stop it the rest of the time, and you’re down to about $42 a month in compute. That’s 70% off, and you get it whether you chose hibernate or stop.
Where the resume speed actually matters
So why use hibernation at all? Because for some workloads, a cold boot is the real cost, not the compute bill. Microsoft’s own use case for this feature is systems with long boot times from memory-intensive applications: an AVD session host with a user’s apps and files already open, a dev workstation with an IDE and a big dataset loaded, a workstation you want “pre-warmed” for the moment someone needs it.
Stop that kind of VM overnight and the user comes back to a cold boot, a fresh login, and every app reopening from nothing. That’s minutes of friction, every morning, for every user. It’s the kind of friction that gets you a support ticket asking why the VM can’t just stay on. Hibernate it instead and the user’s session comes back the way they left it. The VM being off overnight becomes invisible to them, which is what actually lets you turn it off in the first place.
The catch: your OS disk gets bigger
Hibernation needs somewhere to put the memory image, and that somewhere is the OS disk. The disk has to hold the OS, the pagefile, and a full copy of RAM, on top of whatever it already stores. General-purpose VM sizes up to 64 GB of RAM support hibernation today (the Dsv5, Ddsv5, Easv5, Eadsv5, Esv5, and Edsv5 families); GPU sizes up to 112 GB are supported on NVv4 and NVadsA10v5. Size a 64 GB-RAM VM for hibernation and your OS disk needs enough free space to absorb that entire memory image, which can push you to a bigger disk or a pricier tier. It’s not a huge number, but it’s a real one, and stop/deallocate doesn’t carry it.
Where it doesn’t fit at all
Hibernation comes with a real limitations list, and it rules the feature out for a lot of production VMs:
- No Azure Backup. If you already run Enhanced Policy for crash-consistent restore points, know that Azure Backup doesn’t support hibernated VMs at all.
- No ephemeral OS disks, no Spot VMs, no Availability Sets.
- No Virtual Machine Scale Sets in Uniform mode. Flexible orchestration is fine.
- No capacity guarantee on resume. Azure doesn’t promise the hardware will be there when you un-hibernate. It’s rare, but it’s a real gap for anything on a tight recovery clock.
Any one of these can be the reason hibernation is off the table before you even get to whether it’s a good fit.
When to actually use it
Turn it on for AVD session hosts and dev workstations where users keep real state open, and for VMs with long, memory-heavy boot sequences you want ready to go the moment someone needs them. Skip it for anything backed by Azure Backup, anything on Spot pricing, anything in an Availability Set, and anything where a plain stop/deallocate already gets you the same bill without the disk overhead or the feature restrictions.
The question to ask isn’t “will hibernation save me money.” It won’t, beyond what stopping the VM already saves you. The question is whether the state you’d lose on a cold boot is worth paying for a bigger disk and giving up Backup, Spot, and Availability Sets to keep.
Subscribe for more of these.