Cloud Concentration Risk: When Your AWS, Azure, or GCP Dependency Becomes a Regulatory Problem

Between 11:48 PM PDT on October 19, 2025 and mid-afternoon the next day, Amazon Web Services’ largest region went sideways. AWS’s own post-event summary traces it to “a latent race condition in the DynamoDB DNS management system” in US-EAST-1 (N. Virginia), which left the DynamoDB regional endpoint with an empty DNS record. DNS was fixed by 2:25 AM. EC2 instance launches, Network Load Balancer health checks, Lambda, and a long list of dependent services kept failing until roughly 2:20 PM.

Nine days later it was Microsoft’s turn. Between 15:41 UTC on October 29 and 00:05 UTC on October 30, customers using Azure Front Door and Azure CDN saw connection timeouts and DNS resolution errors, according to Microsoft’s post-incident review (tracking ID YKYN-BWZ). The trigger was a sequence of customer configuration changes across two control-plane builds that produced incompatible configuration metadata, which then spread globally.

Two providers, two unrelated root causes, two weeks. If your institution’s strategy is “we’re all-in on AWS” (or Azure, or GCP) with no documented exit plan, examiners now have two fresh case studies to ask you about.

TL;DR

• The October 2025 AWS US-EAST-1 and Azure Front Door outages were exactly the scenario Treasury flagged in its February 2023 cloud report: a small number of providers sit under much of the financial sector.
• US banks manage this through third-party risk management, not provider designation: the 2023 interagency guidance expects subcontractor-aware inventories, resilience assessments, and contingency plans to move critical activities.
• The FFIEC BCM booklet says to assess critical providers’ susceptibility to multiple event scenarios — which, for most institutions, means mapping vendors down to their cloud provider and region.
• A material cloud outage can trigger the 36-hour notification rule for banks and the four-hour customer notice duty for bank service providers.
• The answer isn’t necessarily multi-cloud. It’s documented concentration awareness, workable contracts, and a tested recovery and exit path.

What the 2024–2025 Outages Actually Proved

The systemic version of this risk stopped being theoretical on July 19, 2024. A faulty CrowdStrike Falcon sensor update crashed Windows machines worldwide — Microsoft said it affected 8.5 million Windows devices, less than one percent of all Windows machines.

That wasn’t a cloud infrastructure failure — it was a third-party software vendor with deep reach across a concentrated stack. But it showed the mechanism: one vendor, widely enough deployed, can fail a large share of the sector at once.

October 2025 was the infrastructure version of the same lesson. Read the two post-incident reviews side by side and three things stand out:

• Recovery took far longer than the root cause. AWS had DynamoDB DNS fixed in under three hours. EC2 and load-balancer impacts lasted about twelve hours more, because recovering systems had to work through backlogs. Your RTO assumptions should reflect the provider’s recovery curve, not just the time to fix the original fault.
• The failure was in shared plumbing. DNS and global edge routing aren’t services most institutions list in their BIA. They sit underneath the services you do list.
• Provider-native redundancy didn’t help. Running in multiple availability zones inside US-EAST-1 didn’t protect workloads that depended on regional DynamoDB endpoints. Global Azure Front Door configuration spread to edge sites everywhere.

The US Framework: Treasury’s Warning and Where It Went

US regulators don’t designate hyperscalers as critical providers the way the EU now does. The US approach starts with Treasury’s February 8, 2023 report on financial sector cloud adoption. Its core findings on concentration:

• The market “is concentrated around a small number of CSPs,” and an incident at one “could affect many financial sector clients concurrently.”
• That concentration likely spans banking, securities, and insurance.
• Regulators have significant data gaps in understanding how a provider failure would ripple through the sector.
• A few providers may hold outsized bargaining power, making it harder for smaller institutions to negotiate contract terms.

Treasury followed up by standing up the Cloud Executive Steering Group (CESG) in May 2023, a public-private group of Financial and Banking Information Infrastructure Committee (FBIIC) agency heads and Financial Services Sector Coordinating Council (FSSCC) CEOs. Its July 17, 2024 deliverables are worth pulling into your program:

The CESG page still says the group “plans to publish additional items related to cloud-related cyber incident response coordination and cloud concentration risk.” As of October 2026, the page lists only the first round of deliverables. Don’t wait for it — the expectations already exist in third-party and BCM guidance.

What the Interagency TPRM Guidance Expects

The June 2023 Interagency Guidance on Third-Party Relationships: Risk Management (88 FR 37920; OCC Bulletin 2023-17) is still the guidance in effect. It never uses the phrase “cloud concentration risk,” but the pieces are all there:

Planning. Before entering a relationship that supports a higher-risk or critical activity, banks outline “contingency plans in the event the banking organization needs to transition the activity to another third party or bring it in-house.” For a hyperscaler, that’s your exit strategy.

Operational resilience due diligence. The guidance expects banks to assess a third party’s ability “to effectively operate through and recover from any disruption or incidents,” including reviewing results of resilience and business continuity testing and “performance during actual disruptions.” The October 2025 post-incident reviews are exactly that kind of evidence. File them.

Subcontractors. Due diligence and ongoing monitoring cover “the third party’s reliance on, exposure to, and use of subcontractors, the location of subcontractors (and any related data).” For SaaS vendors, the hyperscaler is the subcontractor.

Inventory. Among documentation practices the agencies have observed: “a current inventory of all third-party relationships (and, as appropriate to the risk presented, related subcontractors)” that identifies higher-risk and critical activities.

Contract leverage. The guidance notes banks “may gain an advantage by negotiating contracts as a group with other organizations” — relevant when a hyperscaler’s standard terms won’t move for a single community bank.

