If Web3 is decentralized, why do DeFi dApps still break when the cloud goes down?

On October 20th, Amazon experienced an outage in its US-EAST-1 region, causing a knock-on effect across the cryptocurrency industry. Coinbase reported service degradation, Infura and Alchemy posted AWS-related incident notes, and some wallets and rollups started timing out.

None of these failures are due to the blockchain itself. The consensus was fine. The problem was everything around it: cloud databases, RPC gateways, DNS, indexers, key management systems, etc. that turned blockchain into a usable app.

This was a stark reminder that much of Web3 is still heavily dependent on Web2. When one region of AWS sneezed, a quarter of the cryptocurrency user interface caught a cold.

invisible monoculture

Behind the rhetoric of decentralization is a quiet dependency map that appears surprisingly centralized. A typical dApp starts with a frontend hosted on S3 or Cloudflare Pages, served through a CDN like Fastly, and resolved by Route 53 or Cloudflare DNS.

Below that is read and write RPC (often Infura, Alchemy, or QuickNode), most of which themselves run on AWS or another “big 3” cloud. Then come indexers like The Graph and Covalent, rollup sequencing services, and storage and key management systems like Fireblock. Each tier introduces a single point of failure.

When AWS’ DynamoDB and DNS services failed, multiple layers were attacked simultaneously. Coinbase’s API became slow, Infura and Alchemy reported upstream AWS issues, and several rollups saw sequencers hang up until manual intervention. Even The Graph’s indexer for zkSync already exhibited a similar vulnerability a few weeks ago.

The illusion of redundancy has also been shattered. Two independent RPC providers each promise “9.9x” uptime, but their failures are correlated when both are on the same cloud region. Statistically, independence breaks down. The effective correlation coefficient between AWS-centric stacks can reach 0.9.

This concentration is not limited to cryptocurrencies. AWS still holds around 30-32% of the global cloud share, Azure around 20% and Google Cloud 13%. The six-hour disruption in one major region affected DNS, object storage, and database services used by thousands of businesses.

For encrypted apps, this means that 10% to 30% of EVM-based frontends or read functionality can degrade during such events. Writes and transactions that rely on sequencers or managed signature paths may freeze completely.

the myth of independence

It’s easy to confuse on-chain resiliency with application resiliency. Blockchains like Ethereum and Solana have the potential to maintain consensus through global nodes. However, the tools that people actually use often rely on centralized intermediaries. Solana’s 5-hour outage in February 2024 was an on-chain failure, but the AWS outage was not. It was an off-chain thing and much more common.

Each layer adds its own Achilles heel.

  • Sequencers on L2 are still mostly single-operator setups. When the connection to Ethereum’s RPC is broken, the ability to post new batches is also broken.
  • Content delivery and DNS introduce additional vulnerabilities. Cloudflare’s July 14 resolver issue left parts of the internet inaccessible for nearly an hour.
  • Even “distributed” storage can be dependent on a single company. When Infura’s IPFS gateway went down on September 20, access to assets that were theoretically mirrored across the network was halted.
  • Custody and key management platforms such as Fireblock used by exchanges and funds also experienced processing delays on October 26th and September 17th, causing withdrawals and payments to be delayed.

These failures are important because they affect user trust more than protocol uptime. When your wallet shows stale balances or bridge transactions get stuck, you lose faith in the very decentralization your wallet claims to provide.

Regulators are also starting to take notice. The EU’s Digital Operational Resilience Act (DORA), which comes into force in January 2025, requires financial institutions to test and report third-party ICT dependencies. Britain’s “significant third party” regime is expected to bring hyperscalers under direct supervision next year.

Cryptocurrency custody, stablecoin issuers, and tokenized asset platforms currently overlap with regulated finance, so the same expectations for cloud diversification will soon apply here as well. Reliance on a single vendor cloud is turning into a board-level risk.

The fix isn’t sexy, but it’s coming soon

The solution has been shipped. In the short term, developers are introducing provider quorum RPC, which queries multiple endpoints, self-hosted, SaaS, and distributed (such as pocket networks) and displays results only if two out of three agree. Tools like Helios bring light client verification directly into wallets and mobile apps, allowing users to verify data without relying on a central gateway.

The infrastructure team employs a multi-CDN and multi-DNS setup with active failover. When it comes to storage, running your own IPFS gateway or mirroring assets with Arweave or Irys is becoming the norm. In the rollup world, projects like Espresso, Radius, and Astria are building shared or distributed sequencers, while OP Stack is starting to deploy permissionless, fault-proofing.

Further down the roadmap, Ethereum’s PeerDAS proposal aims to make data availability checks affordable enough to be performed at the wallet level. When combined with light clients, validation can be pushed towards the edge of the network rather than the center of the cloud.

Institutional pressures will reinforce these changes. With DORA and UK CTP rules, multicloud architecture is becoming a policy rather than a preference. We expect large custodians and exchanges to request vendor diversification across RPC, indexers, and key management providers.

None of these will make cryptocurrencies completely independent of traditional infrastructure, but they will narrow the gap between decentralized ideals and chaotic operational realities. The lesson of October 20th is not that blockchain has failed, but that the scaffolding supporting it has not yet caught up.

A truly decentralized app doesn’t mean every user runs a server. That means no single server can bring down the system. Until it becomes the default, all “Web3” outages will still start the same way. In other words, when the cloud sneezes, the blockchain trembles.

mentioned in this article

Leave a Reply

Your email address will not be published. Required fields are marked *