Stopped vs Stopped (deallocated)
Today VMs can be in a stopped or stopped(deallocated) state. This is an important distinction for billing purposes as the stopped state continues to bill for resources and stopped (deallocated) does not. Needless to say this is confusing because the portal (old version) has a "Shutdown" command that puts the VM in the Stopped(deallocated) state but if you "shutdown" from within the VM it is just in a Stopped state.
PLEASE MAKE THIS DISTINCTION MORE CLEAR!! :-)
The new portal for managing VM only shows my stopped (deallocated) VMS as just Stopped. This is totally confusing.
Great feedback. We will work on making this more clear!!
Some years old, this issue - but still relevant, especially for beginners in the Azure universe. If the first experimental steps accidentally cost a company a lot of money the management will be not very pleased and stop the project. Just my experience today...
This cost me over $1000 🤬
Chris Nicholas commented
I am glad a searched this out as it makes a big difference in POC costs when using Azure as a Sandbox for some testing.
It would be really nice if an information icon was present when a system is in the "Stopped" state just reminding you that this has allocated resources and is still billing / charging for those resources.
Виктор Милованов commented
Ugh. Just got bitten by that.
Three years later, this is still a problem. You do not indicate in the VM list that a VM is incurring charges. It still just says stopped. You have to enter the VM detail to see that. My biggest problem is this. If it is stopped, it is because I am done using it. Why would it need to keep running, or consuming resources, if I am done using it? As far as allocation, why would we need to keep it allocated? Isn't the whole point of a cloud that we can start and stop a VM at will without having to reserve resources or in some way prepare the environment? As a business, haven't you already planned your own resource availability to make sure that you can accommodate additional demand when necessary and therefore wouldn't need us to allocate or reserve capacity in order to ensure we have it when we request it?
I'm using the Auto-shutdown feature in the new portal for the purpose of limiting my spend to the time I am actually on the machine. Even though the machine was stopped by Azure itself it continued to burn at the same rate as if it were turned on 24x7. It has burned over $100 in 18 days. Why does this happen?
This STILL needs to be more clear. I just racked up a bill based on me still thinking -- and who can blame me -- that shutting the machine down means it's actually stopped, and stopped means it's not using any resources, and not using resources means it shouldn't cost me anything.
My question is this: I think I can understand the need for larger users to keep resources provisioned, "booked" as it were, ready for use so that machines can be fired up at a moment's notice. But for smaller users (the hardest hit when mistakes like this are made), why is "Stopped (but still Allocated)" even an option?
Perhaps users should be able to choose on a machine-by-machine basis on setup whether to keep resources allocated when a machine is shut down?
I would like more about to know what is pay per use model(If I shut down dev azure sharepoint server on weekend will MS charge for those 8 days of a month)
Kay bee commented
Why is this not fixed I still see Stopped and I get billed. Why there are no clear instructions. Why is there no option to Deallocate? This is deceptive practice
Agree with this! Please make it more clear...still not done.