Network Insight · High Availability Architecture
Active-Active Data Center Design: Building for Continuous Availability
What happens when one data center can no longer serve its workloads? An active-active architecture aims to keep multiple sites operational at the same time, distributing traffic and capacity while preparing services to withstand component, network and site failures.
Modern applications rarely depend on a single network, server or storage system. They operate across interconnected infrastructure, distributed services and, increasingly, multiple locations. Active-active design brings these components together into an architecture where more than one site can actively serve workloads. But operating two sites simultaneously is not simply a matter of duplicating hardware. Routing, application behavior, data consistency, traffic distribution and failure detection must work together.
Data Center A
Primary active site in this illustration
Data Center B
Second active site in this illustration
01 · Connectivity
Route around failures
Use diverse network paths and appropriate routing policies to preserve reachability when links or devices fail.
02 · Consistency
Keep application state safe
Design replication, quorum and application behavior around the consistency requirements of the service.
03 · Recovery
Prove service continuity
Test site isolation, traffic shifts and recovery behavior instead of assuming that redundancy guarantees availability.
The essential distinction: both sites can be active without every application being able to survive every failure. True service resilience depends on the complete design—including data consistency, health detection, routing, capacity and application recovery behavior.
Understanding Active-Active Data Center Design
Explore how two or more data center sites can serve workloads concurrently, how this differs from active-passive resilience, and why application behaviour, dependency design and failure handling matter as much as network redundancy.
Understanding Active-Active Data Center Design
Active-active design allows two or more data center sites to serve production workloads concurrently. The objective is to use distributed capacity while maintaining service continuity when a component, network path or site becomes unavailable.
Traditional active-passive designs generally keep one site serving traffic while another is prepared to take over during a failure. In an active-active design, both sites perform useful production work during normal operation. Traffic may be distributed through global load balancing, application-aware routing, anycast services or other mechanisms appropriate to the application and network architecture.
This can improve resource utilisation and provide additional capacity options. It also introduces design questions that cannot be solved by routing alone: where application state lives, how data is replicated, how clients reach healthy services, and what happens when the sites lose contact with one another.
Data Center A
Serving production traffic
Local compute and services
Data Center B
Serving production traffic
Local compute and services
Three principles that shape the design
Concurrent workload
Both sites contribute to normal service delivery. Capacity planning must account for traffic distribution and whether surviving infrastructure can absorb additional demand after a failure.
Consistent service behaviour
Applications must handle sessions, shared state, data replication and concurrent updates according to their consistency and availability requirements.
Designed failure response
Health checks, routing policies, load balancers and application recovery logic must work together to direct clients towards services that can actually respond.
Important distinction: two active sites do not automatically provide application resilience. If both sites depend on the same database, identity service, WAN path or control-plane component, that shared dependency may still become a single point of failure.
Questions to answer before choosing active-active
- Can the application safely run across multiple sites at the same time?
- How much data loss, if any, is acceptable following a site failure?
- What recovery time is required, and how will client traffic move to healthy services?
- Can one surviving site handle the required workload during a major failure?
- How will split-brain conditions, network partitions and inconsistent state be detected and handled?
Active-active is an end-to-end service architecture, not simply a pair of interconnected data centers. Reliable outcomes depend on coordinated network design, application behaviour, data consistency, capacity planning and tested recovery procedures.
What Happens When a Data Center Fails?
Switch the deployment model or simulate a site failure. Observe the illustrative traffic paths, site states and engineering implications. This is a conceptual model, not a live network simulator.
Both sites serve production traffic
Workloads at both sites are available to serve requests. Traffic distribution depends on application placement, routing, load balancing and health checks. Shared dependencies and data consistency still need deliberate design.
Engineering checks
- Confirm application and data consistency.
- Verify each site's independent capacity.
- Test routing and service health during failure.
Multi-Site Network Architecture and BGP
Follow traffic between data centers and external networks. Understand how BGP exchanges reachability, how routing policy and multipath influence path selection, and how engineers avoid asymmetric traffic, route leaks and unexpected failover behaviour.
Multi-Site Network Architecture and BGP
An active-active design needs more than two functioning data centers. It needs predictable routing, resilient inter-site connectivity and a clear policy for how users and applications reach services when paths or entire sites fail.
The network provides the connectivity between data centers, users, applications and external services. In a multi-site architecture, Data Center Interconnect (DCI) links connect the sites, while routing and traffic-management systems determine which paths are available and where traffic should be sent.
Border Gateway Protocol (BGP) is commonly used to exchange reachability information between sites, WAN networks and external networks. Its policy controls can influence path selection and traffic distribution. However, BGP does not by itself verify that an application is healthy or that its data is consistent.
Data Center A
Applications and local services
Data Center B
Applications and local services
The three network design layers
Data Center Interconnect
DCI may use routed IP connectivity, an optical transport service or an overlay architecture. Choose bandwidth, latency and path diversity according to application traffic and replication requirements—not simply the number of physical links.
Routing and reachability
BGP can advertise site prefixes and apply routing policy. Multipath forwarding may use multiple eligible routes when supported and correctly configured. Route selection and forwarding behaviour must be validated for the actual platform and topology.
Service traffic steering
DNS-based global load balancing, anycast, application load balancers or other steering mechanisms can direct clients towards available services. Health checks must reflect genuine service readiness, not just network reachability.
BGP: control the path, then validate the outcome
A common design advertises service or site prefixes from more than one location. The routing policy determines which advertisements are accepted and how paths are preferred. Depending on the design, engineers may use attributes such as LOCAL_PREF within an autonomous system, AS_PATH for inter-AS policy, or multipath features to support selected equal-cost paths.
The important distinction is between route availability and service availability. A router may have a valid route to a site whose application is unhealthy. Conversely, an application may be healthy while a routing or traffic-steering policy prevents clients from reaching it. These systems need coordinated health signals and carefully tested failure behaviour.
Design warning — avoid accidental traffic tromboning. If a client reaches a service in one site but the application retrieves data or calls a dependency in the other site, traffic may cross the DCI unnecessarily. This can increase latency, consume inter-site bandwidth and complicate failure handling. Keep traffic local where practical, while preserving the required consistency and availability guarantees.
What should happen during a failure?
- DCI link failure: traffic should use a surviving path where one exists, with convergence and capacity validated under load.
- Border router failure: alternate routing paths should remain available without creating a forwarding loop or black hole.
- Site failure: route withdrawal and service-health mechanisms should steer new traffic away from unavailable services.
- Application failure: health checks should stop advertising or selecting an endpoint that cannot deliver the required service.
- Network partition: routing and application policies must avoid unsafe assumptions about the remote site's state or data ownership.
Architecture checks before deployment
- Identify shared physical and logical failure domains across DCI paths.
- Document prefix advertisements, routing policy, route filtering and intended path preferences.
- Check convergence behaviour and whether surviving links can carry the expected load.
- Validate inbound and outbound traffic steering independently; they may follow different paths.
- Test application health checks alongside routing changes and site-isolation scenarios.
BGP and DCI establish and control network reachability; they do not guarantee that an application is usable. A resilient active-active design coordinates routing, traffic steering, application health, capacity and data consistency—and verifies the result through controlled failure tests.
Trace the Route Between Data Centers
Explore how inter-site connectivity, BGP reachability and routing policy influence traffic. Simulate a DCI link failure or route withdrawal, then select a router or network to inspect its role.
Reachability is available through the configured paths
The diagram illustrates an available inter-site path and route advertisement. Actual forwarding depends on the installed route, routing policy, next-hop reachability and data-plane health.
Select a network component
Select either border router, an application network or the external AS in the diagram to explore its role in route propagation and traffic forwarding.
| Item | Illustrative state | What to verify |
|---|---|---|
| Inter-site path | Available | Independent physical paths, capacity and forwarding health. |
| Route advertisement | Present | Accepted prefixes, next hop, policy and route installation. |
| Service reachability | Check required | End-to-end application health, not only control-plane state. |
Layer 2 Extension, Overlays and Workload Mobility
Compare stretched Layer 2 networks with routed Layer 3 designs, and examine how VXLAN/EVPN overlays can support multi-site connectivity. Consider workload mobility, broadcast scope, failure propagation and the risk of traffic tromboning before extending networks between sites.
Layer 2 Extension, Overlays and Workload Mobility
Workload mobility across data centers can simplify some application migrations and recovery scenarios. The challenge is deciding how much network continuity is actually required—and whether extending a Layer 2 domain is the right way to achieve it.
In a multi-site environment, applications may need to move between sites for maintenance, capacity balancing, disaster recovery or infrastructure changes. Some workloads can move while retaining their IP addresses; others can reconnect through a new endpoint or service address. The application’s requirements should determine the network design, rather than assuming that every workload needs a stretched subnet.
A Layer 2 extension carries an Ethernet broadcast domain across multiple locations. This can preserve subnet membership and support certain migration workflows, but it also extends the domain’s failure and operational characteristics. A Layer 3 design keeps subnets local to each site and uses routing to connect them, often reducing the scope of Layer 2 failure propagation.
Stretched Layer 2
The same VLAN or subnet is available across sites, subject to the chosen extension technology and design constraints.
- Can support address-preserving workload mobility.
- May carry broadcast and unknown-unicast traffic across the DCI.
- Requires careful control of loops, failure domains and inter-site latency.
- Can make partial failures harder to diagnose.
Routed Layer 3
Each site uses its own routed subnets, and connectivity between sites is provided through routing and application-level service discovery or traffic steering.
- Provides clearer Layer 3 failure boundaries.
- Supports route summarisation and explicit traffic policy.
- May require application, DNS or load-balancer changes during migration.
- Often simplifies fault isolation and scaling.
VXLAN and EVPN: separating the overlay from the underlay
VXLAN (Virtual Extensible LAN) encapsulates Layer 2 frames in UDP packets so that virtual networks can be carried across an IP underlay. VXLAN Tunnel Endpoints (VTEPs) perform encapsulation and decapsulation. EVPN (Ethernet VPN), commonly used as a control plane for VXLAN fabrics, distributes MAC and IP reachability information and supports policy-driven tenant connectivity.
This separation allows an IP-routed fabric to carry multiple logical networks without requiring the physical underlay itself to be one large Layer 2 domain. EVPN can support distributed gateway designs and multi-homing, depending on the implementation. It does not, however, remove the need to design inter-site routing, failure handling and application consistency deliberately.
Data Center A
IP underlay · Local VTEP
Data Center B
IP underlay · Local VTEP
The diagram is illustrative. Actual VTEP placement, EVPN route exchange, gateway placement and whether an overlay spans both sites depend on the design.
Where do OTV, FabricPath and LISP fit?
OTV
Overlay Transport Virtualization was designed to extend selected Layer 2 connectivity between data centers while limiting some traditional Layer 2 extension risks. Treat it as a platform- and lifecycle-dependent technology, not a universal modern default.
FabricPath
Cisco FabricPath introduced a Layer 2 fabric approach using a fabric control plane rather than relying on conventional spanning tree for all forwarding decisions. It is mainly relevant when understanding existing or legacy environments.
LISP
Locator/ID Separation Protocol separates endpoint identity from routing location. It can support mobility and mapping use cases in appropriate architectures, but it is not interchangeable with VXLAN or EVPN.
Design principle: do not extend Layer 2 simply because an application currently uses a fixed IP address. First check whether the application can tolerate a different subnet, use a stable service endpoint, or reconnect through DNS or a load balancer. A routed design may meet the requirement with a smaller failure domain.
Workload mobility and traffic tromboning
Preserving a workload’s IP address does not guarantee that its traffic path remains optimal. After a workload moves, clients or dependent services may still reach it through a remote site. This can create traffic tromboning: packets travel across the DCI to reach a service and may cross back again to reach another dependency.
The result can be increased latency, unnecessary bandwidth consumption and a more complicated failure path. Mobility planning should therefore include endpoint discovery, routing updates, load-balancer behaviour, dependency locality and the time needed for existing sessions to recover.
Questions to resolve before extending a network
- Does the workload genuinely require the same subnet at both sites?
- What are the latency, bandwidth and MTU requirements across the DCI?
- How are MAC/IP reachability and gateway behaviour handled after a move or failure?
- Can a Layer 2 loop, broadcast event or control-plane issue affect both sites?
- Will traffic remain local to the active workload and its dependencies?
- What happens to established sessions when the workload or site becomes unavailable?
VXLAN and EVPN can provide scalable overlay connectivity, while routed designs can keep site boundaries clearer. Choose Layer 2 extension only when the application and operational requirements justify it, and test mobility, failure isolation and traffic locality before relying on it for resilience.
Layer 2 Extension, Overlays and Workload Mobility
Compare three ways to connect data-centre sites. Change the design, simulate an inter-site failure, and examine what happens to addressing, mobility and the fault domain.
Both sites use the same example subnet. This can support address continuity, but it also extends Layer 2 dependencies across the sites.
Engineering trade-off
A stretched VLAN can make subnet continuity easier, but the design must deliberately control loop prevention, broadcast scope, gateway behaviour and inter-site failure handling.
- Define the Layer 2 extension boundary
- Test behaviour during link and site failure
- Validate gateway redundancy and convergence
- Confirm application recovery requirements
Application, Storage and State Consistency
Network redundancy cannot guarantee application availability on its own. Examine stateless and stateful services, session continuity, synchronous and asynchronous replication, quorum, split-brain risk, and the trade-offs between recovery time and potential data loss.
Application, Storage and State Consistency
A network can keep routes available while an application remains unable to serve requests. Active-active resilience therefore depends on how application instances, user sessions and persistent data behave across sites—not just on redundant links and routers.
In an active-active environment, application instances in different data centers may process requests concurrently. That arrangement works well only when the application can manage shared state, concurrent operations and failures consistently. A stateless service is often easier to distribute because each request can be handled by any healthy instance, provided its dependencies are also available.
Stateful applications introduce more complexity. They may depend on databases, distributed caches, message queues, session stores or file systems. Each dependency needs an explicit availability and consistency strategy. Replicating the application tier alone does not make the whole service resilient if its database or identity provider remains a single point of failure.
Data Center A
Active application instance
Application service A Local connection pool Data replica / access pathData Center B
Active application instance
Application service B Local connection pool Data replica / access pathSynchronous versus asynchronous replication
Replication determines how updates made at one site become available at another. The key trade-off is between acknowledgement latency, consistency guarantees and the amount of data that may be lost during a failure. These characteristics vary by platform and configuration; the terms alone do not guarantee a particular recovery outcome.
Synchronous replication
A write is acknowledged only after the configured synchronous durability or commit conditions have been met.
- Can reduce the recovery point exposure for acknowledged writes.
- Inter-site latency can affect write response times.
- A link or site failure may affect write availability, depending on quorum and product design.
- Requires careful planning for network partitions and failover.
Asynchronous replication
A write can be acknowledged before the remote replica has received or committed the update.
- Can reduce the impact of remote-site latency on write acknowledgement.
- Replication lag may leave the remote site temporarily behind.
- A sudden failure can result in loss of updates not yet replicated.
- Recovery procedures must account for lag and data reconciliation.
Important: synchronous replication does not automatically mean zero data loss in every failure scenario, and asynchronous replication does not always imply unacceptable loss. The real outcome depends on commit semantics, quorum, durable storage, topology and the failure being considered. Define the required Recovery Point Objective (RPO) and Recovery Time Objective (RTO), then validate them against the actual platform.
Three application-level challenges
Session continuity
If a client moves between sites, its session may depend on local memory, a shared session store, a signed token or another mechanism. Design for reconnects and retries instead of assuming a transport path change preserves every session.
Concurrent updates
Two active instances may attempt to modify the same logical record. Transactions, conflict resolution, idempotency and application-specific consistency rules must prevent duplicated or conflicting operations.
Dependency availability
An application instance may be healthy while its database, authentication service, queue or external API is not. Service health should reflect the dependencies required to complete real user operations.
Quorum, network partitions and split-brain
A network partition can leave two sites running while preventing them from communicating. If both sides independently accept conflicting writes or claim ownership of the same resource, the system may enter a split-brain condition. Restoring connectivity does not necessarily reconcile the resulting state safely.
Distributed systems often use quorum, leases, fencing tokens, leader election or other coordination mechanisms to decide which operations are permitted during a partition. A two-site deployment may need a third failure-independent voting participant or witness, depending on the platform. A witness can help establish a decision, but it does not replace data replication or application-level recovery design.
Network partition is not the same as site failure. If the DCI fails, both sites may still be running and serving local clients. The architecture must decide whether each site can safely continue, whether one side must stop writes, and how service ownership is re-established when communication returns.
Questions to answer before production
- Can application instances safely process requests concurrently in both sites?
- Where is session state stored, and what happens when a client is redirected?
- What RPO and RTO are required for each critical data store?
- How are quorum, ownership and split-brain conditions handled during a partition?
- Can the surviving site sustain the required transaction rate and connection load?
- How will replication lag, failed writes, stale reads and recovery conflicts be detected?
- Have failover and failback been tested with real application transactions, not just ping tests?
Active-active application resilience requires an explicit strategy for state, replication, coordination and recovery. Network redundancy helps services communicate, but only the combined behaviour of the application, data platform and network determines whether service can continue safely during a failure.
Application, Storage and State Consistency
A network can remain connected while an application becomes unsafe or unavailable. Explore replication modes, simulate an inter-site partition, and examine why two active sites need a deliberate write-ownership strategy.
In this conceptual synchronous model, a write waits for the configured remote acknowledgement before it is confirmed. Real guarantees depend on the data platform and commit policy.
Engineering checks
A healthy network path does not prove that a transaction is durable or that both replicas agree. Check the application's consistency contract and the data platform's failure behaviour.
- Confirm what a successful commit guarantees
- Define quorum and write ownership
- Measure replication delay and transaction errors
- Test failover, fencing and safe recovery
Failure Scenarios, Observability and Recovery
Move beyond theoretical redundancy and test how the architecture behaves under real failure conditions. Trace link loss, BGP changes, application dependency failures, replication lag and site isolation using telemetry, incident procedures and measured recovery objectives.
Failure Scenarios, Observability and Recovery
Active-active architecture must be designed around failure, not just normal operation. Reliable recovery depends on detecting what has failed, identifying the affected services, understanding the data state and directing traffic towards capacity that can safely serve it.
Redundant links and duplicated infrastructure reduce some risks, but they do not eliminate failures. A site can remain reachable while its applications are unhealthy; a routing session can remain established while packets are being dropped; and a database replica can be online while lagging behind the active data set. Effective operations require end-to-end observability across network, application and data layers.
Identify the real failure
Use telemetry and health checks to distinguish a failed link, an unreachable site, a degraded application and an unhealthy data dependency.
Choose a safe response
Determine whether traffic should move, whether writes can continue, and whether the surviving site has enough capacity to take additional work.
Prove service recovery
Confirm that users can complete meaningful transactions, not merely that interfaces are up or routing adjacencies have recovered.
Five failure scenarios to test
Inter-data-center link failure
One DCI path fails while both sites remain operational. Check route convergence, alternate-path capacity, packet loss and whether replication or application dependencies are affected.
Validate: path failover · latency · loss · capacityBorder router or routing failure
A border device fails, a route is withdrawn or a policy change directs traffic incorrectly. Verify that alternate routes are usable and that recovery does not create a forwarding loop or black hole.
Validate: BGP state · route changes · forwarding pathApplication or dependency failure
Network connectivity remains available, but an application instance, database or identity service cannot complete requests. Check whether health signals remove the affected endpoint from service selection.
Validate: synthetic transactions · dependency healthReplication lag or data inconsistency
The remote data copy falls behind or a replication process stops. Establish whether the secondary site is safe to promote, what data could be missing and how consistency will be verified before normal service resumes.
Validate: replication lag · RPO · recovery procedureComplete site loss or network partition
A site becomes unavailable, or both sites remain running but lose communication. Confirm the failover decision, capacity at the surviving site, data ownership and safeguards against split-brain.
Validate: site isolation · quorum · service continuityA practical incident investigation sequence
During an incident, investigate from the observed user impact towards the underlying dependency. Correlating timestamps across routing events, interface counters, application logs and replication metrics helps distinguish the initiating failure from symptoms that appear later.
Identify affected users, services, sites and transactions.
Compare network, application and data telemetry.
Follow tested routing, failover and data procedures.
Test transactions, data integrity and performance.
What should you monitor?
| Layer | Useful signals | What they help reveal |
|---|---|---|
| Network | Interface errors, packet loss, latency, BGP changes, path utilisation | Transport degradation, route changes and capacity pressure |
| Application | Request success rate, latency, error rate, synthetic transactions | Whether users can actually complete operations |
| Data | Replication lag, commit failures, consistency checks, storage health | Whether the remote site has a safe and sufficiently current data set |
| Platform | CPU, memory, connection pools, queue depth, storage throughput | Whether the surviving site can absorb additional workload |
| Recovery | Failover duration, RTO/RPO achievement, recovery test results | Whether the design meets its agreed recovery objectives |
Do not confuse an infrastructure health check with a service health check. An interface can be up, a BGP session can be established and a server can respond to ping while a real transaction fails. Use application-aware probes and representative synthetic transactions wherever practical.
Failover, failback and recovery objectives
Recovery Time Objective (RTO) defines the target time to restore a service after disruption. Recovery Point Objective (RPO) defines the acceptable data-loss window, expressed as time or an equivalent recovery-point requirement. Different applications and data stores may need different objectives; a single pair of numbers should not automatically be applied to every service.
Failover is only half of the recovery story. Failback—returning service to its intended operating arrangement—can introduce another period of risk. Before returning workloads, confirm data consistency, replication health, routing policy, capacity and the correct ownership of stateful services. Avoid automatic failback if it could trigger repeated site switching or disrupt active sessions.
Operational readiness checklist
- Document the expected behaviour for link, device, application, data and full-site failures.
- Ensure alerts identify the affected service and provide enough context for investigation.
- Test routing convergence and verify actual packet forwarding after route changes.
- Confirm that the surviving site has enough compute, storage, network and application capacity.
- Define who can authorise failover, data promotion and failback during an incident.
- Record measured recovery times and data outcomes during controlled exercises.
- Review failures and near misses to improve runbooks, monitoring and architecture.
Resilience must be measured through observed service outcomes. Combine network telemetry, application health, data replication metrics and tested recovery procedures to determine whether the active-active architecture can withstand the failures it was designed to handle.
Failure Scenarios, Observability and Recovery
Simulate a router failure, an inter-site partition or a complete site outage. Observe the illustrative network state, monitoring signals and recovery checks that matter before declaring an active-active service healthy.
The conceptual topology shows active services at both sites. Monitoring should confirm end-to-end transaction success, route health, replication status and available capacity.
Observability panel
Recovery checklist
A green interface or established BGP session is only one signal. Correlate network telemetry with application transactions, data health and the capacity of the surviving site.
- Confirm the failure and its scope
- Validate the alternate forwarding path
- Check application and data integrity
- Verify recovery objectives are met
Cloud Connectivity and Modern Design Choices
Explore how data centers connect to cloud networks using private connectivity, VPNs, dynamic routing, VPC peering and hub-based services such as Google Cloud Network Connectivity Center. Compare resilience, route control, security, latency and cost without assuming one cloud model fits every deployment.
Cloud Connectivity and Modern Design Choices
Active-active design does not stop at the data center perimeter. Applications may depend on private cloud services, public cloud workloads, shared identity systems, or data platforms in another environment. The challenge is to connect these resources without creating hidden dependencies, unnecessary latency, or new single points of failure.
1. Separate data center interconnect from hybrid cloud connectivity
A data center interconnect (DCI) connects separate data center sites. Hybrid cloud connectivity connects an enterprise network or data center to cloud networks and services. These designs can overlap, but they solve different problems and should be assessed independently.
For example, two active data centers may exchange application traffic over a dedicated DCI while each site also has its own connection to a cloud provider. Another design may route both sites through a shared cloud connectivity hub. The right choice depends on application placement, traffic patterns, security boundaries, and failure-domain requirements.
2. Choose the connectivity model for the workload
Cloud connectivity is not one universal design. Dedicated private links, provider-managed private connectivity, and IPsec VPNs offer different trade-offs in capacity, latency, encryption, deployment time, and cost.
Private connectivity
Often suited to predictable, sustained traffic and workloads with demanding bandwidth or latency requirements. Validate provider availability, port and circuit diversity, routing hand-offs, and the actual end-to-end service commitment.
Site-to-site VPN
IPsec VPN can provide encrypted connectivity over an IP underlay. High-availability VPN designs use redundant tunnels or endpoints, but the underlying internet paths and provider failure domains still matter.
Cloud routing
Cloud routers and BGP sessions can exchange routes dynamically where supported. Define which prefixes are advertised, accepted, preferred, or filtered, and test behaviour when a peer or path fails.
Hub-and-spoke connectivity
A cloud transit or connectivity hub can simplify connections between multiple networks. It also becomes an important policy and operational component that needs its own resilience and capacity planning.
3. Understand VPCs, peering and cloud connectivity hubs
In Google Cloud, a Virtual Private Cloud (VPC) provides a logical network boundary for cloud resources. VPC connectivity, Cloud VPN, Cloud Router, and Network Connectivity Center (NCC) address different parts of hybrid and multi-network design. Other providers have comparable concepts, but their capabilities and terminology differ.
| Building block | Design role | Important consideration |
|---|---|---|
| VPC network | Provides a logical network environment for cloud resources. | Plan address ranges, segmentation, route policy, and access controls. |
| VPC peering | Connects eligible VPC networks through a peering relationship. | Do not assume peering provides transitive routing through another VPC. |
| Cloud VPN | Provides IPsec-based connectivity between networks. | Plan tunnel redundancy, routing, encryption requirements, and failover testing. |
| Cloud Router / BGP | Supports dynamic route exchange for compatible connectivity services. | Validate advertised prefixes, learned routes, route priorities, and withdrawal behaviour. |
| Network Connectivity Center | Provides a hub-based framework for supported network connectivity patterns. | Check supported resources, topology constraints, route propagation, and configuration requirements. |
A cloud hub, a pair of VPN tunnels, or two physical circuits does not automatically make an application highly available. Shared carrier infrastructure, common provider endpoints, route-policy errors, cloud-region dependencies, DNS, identity, and application state can still create a common failure mode.
4. Design the routing and failure behaviour
Once connectivity is established, define what happens when a link, tunnel, router, data center, or cloud attachment becomes unavailable. Routing must support the intended failover behaviour without creating loops, accidental transit, or unintended access between security zones.
Route control
Advertise only required prefixes. Apply explicit import and export policy, avoid overlapping address spaces, and understand how route preference changes during failure.
Path diversity
Check whether redundant connections use independent devices, facilities, carriers, cloud endpoints, and regions where the availability objective requires it.
Security boundaries
Apply segmentation, firewall policy, identity controls, and inspection requirements to both primary and failover paths. A backup route should not bypass required controls.
Application dependencies
Validate DNS, authentication, secrets, databases, monitoring, and other shared services. Network reachability alone does not prove that the service can operate.
5. Compare the design options before committing
Select connectivity according to measured workload requirements and operational constraints—not simply because a particular product or topology is available.
| Design question | What to evaluate |
|---|---|
| Traffic profile | Peak and sustained throughput, burst behaviour, packet size, and growth expectations. |
| Performance | Latency, jitter, packet loss, regional distance, and application sensitivity. |
| Availability | Independent paths, redundant endpoints, provider failure domains, and tested recovery behaviour. |
| Routing | Address planning, BGP policy, route propagation, failover timing, and prevention of unintended transit. |
| Security | Encryption, segmentation, inspection, identity, and compliance requirements. |
| Operations and cost | Provisioning lead time, monitoring, support ownership, data transfer charges, and ongoing operational effort. |
6. Validate the architecture with failure tests
Test the complete application path, including the network and the dependencies it uses. Record what users experience, how quickly the system detects a failure, which routes change, and whether recovery occurs within the required objective.
- Disconnect one connectivity path and verify traffic moves as designed.
- Withdraw a route and confirm that only intended prefixes change reachability.
- Test a cloud attachment or VPN endpoint failure where the environment permits.
- Verify that security policy remains enforced on the alternate path.
- Measure application recovery, not just routing convergence.
- Document ownership, alerts, escalation, and restoration procedures.
Active-active data center design and hybrid cloud connectivity should be designed together where workloads depend on both—but they are not the same problem. Choose private connectivity, VPN, peering, or a hub-based model according to workload needs, then validate route policy, failure-domain independence, security, and application recovery end to end.
Cloud Connectivity and Modern Design Choices
Choose a connectivity pattern to explore how an on-premises network can connect to cloud networks. Compare the conceptual architecture, routing considerations and security decisions before selecting a design for a real environment.
Conceptual diagram, not a provider-specific reference architecture. Redundant tunnels, gateways and route exchange must be designed and tested explicitly.
Site-to-site VPN
Build an encrypted connection between the enterprise network and the cloud provider's VPN endpoint. The internet may carry the tunnel traffic, while routing controls which prefixes can traverse it.
- Confirm tunnel encryption, authentication and key-management requirements.
- Validate route advertisements, allowed prefixes and return-path symmetry.
- Test failure detection, alternate paths, throughput and maximum packet size.
- A tunnel being established does not prove application reachability.
- One tunnel or gateway can remain a single point of failure.
High availability is an end-to-end property
Consider independent circuits, gateways, cloud regions or zones where supported, route convergence, capacity under failure, and the application's own dependency model. Two connections that share the same failure domain may not provide meaningful redundancy.
Routing and security are separate decisions
Route exchange determines reachability; firewall policy, segmentation, identity and encryption determine what is permitted and protected. Validate both directions and test the application path rather than relying on a successful routing adjacency alone.
Active-Active Data Center Design: Key Takeaways
A practical recap of the architecture, routing, application dependencies, failure planning and cloud connectivity decisions behind a resilient multi-site data center.
Active-active data center design aims to use multiple sites to serve workloads concurrently while maintaining service continuity when links, network devices, applications or entire sites fail. Achieving this requires more than duplicating infrastructure: routing, application state, data consistency, security and recovery procedures must work together.
Architecture and workload placement
Define which services operate at each site, how traffic is distributed, and what happens when one location becomes unavailable. Active-active is a service and workload design decision, not simply a topology with two data centers.
Multi-site routing and BGP
Use explicit routing policy, controlled prefix advertisement and deliberate path selection. Validate convergence, asymmetric paths, route withdrawal and the capacity of the surviving site under failure conditions.
Layer 2 extension and overlays
Choose between routed inter-site connectivity, selective Layer 2 extension and overlay-based approaches according to workload requirements. Avoid extending broadcast domains across sites without a clear operational and failure-containment justification.
Application and data consistency
Understand replication lag, transaction behaviour, quorum, write ownership and recovery objectives. Network reachability alone cannot guarantee consistent data or prevent conflicting writes during a partition.
Failure detection and recovery
Monitor routing and infrastructure alongside application transactions, replication health and user-visible service availability. Test realistic failures and document safe failover, failback and recovery procedures.
Cloud connectivity and modern choices
Select VPN, private connectivity, network peering or hub-based connectivity based on reachability, routing, security and resilience requirements. Confirm provider-specific route propagation and service limitations before implementation.
Six engineering principles to carry into your design
- Design around service availability, not device availability alone.
- Ensure the surviving site has sufficient capacity for its intended failure role.
- Keep routing policy, application behaviour and data consistency aligned.
- Use Layer 2 extension only where the workload genuinely requires it.
- Measure end-to-end service health, not just link and routing status.
- Prove failover and recovery through repeatable tests and documented outcomes.
Final perspective: resilience must be engineered and tested
The strongest active-active designs make failure behaviour explicit. They define how traffic moves, how stateful applications continue safely, how data is protected, and how operators recognise and resolve degraded service. They also account for partial failures, where a site remains reachable but can no longer safely perform its intended role.
No single technology guarantees resilience. BGP, overlays, replication, cloud connectivity and redundant infrastructure are building blocks whose effectiveness depends on the requirements, implementation and operational testing around them.
Build for the failure you need to survive, define the service outcome you must preserve, and test that outcome before relying on the architecture in production.