Yesterday, I posted a tweet with an imaginary conversation that is sadly based on many real conversations I have had. The tweet received some interesting replies, and the point about spending limits came up multiple times. So as a thought experiment, let’s think about the pros and cons of a spending limit and if it makes sense.

What is a spending limit?

But first, let’s define what a spending limit is and how it differs from the existing AWS Budget feature.

AWS Budget lets you monitor and manage your AWS costs by setting a custom cost and usage budget. It provides notifications when your defined thresholds are approached or exceeded. It helps you maintain better control over your spending and optimize resource utilization.

The thresholds can be set against both actual accumulated cost as well as projected cost (based on the rate you’re currently spending). And you can set multiple thresholds in your budget. For example, at 20%, 50% and 100% of your budget.

It should be said that every AWS customer should use AWS Budget. It’s not perfect by any stretch, especially since billing data are several hours behind the curve. But it can still help you detect and catch spending abnormalities before they become a bigger surprise, as illustrated by this thread.

What it doesn’t do, however, is stop you from using your AWS resources when you have reached your budget.

That is what a spending limit is. That is, you will no longer be able to use anything in your AWS account until the next payment period or you raise the spending limit.

Many services have spending limits, such as mobile phone plans or prepaid debit cards, or even some subscription-based services such as Midjourney.

So let’s have a look at some pros and cons of having a spending limit and I will share my thoughts at the end.

The cons of spending limit

1. Service disruption : Once the spending limit is reached, your system becomes unavailable. It will negatively impact your business operations and user experience.
2. Hard to find the right limit : Businesses would likely struggle to accurately determine the appropriate spending limit for their needs. Most businesses already struggle to understand their cloud spending. This would exacerbate the problem by adding potential service disruption to the mix.
3. More management overhead : Businesses would need to closely monitor their AWS usage to ensure they do not hit the spending limit. Which could require additional time and resources.
4. Limited flexibility : A hard spending limit doesn’t cater for growing businesses or businesses with fluctuating needs. They may need more resources during certain periods, or may experience unexpected surge in traffic because of external events.
5. Under-utilization of resources : In an attempt to avoid reaching the spending limit, businesses might underutilize resources and fail to fully leverage the potential of AWS services.
6. Potential loss of revenue for AWS : AWS might lose revenue from customers who would have otherwise continued to use their services beyond the limit.

The pros of spending limit

1. Tighter budget control : AWS customers would have better control over their budget, as they can define an exact spending limit and avoid unexpected costs.
2. More predictable cost : With a hard spending limit in place, AWS customers can accurately predict their monthly AWS expenses and better allocate resources for their businesses.
3. Prevent abuse : A fine-grained spending limit can help prevent unauthorized usage or abuse of services. For example, by disabling spending on unused regions and services.
4. Fewer billing surprises : Customers would experience fewer surprises in their monthly bills, as their spending would be capped at the limit they set.
5. Encourages efficient resource usage : A spending limit might encourage AWS customers to optimize their AWS usage and make more efficient use of resources.

My thoughts

I’m against the idea of a global (account or organization-wide) spending limit. The suggestion of a spending limit often comes up in the immediate aftermath of a costly mistake.

However, as a business, the impact of a potential service disruption makes it a non-starter. After suffering revenue loss from a costly mistake, the last thing I’d want would be a service outage to add salt to the wound!

Service disruption means user churn, damaged reputation, loss of market opportunities and wasted productivity.

And the potential loss of revenue to AWS also means we’re unlikely to ever see this kind of global spending limit.

On the other hand, what works for businesses might not work best for hobbyists. For whom, even small unforeseen cost surprises would have an outsized impact.

But more importantly, a small-scale, service-wide spending limit might be very beneficial. For example, by allowing AWS customers to specify a spending limit on specific services such as API Gateway and Lambda.

It can help ease many businesses’ concerns about “potentially unbounded costs”.

For those of you who have worked with serverless technologies, you would know that these fears are usually unfounded. Especially if you have cost control mechanisms in place already, such as using AWS Budget.

Again, everybody should be using AWS Budget regardless if you’re a hobbyist or a multi-billion dollar company.

If businesses are able to put a spending limit on a service they wish to experiment with then it will encourage more experimentation. This creates a virtuous feedback cycle which would benefit both AWS and its customers in the long run.

Even AWS measures the success of their services by adoption, not revenue. And we know that successful experimentations with serverless are the launchpad for wider adoptions of AWS services.

I lose count of the number of times clients have told me how they went all-in on serverless after an initial successful experiment. There are many such examples from my podcast alone.

And if a service-wide spending limit can help alleviate some of these fears and encourage more customers to try things out, then it’s a win-win situation for everyone.

Additionally, the spending limit must be opt-in and might be time-boxed so they are not accidentally left hanging around after the experimentation phase.

The post The Sky’s the Limit: Debating the Benefits of AWS Spending Restrictions appeared first on theburningmonk.com.