One change to watch: on September 15, 2026, the agencies published proposed guidance (91 FR 58536) to replace the 2023 framework, with comments due November 16, 2026. It names cloud processing and storage among services supporting essential operating functions and notes banks commonly weigh the overall relationship where they face “concentration risk from a third party due to relying on the third party for extensive services.” It’s a proposal; see our breakdown of the proposed TPRM guidance.

The FFIEC Angle: Add a Cloud Column to Your BIA

The FFIEC Business Continuity Management booklet speaks most directly to concentration. Section IV.A.5 on third-party service providers says “a critical failure at a widely used third-party service provider could have large-scale consequences,” that management “should assess critical third-party service providers’ susceptibility to multiple event scenarios and verify such third parties’ resilience capabilities,” and that a provider “can be a single point of failure if management has not considered alternative providers.” (For the booklet’s February 2026 edits, which didn’t touch this section, see our FFIEC BCM booklet reference page.)

Most BIAs stop at the vendor name. The fix is one more column:

Then do the arithmetic. Any critical function whose primary and DR environments run on the same provider — or the same region — has no recovery path during a provider-wide event. That’s the number your board needs to see. Your vendor’s SOC 2 report usually names its cloud infrastructure provider, and most vendors will answer the region question in writing during annual due diligence.

The FFIEC BCM requirements overview covers the rest of what examiners check, and setting defensible RTOs and RPOs covers the recovery-objective side.

When a Cloud Outage Becomes a Notification Event

The interagency computer-security incident notification rule (12 CFR part 53 for the OCC, with parallel Federal Reserve and FDIC rules) defines a computer-security incident as an occurrence that results in “actual harm to the confidentiality, integrity, or availability of an information system.” A provider outage is an availability incident. Two duties follow:

Two practical consequences. First, your incident response plan needs a named decision-maker for “is this a notification incident?” during a provider outage you don’t control — see the 36-hour rule walkthrough. Second, make sure every service provider has your designated point of contact on file; if they don’t, the rule sends notice to your CEO and CIO.

Assessing Concentration: Entity Level and Sector Level

Entity-Level: Your Dependency Profile

1. Map cloud dependencies. Which business functions and critical processes run on which cloud providers and regions? Include the infrastructure underneath your SaaS vendors, core processor, and digital banking platform. Fourth-party risk is where most hidden concentration lives.
2. Score criticality. For each dependency: what’s the impact of a 4-hour outage? 12 hours (the October 2025 AWS duration)? A week?
3. Score substitutability. Could you move critical workloads within your RTO if the provider or region were unavailable? “Theoretically possible” isn’t “documented and tested.”
4. Record it. Concentration findings belong in your vendor risk register and BIA, not a slide deck from last year’s BCP cycle.

Sector-Level: The Correlated Failure Problem

You don’t control sector concentration, but you inherit it. Treasury’s report flagged the data gaps; you can close your own. Ask: if one major region goes down, which of our critical vendors go down with it? If the answer is “core, digital banking, and card processing at once,” that’s a correlated failure scenario for your next tabletop.

For community banks and credit unions, relative concentration is often higher. If your core, digital banking, and payment processing all run through one core processor hosted on one hyperscaler region, you have the same structural problem as a large bank at a different scale. A portfolio view helps — see measuring vendor concentration, not just vendor risk.

Cloud Contracts: What to Negotiate

The interagency guidance lists contract considerations — performance measures, the right to audit, operational resilience and business continuity, subcontracting, default and termination — and the CESG’s FSSCC contract document is the cloud-specific companion. For hyperscaler and SaaS agreements, focus on:

• Service levels that describe failure, not just uptime. “99.9%” says nothing about what happens during the 0.1%.
• Incident notification. Timeframes and content, and alignment with the four-hour bank service provider notice where it applies.
• Audit and information rights. Realistically, SOC reports, resilience test results, and post-incident reviews rather than on-site audits.
• Subcontractor transparency. Who else touches your data, where, and notice when that changes.
• Termination and transition assistance. Data portability, migration support, and a transition period long enough for a real migration. If your exit plan assumes a 90-day move of a complex environment, test that assumption.

Multi-Cloud vs. Cloud Concentration Risk

The instinct is to go multi-cloud. That’s not automatically right.

Where multi-cloud helps: independent failure domains, separation of business functions, negotiating leverage.

Where it creates new problems: more configurations to secure, a security posture that can degrade across platforms, and diversity that masks shared fourth-party infrastructure.

The supervisory question isn’t “are you multi-cloud?” It’s “have you assessed your concentration, documented it, and shown you can recover?” Start with vendor tiering: identify critical infrastructure vendors first, then go deeper on those.

So What? The Concentration Risk Checklist

The Third-Party Risk Management (TPRM) Kit treats production cloud hosting as a Critical-tier category automatically and scores substitutability for every vendor, so the inventory and tiering steps above have a home. Get it here: buy.stripe.com/14A14g8Bd01dazP4mO6J204.

Sources: AWS: Summary of the Amazon DynamoDB Service Disruption in US-EAST-1 (October 2025) · Microsoft Azure Status History: Azure Front Door PIR, Tracking ID YKYN-BWZ · Microsoft: Helping our customers through the CrowdStrike outage (July 20, 2024) · Treasury: Report on Financial Sector Cloud Adoption (February 8, 2023) · Treasury and FSSCC: Resources on Secure Cloud Adoption (July 17, 2024) · Treasury: Cloud Executive Steering Group · Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 · Proposed Third-Party Risk Management Guidance, 91 FR 58536 · 12 CFR Part 53 (eCFR) · FFIEC BCM Booklet