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)
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!
Jesper R commented
Hard limits are absolutely required. Not having that option makes customers worried to the point of blocking adoption. I have seen this several times.
Valid production use cases for this very much exist, and it should be high on your teams list.
Feel free to reach out to me via the billing advisors group for more detail.
Oh, I forgot, you also asked how we would use a hard-limit:
we are working on a startup company that shows art oriented 360-degree videos. We need to deliver the videos ourselves through a custom 360-degree video player. That's our only option on iPad Safari as Youtube 360 doesn't work on iPad Safari. Actually nothing works on iPad Safari expect this custom player.
Each video is 100-600Mb. As we do our marketing, we can predict the usage and the popularity of our project, hence we know the approx. cost. But we just cannot afford an attack when these videos are downloaded 1 million times in a day. It would make us go bankrupt, and who can guarantee that nobody will attack the project..? So.. who has a break for us..?
Currently we are with Amazon, but actively looking for someone who is offering this feature as Amazon only has some useless alert, and we don't have 24/7 monitoring yet. I just cannot sleep well due to this, and I am even considering going for a dedicated server with Hostgator. It may not be fast enough as a CDN but at least I know my monthly budget.
Well, I guess it depends on the nature / size of the business. In my opinion, this safety feature would be 100% attractive for up-and-coming businesses, startups and even non-profit projects. (while established business may just not use this option) But a startup simply cannot afford making a mistake at the beginning. Of course they may not be your biggest cash-cow now, but be forward thinking: they will eventually grow, so if they come to Azure due to this safety feature, rather than Amazon, then they are likely to stay with you even when they become more established - since they have a workflow setup. And Amazon really doesn't care.
And here are some real arguments:
1) An established, bigger business can afford more and better qualified IT experts to prepare for Ddos attack, and create several layers of protection. A small business may not be able to set up a similar protection, yet it's the small business who could go bankrupt if there is a sudden Ddos attack generating a sudden $30.000 bill.
2) who can guarantee that a bigger company, who sees potential in the "revolutionary" product idea of a startup, will not hire someone to generate a Ddos attack to bring them down?
3) An established business can afford 24/7 monitoring through 3rd party expensive apps, a budget sensitive up-and-coming or startup business may not be able to afford this.
4) You mention better billing alert system: but again, for a startup, they may not have somebody 24/7 who can respond to a sudden ultra-high spike. Or, even worse: they may not even know what to do for a few days... can you imagine what that means?!
I tell you a customer's example. He reported his case on Amazon forum. He was working on a small business. Everything was ok for months. And one weekend he was away, and during that 48hours, there was an attack generating +$2-3000 bill. He was lucky that he could stop the service manually, and the spike lasted for "only" 48hours. Imagine another 2-3 days.. Another user reported a $10.000 unexpected bill and there are so many stories out there. So try to put yourself into the position of a startup owner and you can see why he can afford ZERO such financial mistake / risk during the first 1-3 years. Later, maybe it's less critical, but not at the beginning.
INSURANCE: (!!) so for small businesses, it's is a bit like driving a Ferrari car without any insurance. And on top of that, without the experience of a race-driver, who at least knows how the car will react in some extreme situations. And if there is an accident, you pay the medical bill forever.
If you use this INSURANCE example, you can treat a Ddos attack as an illness. In "real life" we have medical insurances if a nasty illness brings you down. (at least in the EU) If it attacks you, the insurance will pay. Here, we cannot do that, and proper IT security might be inaccessible for smaller businesses, so we must have some optional breaks.
From this point of you, it's not even a must-have feature, but it's the ONLY ethical way towards smaller businesses.
And I think it's healthier from a competition point of view as well, as a startups will have more confidence in building new ideas. So in an indirect way, it's better for the economy as well. I am idealist, and I would love if bigger companies like yours would grasp the idea of "mutual responsibility". Let's build a better web. Let's build a better world.
And a very last word: you mentioned mission critical applications. In this case, there are three things: 1) either the business will opt-out for a hard limit 2) or they will do better estimations and adjust their hard-limit above the estimation 3) they can raise it if needed By the way, the limit should be adjustable on the fly. So if I am expecting a natural spike due to CNN.com coverage, I adjust my estimation. But in either case, if my estimation is let's say $500 usage a month, I would set up a hard limit probably at $1500. I can deal with an extra $1000 loss, but I cannot deal with $20.000 due to a nasty competition directing an attack against my service.
Everybody will be winner:
1) you will gain more confidence from us
2) therefore more startups will choose you
3) AND A BIG ONE: it may discourage some Ddos attackers. Not all, but at least those whose only motivation is to make a smaller competition bankrupt, may not be able to do it. So it will be better for the industry. Yes, they could still cause harm, but way less harm.
That's what I think:
It's a responsibility, not a feature.
Question: are hard spending limits really what's desired here or would improved cost management/controls via billing alerts and similar serve a better purpose? Depending on how limits are implemented, the risk of bringing down production services is a very real danger. We're actively discussing/evaluating this feature (no timeline yet, sorry) and are really curious to get opinions and/or example use cases from our customers who are asking for this.
-Nick (Azure Billing Team)
I will move my business from Amazon AWS to AZUR within a minute if spending limit for Pay-as-you-go is implemented. It's THAT important. I won't even hesitate for a micro second.
Amazon doesn't give a ****, and I am happy to make a switch, but only if this is implemented.
Very roughly, WHEN is it going to be happen?
Anytime this year (2016)?
Please provide some quick update, so we can have more clarity.
Tim Scott commented
Yup, big deal, I'll be paying personally for any initial investigation, but if I like what I see it would lead to a considerably larger investment by my company, at the moment I don't dare experiment as it's a very complex environment and fairly difficult to understand what costs and what doesn't, unlike AWS it doesn't seem to be very forthcoming about what services you consume in the free period actually would have cost.
I am working as a senior executive running FB and GG ads for SMEs company in Vietnam which is an advertising company.
- Our job is running ads CPI, CPC, KPI ... via FB and GG.
- We also lease GG and FB account. Our customers can spend a lot of money and not worry about being locked.
- We have been running ads for a number of national and international companies.
- After providing advertising accounts for a lot of customers, we do have a lot of experience in running the ads. We can assist you with the experience we had and we hope to share and learn more from you guys.