Does multisite mean multiple cloud providers?

No. Several sites can belong to one provider or organization. Multicloud describes a different dimension of the deployment.

Is active/active always preferable?

No. It can improve some availability and distribution goals but adds data coordination and operational requirements. Suitability depends on the workload and objectives.

Does geographic separation guarantee independence?

No. Sites can still share network routes, management systems or other dependencies. The actual failure boundaries must be examined.

AI Glossary / Data engineering and architecture / Intermediate

Multisite cloud

Definition

A multisite cloud distributes cloud infrastructure or workloads across more than one physical location. The locations may serve different users, share work or provide recovery capacity for one another. The term describes geographic or physical distribution; it does not by itself specify the cloud provider, replication method, failover behavior or level of independence between sites.

What it means

An organization might use two data centers to reduce dependence on one location, or several locations to place services closer to users. The sites can belong to one provider or organization. This differs from multicloud, which emphasizes using more than one cloud provider or cloud environment.

Names such as region and availability zone do not have identical meanings everywhere. Some platforms permit logical regions within one physical site. To understand resilience, inspect actual failure boundaries, power, networking and shared services rather than relying only on labels in a console.

How it works

The design assigns compute, storage, networking and management responsibilities across sites. It establishes how users reach the correct service and how application data becomes available where it is needed. Identity, configuration and monitoring may be shared, replicated or independently operated.

In an active/passive arrangement, one site serves the workload while another is prepared for recovery. In an active/active arrangement, multiple sites serve traffic. These patterns create different capacity, routing and consistency requirements.

Data replication may be synchronous, waiting for remote confirmation, or asynchronous, allowing a delay. Distance and network behavior influence the tradeoff. A complete design also handles loss of connectivity between functioning sites, not just total site failure. Decisions about which site may accept writes must prevent conflicting activity that the application cannot reconcile.

Three practical examples

1. Regional service delivery: An application serves users from several locations to reduce distance-related delay. Shared account or transaction data still needs a defined consistency and routing strategy.

2. Recovery environment: A business keeps a second location ready to restore a critical service. It tests application startup, dependencies and data recovery rather than assuming that replicated storage alone makes the service usable.

3. Distributed AI service: Inference capacity runs at two sites, with controlled model and configuration deployment. The team checks that routing changes do not unexpectedly send users to an incompatible model version or unavailable dependency.

Think of it this way

Think of a business operating two service centers. Both can help customers only if they have the necessary staff, records and authority. A second building does not help when all essential records or the only approval officer remain at the first.

The analogy has limits. Distributed software must coordinate rapidly changing state and distinguish an unreachable site from a failed one. Those problems require explicit technical rules, not simply a decision to open another location.

Worked example

Suppose a fictional primary site accepts an order at 10:00:00. Its asynchronous copy reaches the recovery site at 10:00:20. If the primary site becomes unavailable at 10:00:10, that order may not yet be available at the recovery site.

This illustrates a possible recovery-point gap. It is separate from recovery time: even with recent data, the application might need several minutes to redirect traffic, start services and validate operation.

Now suppose each of two active sites can handle 600 requests per second and normally serves 450. If one fails, the surviving site's normal capacity cannot handle the combined 900 requests per second. Multisite operation therefore needs a capacity plan as well as a replication plan. These numbers are invented and do not imply a particular provider's guarantees.

Illustrative case study

Fictional case study: SiteMeadow deploys its customer portal at two locations and describes it as protected against losing either site. During a recovery exercise, the application servers at the second site start successfully, but users cannot sign in because authentication depends on a service available only at the first.

The team maps the dependency and revises the recovery design. It also checks configuration, certificates, data freshness and the process for returning to normal operation after failover.

SiteMeadow's lesson is that resilience belongs to the complete user workflow. The existence of a second application deployment is useful evidence of preparation, but not proof that the service can survive every relevant failure.

Common misconceptions and mistakes

A common mistake is equating multisite with automatic disaster recovery. Recovery requires working data, dependencies, capacity and tested procedures. Another is assuming two logical regions must be physically independent; platform definitions and deployment details matter.

Do not treat replication as a complete backup strategy. An unwanted change can propagate to another site, so recoverable history may still be necessary. Active/active also does not automatically eliminate downtime or conflicting writes. Finally, shared identity, management or network services can create common failure points even when the application servers are geographically separated.

Business use

Multisite cloud designs can support continuity, geographic reach and workload placement. They also introduce operational complexity, transfer costs and coordination requirements. The business should define acceptable interruption and data-loss exposure before choosing a pattern.

Evaluate the complete recovery exercise, including degraded capacity, unavailable dependencies and return to normal service. For AI workloads, include model artifacts, retrieval indexes, access policies and application configuration in the dependency map. A second site with an older index or incompatible model may remain technically reachable while delivering an unsuitable user experience.

Check your understanding

Two sites host identical application servers, but both require a database available only at one site. Is the application fully independent of that site's failure?

Answer: No. The shared database remains a critical dependency. The design needs an appropriate data and recovery strategy, followed by a realistic test.

Related terms

Availability zone
Replication (statistics)
Cloud region
multicloud
disaster recovery
replication
active/active
recovery time objective
recovery point objective

Learn next

Draw every dependency needed to complete one user transaction at each site. Then remove one site and one intersite connection separately. Identify which functions remain possible and which assumptions require testing.

Sources

Canonical OpenStack, multi-region deployment documentation and region semantics: https://canonical.com/openstack/docs/2025.1/how-to/misc/multiregion-deployments/

AWS, disaster recovery options, including active/passive and multisite patterns: https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html

These primary sources illustrate differing platform designs and recovery considerations. SiteMeadow, timings and capacity figures are fictional examples, not service commitments.

Previous: Multiprocessor system architecture Next: Multispectral pattern recognition