Thread

1. joshdavham · 1791078994 · focus · HN ↗

   It’s incredible that in 2026, AWS and GCP are only just now introducing this. It’s possibly one of the most obviously needed features for a cloud provider.

   Also, does anyone know why it’s taken this long? I suspect it’s a technical reason. While one could be cynical, I doubt it’s an intentional business/product decision. Hard spending caps are both excellent product differentiators and could possibly save these providers money as they don’t have to forgive their users when they accidentally over-use a service.

   1. Anon1096 · 1791080413 · focus · HN ↗

      It's one part technical, one part a product decision. The technical part is that billing is not actually instant. As a most basic example, a VM reports its billing units every X period of time it is active. If there is some network blip but it's still running, then that billing data could be delayed.

      The product level decision is that "shut down everything" is something the customers you want to target don't actually want. Are we including deleting RDS data? S3? Glacier storage? If so then the headline will just change from "Hobbyist got charged XXXXXX on AWS" to "Business literally had all their data deleted because a hacker took over their VM and mined bitcoin". The only people who really want this are hobbyists and it's not a market segment that's worth chasing. Easier to do the status quo of forgive afterwards then even open the can of worms of deleting all of a business's data and all their backups just because they had a 100k overrun.

      1. cj · 1791082098 · focus · HN ↗

         > The only people who really want this are hobbyists and it's not a market segment that's worth chasing. Easier to do the status quo of forgive afterwards then even open the can of worms of deleting all of a business's data and all their backups

         Hit the nail on the head.

         Nearly all businesses would prefer a cost overrun than services going offline.

         1. simonw · 1791083425 · focus · HN ↗

            Today's hobbyist is tomorrow's decision maker at work over which service to use.

            1. bryanrasmussen · 1791085806 · focus · HN ↗

               and if they're going to be a good decision maker they need to put their personal feelings from hobbyist times aside and realize stuff is different in the two scenarios.

               1. necovek · 1791088486 · focus · HN ↗

                  If your peak monthly cost for AWS services as a business is $100k, do you not think setting a $200k spending limit is reasonable?

                  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.

                  1. miki123211 · 1791095133 · focus · HN ↗

                     And if you use enough services, a global per-account spending limit can't distinguish between peak usage versus one service being abused.

                     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. bryanrasmussen · 1791097868 · focus · HN ↗

                        I agree but I think also, as a programmer, surely this is not an insurmountable problem. The idea that pops into my head immediately when hearing this problem is

                        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.

                        1. lazyasciiart · 1791100550 · focus · HN ↗

                           The systems are hopefully created with the help of finance professionals who are familiar with a massive variety of unpredictable cost scenarios.
               2. zufallsheld · 1791090587 · focus · HN ↗

                  How would they know if the service is any good when they didn't try the service as a hobbyist because of spending fears?

                  1. chii · 1791092284 · focus · HN ↗

                     They would ask around, as well as perform a proper evaluation based on their current needs, rather than their experienced needs as a hobbyist?

                     1. dingaling · 1791093604 · focus · HN ↗

                        Meanwhile while in the real business world, Cloud decisions are shaped by marketing campaigns and it's the hobbyists and old grey-beards who provide the empirical push-back and reality checks.
               3. tomjen3 · 1791095684 · focus · HN ↗

                  You are correct; however, you're also putting a lot of faith in people's ability to make decisions.

                  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.

Unofficial Hacker News client; not affiliated with Y Combinator.