Concentration risk: when half the internet depends on three companies

In October 2025, a race condition in a single DNS automation microservice deleted the endpoint record for AWS DynamoDB in US-East-1. DynamoDB went down. Then EC2 went down because it depends on DynamoDB. Then over 140 AWS services went down because they depend on EC2. Within hours, Snapchat, Roblox, Reddit, Netflix, Venmo, Coinbase, Slack, and dozens of other platforms were unreachable. Users filed seventeen million outage reports. Full recovery took fifteen hours.

One microservice. One region. One provider. Half the internet went dark.

The illusion of diversity

The internet feels distributed. It is not. Three hyperscalers (AWS, Azure, and Google Cloud) account for seventy to eighty per cent of cloud infrastructure spend in markets like the UK, a concentration the CMA flagged in its 2025 market investigation. A handful of DNS resolvers, CDNs, and certificate authorities underpin much of the rest. Organisations assess this through vendor questionnaires and contracts. They know who they pay. What they often don't know is whether those vendors all depend on the same underlying infrastructure.

Your CRM, your email platform, your analytics service, and your payment processor might all resolve through the same CDN, sit behind the same DNS provider, or route through the same autonomous system. On paper, four independent vendors. At the infrastructure level, a single point of failure. Most organisations have no idea how much of this they carry.

Questionnaires can't see this

Traditional vendor risk management asks the right questions at the wrong layer. Compliance certifications tell you a vendor takes security seriously. Contracts define liability. Neither tells you that three of your critical vendors share an ASN, or that their DNS all points to the same nameserver cluster. When the CrowdStrike update failed in July 2024, it took down systems serving fifty-eight per cent of UK GP practices. Not because the NHS was the target, but because a single vendor's software sat inside infrastructure that half the health service depended on.

These are infrastructure-level dependencies. They don't appear in vendor assessments because vendor assessments operate at the business layer. The result is organisations that look diversified on their supplier lists but are structurally fragile underneath. One failure in a shared layer, whether a cloud region, a DNS provider, or a routing path, and services that appeared independent collapse together.

Mapping what's actually there

Whisper maps the actual infrastructure dependencies beneath services: where their domains resolve, which ASNs route their traffic, how their DNS is configured, which certificate authorities they use. Instead of asking vendors what their infrastructure looks like, you can see it directly, across over 3.7 billion nodes and 31 billion edges modelling the internet's real topology.

This is how you find the single points of failure that questionnaires miss. WhisperRank scores the structural health of a resource's network neighbourhood, so concentration risk surfaces even when every individual vendor looks clean on its own. Blast radius analysis goes a step further: pick a provider, region, or ASN, and see which of your services go down with it, how many of your vendors share the dependency, and how concentrated your exposure actually is. You can quantify the risk before the outage happens.

The internet's dependencies are not hidden. They're published in DNS records, BGP tables, and certificate logs. The problem was never access. It was assembly. Whisper gives you the graph directly from your own tools. Plug it into your SIEM, your scripts, your AI agents. There's a free API key if you want to try it.