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. simonw · 1791079818 · focus · HN ↗

      It's definitely technically difficult. You can't easily estimate how much an operation is going to cost before you kick off that operation, which means as soon as you get close to the limit you are at risk of tripping it.

      Consider something like a "select * from bigtable" SQL query that might process a trillion rows. Hard to know that's going to cost $100 until after you have run it.

      1. mcapodici · 1791080358 · focus · HN ↗

         Yes and then the choice is run it and forgive it, or, stop the process midway.

         If you stop then you have to decide whether to charge for uncompleted work.

         Interesting tradeoffs.

         For very small ops e.g. individual Lambda invocation you have similar concerns especially if lots are fired at once from a queue or schedule or fanout.

Unofficial Hacker News client; not affiliated with Y Combinator.