Cloud-to-Cloud Connectivity

Cloud-to-cloud connectivity links two (or more) public clouds privately through the Tata Communications backbone, with no public-internet hop between them. Each cloud connection runs as a normal IZO™+ Multi Cloud Connect connection; the cloud-to-cloud configuration joins them on the backbone, and routing is exchanged over BGP. Inter-cloud bandwidth can be shaped independently of your site-to-cloud traffic.

When to use it

This scenario fits multi-cloud architectures where workloads in different clouds need to talk to each other. Common cases:

Multi-cloud applications - for example a web tier in one cloud and a database or analytics tier in another, where inter-tier traffic must be private and fast.
Disaster recovery across clouds - a primary in one cloud and recovery in another, with high-volume replication between them.
Multi-cloud data sharing - teams or business units on different clouds with regular data flows between them.
Compliance - traffic that is not permitted to traverse the public internet.

Unlike the other scenarios, no on-premises site is involved - the connection joins two clouds directly.

The “double egress” problem this solves

Without a private cloud-to-cloud path, traffic between two clouds usually leaves the source cloud to the public internet and enters the destination cloud from it. The path is public and the source cloud charges egress. With cloud-to-cloud connectivity the traffic stays private end to end over the backbone. Cloud egress charges still apply - the cloud provider charges for traffic leaving its network regardless of path - but the route is private, performance is predictable, and there is no public-internet exposure.

How it works

Cloud-to-cloud connectivity is delivered through the same modular design as the other scenarios. For each pair of clouds you want to interconnect:

You order an IZO™+ Multi Cloud Connect connection to each cloud (for example, one AWS connection and one Azure connection).
Tata Communications joins the two cloud connections on the backbone using a dedicated logical connection.
BGP is established between the two cloud connections, exchanging routes in both directions.
Traffic flows directly between the clouds over the backbone - it does not transit your data centre or any other site.

Bandwidth between the two clouds can be shaped independently of the bandwidth provisioned for site-to-cloud traffic.

Worked example: a customer holds a 200 Mbps connection to Azure and a 200 Mbps connection to AWS but wants inter-cloud traffic capped at 100 Mbps - this is delivered by applying a 100 Mbps shaper to the AWS-to-Azure flow while each cloud connection remains at 200 Mbps for its own site-to-cloud traffic.

Example Scenario

A media company stores its content library in AWS but runs its analytics and AI tooling in Google Cloud. Nightly transfers of large media files between the two were slow over the public internet and were driving up egress charges. A cloud-to-cloud connection joins the AWS and Google Cloud environments privately across the backbone. The bulk transfers now stay off the internet entirely, finishing faster and at lower cost, and the two cloud teams no longer expose data paths to the public network. No on-premises site is involved - the connection links the two clouds directly.

Supported cloud combinations

Cloud-to-cloud connectivity is supported across all IZO™+ Multi Cloud Connect destinations - any pairing among AWS, Azure, Google Cloud, Oracle, IBM Cloud and other major public cloud service providers. Multi-way connectivity (three or more clouds in a mesh) uses the same pattern, with a connection to each cloud joined on the backbone.

Latency

Inter-cloud latency is determined by the backbone path between the two clouds’ peering locations, so it depends on the metros you choose. For the lowest latency, provision both cloud connections at peering locations in the same metro. For latency expectations on specific metro pairs, check with your Tata Communications account team.

Constraints

Inter-cloud bandwidth is independently shapeable but must be less than or equal to the smaller of the two cloud connections’ bandwidths.
BGP route limits apply per cloud; high prefix counts may require route summarisation. Customer-side prefix controls (set in each cloud) determine which routes are advertised between the clouds.
The connection is bidirectional by design.

What’s on the cloud side

Each cloud connection is created in the cloud provider’s console. This page covers how the two connections are joined on the Tata Communications side; for each cloud-side connection request and routing, see the relevant per-cloud section.