“Pay what they say.” AWS Account Limit Unanswered Question for 10 Years

When a user asked to cancel a payment

Habré published stories of AWS users who accidentally “flew in” thousands of dollars. Roughly speaking, you wake up in the morning – and overnight virtual machines scaled up and wind up crazy money. Or, at the end of the month, a wild bill suddenly comes.

For this reason, using cloud services is a little scary: you cannot predict the load and costs.

It would seem that the situation can be easily corrected if you set a limit on the maximum budget or a hard limit on resources.

But Amazon does not do it on purposedespite customer complaints. The problem has been tracked since 2011.

On January 13, 2011, on the AWS Forums, a user asked a question about the current status of the development of the maximum account size limitation feature:

Dear Amazon,

You make a great S3 service, it allows small developers to take advantage of world-class pay-as-you-go storage. The only part missing in my opinion is the function to limit the maximum account size.

The community has asked for this many times and you promised this feature, but it has been stuck for many years. I know that limiting accounts can be done through programming on our side (through checking logs and / or signed URLs), but I do not think this is a suitable solution. This should be a native function.

The account limit will reduce the risk for small developers who can literally go broke with S3 hosting. Such control over the account will close the logical loop, and after that I can’t even think of a reason why someone will refuse from using S3.

So my question boils down to this. If the feature is planned, when will it appear? If she never shows up, I’m sorry, but please officially confirm it.

Thanks in advance for any answer. By the way, here’s how this function might work in my opinion:

  • The limit is set to the maximum amount per month for the bucket
  • When the limit is reached, objects from the bucket stop being served
  • When the limit is reached for the first time within a month, the user receives a notification
  • Although objects are not returned, incoming requests still generate traffic on their own. Therefore, it’s okay to continue charging for every 1000 requests.

The question has not been answered so far, that is, more than ten years …

Obviously, Amazon either cannot or does not want to develop this feature. On the one hand, it is almost impossible to develop billing in real time. Billing always works late.

On the other hand, you can pretendthat billing in real time exists, implement the function and resolve all disputes in favor of the client. That is, when billing late registers the load in excess of the limit, the client will not be charged extra money.

What does the lack of a limit lead to and how you can fly into money – for example, it was described in the article “How we accidentally burned $ 72,000 in two hours on Google Cloud Platform and nearly went bankrupt”… This is a typical story, not some rare case. Google Cloud is no different from AWS in the sense of the lack of limits.

Here’s how the author did it:

And suddenly we learned about the Cloud Run system, which then had a large free use limit! Without understanding it completely, I asked the team to deploy the “test” function Announce-AI in Cloud Run and evaluate its performance. The goal was to play around with Cloud Run to gain experience.

Since we have a very small site, we used a Firebase database for simplicity, since Cloud Run does not have any storage, and the deployment of SQL Server or another database is too excessive for the test.

I created a new GCP ANC-AI Dev project, set up a $ 7 cloud billing budget, saved the Firebase project with a free plan (Spark). The worst case we have imagined is going over the daily Firebase limit.

After some modifications, we prepared the code, made a few manual requests, and then left it working.

Although the system worked fine on the test day, Announce-AI continued to generate requests. Subsequently, many architectural flaws in the code were discovered, which caused the system to scale rapidly due to exponential recursion in the creation of Cloud Run instances.

In general, the next day there was automatic upgrade of a Firebase account to a paid account… In total, the experimental version of the application on Cloud Run did 116 billion reads and 33 million writes in Firestore. Firebase reads cost: $ 0.06 per 100,000, resulting in $ 69,600 reads. Everything is fair.

The same thing happens on AWS with some services – automatic upgrade to a paid account. For many users, this happens unexpectedly. Add exponential load growth and here’s the result.

Most importantly, there are no billing limits on AWS. For comparison, in Google Cloud they are, on Azure also have (not for all accounts). Although the limit is triggered with a delay of about a day. This refers to the lag between the road load and the recording of its value. This is often a critical lag, because tens of thousands of dollars can be “burned” in a few hours, as in the story above. Well, on AWS there are no limits at all, even with a delay of a day. There are only default limits on the maximum use of resources, but they are quite large and will not save you from thousands of accounts.

You can, of course, protect yourself somehow. For example, limit the maximum amount of a credit card payment at a bank. But that won’t remove your huge debt to AWS, see the discussion “What Happens If You Don’t Pay Your AWS Bill?” in the questions and answers section on Habré. The person opened a free account, linked a card with 1 dollar in the account, and soon found that they were trying to withdraw $ 1500 from him.

Basically, this is a good scenario. If this happens, we close the account, block the card and forget about this story forever. Amazon will definitely not go to a Russian court (or a Ukrainian one, and even more so a Belarusian one). But the residents of Western countries may have problems, probably.

Thus, when we register on AWS or Google Cloud, we immediately assume arbitrary billing. The bill can come down completely wild even on a free account… It is better to insure in advance against such a development of events – see above about the card with 1 dollar.

In addition, it is useful to use monitoring with alerts: they have a delay of a couple of minutes, so that you have time to react to an emergency increase in load.

On this topic:
“How I managed to owe Amazon $ 12,000 in 1 day”
How to Protect Against Unexpected AWS Bills
Why You Shouldn’t Use Google Cloud


Looking for VDS with transparent and understandable pricing for the development and placement of your projects? You are definitely our client 🙂 Daily billing of servers, create your own configuration in a few clicks, anti-DDoS is included in the price.

Subscribe to our chat in Telegram

Similar Posts

Leave a Reply