What is multicloud? Benefits, trade-offs, and decisions for resilience, data, and operations

October 26, 2026 · 12 min read

Should you use more than one of AWS, Google Cloud, and Azure? Follow an order service to distinguish multicloud from multiple regions and hybrid cloud, compare workload placement with disaster recovery, and evaluate data ownership, RTO, RPO, transfer costs, identity, and exit plans.

What is multicloud? How it differs from multiple regions and hybrid cloud

Multicloud means using services from at least two cloud providers, such as AWS, Google Cloud, and Azure. It includes separate departments choosing different providers and a single service deployed across two providers. Neither arrangement implies that every application can fail over between them.

Term	What is separated	What it establishes and leaves undecided
Multicloud	Cloud providers	Multiple providers are used; workload redundancy and automatic failover require additional design
Multi-region	Geographic placement	Multiple regions are used; one provider can supply them
Hybrid cloud	On-premises or private environments and public cloud	Existing environments and public cloud are combined; multiple providers can also participate
Multi-AZ or multi-zone	Zones within a region	Addresses zone failures; an entire regional outage is a different failure scope

An order service deployed in two AWS regions is multi-region. Taking orders on AWS and running analytics on Google Cloud is multicloud. In the latter case, analytics remaining available during an AWS outage does not establish that order processing can resume.

Benefits and trade-offs: give each additional cloud a requirement to satisfy

Potential benefits include specialized services, placement in required locations, organizational integration, and reduced concentration on one provider. IAM, networking, monitoring, contracts, and on-call skills also expand. AWS guidance calls for evaluating whether the benefits justify additional investment and operational capabilities. Having more providers is not itself an acceptance criterion.

Goal	Intended benefit	What to establish before adoption
Use a specialized service	Obtain a required capability such as analytics	Data integration does not undermine the primary workload's response time or continuity
Place processing in a required location	Process within a specified geography	Backups, logs, and external integrations also fit the placement requirements
Address a broad provider outage	Resume critical business operations on another provider	It provides required isolation beyond another region and meets recovery objectives
Preserve switching capability	Exit when circumstances change	Data reimport and business cutover can be rehearsed

Compare with a single-provider option covering the same workload, failure scope, and operating responsibilities. Signing up for two clouds does not prove portability. Conversely, a service normally using one cloud can still benefit from rehearsing its exit procedure.

An order service: separate analytics placement from order recovery

The first request is to use B's analytics capabilities. Analytics can lag by 30 minutes, and orders should continue during an analytics outage. Evaluate keeping the order database and processing together on A and sending committed data to B through a retryable asynchronous path. Deduplicate at the destination, define deletion and schema-change handling, and size A's retained changes for transfer outages.

Proposed analytics integration. Arrows represent data flow; order success does not wait for B

A: order API commits to authoritative DB → A: retain durable change records → Asynchronous transfer, retries, deduplication → B: update analytical copy

Now add a separate requirement: after a broad outage of A, resume orders within 30 minutes and lose no more than a 60-second window of updates. These are the recovery time objective (RTO) and recovery point objective (RPO), respectively. The analytical copy might omit order transitions or required history. Evaluate recovery of order processing separately from analytics integration.

Choose a pattern: workload partitioning, active-passive, or active-active

Pattern	Typical use	Data and operational work
Partition by workload	Orders on A, analytics on B	Define authoritative data and integration contracts; analytics is not an order standby
Active-passive	Take orders on A normally; switch to B after failure	Maintain B's data, capacity, and configuration; exercise write cutover and return
Active-active	Serve business operations on both A and B normally	Define conflicting-write handling, ownership partitions, and capacity to absorb the full load

Active-active can mean assigning each tenant a single write location or allowing both sides to modify the same order. These have different difficulty levels. Concurrent inventory or payment updates need conflict detection and resolution or a suitable agreement protocol. Starting two APIs behind a load balancer does not solve that problem.

Google Cloud's architecture patterns cover both placing different workloads across environments and redundantly deploying the same workload. For order recovery, first compare another region of one provider with a standby on B. Establish which option isolates the failure scenarios you need to address.

Data: establish one authority and handle replication lag and competing writers

To make the B standby option concrete, assume self-managed PostgreSQL 17 on VMs on both sides, with asynchronous streaming replication between compatible builds and configurations. This is not an example of directly attaching arbitrary managed databases as physical replicas. Verify the combination, including extensions, operating systems, collations, and recovery tools.

A is the only writer, and B remains read-only until recovery. With asynchronous PostgreSQL replication, an update acknowledged on A may not yet have reached B. Losing A can therefore lose those untransferred updates. A normal lag of 20 seconds does not prove an RPO of 60 seconds: if replication disconnects while A keeps accepting writes, the gap grows.

Relate A's committed order records to the position durably stored and applied on B. Check recovered order IDs, states, and history to establish the loss window, rather than relying only on the last replication timestamp.
Agree what happens when the RPO is at risk: keep accepting updates, stop accepting orders, or adopt a different synchronous design. Monitoring itself also has observation delay.
Read a user's immediate order confirmation from the current authority or a copy caught up through that update. Do not use the analytical copy as the authority for order confirmation.
Keep historical backups because replication can also copy accidental deletion. Test restoration and decryption on B without depending solely on A's key service.

During cutover, distinguish A being down from only the connection between A and B being down. Promoting B simply because it cannot reach A can create split brain, with both accepting updates. Establish fencing: confirm that the former writer has stopped or been isolated. A DNS change does not stop existing connections or internal jobs and cannot enforce exclusive writing.

