Multi-Cloud Strategy in 2026: When It Pays, What It Costs, and How Switching Rules Are Changing
When using more than one cloud makes sense, what egress and staffing cost, lessons from the 2025 AWS outage, and the 2026 EU and UK rules on switching.

Most organizations did not choose to run on several clouds. Flexera's 2026 State of the Cloud survey found that 73% of organizations operate hybrid environments and that multi-cloud adoption keeps rising, driven more often by mergers, SaaS sprawl, and decentralized teams than by deliberate strategy. AWS (83%) and Azure (79%) were both used for active enterprise workloads by most respondents, with Google Cloud a distant third.
A multi-cloud strategy starts from that reality and decides what to keep, what to consolidate, and how to govern the rest. This guide covers the reasons that justify more than one cloud, what the October 2025 AWS outage showed about resilience, the costs (with a worked egress example at September 2026 prices), how EU and UK rules on switching are changing, what portability really takes, and the minimum controls for any multi-cloud estate.
Reasons that hold up, and reasons that don't

| Reason | Holds up when | Weak when |
|---|---|---|
| A specific service is clearly better for a workload | The gain is large and the workload's data can live on that cloud | Chosen for a feature comparison that erodes within a year |
| Acquired companies run on another cloud | Migration cost exceeds the cost of governing two estates | Kept by default with no review |
| Customers or regulators require it | Contracts or rules demand a specific provider, location, or an exit plan | Assumed rather than confirmed |
| Bargaining power at renewal | A credible alternative exists for a meaningful share of spend | The alternative would take years to use |
| Resilience | Critical services are built and tested to fail over across providers | "Multi-cloud" means different apps on different clouds, none of which fail over |
| Avoiding lock-in | The workload is long-lived and the switching risk is real | Every workload is limited to the lowest common denominator of services |
Using one primary provider with a small, well-governed second cloud for specific workloads is often a defensible outcome. Spreading every workload evenly across providers rarely is, because it multiplies skills, tooling, and security effort while giving up volume discounts.
What the October 2025 AWS outage showed
On October 19 and 20, 2025, AWS's Northern Virginia (us-east-1) region suffered a disruption that ran for about 14.5 hours from first impact to full recovery. According to AWS's post-event summary, a latent defect in the automated DNS management for DynamoDB left the service's regional endpoint with an empty DNS record. DynamoDB errors lasted about three hours, and knock-on problems with EC2 instance launches and Network Load Balancer connections continued into the afternoon, affecting services that depend on them.
For resilience planning, the lessons are specific:
- Know your hidden dependencies on a single region, including provider services and SaaS vendors that themselves depend on it.
- Multi-region architecture within one provider handles most regional failures at lower cost than multi-cloud. It does not protect against a provider-wide control-plane or identity failure.
- Cross-cloud failover only works if data is already replicated, traffic management and DNS sit outside the failing provider, identity does not depend on it, and the failover has been exercised.
- Decide which services truly need that level of protection. For most, a documented recovery plan and a realistic recovery time are enough.
Our guide to cloud security posture management covers resilience controls alongside security.
What multi-cloud costs
Egress
Moving data out of a cloud is charged per gigabyte, and "chatty" designs that send data across providers on every request add up quickly. AWS's price list published September 16, 2026 charges, for internet data transfer out of U.S. East after a 100 GB monthly free allowance, $0.09 per GB for the first 10 TB, $0.085 for the next 40 TB, $0.07 for the next 100 TB, and $0.05 above that.
An illustration: a machine learning team trains models on another provider's GPUs using data from a data lake on AWS, pulling 60 TB a month.
| Monthly volume | Monthly AWS egress cost | Annual cost |
|---|---|---|
| 5 TB | $452 | $5,422 |
| 20 TB | $1,784 | $21,402 |
| 60 TB | $5,113 | $61,356 |
| 200 TB | $14,126 | $169,514 |
The same pattern appears in request-driven applications: an API on one cloud that returns 3 MB per request from a database on another, at 20 million requests a month, moves about 57 TB and costs roughly $4,900 a month at these rates. Ways to cut it: keep chatty services and their data on the same cloud and region, move compute to the data rather than the reverse, cache and compress, use dedicated interconnects (which lower per-GB rates but add port and circuit fees), and negotiate transfer pricing into enterprise agreements.
People, tools, and discounts
Each additional cloud needs engineers who know its identity model, networking, and managed services; separate landing zones and security baselines; and cost reporting that can compare bills in different formats. The FinOps Foundation's FOCUS specification standardizes billing data across providers and makes that comparison much easier. Splitting spend also reduces committed-use and volume discounts on each provider. Our guides to cloud cost governance and cloud cost optimization cover the controls.
How switching rules are changing
- EU Data Act. The Act limits the fees cloud providers can charge EU customers for switching, including data egress, to the provider's own costs until January 12, 2027. After that, according to the European Commission, the Act removes switching charges entirely, including egress, for customers moving to another provider or back on premises. Egress for running services in parallel across providers can still be charged, but only at cost. Providers can still charge early termination fees.
- Provider responses. AWS, Microsoft, and Google began waiving egress fees for customers leaving their platforms in 2024. In September 2025, Google launched Data Transfer Essentials, offering no-cost transfer between a customer's workloads on different clouds in the EU and UK, and Microsoft offered at-cost transfers in the EU, both with conditions.
- United Kingdom. The Competition and Markets Authority's July 2025 final decision found that competition in cloud infrastructure was not working well, citing egress fees and Microsoft's licensing terms for running its software on rival clouds. In March 2026, instead of opening strategic market status investigations into cloud, the CMA accepted commitments from AWS and Microsoft to remove or reduce egress fees and improve interoperability, and in May 2026 it opened an investigation into Microsoft's business software ecosystem, including licensing.
- Financial services. The EU's Digital Operational Resilience Act, in force since January 2025, requires financial firms to manage concentration risk and keep exit strategies for technology providers that support critical functions. In November 2025 the European supervisors designated 19 critical ICT third-party providers, including AWS, Google Cloud, and Microsoft, for direct oversight.
These changes lower the cost of leaving a provider and of moving data between providers in Europe. They do not make applications portable; that still depends on architecture.
What portability really takes
- Compute. Containers and Kubernetes make most application code portable, and infrastructure-as-code tools such as Terraform (source-available since 2023, with the open-source OpenTofu fork as an alternative) or Pulumi can provision several clouds from one codebase.
- Data. Databases, data warehouses, and object storage are where lock-in actually sits: large volumes are slow and expensive to move, and managed databases differ in features and behavior. Favor open formats (Parquet, open table formats) and engines available on several clouds for data you may need to move.
- Managed services. Queues, serverless functions, identity, monitoring, and AI services all differ. Wrapping them in abstraction layers adds work and often gives up the features that made them attractive. Decide per workload whether that trade is worth it.
- Identity. Use one identity provider with single sign-on and workload identity federation across clouds, so people and services do not carry separate long-lived credentials for each provider.
For most organizations, a documented and tested exit plan for each critical workload (what would move, how long it would take, and what it would cost) is a better use of effort than making everything portable in advance. Our guide to cloud migration costs covers estimating a move.
Minimum controls for any multi-cloud estate

- An inventory of every cloud account, subscription, and project, with an owner and a business purpose for each.
- A landing zone and security baseline on each provider, with central logging.
- Central identity with single sign-on, least-privilege roles, and no shared long-lived keys.
- Posture management that scans all clouds against the same policies.
- Tagging and cost allocation rules applied everywhere, with bills normalized to one format.
- Data classification and residency rules that say which data may live where. Our guides to cloud data governance and data privacy compliance cover these.
- For each critical service, a documented recovery and exit plan, tested on a schedule.
This guide is for informational purposes only. Cloud prices, provider programs, and regulations change; prices and rules are as of September 2026. Confirm current terms with your providers and legal advisers before making architecture or contract decisions.



