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

Amazon confirmed the problem on its AWS status page on Friday, July 17, stating that it began seeing inaccurate billing data as of late Thursday, July 16. The company said the bug relates to its billing computation subsystem and that a rollback of a recent change did not resolve the issue as of Friday morning. Amazon's status page indicated the problem was expected to persist for several more hours.

The estimates, while alarming, carry no actual charge. Amazon stated explicitly that the billing estimates in question "do not reflect actual usage and charges." In other words, the underlying metering data capturing real resource consumption appears intact; the failure sits in the computation layer that transforms raw usage records into the cost estimates displayed in the billing portal.

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 patterns.

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. The damage in this scenario is primarily operational: finance teams, automated cost-alerting pipelines, and budget-threshold alerts that poll the billing API can trigger on corrupted estimates, generating downstream noise across an organization's cost-management stack.

That said, the incident does surface a structural question worth weighing. AWS billing estimates are treated by many customers as near-real-time ground truth for cost governance. FinOps teams 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.

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. A corruption event at the billing-computation layer, even one that produces no actual overcharging, erodes confidence in the data pipeline that those processes depend on.

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.