Amazon is fixing a bug in its AWS billing portal that displayed wildly inaccurate cost estimates to some customers, with figures ranging from a few million dollars to nearly $2.5 billion for a single month of usage. TechCrunch reported the issue on July 17, 2026, after affected customers began posting screenshots of their inflated estimates on Reddit.

Amazon confirmed the problem on its AWS status page on Friday, July 17, saying it began seeing inaccurate billing data as of late Thursday, July 16. The company said the bug sits in its billing computation subsystem, the software layer that takes raw usage records and turns them into the cost estimates shown in the portal. A rollback of a recent change did not resolve the issue as of Friday morning, and Amazon expected the problem to persist for several more hours.

The estimates, while alarming, carry no actual charge. Amazon stated explicitly that the figures in question "do not reflect actual usage and charges." In other words, the underlying metering data, the system that tracks how much computing power, storage, and other resources a customer actually consumed, appears intact. The failure is in the computation layer that transforms those raw usage records into the dollar amounts displayed in the billing dashboard.

The scale of the distortion varied widely. One AWS customer posted a Reddit screenshot showing a monthly billing estimate of close to $2.5 billion. Others reported estimates in the range of a few million to hundreds of millions of dollars. The common thread across affected accounts is that the displayed figures bore no plausible relationship to the customers' actual consumption.

TechCrunch's reporting drew primarily on Amazon's own AWS status page updates and customer posts on Reddit. An Amazon spokesperson did not immediately return TechCrunch's request for comment. The AWS Health Dashboard had separately reported a multiple-services operational issue affecting the us-east-1 region on July 16, though the available information does not confirm a direct link between that operational issue and the billing computation bug.

For anyone who has managed cloud infrastructure budgets, the distinction between a metering failure and a billing-computation failure matters considerably. If raw usage data is intact, customers will not be overcharged on their actual invoices. The estimates in the portal are informational, not transactional. Think of it like a gas pump that displays the wrong dollar total while the internal meter that tracks gallons pumped is still accurate: you pay for what you actually used, not what the display says.

The damage in this scenario is primarily operational. Finance teams, automated cost-alerting pipelines, and budget-threshold alerts that pull data from the billing API can trigger on corrupted estimates, generating downstream noise across an organization's cost-management stack. A team might get an automated alert that their monthly spending has suddenly jumped to hundreds of millions of dollars, prompting an investigation that turns up nothing wrong.

The broader context here is that cloud cost management has become a first-class operational discipline. Organizations running multi-million-dollar AWS footprints rely on the accuracy and timeliness of billing data to make scaling decisions, trigger cost-optimization workflows, and enforce budget guardrails. FinOps teams, the people responsible for managing and optimizing cloud spending, build alerting rules, anomaly-detection logic, and executive dashboards that consume the billing API's estimated figures. When those estimates can swing by orders of magnitude without any change in actual usage, the reliability of the entire cost-observability layer built on top of them comes into question. A billing estimate that can show $2.5 billion where the real figure is presumably a small fraction of that is not a rounding error; it is a total failure of the computation path, and the fact that a rollback did not immediately fix it suggests a non-trivial fault in the subsystem's change-management pipeline.

Amazon's prompt public acknowledgment and its statement that actual charges are unaffected are the right corrective steps. The status-page transparency, however, is operating within AWS's standard incident-communication pattern: periodic updates with limited technical detail on root cause. For a billing-system failure of this magnitude, affected customers will reasonably want a post-incident explanation of how the computation subsystem produced orders-of-magnitude errors and what changes will prevent a recurrence.

The episode is, at its core, a contained incident with no financial impact on customers. It is also a reminder that the billing and cost-estimation layer of a major cloud provider is itself a complex, failure-prone system, and that downstream consumers of its data should architect their cost-management tooling with appropriate skepticism about the reliability of any single data source.