‹ BackHN Continuity

Thread

We're going to need default hard budget caps on pretty much everything

606 points · 302 comments · elffjs

  1. joshdavham · · 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. twoodfin · · focus · HN ↗
      This is one of those features that customers think they want without having thought it through:

      “Never let me spend more than $X” also means, “Shut down my business-critical app/service/solution at 2 am on a Sunday morning because Joel in IT forgot to plan for the new report runs.”

      The product design work to let customers have the first thing without risk of major pain from the second thing is non-trivial.

      1. simonw · · focus · HN ↗
        I don't really understand that argument. This seems pretty obvious to me, as a customer. Is this really something that companies don't understand?

        Sending an email when your budget gets low shouldn't be a big lift.

        1. kasey_junk · · focus · HN ↗
          Big companies have thousands of budgets. An email is _worthless_. In fact, it would probably cause me to lose faith in a cloud that provided that as the control.
      2. handoflixue · · focus · HN ↗
        The alternate conversation is "the new report run had a bug and cost us $1,000,000 over the weekend" and I think that one's usually worse.

        But one could just have two categories of service - the default capped plan, and a special Enterprise one where you sign a contract making it clear you understand the consequences of not having a budget limit.

        Also, if your average usage is $900, set your hard limit at $2,000, not $1,000. Then when the report runs $500 over expected, you get a soft limit email and still have your report. Even a "business critical" run is probably not actually worth more than double your average spend.

        1. Gigachad · · focus · HN ↗
          Even if you set your cap at $10,000 it would be better than nothing.

          The price cap should be the number you’d be willing to spend to avoid an outage vs when you’d rather kill everything and work out what happened.

          1. twoodfin · · focus · HN ↗
            This is the right perspective, but the folks who would be setting this cap for the customers that matter likely have no idea how to price that, or the price would be so absurd as to make the cap meaningless.

            How much would a hospital pay to avoid unexpected downtime of their software systems?

            1. Gigachad · · focus · HN ↗
              I would think once you reach the scale that this becomes an issue you can afford someone or a team to be monitoring the system 24/7 able to respond to a price spike.

              Price caps are for small scale stuff where you wake up on Monday and see 1000x the normal bill.

              1. twoodfin · · focus · HN ↗
                I imagine that the product folks at places like AWS are averse to introducing discontinuities in the experience based on scale. Little customers get the same experience as big customers who get the same experience as mega customers.

                Obviously they’ve changed their mind about cost management in light of the scale and dynamism of agents, which isn’t too surprising.

            2. simonw · · focus · HN ↗
              A hospital should select the checkbox that says "no spending limit".
              1. twoodfin · · focus · HN ↗
                Sure, but prior to AWS introducing a notion of “project”, then they’d be at risk for those $1M bills from the data science team looking for agentic magic to reduce readmissions.

                My point is this was never as simple as, “Give me a dial to set my maximum account spend.”

              2. matkoniecz · · focus · HN ↗
                No, hospital should be able to work offline.

                And presumably getting bill for bajillion dollars would be bad also for them.

            3. Dylan16807 · · focus · HN ↗
              A hospital needs to be able to handle a full cloud outage. So I'd be worried if they're near the top of the list of how much they'd be willing to pay here.
      3. cogman10 · · focus · HN ↗
        Counter argument, this is the sort of thing that, especially for a smaller business or individual, can be the difference between a bad night and bankruptcy.

        Sure it sucks that critical services blinked out at 2am. But what sucks even more is finding out the image on my ASG had a vulnerability that allowed someone to install a bunch of bitcoin miners which kept me fully scaled from midnight to 2am.

        Or more likely, that a mistake in terraform 1000xed my spending.

        Most people have predictable spending and could easily say "don't spend more than 10x what I normally spend". Or 1.5x, or 2x, 3x, etc. All depending on how they want to balance a runaway cloud expense.

        1. twoodfin · · focus · HN ↗
          For a large enterprise spending millions on AWS, 1.5X is already a budgetary disaster. Unfortunately, shutting off critical IT infra because it hit 1.4X spend this month is a business disaster.

          There’s no magic wand that produces good outcomes when planning or execution goes awry at scale.

          1. cogman10 · · focus · HN ↗
            > especially for a smaller business or individual, can be the difference between a bad night and bankruptcy.

            Just because this isn't a good solution for everyone, doesn't mean it's not a good solution for a large number of people and businesses.

            A lot of businesses can tolerate outages. In fact, even very big businesses come out mostly unscathed when they have multi-hour outages. (how many is it for github this year?)

            An outage causes a reputational black eye. It does not necessarily translate to lost income.

          2. pixl97 · · focus · HN ↗
            There is a magic wand.

            If you're a big business that wants to spend unlimited money, you apply for unlimited credit with a credit check.

            If you don't, you get hard caps.

    2. MobiusHorizons · · focus · HN ↗
      It is a technical reason. Basically cloud billing is much more granular and across many more services / line items than most things that basically the pipelines that figure out how much you have spent take a long time to know how much you have consumed. I believe all cloud providers with granular usage based billing have this problem.
    3. simonw · · 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. stuartaxelowen · · focus · HN ↗
        Advertising platforms have had this since their inception. They were just motivated because they could be left holding the bag.
      2. mcapodici · · 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.

      3. nvader · · focus · HN ↗
        Yeah, we probably want some kind of traffic light system:

        Green means go Orange means finish what you're doing but don't start anything new Red means stop everything

        And probably a special rule to permit stable, critical spend through regardless, the same way we allow police and ambulance to run lights.

        1. Gigachad · · focus · HN ↗
          Stop everything is pretty damaging any real business though. Things were better in the era of VPSs. You paid for a fixed amount of compute, if you ran a stupidly expensive operation than it just maxed out your system for a certain amount of time and things slowed down. But you didn’t kill the service entirely and you didn’t have unlimited potential price
        2. eddythompson80 · · focus · HN ↗
          In this example, that would require the “big query” to have billing baked into its actual query runtime, which isn’t impossible, just not how one would design a query planner per se. Usually such services emit metrics of usage units, then the billing calculation happens in a completely different system taking into account discounts, promotions, contracts, regional and currency differences, etc.

          Suddenly a database, a storage service or a computer service needs to be aware of the billing situations and make behavioral decisions based on the billing status. Again, not impossible, but something that suddenly promotes billing from an async/non-crucial background service that can be paused, replayed, adjusted by account teams etc, into a crucial hot-path service.

          1. miki123211 · · focus · HN ↗
            The way you'd usually handle that AFAIK is to have the service ask the billing system for a "reservation" in its native units, likely with an attached TTL. Then, the service would translate those units to U.S. Dollars (or possibly Indian Rupees), taking your plan, discounts, vouchers, contracts, grandfathered pricing and all that into account. It would then "lock" the calculated amount of money, denying the reservation if total_spent + total_locked > spending_limit. After finishing the operation, the service would ask for actual billing and free the unused units.
            1. eddythompson80 · · focus · HN ↗
              Yes, thats one way to implement it. It still moves that global billing system into a ring 0 importance with 99.9999% availability and performance requirement, where before it wasn’t even in the picture. Not impossible, just suddenly every single AWS (or GCP or Azure etc) has a global single point of failure that gates all their performance and runtime actions.

              Not to mention having no way to network isolate such service as every single service in every single network boundary needs to be able to contact such service, and every service needs (more or less) same auth permissions on all user accounts it’s running.

              Again, solvable problems with enough code, but not simple problems by any means if you operate at a large scale.

      4. joshdavham · · focus · HN ↗
        > You can't easily estimate how much an operation is going to cost before you kick off that operation

        I recently had a debate with a colleague on this topic but concerning estimating the costs of AI agent work. For example, if you prompt an AI to refactor your codebase, the final cost can't be estimated perfectly, but I'm sure it can at least be estimated with some amount of precision! Like simply knowing that it will cost < $100 is actually great information even if the final work only ends up costing $5.

        I think there actually might be a business opportunity (or at least the opportunity to build something cool here) if anyone wants to work in the AI cost estimation space. It's not exactly an idea I want to pursue, but just thought I'd put it out there. AI cost estimation (even with wide confidence bands) would be very useful to a lot of people.

    4. kasey_junk · · focus · HN ↗
      Because most enterprise users would much rather have overages in billing than outages. The opportunity costs on any serious service I deploy dwarfs usage pricing, at least at the level a generic cloud can determine.

      So it’s a feature the best customers don’t want, that adds risk to those customers deployments, to appease the worst customers.

      At least historically. Perhaps Simon is right that the calculation has changed.

      1. josephcsible · · focus · HN ↗
        That's a reason to not force a hard budget cap on all of your customers, but it's not a reason to not offer one.
        1. kasey_junk · · focus · HN ↗
          Features for bad customers that risk good customers are easy to say no to.
      2. koolba · · focus · HN ↗
        It’s not a binary decision though. Any sensible enterprise has many AWS accounts. Often hundreds or thousands. It’s the only clear separation of privilege.

        There’s no reason for the majority of them to have an infinite budget cap. Prod? Sure. UAT? Why not. The sandbox environment Johnny just spun up to test some new agentic workflow? Hell no.

    5. Anthozoa · · focus · HN ↗
      A very charitable take, in light of tech industry habits of exorbitant rent-seeking in scenarios of Platform Dominance (e.g. Google and Apple on the app store). We should remember AWS and Google companies are among the best in the world at A/B testing and extracting revenue from cloud services.

      When you're one of only two real options out there, you can afford to demand users put up with things that on their surface seem ridiculous. Such as a billing system that (oops!) makes it difficult for customers to see where their costs are coming from, trim their largest sources of spend, notice meaningful changes in line item prices, or limit their spend. Wild how they can figure out a million different advanced services but gosh-darn-it can't figure out the hardtech of displaying line items.

      Large enterprises can afford employees who are tasked full time with unwinding this capacity to mitigate the impact of these billing headaches. But I think this measure is introduced now because LLMs introduced a risk that these billing specialists could not control without caps.

    6. Anon1096 · · 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. Gigachad · · focus · HN ↗
        I think there is a middle ground between deleting data and allowing 5000 VMs to be created to mine bitcoin. Obviously there are a lot of different scenarios to consider but the explosive costs seem to be constrained mostly to a couple of features which would be fairly safe to cap.
        1. asdfaoeu · · focus · HN ↗
          AWS and similar already have service quotas that cap these.
      2. cj · · 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 · · focus · HN ↗
          Today's hobbyist is tomorrow's decision maker at work over which service to use.
          1. bryanrasmussen · · 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 · · 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 · · 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 · · 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 · · 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 · · 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 · · 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 · · 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 · · 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.

        2. Symbiote · · focus · HN ↗
          I removed some pay-per-use APIs from our (business) public website after a surprise $4000 bill, caused by an LLM company scraping the site.

          Some were replaced with a competing service which has a limit, others replaced by a self-hosted alternative.

          I think many small businesses would prefer to be offline or have a degraded service than pay $X000.

        3. fcarraldo · · focus · HN ↗
          yeah, I don’t know why anyone thinks otherwise.

          for personal/hobby accounts sure. for a business, it’s much better to negotiate around billing or adjust systems/processes post-facto than it is to have service cut off unexpectedly.

          debts are easier to manage when you have an active (ideally growing) customer base. you don’t have customers anymore if your cloud account takes down your service for the rest of the month due to spending limits.

          1. necovek · · focus · HN ↗
            If you are actually a business, a common warning that you are near the limit should mostly resolve it. It might only be tricky because the estimated time remaining is really short if it's a huge recent spike: eg. nobody is looking forward to a notice of "you'll use up your spending limit in 4h" on the weekend.

            This type of warning should give you enough time to investigate if the warning is real and adjust the spending limits.

            But then again, even if you hit them and your services get paused, you'd be increasing the spending limits and restoring services after you are back at work and notice they are down, so it mostly comes down to your incident response times.

      3. 10000truths · · focus · HN ↗
        > Are we including deleting RDS data? S3? Glacier storage?

        If you're billing per GB of storage, then you can put hard caps on storage capacity, and then hard-reject any operation that would take the total stored size over that capacity.

      4. simonw · · focus · HN ↗
        Amazon's new feature for this specifically says that it won't delete any of your data for 90 days:

        > If you take no action within 90 days of your project being paused, AWS permanently deletes your project data.

        From <a href="https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;accounts&#x2F;latest&#x2F;reference&#x2F;create-spend-limit.html#spend-limit-reached" rel="nofollow">https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;accounts&#x2F;latest&#x2F;reference&#x2F;create...

        1. eddythompson80 · · focus · HN ↗
          Can I store few petabytes, and pay for it for one day every 90 days to reset the timer?
          1. sillysaurusx · · focus · HN ↗
            What surprised me about GCP was that yes, you could load all of your training data and model weights (terabytes) into a free starter account, then create a new account after 30 days and transfer the billing obligation from account A to account B.

            It was such a blessing for hobbyists, back in ye olde 2019.

          2. radicalbyte · · focus · HN ↗
            Given that the cloud providers just put a 0 or two on the cost to determine their prices then yes, you could try.

            They&#x27;ll ban you after a year because it will be against their TOS.

            But sure, go for it.

          3. DangitBobby · · focus · HN ↗
            Presumably you&#x27;d have to back pay the 90 days but it&#x27;s your life
      5. cortesoft · · focus · HN ↗
        Yeah, you can&#x27;t just implement it as a pure &quot;stop all services immediately once I hit a set amount&quot;

        It needs to be more like &quot;don&#x27;t allow spinning up additional services after you hit this amount&quot;, 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&#x27;t risk shutting down important things.

        1. onion2k · · focus · HN ↗
          It really is difficult to implement a spending cap that doesn&#x27;t risk shutting down important things.

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

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

          1. chii · · focus · HN ↗
            &gt; That&#x27;s a checkbox decision for the customer.

            and they would still complain if they got it wrong - it&#x27;s always the platform&#x2F;company&#x27;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&#x27;s why there&#x27;s all sorts of hoops and such to prevent customers from failing - and that causes friction for people regularly.

            Therefore, the cloud company&#x27;s decision to default safer is more correct from this perspective.

            1. throwaway27448 · · focus · HN ↗
              &gt; and they would still complain if they got it wrong - it&#x27;s always the platform&#x2F;company&#x27;s fault.

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

          2. tomjen3 · · focus · HN ↗
            It&#x27;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&#x27;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.

      6. amluto · · focus · HN ↗
        A provider could, in theory, calculate the cost of storage for X days and prevent you from uploading an object that would push you over the limit.
      7. Dylan16807 · · focus · HN ↗
        For S3 a reasonable option is a data limit as the primary limit. If you set it a TB over your real needs you only waste one dollar per day after it locks. And there&#x27;s no need for any other paused service to charge more than that for idle data.

        You&#x27;re right that nobody wants deletion. Spending limits do not imply deletion.

        1. judge2020 · · focus · HN ↗
          I think a more sensible default is S3&#x2F;etc locking access to data for 30 days, maybe even as little as 7 days, while you&#x27;re able to still list and DELETE said data as you wish, without being able to get or put.
      8. [deleted] · · focus · HN ↗

        [deleted]

      9. Doohickey-d · · focus · HN ↗
        Regarding hobbyists: some clouds, and also the bigger clouds, do target hobbyists quite a lot, presumably with the intention that some of those hobbyists will eventually grow and stick with them. So I don&#x27;t think &quot;not wanting hobbyists&quot; is entirely true.

        But yes, the amount of money they spend is less, so it makes less sense to implement features that only hobbyists want.

      10. miki123211 · · focus · HN ↗
        A lot of billing systems are organized around event delivery. The system does what it does and reports usage. This reporting is asynchronous and can be done E.G. via cron jobs running on a 24 hour cadence in certain cases. There&#x27;s an internal guarantee that billing records for a given period are delivered by a certain time. Nobody checks whether the user has enough money to do what they&#x27;re trying to do, just whether they&#x27;re authorized to access the system in the first place. Shutting down accounts due to non-payment is more of an abuse &#x2F; fraud concern, and happens long after the bill is delivered.
        1. Joker_vD · · focus · HN ↗
          Wow, I wish my my cell provider worked like that! Instead, they somehow manage to track and bill me literally in real time. How do they do it? Do the telcos have some magic pixie dust or what?
      11. beAbU · · focus · HN ↗
        There is a middle ground here: Make this setting configurable, off by default, and with all the associated warnings of what will happen if you switch it on. Better yet, make it settable on each billable service. Keep Route 53 going, but halt and delete any VMs that exceed some limit.
      12. tancop · · 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&#x27;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 · · focus · HN ↗
          Yeah, the storage point made the whole case weaker.
          1. zbentley · · 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 · · 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 · · focus · HN ↗
                You’re literally agreeing with the GP but phrasing it like they’re wrong.
            2. gpt5 · · focus · HN ↗
              The solution above (no new storage) would solve that problem.
        2. hnlmorg · · focus · HN ↗
          I’ve recently worked somewhere where S3 read access was the second largest AWS cost.

          I’m not saying it’s normal. Just that AWS is complicated, and people use it in a plethora of ways, thus billing caps aren’t easy to get right either.

    7. dhosek · · focus · HN ↗
      I had a $.20&#x2F;month recurring charge from AWS that I could only remove¹ by completely deleting my AWS account. That was enough to get me to give up on AWS for personal projects.

      ⸻

      1. The key word was “I.” Maybe someone more skilled at navigating AWS’s menu structure than I could would have done it quickly and easily, but even though I knew what it was for, turning it off and not getting billed for it turned out to be a huge challenge. Thankfully it was only $.20, but if I were using the service for something that generated actual bills, that $.20 (and possibly more) would end up quietly siphoning money out of my pocket into Amazon’s).

      1. yardstick · · focus · HN ↗
        Sounds familiar. I’m being billed £0.01&#x2F;month for something in GCP, I don’t know what even after digging, but I’m too fearful to complain about it or disable the account lest it somehow gets my main Gmail account blacklisted somehow.
      2. gentlerain · · focus · HN ↗
        I have been using AWS more recently but something I can&#x27;t believe is how the whole UI&#x2F;UX revolution of the last 10 or so years escaped them.

        Starting from the login point, who asks to login to root or IAM user account in 2026?

        Or having to change regions from a dropdown to see resources you own in those regions?

        It&#x27;s really in top 5 messy UI i have ever seen.

        1. NBJack · · focus · HN ↗
          And it changes constantly &quot;for the better&quot;.

          Remember when they decided the best UI experience was to give everything a vague abstract collection of shapes? Early 2010s or so. Couldn&#x27;t tell a damn thing apart.

      3. dehrmann · · focus · HN ↗
        It&#x27;s possible to get billed for things not exposed in the UI. ~10 years ago, I had one of these. A Glacier upload chunk was stuck in a staging area for over a month. I couldn&#x27;t complete or cancel the upload, or remove the chunk. Support was able to, and they refunded the money without much hassle. But I did have to reach out to support (as a &lt;$100 per month customer) to ask. Glacier was new, so I chalk it up to it being a new product, not anything greedy or malicious.
    8. pixelready · · focus · HN ↗
      If these cloud providers had needed a standard customer acquisition strategy to grow to their current size, hard caps and other “training wheels” features would already be in place to get people interested in and comfortable using the platform, with the hope of eventually getting a foothold into Enterprise like most SaaS startups have to do (“enjoy our product on a side project and then recommend us to your CTO!”). But AWS and GCP got to start as in-house providers for their own constellations of massive sites and back out from that to serving other hyper scale businesses first. The lack of friendly on-ramps and starter account features is a reflection of that origin more than anything.
    9. bpodgursky · · focus · HN ↗
      How do you hard-cap S3 and other persistent data storage?

      &quot;Sorry, you had a hard cap on AWS spend so we deleted all your S3 data on August 27th&quot;. Yeah not going to fly.

      1. simonw · · focus · HN ↗
        See <a href="https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;accounts&#x2F;latest&#x2F;reference&#x2F;create-spend-limit.html#spend-limit-reached" rel="nofollow">https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;accounts&#x2F;latest&#x2F;reference&#x2F;create... - they pause your access but don&#x27;t delete your data for a 90 day grace period.
      2. 3eb7988a1663 · · focus · HN ↗
        There is a huge difference between &quot;stop accruing new spend&quot; and &quot;nuke everything&quot;.

        The horror stories I have seen are of the type: some big artifact was getting pulled in a loop, causing TBs of network traffic or access keys were leaked and malware spun up 1000 xxxlarge instances.

        The ability to stop the bleeding is the bare minimum people want. Not, &quot;Well, you made a boo-boo so now you lost everything.&quot;

      3. matkoniecz · · focus · HN ↗
        &gt; How do you hard-cap S3 and other persistent data storage?

        grace period as AWS did or set aside x% of data spend limit on holding existing data for N days

      4. csande17 · · focus · HN ↗
        Simple: when data is added to S3, immediately bill the full cost of storing that data until the end of the month (or fail the upload request if there&#x27;s not enough quota left). If the data is deleted before the end of the month, refund the remaining storage time.

        To prevent cases where users can upload an excessive amount of data on March 31 that they then can&#x27;t afford the April bill for, AWS should also maintain a &quot;next month&#x27;s balance&quot; limit that gets handled in the same way.

        It would take a bit more work to correctly handle things like ephemeral data and tiered storage classes, but it&#x27;s not insurmountable.

        You could apply the same kind of billing to most other long-lived resources, including VMs that run business-critical services.

    10. cubefox · · focus · HN ↗
      &gt; 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.

      GCP did have a budget cap previously. I think the new one is just more fine-grained to apply to specific services.

    11. ButlerianJihad · · focus · HN ↗
      As a hobbyist, I pulled completely out of AWS when I realized the billing issues could never be resolved. Even&#x2F;especially with tight monitoring and hard caps.

      Even as a hobbyist, even as a most careful and judicious architect and admin, I could not prevent my VPS from incurring costs beyond my control. That means that the entire Internet, anyone with some kind of material access to the VPS, and especially any user or authorized entity, they could incur costs to me without bound and without notice until slapped with a bill.

      Even something as simple as egress charges aren&#x27;t under your control. So if people download enough data, you pay for all of it? It seems like an absurd proposition.

      It&#x27;s like opening a business somewhere in a war zone, and vandals and squatters are constantly attacking your storefront, and maybe you have a band of toughs as security and some good cops to defend awhile, but you&#x27;re utterly in a war zone with adversaries acting far beyond your control.

      As a hobbyist, I could never again justify running a pure VPS with the Linux and stack on top, as I ran before like the MediaWiki server. I was excited to learn all the vocabulary and skillsets of cloud services, but on the &quot;free tier&quot; uncapped, there was no telling when I&#x27;d be presented with costs beyond my ability to handle. And I do not see how a Fortune 500 would have any different calculus in this regard.

      Most businesses in recent memory were &quot;their own landlord&quot; of on-prem equipment and machine rooms. Yeah, they began to outsource even their IT admin, but the machinery was in-house until the cloud services took over. Did we go through a phase of collective machine rooms or data centers with a collection of tenants? It seems we skipped from &quot;homeownership&quot; to &quot;feudalism&quot; with the Cloud Providers being the Princes [beyond mere Lords] who provide minimal resources to the serfs now. I can see many corporate execs who begin to hate &quot;AI Data Centers&quot; just for what they have become: a very attractive and irresistable way to reduce your capex and footprint and physical plant, by &quot;migrating to the cloud&quot; but is that really a better status quo after all your revenue is being pumped into AWS?

      And in view of what I just wrote, a &quot;hard budget cap&quot; checkbox is even worse for you than runaway costs, because it will allow any determined adversary, butterfingered DevOps, or innocent fuckup, to shut you down and deny your service by hitting that cap. When a business experiences a service or infrastructure outage, they count that in dollars of revenue. Your &quot;budget cap&quot; will cost you money because it &quot;paused your project&quot; and your customers all got burned in turn.

      Moving toward real solutions, just spitballing, but I can envision throttling and capping of everything, every billable service, monitored by the cloud provider and ensured that your services don&#x27;t spill over into unmanageable territory. If your spend could be throttled and capped by-the-minute, by-the-hour, daily, then there is a start for it. But really, any service that incurs costs to you should have reasonable rate-limiting, throttling, caps and alerts that can help you manage it. I think all that stuff is currently missing but I am not a cloud admin, obviously. Cloud services obviously have perverse incentives to open the floodgates and bill as much as possible for any possibly legitimate usage that doesn&#x27;t exceed their aggregate capacities. It&#x27;s like LLMs today that just burn tokens like there&#x27;s no tomorrow, because someone [you, not Mexico] will eventually pay for it all.

    12. mejutoco · · focus · HN ↗
      &gt; While one could be cynical, I doubt it’s an intentional business&#x2F;product decision

      Why is egress more expensive than ingress in clouds? To lock in users.

      Why cloudformation in some cases leaves s3 buckets laying around after destroy? To keep charging those cents.

      Why no caps? To get the user into the mindset of we ll pay whatever they say, and charge the ones that dont notice or dont ask for the refund. Same reason why my newspaper subscription autorenews.

      Nothing cynical about both of these. I think assuming it is technical is naive.

      1. toast0 · · focus · HN ↗
        &gt; Why is egress more expensive than ingress in clouds? To lock in users.

        Eh... Bandwidth contracts are almost always billed only in the dominant direction. Very few cloud applications are inbound dominant. There&#x27;s no need to bill for inbound traffic.

        I personally find the cloud bandwidth prices pretty high, and I assume that&#x27;s where they make up for difficult to account for costs, but not charging for inbound is totally reasonable.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.