RTO includes more than database promotion

Assume the following stages run sequentially and finish within their assigned times. Recovery takes 2 + 3 + 4 + 6 + 4 + 3 = 22 minutes. That leaves eight minutes against a 30-minute RTO, but this is planning headroom. Measure the effects of retries, unavailable responders, reconnection, and insufficient capacity.

Original assumptions: sequential recovery stages in minutes. Total 22 minutes against a 30-minute target

Detect failure: 2 min
Decide to recover: 3 min
Fence former writer: 4 min
Check data and promote DB: 6 min
Switch application and connections: 4 min
Validate business operations: 3 min

Recovery ends when orders can be created and confirmed under the agreed load, rather than when B's VMs have started. Include DNS caches, existing connections, credential renewal, and database connection pools. If the standby is small, measure both the quota available to reach the peak of 200 requests/s and the time needed to expand.

Do not immediately route traffic back when A returns. Keep B authoritative, resynchronize A, reconcile divergent updates and external payment outcomes, and then perform a planned write cutover. Returning to A is another migration, with reverse transfers, permissions, load, and execution time.

Networking and cost: reduce boundary crossings and transferred bytes

Suppose a request makes three sequential cross-cloud round trips, each adding 30 ms of network waiting. Network waiting alone then consumes 90 ms. This is illustrative addition, not a prediction of p99 latency. Splitting processing also puts remote provider and network failures on the order success path. Asynchronous analytics transfer removes that wait from order success.

Alongside bandwidth and latency, check overlapping IP ranges, DNS, BGP routes, firewalls, and independent paths. Dedicated connectivity alone does not establish encryption. Google Cloud's connectivity guidance describes configurations such as HA VPN over Cloud Interconnect for encryption. Verify the required protection for each segment.

Total cost of ownership includes standby databases, monitoring and audit, support, training, on-call coverage, and recovery exercises alongside additional compute. Transfers can spike during a full copy or return from a disaster even when normal traffic is modest. Set volume and cost limits for both routine operation and recovery.

Identity and operations: common standards with independent recovery paths

The two providers do not have identical permission models. Share the standard defining who may perform which operations in each environment. Implement roles and policies separately, and distinguish production from testing and deployment from data access. Record the actor, target, outcome, and relevant order or operation identifier so incidents can be investigated in each environment.

For example, a process on A accessing Google Cloud analytics can use Workload Identity Federation to exchange a supported external identity for short-lived credentials. This reduces distribution of long-lived service account keys, but permissions still need explicit limits. For OIDC, check issuer, audience, and organization or execution attributes, and verify that unauthorized identities are rejected.

If resuming orders on B requires A's identity issuer, CI, container registry, or KMS to respond, A's outage can prevent recovery. Include shared identity and DNS failures in your failure model too. Prepare access to artifacts, configuration, and keys on B, plus an auditable emergency operating path. Test starting with expired credentials.

Assign primary and backup owners for each provider and alert from the order SLO. Keep incidents and response progress visible when one management console or monitoring export is unavailable.
Track application versions, configuration, and schema compatibility; apply changes to the standby as well. Reduce dependencies on fetching new configuration for the first time during recovery.
Bound communication and replication attempts with deadlines and retry limits. For order-to-analytics integration, define degradation or stopping conditions before retained changes reach capacity.

Lock-in: Kubernetes and Terraform do not complete the migration

Containers and shared infrastructure tools increase the portion you can carry across environments. They do not make data and service semantics identical. GOV.UK guidance balances the value of cloud dependence with the time and expense of switching. Define the exit capability you need before reducing every component to a common feature set.

Area	What helps portability	What to verify in an exit rehearsal
Application	Containers and explicit external API boundaries	CPU and runtime, volumes, load balancers, and secret handling
Data	Contracts for schemas, history, and export	SQL and extension compatibility, transformation, reimport, deletion, and permission semantics
Infrastructure	Shared change and review practices using tools such as Terraform	Provider-specific resources, state management, quotas, and apply permissions
Operations	SLOs, procedures, and audit standards	Identity, notifications, investigation, and on-call capability at the destination

Being able to exit over several months differs from resuming within 30 minutes during a disaster. Another option is to retain the benefits of a managed database while regularly testing export, conversion, and restoration. Compare the resulting recovery capabilities and maintenance burden with continuously managing identical infrastructure on two providers.

Validate before adoption: which cloud fails, and what constitutes success?

Condition to exercise	Expected result	Reason to reconsider adoption
Stop B's analytics and transfer	Orders continue on A; retained changes are applied without duplicates after resumption	Orders wait for B or untransferred changes are lost
Disconnect A from B while A stays running	B does not start writing on its own; replication lag is detected	Both sides can update the same order
Remove access to A's management APIs and data path	Establish exclusive writing independently and resume, or stop safely	B is promoted without confirming exclusive ownership
Expire credentials and block artifact retrieval from A	Renew identity, deploy, decrypt, and investigate on B	A's identity, registry, or keys are prerequisites for recovery
Recover onto B under peak load	Reconcile orders and history; verify a loss window within 60 seconds and business recovery within 30 minutes	Only promotion is timed; data loss or capacity remains untested
Return to A after accepting updates on B	Keep one authority, reconcile orders and payments, resynchronize, and cut over	A's stale state overwrites updates from B

Passing an exercise does not guarantee recovery for every failure. Record failure scope, load, data volume, versions, measurement boundaries, actual recovery time, and data-loss window; repeat after architectural changes. Stopping because fencing is unavailable can validate safety, but does not demonstrate that the order recovery RTO was met.