An active-active design runs the same application in two cloud regions at once, each reached over its own private connection. Both regions serve traffic in normal operation; if one region or path fails, BGP steers all traffic to the survivor with no manual intervention.
When to use it
Choose active-active when downtime is expensive and you cannot wait for a cold or warm site to come up — payment processing, order capture, authentication, or any service with a tight availability target. It also spreads load geographically, placing users near the closest healthy region and reducing round-trip latency.
How it works
The application is deployed identically in two regions of the same cloud. Each region has its own dedicated connection over IZO™+ Multi Cloud Connect, so the two regions do not share a single point of failure in the connectivity layer. This is the Maximum resiliency tier — paths diverge across regions or metros rather than sitting side by side in one location.
Traffic engineering is done with BGP. Tata Communications advertises from ASN 4755 and controls path selection with local preference and AS-PATH prepend:
|
Path |
Local preference |
AS-PATH prepend |
|
Primary |
400 |
none |
|
Secondary |
300 |
4755 2 |
|
Tertiary |
200 |
4755 3 |
|
Quaternary |
100 |
4755 4 |
For a true active-active service you weight the two regions equally at the application layer (DNS or a global load balancer) while keeping the network paths deterministic underneath, so a path failure produces a clean, predictable shift rather than route flapping. Fast failure detection uses BFD with a standard 300 ms × 3 timer, so loss of a path is noticed in under a second and BGP reconverges onto the healthy region.
Data consistency is the design constraint that matters most. Synchronous replication between regions bounds how far apart they can be before write latency hurts; asynchronous replication relaxes distance at the cost of a small data lag. That trade-off, not the network, usually decides the region pair.
Example
A payments platform runs its authorisation service active-active across two Azure regions. Each region has its own Multi Cloud Connect Direct connection; Azure peers with Tata Communications (Azure ASN 12076) on each. A global load balancer splits live traffic across both regions. When one region’s path degrades, BFD detects it within a second, BGP withdraws that path, and all authorisation traffic converges on the surviving region — customers see no interruption.
Bandwidth planning
Size each regional connection to carry the full production load, not half of it — in a failover, one region must absorb everything. Add capacity for inter-region replication, which runs continuously and competes with user traffic. A frequent mistake is sizing each path for the steady-state 50/50 split and then saturating the survivor during an outage.
MCC components in this architecture
An active-active design is a dual build — a component pair per region or metro:
Multi Cloud Connect Direct (private MPLS underlay):
-
Fabric Port ×2 — one per region/metro path, for diverse on-ramps.
-
Virtual Cloud Connection ×2 — one landing per region, to the same or paired cloud regions.
Multi Cloud Connect Flex (internet underlay with an in-path VNF):
-
Fabric Port ×2 and Edge Connect ×2 — where an in-path function is wanted per path.
-
VNF (optional) ×2 joined by a Device Interconnection for the HA pair.
-
Virtual Cloud Connection ×2 — one per region.
From the IZO™+ Multi Cloud Connect side, this architecture uses two Fabric Ports + two Virtual Cloud Connections (a pair per region; add VNF + Edge Connect + Device Interconnection on Flex); the Tata Communications-billed parts run from the Fabric Ports to the Virtual Cloud Connections, while each cloud region’s port/attachment and egress sit on your cloud bill.
Considerations
-
Dual by design. Both regional chains are always live; size each Fabric Port and Virtual Cloud Connection to carry the full load, not half — a failover puts everything on one path.
-
Path determinism. Weight the two paths with BGP (local preference 400/300, AS-PATH prepend on the backup) so failover is clean; BFD (300 ms × 3) gives sub-second detection.
-
Cloud-side specifics. On Azure, Virtual Cloud Connections are dual by default (primary + secondary peering) and the effective MTU is 1500 (no jumbo); peering uses Azure ASN 12076.
-
Data consistency. Synchronous replication bounds region distance; asynchronous relaxes distance at the cost of a small lag — this, not the network, usually decides the region pair.
-
Cost. Roughly twice the connectivity components of a single-region build; account for continuous inter-region replication bandwidth.
What’s on the cloud side
Each cloud connection is created in the cloud provider’s console. This page covers how the two regional paths are delivered and steered on the Tata Communications side; for each cloud-side connection request and routing, see the relevant per-cloud section.