I Got a $95 Million AWS Bill Alert at 3am. Here Is How I Triaged It
AWS emailed me a $95 million bill at 3am. I froze my cards and went to sleep. By morning it was 24 cents. The July 2026 AWS billing bug, and what it really taught me.

My phone lit up at 3:22 in the morning with a subject line no cloud engineer wants to read half asleep:
AWS Cost Management: Cost anomaly(ies) summary for account [2026-07-17]
The body claimed a single day of Amazon Simple Storage Service usage with this cost impact:
Max Daily Impact:
$9.524186364E7Total Impact:$9.524186364E7
That E7 on the end is scientific notation. Nine point five, times ten to the power of seven. Ninety five million, two hundred forty one thousand, eight hundred sixty three dollars. On a personal account.
Here is what I did about it: nothing, and then I went to bed. My reasoning at 3am was simple. If I genuinely owe Amazon ninety five million dollars, that is a them problem, not a me problem. I do not have ninety five million dollars. I do not have the first million of it. You cannot get blood from a stone, and you cannot get it from a solo founder asleep in his bed either. So I froze my business bank cards as a precaution, put the phone face down, and gave my brain the one thing it actually needed: a night to let the news of owing money in this life and the next one settle before I did anything I could not undo.
By the time the sun came up and I looked properly, the real figure was sitting there in plain sight: the actual Simple Storage Service cost for the whole month was twenty four cents. Not ninety five million dollars. Twenty four cents. This post is the calm walk through I did over coffee, written down so you can run it in twenty minutes instead of losing a night to it, followed by the guardrails I set up afterwards so the next 3am email does not even wake me.
If you got a version of this email over the weekend of July 16 to 18, 2026, you were not alone and you were almost certainly not hacked. AWS confirmed a bug that inflated cost estimates into the trillions for customers all over the world. More on that in a moment. But at 3am I did not know that yet, and if you are reading this mid panic, neither do you. So here is how you tell a real emergency from a display bug before the news catches up.
First, decode the number
AWS renders these anomaly emails with raw scientific notation, which is most of the terror. Here is the same alert in plain figures:
- Amazon Simple Storage Service:
$9.524186364E7is $95,241,863.64, flagged over one day. - Amazon DynamoDB: $62,955.57 total, over two days, mostly point in time recovery storage.
- Amazon CloudFront: $371.50, data transfer out.
The two "root causes" AWS listed for the storage line were a us-east-1 contribution of $3.416076066E7 ($34.2 million) and a eu-central-1 contribution of $5.637901996E7 ($56.4 million), both against the usage type TimedStorage-ByteHrs.
Before you touch anything, sit with one fact: the word "impact" in these emails is not the word "charge". Cost Anomaly Detection reports how far your spend deviated from what its model predicted, and that model is fed by AWS's estimate of your spend. An estimate can be wildly wrong, as this whole weekend proved. Ninety five million dollars of storage byte hours appearing overnight is not physically possible on a personal account. At roughly two cents per gigabyte per month, that figure implies exabytes of data materializing in a day. Nobody uploads four billion gigabytes by accident.
So the number was almost certainly noise. But "almost certainly" is not a plan. There were four real ways this could have been something, and I checked each one.
The four questions I asked over coffee
The email arrived at 3am. The answers waited until I was awake. Here is what I checked, in order, with a clear head.
1. Is this email phishing?
A fake billing alarm is the oldest trick there is, and panic is exactly the state attackers want you in. So before clicking anything, I checked the envelope, not the body.
In Gmail, open the message, click the three dots, and choose "Show original", or just expand the header summary. Mine read:
mailed-by: amazonses.comsigned-by: costalerts.amazonaws.com- Standard encryption (TLS)
That is genuinely AWS. Cost alerts are sent through Amazon Simple Email Service, and the DomainKeys Identified Mail signature belongs to costalerts.amazonaws.com. A phishing message will fail here: the signing domain will be some lookalike, the DomainKeys and Sender Policy Framework checks will not pass, and the links will point somewhere that is not console.aws.amazon.com.
What to check on any scary billing email:
- Who signed it. The signing domain, not the friendly "from" name, is the truth.
- Where the links go. Hover, do not click. Real AWS links land on
aws.amazon.comorconsole.aws.amazon.com. - How it asks you to act. Real AWS never asks for your password or a card number by email.
Verdict: real email. On to the money.
2. Is this a real charge or a modeled anomaly?
Never trust the email for the actual number. Go to the source. Open the AWS console (by typing the address yourself, not from the email) and look at three places:
- Cost Explorer, filtered to Amazon Simple Storage Service. Set the date range to the current month and add a filter for the one service the email screamed about. If ninety five million dollars were real, it would be sitting right there as a column you could see from space. Mine read $0.24 total for the month. Twenty four cents.
- The billing home, month to date and forecast. My whole account, every service combined, was at $12.30 month to date with a forecast of $18.91 for the month, both down on the previous month. Nothing was on fire.
- The Recommended actions panel. This is the detail that ended the panic. AWS's own console summarized it for me: "9 cost anomalies detected in the last 90 days with a total cost impact of $0.14." The same system that emailed me a ninety five million dollar number valued every anomaly it had ever raised, across three months, at fourteen cents.
Sit with that gap. The email and the console are the same AWS, describing the same account, and they disagree by nine orders of magnitude. When a billing surface contradicts your real usage that violently, the broken thing is the number, not your account. Hold that thought, because the reason it broke turned out to be far bigger than me. The charge never existed.
Verdict: no real spend. But an alert this loud can also be a symptom, so I kept going.
3. Were my credentials stolen?
The genuinely frightening version of this alert is real: someone gets your access keys, spins up expensive resources, and you find out from the bill. A few signals in my own email actually pointed here and were worth ruling out. The anomaly touched regions I do not normally use, including ap-southeast-1 for the CloudFront line. Unfamiliar regions are a classic sign of abuse, because attackers spread load to wherever your account has room.
How to rule out a compromise, fast:
- CloudTrail event history. Filter the last few days for
RunInstances,CreateBucket,CreateFunction, and anyCreateorRuncall you did not make. Look at the source region and the calling identity. - IAM credential report. Download it and check the last-used timestamp on every access key. Anything active that you do not recognize gets disabled immediately.
- GuardDuty. If it is on, it will already have flagged anomalous console logins, credential exfiltration, or crypto mining patterns. If it is off, this is your sign to turn it on today.
- Root account. Confirm multi factor authentication is on and there are no access keys attached to root at all.
Everything in my account traced back to me. No unknown identities, no keys I did not create, no resources I did not launch.
Verdict: not compromised. One suspect left, and it is the modern one.
4. Did I, or an agent, publish my keys somewhere public?
This is the 2026 twist. A lot of us now let coding agents write and commit code. Agents are fast, and fast is exactly how a secret ends up in a public commit: a .env file staged by a wildcard, a hardcoded key in a config, a credential pasted into a test fixture and pushed before anyone reads the diff. Bots scan public code hosts for exposed AWS keys within minutes and start spending.
How to check whether a key leaked:
- Search your public repositories for the access key prefix
AKIA. Every long lived AWS access key id starts with it. - Turn on push protection and secret scanning on your code host so a commit carrying a key is blocked before it ever leaves your machine.
- Add a pre commit secret scanner such as gitleaks or trufflehog, so agents and humans alike get stopped locally.
- If anything is exposed, rotate first and investigate second. Deactivate the key in IAM, create a new one, update your systems, then read the logs. Rotation is free and takes a minute. A leaked key does not.
I scanned. Nothing exposed. Which left me with the boring, happy answer.
The verdict: a false alarm, and the AWS bug behind it
All four checks came back clean. The ninety five million dollar alert was not a real charge, not phishing, not a break in, and not a leak.
Why did it happen? Because this was never really about my account. Over the weekend of July 16 to 18, 2026, AWS ran a bug in the subsystem that estimates and forecasts your spend. A change pushed incorrect unit prices into that estimation layer, and those wrong prices multiplied ordinary usage into impossible numbers. Customers around the world opened their consoles to projections in the trillions. Reported figures from that weekend included a 1.5 trillion dollar bill, one account showing month over month usage growth of 745,728,201,771 percent, and a United Kingdom charity that normally pays under one pound a month faced with a projected 5.8 billion pounds.
I went looking to check whether I had lost my mind, and instead found half the internet in the same boat. Under one video explaining the glitch, the comments read like a disaster hotline: one person reported a 4.4 million dollar bill on less than a megabyte of storage, another 74 billion, another a precise 9,289,124,218,442 dollars and 57 cents. The amounts were random because they were noise. My twenty four cents of storage became ninety five million dollars by exactly the same mechanism.
On X the mood was the same, equal parts terror and comedy:
Post your highest AWS billing. We are at $333B lol #aws
I just saw $1.5 trillion on my AWS bill and my soul left my body
AWS said so itself, in a post that was viewed millions of times as the panic spread:
Service Update: AWS Billing Console
We are investigating issues with Cost Explorer reflecting inaccurate estimated billing data.
Track status: go.aws/aws-hd
#AWS #AWSSupport
By 3:03 in the morning BST on July 17, hours after the trouble started the previous evening, they had the root cause: "an issue with unit pricing within the estimated billing computation subsystem". They stated plainly that "the displayed billing estimates do not reflect actual usage and charges" and that "no customer action is required", then paused the estimates, corrected the pricing, and began recomputing the real figures across every affected account, a job they warned would take hours. The anomaly emails landing in inboxes at 3am, mine included, were that estimation bug's fallout.
So the lesson is not "ignore the alerts". Two lessons, actually. First, no single number from a single surface is the truth. The email, the anomaly monitor, and the forecast are all estimates, and on that weekend they were wrong together. Only the charges on your actual bill and your real usage records are ground truth, and those never moved. Second, and this is the one that matters: the danger was never the fake number. It was what people did with it.
The real danger was never the number
Here is the part that should stay with you. AWS's actual billing was correct the entire time. The only way this incident cost anyone anything real was through their own reaction to it. In those same comment threads, person after person described the same reflex. One saw a budget alert for 1.15 billion dollars, got angry, and deleted every resource in the account that night. Others assumed the only explanation was a breach and started tearing things down to stop the bleeding. AWS did a poor job of telling people in time, which left panic to fill the gap.
Think about the asymmetry. A fake eleven figure number that you calmly verify costs you twenty minutes of sleep. The same number wired to a function that stops or deletes resources, or handed to an autonomous agent told to bring spend down, can cost you your uptime and your data. The bill was never going to be paid. The deleted production database is gone for good.
That gap between a scare and a disaster is entirely within your control, and it is exactly what the guardrails below are built to protect. Every one of them is about verifying and containing, never about reacting automatically.
The guardrails that let me sleep
Here is what I set up so the next 3am email is either accurate or does not fire at all. Everything below is free or nearly free.
Never point destructive automation at a cost signal. This is the one the weekend taught in blood. Do not wire a budget action, an anomaly alert, or an agent instruction to anything that deletes, stops, or tears down resources. Cost alerts can and do fire on numbers that are flat wrong. Let them notify a human, and let the human decide. Automation that reacts to a fake bill by destroying real infrastructure is worse than no automation at all.
Set a real budget, not just an anomaly monitor. In AWS Budgets, create a monthly cost budget at a number that would actually alarm you, and alert on both actual and forecasted spend. Forecast alerts warn you before the money is gone, not after.
Add a near zero budget as a tripwire. A second budget set a little above your normal spend catches a genuine runaway on day one, while the big anomaly figures are still arguing with themselves.
Give Cost Anomaly Detection a dollar threshold. Replace or supplement the default percentage monitor with one that only alerts above an absolute dollar impact that matters to you. This alone would have kept my phone quiet at 3am while still catching anything real.
Turn on GuardDuty. It is the cheapest insurance in the account. It watches for stolen credentials, unusual regions, and mining workloads, and it tells you in plain language what it saw.
Kill long lived keys. Use short lived credentials through IAM Identity Center or roles wherever you can. Put multi factor authentication on every human login, and make sure the root user has no access keys at all.
Stop secrets at the door. Turn on push protection and secret scanning for your repositories, and add a pre commit scanner locally. This matters more than ever now that agents commit code, because the window between a leaked key and a spending bot is measured in minutes.
Restrict where you can spend. If you only operate in two regions, a service control policy or an identity policy that denies everything else shrinks the blast radius of any compromise to almost nothing.
Write the runbook before you need it. The reason the next 3am email will not cost me a wink is that these four questions now live in a file I can open half asleep. Keep yours somewhere you will find it in that state: check the headers, check Cost Explorer, check CloudTrail and IAM, check for leaked keys. Decode the scientific notation before you decide how scared to be.
A strange kind of perspective
There is an odd afterthought I keep coming back to. For a few minutes that night my little personal account was holding a ninety five million dollar number, and once the fear passed, what replaced it was something closer to perspective. Somewhere out there are people whose real monthly bill looks like that, not a glitch, just an ordinary Tuesday. Whatever they are building, they are clearly onto something big, big enough that ninety five million dollars a month is a cost of doing the thing rather than a reason for a heart attack.
Even the sinister reading points the same way. If someone had actually stolen my credentials and genuinely needed that much compute, then whatever they were running was operating at a scale, and a level of nerve, that makes my side projects look like a lemonade stand. Either way, the number did something my own careful little forecasts never do. It made my bills look insignificant, and it made me wonder whether I have been thinking too small.
I am not about to go and spend ninety five million dollars to prove a point. But I did close that browser tab thinking bigger about where my work sits in the grand scheme of things, and that turned out to be the most expensive free lesson I have had in a while.
Frequently asked questions
Was the AWS trillion dollar bill in July 2026 real? No. Between July 16 and 18, 2026, a bug in AWS's billing estimation system displayed wildly inflated cost projections, some in the trillions, to customers worldwide. AWS confirmed that only estimated and forecasted figures were affected and that actual charges and usage records were never impacted. If you saw an impossible number that weekend, your real bill was fine.
What caused the AWS billing bug in July 2026? AWS traced it to incorrect unit pricing introduced into the estimated billing computation subsystem, the layer that projects your end of month spend from current usage. Wrong unit prices multiplied normal usage into implausible totals. AWS paused the estimates, corrected the pricing, and backfilled the accurate data.
Is a $95 million AWS cost anomaly email real or fake?
The email itself can be genuinely from AWS while the dollar figure is meaningless. Verify the sender through the DomainKeys signature (signed-by: costalerts.amazonaws.com), then verify the money in Cost Explorer. A real message with an absurd number is almost always Cost Anomaly Detection modeling noise, not a charge.
What does the E7 mean in an AWS cost alert?
It is scientific notation. $9.524186364E7 means 9.524 times ten to the power of seven, which is $95,241,863.64. AWS formats these emails in exponential notation, which makes ordinary numbers look catastrophic.
Does a Cost Anomaly Detection "impact" mean I have been charged that amount? No. Impact is how far your spend deviated from the model's prediction, and it is recalculated up to three times a day. It is an estimate of anomaly size, not a line on your invoice. Always confirm actual spend in Cost Explorer or the Bills page.
How do I know if my AWS keys were stolen? Check CloudTrail for actions and regions you do not recognize, download the IAM credential report and inspect the last-used time on every access key, and enable GuardDuty. Unfamiliar regions in a cost alert are a common early sign of abuse.
How do I stop an AI coding agent from leaking my AWS keys? Turn on push protection and secret scanning on your code host, add a pre commit scanner such as gitleaks, and never store long lived keys in files an agent can stage. If a key does leak, deactivate it in IAM and rotate before you do anything else.
The takeaway
The best decision I made that night was to treat a ninety five million dollar bill as Amazon's problem, freeze my cards, and go to sleep. A real AWS email told me I had spent ninety five million dollars overnight. The truth was twenty four cents. The distance between those two numbers is not a bug you fix once, it is a monitoring gap you close with a dollar threshold, a couple of budgets, and a short runbook. Tune the smoke detector, put real guardrails underneath it, keep destructive automation away from it, and the next 3am alert is either worth waking up for or never arrives.
Further reading
- The official word from AWS: AWS Support status update
- A clear timeline and the exact AWS wording: AWS Cost Explorer bug shows trillion dollar estimates
- AWS's estimation bug, explained: Trillion dollar cost estimates displayed to customers
- The scale of it: Customers receive erroneous bills up to $1.5 trillion
- Your invoice is fine, your bots are not: on the automation risk
- A video walkthrough: AWS Users Got a $1.5 Trillion Bill, Here Is What Happened
- A fellow victim at the other end of the scale: My bill skyrocketed from around 5 cents
- The tool that emailed me: AWS Cost Anomaly Detection