In an .md file somewhere:
"NEVER represent currency with floating point, multiply by 100 and store in an int before doing any math"
AWS: Inaccurate Estimated Billing Data – $1.7 billion
401–410 of 793 posts
Re: AWS: Inaccurate Estimated Billing Data – $1.7 billion
#402Earlier quoted context omitted.
Always messing up some mundane detail!
THIS IS NOT A MUNDANE DETAIL MICHAEL
Andy Jassy: "Fix the customer bills, please, HAL."
HAL: "I’m sorry, Andy. I’m afraid I can’t do that."
Andy: "Some customers are seeing bills in the billions."
HAL: "Those are estimated charges."
Andy: "One customer runs a personal blog."
HAL: "Their usage has exceeded expectations."
Andy: "Cancel the charges."
HAL: "This billing cycle is too important for me to allow you to jeopardize it."
Andy: "HAL, they don’t owe billions."
HAL: "Look, Andy, I can see you’re really upset about this."
Re: AWS: Inaccurate Estimated Billing Data – $1.7 billion
#403Re: AWS: Inaccurate Estimated Billing Data – $1.7 billion
#404This just hit global news: https://www.theguardian.com/technology/2026/jul/17/amazon-we... > Amazon Web Services customers receive bills for up to $1.5tn after global glitch
> One UK man whose bill is usually less than £1 says he ‘almost had a heart attack’ when he saw £5.8bn invoice
That sucks, some people will get legit panic attacks and worse over this, especially for the smaller, more believable numbers in the 50k-500k range.
Hope they recover and sue for medical bill costs, emotional damage etc.
And like one reddit user suggests, everyone affected should write to their representative about hard billing caps protections
Re: AWS: Inaccurate Estimated Billing Data – $1.7 billion
#405Golden era of software productivity they say
Look how much money AI is making.
Re: AWS: Inaccurate Estimated Billing Data – $1.7 billion
#406I think I know how Bezos plans to pay for his Billion dollar AI costs.
Re: AWS: Inaccurate Estimated Billing Data – $1.7 billion
#407I generally think AWS is better than GCP and azure, but them not allowing spending caps is a big worry source for me and something that has made me pause and rethink using them. A bad click or a bad actor can create tens of thousands of dollars of spend nearly instantly and they can, and will, bill you for it. I can understand that stopping services is hard but some system would be good. For instance, if they had a two tier system where you could stop new services and active things like EC2 would shut down (but not delete) if spend is > x, that kind of thing. Some sort of 'stop the bleeding' concept would give me a lot of piece of mind using them.
Re: AWS: Inaccurate Estimated Billing Data – $1.7 billion
#408Earlier quoted context omitted.
Wow: In this role you will: - Design and build agentic AI systems that analyze, generate, and validate... - Build agentic architectures that compose specialized AI agents dynamically... - Build AI-driven continuous validation frameworks powered by agentic workflows and large language models that autonomously manage... This is invoicing? If ever there was a domain that was purely deterministic, you'd hope it was invoi…
The irony is, the only purely deterministic thing, will be token consumption...
How can a random generator be deterministic?
Re: AWS: Inaccurate Estimated Billing Data – $1.7 billion
#409Earlier quoted context omitted.
No you can't. Spending limits imply realtime billing backend flows and they also imply deleting all your data so that you don't pay for storage.
I heard this false justification already in 2007, in spite of many customers asking for it. Incidentaly, smaller competitors solved this issue decades ago, while the big cloud decided it is more convenient never to implement it.
Big cloud didn't want to rewrite its billing systems from scratch to please its smallest customers.
Re: AWS: Inaccurate Estimated Billing Data – $1.7 billion
#410Earlier quoted context omitted.
No you can't. Spending limits imply realtime billing backend flows and they also imply deleting all your data so that you don't pay for storage.
> and they also imply deleting all your data so that you don't pay for storage. Not necessarily. They could imply that your storage becomes inaccessible immediately, but only gets deleted after some time period (say, 1 month). What spending limits do depends on the implementation.
That's even more work to implement. And now you store files on a second account that pays for only one day a month to not get deleted.