Concentration risk means many of your dependencies share one underlying provider, region or component. Two dated facts show why regulators and engineers care: a single-region AWS fault in October 2025, and the start of UK oversight of four cloud providers on 13 July 2026.
The facts
AWS's own summary of 19 and 20 October 2025 describes a DNS failure for DynamoDB in us-east-1 that lasted about 14.5 hours end to end once knock-on effects are included. Affected services included EC2 launches, Network Load Balancer, Lambda, ECS, EKS, Fargate, STS, IAM and console sign-in, Redshift, Amazon Connect and AWS Support Center. Existing EC2 instances were not affected. The summary shows how one service inside a region became a dependency for many others.
On 10 July 2026 the Bank of England announced that HM Treasury had designated four providers as critical third parties: Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Ltd and Oracle Corporation UK Limited. Oversight by the Bank of England, PRA and FCA began on 13 July 2026. The Bank says designation is not authorisation, oversight is limited to service resilience, and regulated firms "remain responsible for managing their own third-party arrangements," including vetting, risk management and contingency planning.
This is not a forecast of failure. It is a record that regulators treat the concentration as a risk worth supervising, and that firms still carry their own duty.
What is evidence and what is not
Evidence: the AWS timeline and affected services, and the Bank of England's list and wording. Not shown by these sources: how often such events will recur, or that a multi cloud design always helps. Multi cloud brings its own complexity, so weigh it against simpler measures.
How to map your concentration
- List every production dependency: cloud provider, region, identity provider, DNS, CDN, payment, email, monitoring, CI and source hosting.
- For each, note the provider and region. Count how many share one.
- Ask which dependencies need to be up for you to fix things: for example, does your deploy pipeline or incident chat live in the same region as production?
- Record the result as risks with an owner.
What to do now
- Pick your top three single points of failure from the map.
- For each, choose a response: a second region, a second provider, a degraded mode, or accepting the risk in writing.
- Keep incident tooling, status page and runbooks outside the region and provider you are trying to protect.
- Test failover for the one customer facing service that matters most.
- Add exit and outage clauses to vendor reviews, and ask providers for their post-incident summaries.
How this could have been avoided
Customers cannot prevent a provider's bug. They can limit its effect: a second region with tested failover, graceful degradation when one backing service errors, and incident tooling hosted elsewhere.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
What does the Bank of England say designation of a provider does not mean?
It is not authorisation, and oversight is limited to the resilience of the services provided.
Who remains responsible for third party risk at a regulated firm?
The firm itself, including vetting, risk management and contingency planning.
