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. cortesoft · 1791085188 · focus · HN ↗

         Yeah, you can't just implement it as a pure "stop all services immediately once I hit a set amount"

         It needs to be more like "don't allow spinning up additional services after you hit this amount", although that still allows you to go over the limit by a lot, since most services are billed hourly.

         It really is difficult to implement a spending cap that doesn't risk shutting down important things.

         1. onion2k · 1791087367 · focus · HN ↗

            It really is difficult to implement a spending cap that doesn't risk shutting down important things.

            That's a checkbox decision for the customer. There needs to be the option of "This is important, never turn it off and I'll pay for any overages." versus "I want an entirely predictable bill up to $xxx, so stop my stuff as soon as possible over that."

            It's not up to a cloud service to decide my website is more important than my money for me. That's my decision to make.

            1. chii · 1791092194 · focus · HN ↗

               > That's a checkbox decision for the customer.

               and they would still complain if they got it wrong - it's always the platform/company's fault.

               Look at banks and fraudulent transfers that customers themselves get phished into doing. The bank in the end usually take the hit (after the customer complains long enough). That's why there's all sorts of hoops and such to prevent customers from failing - and that causes friction for people regularly.

               Therefore, the cloud company's decision to default safer is more correct from this perspective.

               1. throwaway27448 · 1791098773 · focus · HN ↗

                  > and they would still complain if they got it wrong - it's always the platform/company's fault.

                  I mean, it's really not unless they don't build it in the first place—that really is the platform's fault.

            2. tomjen3 · 1791095132 · focus · HN ↗

               It's more complicated than that.

               You might be perfectly okay with having certain systems shut down, but you probably still want to pay for the archival storage of your important files.

               That archival storage might be in several places, including one S3 bucket, whereas there might be another one that, contains copies of scraped Craigslist for X where you'd actually be happy that it just shut down.

               This makes it far more complicated to do correctly, and as others pointed out, mostly relevant for hobbyist — this is not something you are going to make a lot of money from.

               Better to spend engineering hours making an MCP for the dashboard or improving your Databricks setup.

Unofficial Hacker News client; not affiliated with Y Combinator.