Spending Limit or Maximum Cost CAP for Azure
As a customer, I really care about Spending Limit or Spending CAP feature of Azure.
How does Azure prevent some evil attack to my Azure sites causing charge a large billing of Credit Card?
For example, it should automatically shut off or temporary disable my site when a certain dollar amount has been reached.
Is this feature in the RoadMap of Azure?
Or is there anyway to control my maximum Spending Limit of Azure?
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)
This is insane. So Microsoft has just decided that they can bankrupt their customers for the malicious actions of others? Wow. Azure just lost all credibility. I can't go bankrupt just because they refuse to implement this obviously necessary feature.
Hrvoje Kusulja commented
I am also interested in opt-in for CSP Azure subscription spending limit. To have hard / financial limit . After reaching the limit to automatically guarantee azure subscription is suspended / no further costs for end-customer should be generated.
Johan Eliasson commented
Peter, you can be notified. Opt-in for Email Alerts on your Account page.
Uaaa, I have subscribed to the service recently and was almost shocked that such a basic feature is not available out of the box! Or at least an option to send a notification when some amount is reached. Probably will switch to some other vendor then.
Over 4 years and still not implemented. Google and AWS have spending limits. Microsoft implement other "features" such as graphs and "better styling" but not one of the most requested features ever that has actual merits.
I would really want to have this feature as well. I don't see a problem when this is an opt-in feature and this cap is not enabled by default?
It's the user that gets to decide whether or not to activate this and he must accept the consequences of his decision. At least he will not be ruined when something goes wrong.
@nick Hard limits are a must. My clients feel like they are at risk of spending nearly infinite money due to attack, misconfiguration, or other circumstances. At the level of an enthusiast, even worrying about a few $100 can be enough to trade Azure for Iaas alternatives that provide pre-paid billing.
Why should Microsoft care if production services get shut down due a configuration setting made by Azure users?
Rob Al commented
@nick there are some really difficult options here. I would guess that one way is to allow spending limits per resource group as well as overall per subscription. Users can select to implement at either level, and at either level to be a "hard" stop or just a warning. So if i have something that absolutely has to keep running, i'd put it in an RG with a soft limit. if it's some development tool i'd put it in an RG with a hard limit etc.
Please look at the number of upvotes and the number of comments. I think it's now pretty obvious that it is a must-have feature. I am not even sure if I understand why you are still hesitating 4 years after this was suggested. I mean what is the reason?
I met so many clients who are not willing to implement Azure because it's pretty much an "open wallet". They are simple too scared of being attacked and go bankrupt (and to be frank, I understand them)
Can you please confirm that you are reading these comments in 2016 and please confirm that you are working on this feature? Can you please at least give us an approximate timeframe when it will be ready?
In response to Mike's concerns about the many workflows that would not respond well to sudden unexpected termination: I propose segmenting workflows that can be halted, or that are more prone to being attacked, into a separate billing plan with a hard spending limit. Put the non-uninterruptible things in a billing plan without a limit. It should be up to the client to decide when the cost of having a process rudely interrupted is going to be less than the cost of continuing to have it run beyond billing expectations / allocation.
Maybe some of us will get it wrong, and get burned. Then we will learn the hard way what not to interrupt, but at least the costs of recovering from that situation should be something manageable. It's too late to plan after the money has already been spent.
Hard spending limits are an absolute must. As an example I have a client who is a registered charity and thus very kindly receive $5000 of Azure a year for free. Sadly they've told me not to use this for them due to no spending limit and thus are still paying for hosting elsewhere.
The cost of a website or service being taken offline can indeed be costly, but the current alternative could destroy a small business or charity.
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.
I think Azure team underestimates the negative impact by not having spending limit as big projects often start with small private experiments. And once one've read a title like this "My [another cloud provider] account was hacked and I have a $50,000 bill" one would not want to have anything to do with Azure as well, as long as there is no way to limit financial exposure.
I believe prepaid credit card will not help as you are still responsible for the costs incurred at the end of a billing period. In fact, sadly, I could not find a way to close my Azure account completely, so if my account is hacked and new subscription is activated (using stolen/prepaid card) I still will be responsible for tens of thousands in the end.
Also, sadly as well, I believe omission of this feature is rather political decision of the Azure team and not technical. Otherwise I do not understand why trial Azure subscription has a spending limit feature, which works rather well, but activating this for monthly spending limit is so much of an issue. Also, based on my experience, not having spending limit provides Azure team with significant cash flow from big corporate accounts which are not always managed properly.
If Microsoft is really interested in Windows platform popularization I have no understanding for this. In fact if I were responsible for Azure service I would give every student a free Azure account capped to 10/20 USD a month - this would be a nice investment in the future of Windows platform.
One easy option would be to allow pre-paid credit cards. Then I could sleep without worries that I'm not overcharged. Stop my services for 30 days when credit runs out, and delete if I don't restore.
Chris Derry commented
Any update on when this feature might be implemented?
I'm starting to develop using Azure platform, but I need be sure, the accrued expenses from Azure not increase my budget.
The following comment (found on a well-known IT forum) exactly shows why we hesitate to adopt these technologies in our business:
"Any IP blocking solution will not work against DDOS which, by its nature, come from widely distributed IP addresses. In addition, the cost reporting and budget warnings features are ineffective against a syncronized DDOS that may download tens of thousand copies of you file in a few minutes."
Knowing this, how can we confidently adopt your services? And as many people pointed out, an alarm system is really not enough. It's great, but often it's too late, and by the time people can react, the damage is done.
So yes, an emergency break is an absolutely wanted feature. As it is now, we don't have enough confidence - because we basically need to trust that the bad guys will avoid us. And who would build a business model based on trusting the bad guys?
Bill Hoag commented
I would hope/like that VM instances be shutdown or suspended (vs deleted) when the spending limit is reached. This would facilitate relaunching/troubleshooting them when additional funds become available. Maybe provide something like a 30-day grace period before the instances get deleted, or provide a different type of billing option for suspended instances.
Enterprise agreements are even harder to monitor as the thresholds allowed seem to only apply to the annual EA and not monthly limits that can then trigger an email. Please include EA billing into the brainstorming that goes on for this. Thanks!