When an application spans multiple clouds, a virtual load balancer on the managed edge distributes traffic across those clouds over private connections – improving performance and resilience without sending inter-tier traffic over the public internet.
When to use it
Use this pattern when application tiers or instances live in more than one cloud and you need to distribute traffic across them – for performance, for resilience, or to place workload near data. Doing this over the internet adds latency and egress cost; doing it on private paths keeps both down.
How it works
A virtual load balancer runs on the IZO™+ Multi Cloud Connect managed edge, alongside the edge’s routing function. Each cloud attaches over a private, dedicated connection with BGP peering to its gateway. The load balancer sits at the edge and distributes traffic across the cloud-resident tiers – for example a web tier in one cloud and a database tier in another region of a second cloud – with every hop private.
Two properties make the edge the right place for this. First, it already has private reach into every attached cloud, so balancing there means no internet detour and no per-gigabyte egress on the balanced traffic. Second, it is a single point to express the balancing policy, rather than stitching together each cloud’s native balancer. Latency awareness matters: keep tightly-coupled tiers in the same region where possible and reserve cross-region balancing for cases where the resilience is worth the round-trip.
As with the other edge-hosted functions, a single load-balancer instance is the baseline and a redundant or clustered pair is the production form; see the High Availability & Redundancy Models page.
Example
A SaaS provider runs its application’s front end in Azure and part of its data and processing tier in AWS, in the same region footprint. A virtual load balancer on the managed edge distributes application traffic across the two clouds over private connections. Users reach the front end; the edge balances backend calls to the AWS tier privately, avoiding internet egress and keeping latency predictable. When one cloud’s tier is degraded, the balancer shifts load to the healthy side.
Bandwidth planning
Size the edge for the sum of the flows it balances, including any backend traffic that crosses between clouds through it. Because balanced backend calls can multiply front-end requests, measure the backend-to-frontend ratio for your application rather than assuming they are equal.
IZO™+ Multi Cloud Connect components in this architecture
Application load balancing is a Flex pattern – the load balancer is delivered as a VNF at the edge:
IZO™+ Multi Cloud Connect Flex (internet underlay with an in-path VNF):
-
Fabric Port – the on-ramp where your network meets the service (Hosted or Dedicated; L3 Private access is typical). Present in every solution.
-
Edge Connect – the short leg that carries traffic from the Fabric Port to the VNF
-
VNF – Load Balancer – distributes traffic across the cloud-resident tiers; sized by vCPU, Tata- or customer-managed.
-
Virtual Cloud Connection – one private landing per cloud across which traffic is balanced.
-
Device Interconnection – for a paired/clustered load-balancer build.
From the IZO™+ Multi Cloud Connect side, this architecture uses a Fabric Port + Edge Connect + Load Balancer VNF + Virtual Cloud Connection(s); everything up to the Virtual Cloud Connections is delivered and billed by Tata Communications, while each cloud port/attachment and egress sit on your cloud bill.
Considerations
-
Flex is required - The load balancer is an in-path function – IZO™+ Multi Cloud Connect Flex, not Direct.
-
Private paths only - Balancing at the edge means every cloud leg is a private Virtual Cloud Connection – no internet detour and no per-gigabyte egress on the balanced traffic.
-
Latency awareness - Keep tightly-coupled tiers in the same region; reserve cross-region balancing for cases where the resilience justifies the round-trip.
-
Sizing - Size the VNF for the sum of balanced flows, including backend calls that cross between clouds – measure the backend-to-frontend ratio rather than assuming parity.
-
HA - Add a paired load-balancer build with a Device Interconnection for production.
What’s on the cloud side
Each cloud connection and gateway are created in the cloud provider’s console. This page covers how balancing across the private connections is delivered on the Tata Communications side; for the cloud-side connection request and routing, see the relevant per-cloud section.