Hybrid Cloud Blueprint

The hybrid cloud blueprint connects a single on-premises data centre to one primary public cloud over a private, managed connection — giving you predictable latency, a clean routing boundary, and a single point of policy control, without exposing traffic to the public internet.

What this is

The hybrid cloud blueprint is the starting pattern for most enterprises: one data centre, one primary cloud, connected privately. It is the foundation the other reference architectures build on. You keep your systems of record on-premises, place new or elastic workloads in the cloud, and join the two over IZO™+ Multi Cloud Connect so the link behaves like an extension of your own network rather than an internet path.

Use it when you are taking a first, deliberate step into public cloud, when a workload needs consistent low latency to on-premises systems, or when data residency and security rules mean traffic must stay off the public internet.

How it works

Your data centre connects to a shared cloud-facing port on the Tata Communications network. Over that port, a dedicated logical connection is provisioned to your primary cloud. Routes are exchanged with the cloud edge using BGP, with Tata Communications advertising from ASN 4755. Your existing routers do not change — the service shapes bandwidth per connection and hands off routing at a clean boundary.

The blueprint comes in two service models. Multi Cloud Connect Direct uses a private MPLS underlay for the most predictable performance and is the usual choice for a primary production link. Multi Cloud Connect Flex uses an internet underlay with encrypted transport, and suits sites where a private circuit is not yet in place. Both terminate on the same managed edge and reach the same cloud.

Three design decisions define a good blueprint:

Decision	What to choose	Why
Service model	Direct for production; Flex for rapid or interim reach	Balances predictability against speed of turn-up
Resiliency tier	Standard (in-metro dual-path) as a baseline	Two diverse paths remove the single-link risk
Routing policy	Active/backup via BGP local preference	Deterministic path selection and clean failback

Even where the cloud treats both paths as active/active, Tata Communications tunes BGP — local preference and AS-PATH prepend — so one path is primary and the other takes over on failure. Security is applied at the hand-off: private addressing end to end, and an inspection point (your on-premises firewall, or a virtual firewall on the managed edge) for traffic entering and leaving the cloud.

Example

A discrete-manufacturing company runs its ERP and MES on-premises and wants to place a new analytics and reporting tier in AWS. It provisions a Multi Cloud Connect Direct link from its primary data centre to AWS, Standard resiliency, with two diverse paths in the same metro. BGP is set active/backup so reporting traffic follows the primary path and fails over automatically. The ERP stays on-premises; only the reporting tier sits in the cloud, reachable privately at consistent latency.

Bandwidth planning

Size the link to the aggregate of steady-state replication plus peak interactive traffic, then add headroom for growth. A common starting point is a 1 Gbps logical connection with the ability to step up in slabs as cloud workloads grow. Where a backup-and-replication window overlaps business hours, size for the sum, not the average, so the replication stream does not starve interactive sessions.

IZO™+ Multi Cloud Connect components in this architecture

IZO™+ Multi Cloud Connect assembles every solution from a small, reusable set of components. The hybrid cloud blueprint can be delivered with either service model:

Multi Cloud Connect Direct (private MPLS underlay):

Fabric Port — the on-ramp where your network meets the service (Hosted or Dedicated; L3 Private access is typical). Present in every solution.
Virtual Cloud Connection — lands on your primary cloud with BGP peering; on Direct, Tata Communications allocates the peer IPs.

Multi Cloud Connect Flex (internet underlay with an in-path VNF):

From the IZO™+ Multi Cloud Connect side, this architecture uses a Fabric Port + Virtual Cloud Connection (plus Edge Connect + VNF on Flex); everything from the Fabric Port to the Virtual Cloud Connection is delivered and billed by Tata Communications, while the AWS Direct Connect hosted connection and egress sit on your cloud bill.

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; present only when a VNF is used.
VNF — Router / Firewall — an optional in-path virtual device, sized by vCPU (2/4/8/16 cores), if you want a network function in the path.
Virtual Cloud Connection — lands on the cloud; on Flex you define the BGP addressing when you order.

Considerations

Solution choice. Choose Multi Cloud Connect Direct for the most predictable performance on a plain private link; choose Multi Cloud Connect Flex when you need an in-path function — Flex adds a VNF and an Edge Connect.
Resiliency. A single Fabric Port and Virtual Cloud Connection is the baseline; step up to dual (Primary + Secondary) for production. See High Availability & Redundancy Models.
Addressing. On Direct, Tata Communications allocates the BGP peer IPs; on Flex, you define the interface, neighbour IP and ASN at ordering.
Cloud-side specifics. On AWS you accept the hosted connection and create a Virtual Interface, peering with Tata Communications ASN 4755; the Direct Connect port and egress are on your AWS bill.
Bandwidth & cost. Fabric Port and Virtual Cloud Connection are priced by bandwidth (doubled if dual); on Flex the VNF vCPU size is the dominant cost lever.

What’s on the cloud side

The cloud connection at the far end is created in the cloud provider’s console. This page covers how the private hybrid link is delivered on the Tata Communications side; for the cloud-side connection request and routing, see the relevant per-cloud section.