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

On October 20, a hiccup in the US-EAST-1 region of Amazon started a chain reaction throughout the crypto industry. Coinbase degraded service report, Fat and Alchemy published incident notes related to AWS, and several wallets and rollups began to leak.

None of these failures come from the blockchains themselves. The consensus was good. U problem it was all wrapped around it: the cloud databases, RPC gateways, DNS, indexers and key management systems that turn a blockchain into a usable app.

It was a stark reminder that most of Web3 also relies heavily on Web2. When a region of AWS sneezed, a quarter of the crypto user interface took a cold.

The invisible monoculture

Behind the rhetoric of decentralization lies a map of quiet dependence that seems highly 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 are read and write RPC, often Infura, Alchemy, or QuickNode, most of which run on AWS or another of the “Big 3” clouds. Then come indexers like The Graph or Covalent, sequencing services on rollups, and custody or key management systems like Fireblocks. Each layer introduces a unique point of failure.

When AWS’s DynamoDB and DNS services went down, multiple layers were hit simultaneously. Coinbase’s API slowed down, Infura and Alchemy reported upstream AWS issues, and several rollups saw their sequencers stall until manual intervention. Even the Graph indexer for zkSync had already shown a similar vulnerability weeks before.

The illusion of redundancy has also fallen. Two independent RPC providers each promise “four nines” uptime, but if they are both located in the same cloud region, their failures are correlated. Statistically, the independence collapses: the effective correlation coefficient between stacks centered on AWS can reach 0.9.

This focus is not limited to crypto. AWS still holds about 30-32% of the global cloud share, Azure about 20%, and Google Cloud 13%. A six-hour disruption in a major region spanned DNS, object storage and database services used by thousands of companies.

For crypto applications, this means that between 10% and 30% of EVM-based frontends or reading functions may be degraded during such an event. Writes and transactions that depend on sequencers or signature paths of custody can freeze completely.

The myth of independence

It is easy to confuse chain resistance with application resistance. Blockchains like ethereum o Solana can maintain consensus across global nodes; however, the tools that people actually use often depend on centralized intermediaries. The five-hour shutdown of Solana in February 2024 was a failure in the chain, but the interruption of AWS was not. It was an off-chain, and much more common.

Each layer adds its own Achilles heel.

• Sequencers on L2s are still largely single operator setups. If its connection to the Ethereum RPC is broken, so is its ability to publish new batches.
• Content delivery and DNS introduce more fragility: Cloudflare’s July 14 resolution issue left parts of the Internet inaccessible for nearly an hour.
• Even “decentralized” storage can still rely on a single company. The shutdown of Infura’s IPFS gateway on September 20 stopped access to assets that were theoretically mirrored across the network.
• Custody and key management platforms, such as Fireblocks, used by exchanges and funds, experienced processing delays on October 26 and September 17, stalling withdrawals and settlements.

These failures matter because they affect user confidence more than protocol uptime ever could. A bag display a tired balanceor a bridge transaction stuck in limbo, erodes confidence in the very decentralization it claims to offer.

Regulators are starting to notice. The EU’s Digital Operational Resilience Act (DORA), in force from January 2025, obliges financial entities to test and report ICT dependencies on third parties. The UK’s ‘Critical Third Party’ regime is expected to bring hyperscalers under direct supervision next year.

As crypto custody, stablecoin issuers and tokenized asset platforms now overlap with regulated finance, the same expectations for cloud diversification will soon apply here as well. A vendor’s cloud trust turns into a board-level risk.

The fix isn’t glamorous, but it’s coming

Solutions are shipped. In the short term, developers will introduce provider quorum RPCs that query more endpoints, self-hosted, SaaS, and decentralized (such as Pocket Network), and display a result only if two out of three agree. Tools like Helios bring light customer verification directly into wallets and mobile apps, allowing users to validate data without relying on a centralized gateway.

Infrastructure teams adopt multi-CDN and multi-DNS configurations with active failover. For storage, running its own IPFS gateway or mirror assets in Arweave or Irys has become standard. In the rollup world, projects like Espresso, Radius and Astria are building shared or decentralized sequencers, while OP Stack has started to release bug proofs without permission.

Further down the road, Ethereum’s PeerDAS proposal aims to make data availability checks affordable enough to run at the wallet level. Combined with light clients, this could push verification towards the edges of the network rather than the center of the cloud.

Institutional pressure reinforces these changes. Under the UK’s DORA and CTP rules, multi-cloud architectures have become policy, not preference. Expect large custodians and exchanges to demand diversification of RPC vendors, indexers and key management providers.

None of this will make crypto completely independent of traditional infrastructure, but it will narrow the gap between the ideals of decentralization and the messy operational reality. The lesson of October 20 is not that blockchains fail, it’s that the supporting scaffolding has not yet caught up.

A truly decentralized app won’t mean that each user runs a server; it will mean that no server can take over the system. Until this is the default, every “Web3” interruption will always start in the same way: when the cloud sneezes, the blockchain shakes.