We have been considering all of the risks and investigating the steps required to ensure we implement this feature with high positive impact and low to no negative impact.
After this investigation we have decided we will enable Pay-As-You-Go customers the option to configure a spending limit on a Pay-As-You-Go subscription, with appropriate safeguards and measures to prevent both service abuse and production service failure.
We have not yet finished determining the details of what this feature will look like, nor do we have a timeline for release, but we have heard your voices and have added this feature to our backlog.
Thanks for your continued feedback,
-Adam (Azure Billing Team)
Quick correction - I meant "When I posted (to) this issue..".
I was not the OP - just supported and posted comments to this issue.
When I posted this issue over 4 years ago, the reasoning was simple: Shut off my website/media stream/etc. when my net spend exceeds a certain amount so I'm not on the hook for traffic I didn't anticipate. Fast forward a few years, and the reality is it's not that simple, because frankly, not everything running in Azure is a website.
There are many things in the enterprise space that will not react well to being shut off in the middle of work. Scheduled jobs (via Automation or WebJobs), data movement activities (via DataFactory, SQL jobs, Logic workflows), data ingestion and analysis (think Hadoop or HDInsight) are just a few examples. Whether or not these can be safely stopped in the middle of work is very specific to the implementation and use case. And that's the problem: Ensuring the safety and recoverability of these operations if you shut them down while they're doing work.
Cost control is definitely still an important discussion, and is one area the platform still needs to improve on. However, my view of this question is to instead ask it from the opposite perspective: If I were to offer you a feature that would terminate/shutdown ALL your Azure services when you exceed a certain spend, but there were absolutely ZERO guarantees of the safety, integrity, and recoverability of those services, would you still want it? Probably not.
This isn't an easy feature to do correctly, and I'm totally stoked they are still looking at it. But from my perspective, this needs to be safe and not cause downstream issues before it's a viable solution. And that, of course, is going to take some time and thought to get right.
Whether we like it or not, businesses want to purchase applications using a fixed, projected expenditure. As an ISV that is building apps on Azure, it is extremely difficult to sell the "only pay for what you use" angle...customers would rather the system "cap-out" instead of magically charging ten-fold for a month.Mike supported this idea ·
124 votesMike shared this idea ·