One region failed, many financial apps stalled: concentration risk sat in the dependencies
The October 2025 us-east-1 outage hit financial apps whose own designs looked resilient. The exposure lay in shared services and recovery backlogs, so the response is dependency mapping and tested degraded modes, not reflexive multi-cloud.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On Monday, October 20, 2025, Amazon Web Services suffered a major disruption in its US-EAST-1 region in northern Virginia. In its post-event summary, AWS traced the trigger to a latent defect in the automated DNS management for DynamoDB, which left the service’s regional endpoint unresolvable. Failures spread to services that depend on DynamoDB, including EC2 instance launches and Network Load Balancer health checks.
AWS put the customer impact at roughly 14 hours, from late on October 19 to mid-afternoon Pacific time on October 20, in several overlapping phases. A wide range of consumer apps were affected, including payment, trading and crypto apps in the United States. Customers of some UK banks also reported problems with online services.
The easy conclusion from October 20 was that financial firms rely too heavily on one cloud provider. That is true and not very useful. Many affected firms were not running everything in one place by accident. Plenty had multi-availability-zone designs, and some had multi-region plans. What caught them out was narrower. Three distinct exposures explain most of the impact: dependencies firms had not chosen, a recovery tail that outlasted the fix, and governance that measured the provider instead of the firm.
Dependencies nobody chose
A firm can deploy its own application across regions and still depend on one region indirectly. Some cloud features keep their control planes in a single region. Software-as-a-service tools the firm uses, such as identity providers, messaging platforms, fraud scoring or payment gateways, may run in the same region. So may internal tooling: build pipelines, secrets management, feature flags and monitoring.
The result is that failover for the core application can succeed while the services around it fail. If the login service, the push notification provider or the observability stack is down, a healthy core banking API is still unusable to customers and invisible to operators.
The practical response is a dependency map that goes one level beyond the firm’s own architecture. For each important customer journey, such as login, card authorization, bill pay or trade entry, list every service involved, internal and external, and record where each runs. Then ask vendors directly which providers and regions they depend on. Many will not know offhand. That answer is itself useful, and it belongs in the third-party risk file.
The map should also cover the tools used to respond. If the incident chat platform, the status page or the paging service shares the failed region, the firm loses its ability to coordinate at the worst moment. Keeping one out-of-band communication path, on an independent provider, is cheap.
Recovery is a queue, not a switch
The underlying DNS problem was fixed hours before many services returned to normal. In between, throttled requests, retries and stalled work had to drain. Applications that retried aggressively added load to a recovering system. Batch jobs that had stalled restarted at once and competed for the same capacity.
Financial services feels this more than most sectors because so many processes are time-bound. Payment cut-offs, settlement windows, statement runs and overnight reconciliation all have deadlines. A system that is technically up at 3 p.m. but cannot clear its queue until evening may still miss a cut-off. Resilience tests that measure only time to restore service understate the business impact. Firms should also measure time to clear the backlog, and whether downstream deadlines were met.
Design choices shorten the tail. Retries with exponential backoff and jitter prevent clients from hammering a recovering service. Circuit breakers stop a failing dependency from exhausting threads elsewhere. Idempotent transaction design makes it safe to replay requests. Load shedding keeps critical traffic moving by dropping non-essential calls. A documented restart order for batch processes, agreed with operations and finance in advance, avoids an improvised sequence on the night.
Governance that measures the firm, not the provider
Regulators already ask about concentration risk. The U.S. banking agencies’ 2023 interagency guidance on third-party relationships covers it. In the European Union, the Digital Operational Resilience Act has applied since January 2025 and provides for direct oversight of critical ICT providers. Board reports, however, often describe cloud resilience as a property of the provider: uptime commitments, certifications and regions used.
October 20 points to a better question. Can the firm deliver its important business services within defined impact tolerances when one region of its main provider is impaired? That question is about the firm’s design. It leads to concrete tests, such as failing over a customer journey together with its dependencies. It also forces explicit decisions about which services must run active-active across regions and which can accept a degraded mode.
Degraded modes deserve more attention than they get. Showing read-only balances from a cached store, queuing payments for later release with clear customer messaging, or approving low-value card transactions under stand-in rules are all choices that keep customers served. Each needs a business owner, a risk limit and a rehearsal.
Smaller institutions face the same question one step removed. A community bank or credit union rarely contracts with a hyperscaler directly. Its exposure arrives through its core processor, digital banking provider and card processor. Oversight therefore means asking those providers for their own regional dependency maps and test results, and writing that disclosure into renewal terms. A provider that cannot describe its degraded modes is telling the institution something about its resilience.
The same framing settles much of the multi-cloud debate. Running the same workload on two providers is expensive and adds failure modes of its own, from data synchronization to doubled skills requirements. For most institutions, multi-region designs within one provider, plus a few rehearsed degraded modes, deliver more resilience per dollar. Multi-cloud earns its cost for specific components where independence is cheap and valuable, such as DNS, identity, status pages and customer notifications.
With hindsight
The outage did not change how most institutions buy cloud. It did sharpen how they test it. Large incidents followed within weeks: an Azure Front Door outage on October 29 and a Cloudflare outage on November 18 each disrupted widely used services. Together they showed the exposure was shared infrastructure, not one provider.
Supervisors moved too. In November 2025 the European Supervisory Authorities published their first list of critical ICT third-party providers under DORA, which included the major cloud providers. That brought direct EU oversight to the firms whose failures had been in the headlines. Calls for a wholesale move to multi-cloud ran into the usual cost and complexity. The more durable changes were in due diligence, where firms began asking fintech partners and SaaS vendors which regions they depend on, and in measuring recovery against business deadlines rather than service restoration alone.