Today's hobbyist is tomorrow's decision maker at work over which service to use.
Obviously, the system should provide ample time by warning in advance of reaching it (and could even offer suggestion to keep it at N times your peak from M months ago).
If as a business you set your spending limits so tight that you frequently run into them and it's not some unusual activity, the problem is not that spending limits are available :)
It is mostly about protecting from the unknown, likely unbounded attack on your infrastructure, where your spend might grow 100x: even if you can take $100k, you might not be able to take $10M in a month.
Imagine you spend $100k on average each month, but spend around Christmas rises to $1m because of the specifics of your industry. With a global spending limit, you can't distinguish between $200k of general spend increases due to Black Friday versus $200k in fraudulent 2FA SMS to South Sudan.
1. of course spending limits are monthly or even weekly basis. You set a yearly limit, probably most people will do something like November to January 4 times the limits set rest of year.
2. as you near limit calls go to people on your team to tell them you are getting near your limit. Estimate is 2 hours, what do you want. Double Limit for this time period? Triple Limit for This Time Period? Remove Limit Entirely, you will get back to us with potential new limit? It's the beginning of Christmas, the next time your limit resets is the 3rd of January, remove limit entirely and you will get back to them. Why do you decide to remove limit entirely, because you have info that Amazon doesn't, specifically your assassin Nisse doll has gone viral for this Christmas season! The shit is making bank!!
3. When setting limit you say "expected low usage", "expected high usage", "limit". Limit should be significantly above expected high usage. Service informs you - you have been over your expected high usage by 20% last three time periods. Would you like to increase limit and high usage by 20%? Please Look at your settings otherwise.
4. Phone calls when there is an unexpected peaking in usage, like one hour we are 300 thousand which is very high for you, next hour it is 1.5 million.
Obviously none of this stuff helps hobbyists but even the worst run businesses I've worked at would handle this. Otherwise they deserve to be hobbyists, there's no reason to be an organization if you're not organized.
Obviously these things do not stop fraudulent attacks abusing your service, but it does make it harder for them, at the same time making it more difficult for your stuff to just get shut off without you knowing.
Of course, as a programmer I am aware that all these services are created by programmers as effective or more effective than I, and who have undoubtedly thought about it more than I, so I must also assume there are reasons why my off the cuff suggestions are ludicrously unhelpful, but I lack the knowledge as to why this should be so.
Another thing (that does not really apply at AWS anymore), is that todays's enthusiasts are going to be the future CTOs, and the easiest time to recruit them to your service is when they are still an enthusiast who gets to make decisions on their own because there's exactly one decision maker you have to appeal to and that person really likes to try new stuff.
That's why you can get a free fly.io and why we all use Tailscale. And it works too — if I was in charge and needed it, I would immediately go with Tailscale for a business; I know it and I use it.