Cloud Concentration Risk: BCP for AWS, Azure, and Critical Providers

TL;DR

• Measure cloud concentration by business service and dependency, not only by vendor spend.
• Include SaaS, fintech, identity, DNS, observability, and other fourth parties that may ultimately run on the same hyperscaler.
• FFIEC guidance expects institution-specific continuity testing even when a critical service provider supplies test evidence.
• DORA makes concentration, substitutability, contract rights, and exit planning explicit for EU financial entities. It is a useful benchmark elsewhere, but it is not automatically U.S. law.
• Multi-cloud is one possible treatment—not a substitute for architecture analysis, recovery testing, and accepted residual risk.

A regional cloud failure can affect more than workloads hosted there. Authentication, customer communications, fraud decisions, support tools, payment orchestration, and vendor APIs may share the same provider or control plane. If those dependencies are assessed in separate vendor files, management can miss the fact that one failure mode crosses several important business services.

That is why cloud concentration belongs in business continuity and operational-resilience governance, not only in annual third-party reviews.

Start With the Service, Not the Contract

A vendor inventory usually answers who the institution contracts with. A concentration assessment must also answer what each important business service depends on.

For every important service—such as account access, card authorization, ACH origination, fraud monitoring, or customer support—map:

1. customer-facing and operational outcomes;
2. applications and data stores;
3. cloud provider, region, and availability-zone design;
4. identity, DNS, certificates, keys, networks, and observability;
5. direct SaaS and fintech providers;
6. those vendors’ material cloud and subcontractor dependencies; and
7. manual or alternate processing routes.

The same cloud provider appearing behind several vendors is a correlated dependency even if procurement reports each relationship separately.

Four Concentrations to Measure

1. Provider concentration

How many important services depend on AWS, Microsoft Azure, Google Cloud, or another provider? Spend is a weak proxy: a low-cost identity or messaging service may be operationally more critical than a large analytics environment.

2. Regional and control-plane concentration

Workloads spread across availability zones can still share a region, account hierarchy, deployment pipeline, identity plane, or configuration error. Document what actually fails independently.

3. Fourth-party concentration

A bank may contract with different core, payment, fraud, and communications vendors that all run on the same hyperscaler. Ask critical vendors to identify material hosting and operational subcontractors, subject to reasonable confidentiality and security limits.

4. Human and tooling concentration

A nominally portable application may depend on one team, one infrastructure-as-code toolchain, or proprietary services that cannot be reproduced quickly. Skills and operating procedures are part of substitutability.

What FFIEC Guidance Means Operationally

The FFIEC Business Continuity Management booklet treats resilience as an enterprise process tied to the business impact analysis, risk assessment, continuity strategies, testing, and board reporting. Its third-party testing section explains that a financial institution should evaluate service-provider tests and also test its own ability to continue or recover.

That leads to three practical requirements:

• Provider evidence: obtain relevant resilience, disaster-recovery, and incident-communication evidence for critical services.
• Institution evidence: test how your staff, systems, customers, and alternate procedures behave when that provider is unavailable.
• Gap treatment: document limitations, compensating controls, remediation owners, and accepted residual risk.

A SOC report or provider-wide exercise may support assurance. It does not demonstrate that your institution can meet its recovery objectives when integrations fail or vendor communications are incomplete.

The interagency third-party risk guidance reinforces lifecycle governance: planning, due diligence, contracting, ongoing monitoring, and termination. Cloud concentration evidence should be visible at each stage.

DORA Raises the Specificity Bar

For in-scope EU financial entities, DORA has applied since January 17, 2025. Its ICT third-party framework requires entities to consider whether a planned arrangement would create or increase concentration risk, evaluate substitutability, include required contractual provisions, and maintain exit strategies for ICT services supporting critical or important functions.

The European Supervisory Authorities later designated critical ICT third-party providers, including major cloud and technology firms, for direct oversight. That designation does not make the provider responsible for each financial entity’s resilience program. Firm-level accountability, testing, register, contract, and exit duties continue.

For a U.S.-only institution, DORA is not automatically an applicable requirement. Its concentration and exit concepts are nevertheless a useful comparison when existing guidance asks management to understand critical dependencies and recovery options.

A Defensible Treatment Decision

Once concentration is quantified, management needs a recorded treatment choice. Common options include:

• active-active or active-passive resilience across independent regions;
• provider-diverse recovery for selected critical functions;
• portable backups and infrastructure definitions;
• manual or reduced-service modes;
• tighter recovery commitments and incident communications in contracts;
• increased monitoring and exercises; or
• explicit risk acceptance where migration is not proportionate.

Avoid the statement “we are multi-cloud, therefore concentration is solved.” Two environments may share identity, DNS, code deployment, data replication, key management, or the team that operates them. Conversely, a well-tested single-provider design with independent backups and a realistic reduced-service strategy may be more resilient than two poorly operated stacks.

The decision record should identify the scenario, impact tolerance, options evaluated, evidence, cost and complexity, selected treatment, residual risk, approver, and review trigger.

Build an Exit Plan That Can Be Tested

An exit clause is not an exit plan. For each material cloud dependency, document:

• the service and data in scope;
• voluntary and emergency exit triggers;
• decision authority and escalation path;
• data format, export route, encryption, and deletion evidence;
• target environment or alternate process;
• application and network changes;
• vendor transition assistance and contract limits;
• people, access, tooling, and licenses required;
• sequenced recovery steps and acceptance criteria;
• estimated time, cost, and capacity; and
• the most recent test or walkthrough result.

Some services will not be portable within the business impact analysis’s recovery window. That is not a reason to hide the gap. It is a reason to define a reduced-service strategy, pursue architectural remediation, or obtain formal risk acceptance.

A Cloud-Concentration Tabletop

Run a scenario that removes more than compute. For example: the primary region is unavailable, the provider status page is incomplete, the identity service is degraded, two critical fintech vendors on the same provider fail, and recovery estimates change during the exercise.

Test whether teams can:

1. identify every affected important service;
2. classify regulatory, contractual, and customer-notification triggers;
3. invoke alternates without unavailable identity or tooling;
4. reconcile transactions and data after recovery;
5. communicate with critical vendors through out-of-band channels; and
6. produce a timestamped decision log.

Use measured results—actual failover time, unresolved dependency, data-recovery point, manual capacity, and decision latency—to update the risk assessment. A tabletop that ends with no action owners is a discussion, not assurance.

So What?

Cloud concentration cannot be eliminated by a questionnaire or a second cloud account. It can be made visible, governed, tested, and reduced to an approved level.

Map business-service dependencies. Aggregate direct and fourth-party exposure. Compare recovery capability with impact tolerances. Test failure of shared services and control planes. Document why the selected architecture and exit strategy are proportionate.

The Third-Party Risk Management Kit provides vendor-tiering, due-diligence, concentration-assessment, and monitoring structures. Adapt any template to your architecture, regulator, contracts, and operating model.

Primary sources: FFIEC Business Continuity Management booklet | FFIEC third-party service-provider testing | OCC Bulletin 2023-17 | DORA—Regulation (EU) 2022/2554 | ESA critical ICT provider designations