Original reporting sourced from cryptonewsz.com. This article covers the AWS Asia Pacific (Tokyo) outage of August 23, 2019 and its impact on cryptocurrency exchange operations.
What Happened: AWS Tokyo Outage Disrupts Crypto Exchanges
On August 23, 2019, Amazon Web Services experienced a significant disruption in its Asia Pacific (Tokyo) region. The incident was attributed to overheating hardware in an AWS data center, which caused cascading failures affecting caching services and other infrastructure components. Several major cryptocurrency exchanges that relied on AWS infrastructure in that region were caught in the blast radius.
The exchanges most visibly affected included:
- Binance – reported global user impact, primarily around caching services
- KuCoin – cited overheating of AWS-hosted chassis in Tokyo as the direct cause
- BitMax (now AscendEX) – a Singapore-based exchange that temporarily suspended trading
Exchange Responses
Each affected platform responded differently as the situation unfolded.
Binance
Binance CEO Changpeng Zhao (CZ) acknowledged the issue publicly on Twitter:
AWS is having an issue, mostly with caching services, affecting some users globally. We are working with them and monitoring the situation closely.
— CZ Binance (@cz_binance), August 23, 2019
Binance chose to keep trading active but suspended deposits and withdrawals as a precautionary measure while the infrastructure issues were being resolved.
KuCoin
KuCoin issued a community notice stating that overheating in the AWS Tokyo machine room had rendered part of its services unavailable. The exchange worked to migrate or restore affected services while warning users that some functionality might be intermittent.
BitMax
BitMax took the most conservative approach, temporarily halting all trading and suspending withdrawals after it detected that its order book data may have been corrupted. The exchange noted via its Telegram channel that it was not yet certain whether the erroneous price data originated from its own platform or was sourced from a third-party price feed.
Corrupted Order Books and Sub-Dollar Bitcoin Fills
The most striking consequence of the outage was the corruption of live order book data on affected exchanges. When market data feeds fail or return stale and incorrect prices, an exchange’s matching engine may still attempt to fill outstanding limit orders against whatever prices are present in the book.
Some traders routinely place low-ball limit orders — sometimes called “black swan” bids — at extreme discounts to the market price, on the theory that a sudden flash crash could briefly bring prices down to those levels. Under normal conditions these orders sit unfilled indefinitely. During this outage, however, the degraded price data environment appears to have allowed some of those orders to execute.
Reports at the time, citing order book data from the Citex exchange, indicated that some Bitcoin transactions were filled at prices as low as $0.32 — a price roughly five orders of magnitude below Bitcoin’s prevailing market rate at the time. Screenshots circulated on social media, though BitMax did not officially confirm that these specific trades occurred on its platform.
The Legal and Practical Dilemma for Exchanges
The incident raised an awkward question: what recourse, if any, do exchanges have when infrastructure failures lead to clearly erroneous fills?
From a technical standpoint, the trades in question were filled in accordance with the exchange’s own matching engine and limit order infrastructure — even if that infrastructure was operating on corrupted data. Users who had legitimate limit orders sitting in the book did nothing wrong on their end. Traditional financial exchanges have mechanisms for declaring clearly erroneous trades and busting them, but cryptocurrency exchanges generally lack standardized equivalents of those rules.
Exchanges in this situation may have the ability to freeze or reverse withdrawals — and BitMax did halt withdrawals — but reversing completed trades unilaterally raises its own legal and trust issues. Practically speaking, the platforms’ most realistic option may be to contact the benefiting users and request a voluntary return of funds, with limited hard recourse if those users decline.
The Broader Risk: AWS as a Single Point of Failure
This incident is a concrete illustration of the infrastructure concentration risk that exists across the crypto industry. A significant portion of cryptocurrency exchanges, DeFi projects, blockchain node providers, and related services run on AWS. The convenience and operational simplicity of cloud infrastructure comes with a trade-off: a regional outage at a single cloud provider can simultaneously disrupt dozens of platforms and their shared users.
Key architectural lessons from this event include:
- Multi-region redundancy: Critical services should be distributed across multiple AWS regions or multiple cloud providers to avoid a single region becoming a point of failure.
- Price feed validation: Exchanges should implement sanity checks on incoming market data — for example, rejecting price updates that deviate from a reference price by more than a defined threshold — before allowing the matching engine to act on them.
- Circuit breakers: Automated trading halts triggered by anomalous price movements or data feed errors can prevent erroneous fills during infrastructure incidents.
- Graceful degradation: Systems should be designed to fail safely — defaulting to read-only or halted states when data integrity cannot be guaranteed, rather than continuing to match orders against potentially corrupted data.
Summary
The August 2019 AWS Tokyo outage exposed a critical gap between cloud infrastructure reliability and exchange-level resilience. While AWS regional outages are relatively rare, their downstream effects on dependent platforms can be severe and, in this case, financially consequential. For DevOps and platform engineering teams running financial or trading infrastructure, the incident reinforces the importance of multi-cloud or multi-region architecture, robust data validation pipelines, and automated circuit breakers — not as nice-to-haves, but as baseline requirements for operational safety.