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. tancop · 1791097253 · focus · HN ↗

         Storage is almost never the main thing racking up bills so it should be handled in a different way. If you hit a limit you can't store any more data but everything you have stays there and readable.

         This is more about compute, VMs, LLM inference and services like hosted database. These are all safe to stop if the system triggers a normal shutdown when costs hit a limit.

         1. gpt5 · 1791097946 · focus · HN ↗

            Yeah, the storage point made the whole case weaker.

            1. zbentley · 1791099829 · focus · HN ↗

               I dunno, the largest accidental AWS overages I’ve triaged in my career (at very different companies) were all storage. Dangling EBS, forgotten S3 accumulating data after a deletion cron broke, incompletely retention-policy’d CloudWatch buckets, Aurora snapshots…the list is pretty long.

               “Large” is relative to the business of course, but the biggest storage-related overages I’ve personally triaged are in the high $100ks to low $millions per month. Colleagues have heard of orders of magnitude more costly.

               1. lazyasciiart · 1791100446 · focus · HN ↗

                  That’s not storage costs, that’s activity adding to storage used. The question is whether it would be cheap enough for them to keep all your existing data frozen until you paid the bill.

                  1. hnlmorg · 1791100922 · focus · HN ↗

                     You’re literally agreeing with the GP but phrasing it like they’re wrong.
               2. gpt5 · 1791135527 · focus · HN ↗

                  The solution above (no new storage) would solve that problem.

Unofficial Hacker News client; not affiliated with Y Combinator.