<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1705902170274878&amp;ev=PageView&amp;noscript=1">
Skip to content
Talk to Us
  • There are no suggestions because the search field is empty.

SD-WAN Integration

Instead of standing up an SD-WAN gateway in every cloud region, you terminate the SD-WAN overlay once on a virtual instance at the managed edge, then reach every cloud privately from that single point. Branches get consistent policy and one place to control routing between the WAN and the clouds.

When to use it

Use this pattern when you already run SD-WAN across your branches and want those branches to reach cloud workloads without replicating SD-WAN gateways cloud-by-cloud. It consolidates north–south traffic (branch to cloud) and east–west traffic (cloud to cloud) at a single control point, which keeps policy consistent and cost down.

How it works

A virtual SD-WAN instance runs on the IZO™+ Multi Cloud Connect managed edge. On one side it terminates your SD-WAN overlay, joining the same encrypted mesh as your branches. On the other side it does underlay routing into each cloud over private, dedicated connections – no public internet in the cloud path. The branch overlay and the private cloud underlay meet on this one instance, so the edge becomes the hinge between your WAN and your clouds.

The traffic flow is straightforward: a branch sends traffic across the SD-WAN overlay to the managed edge; the edge routes it over the private connection to the correct cloud; the cloud gateway peers with the edge over BGP. Return traffic follows the reverse path. Because the cloud-side hops are private, you avoid internet egress charges and get predictable latency.

For resilience, the single virtual instance can be upgraded to a redundant pair – see the High Availability & Redundancy Models page. Where a cloud mandates dual circuits (for example, paired connections into Azure), map that requirement onto diverse paths from the edge rather than relying on a single connection.

The IZO™+ Multi Cloud Connect Flex service model is the natural companion where branches reach the edge over an internet underlay.

Example

A retail chain runs SD-WAN across several hundred stores and wants each store to reach inventory services in AWS and a loyalty platform in Azure. It deploys one virtual SD-WAN instance on the managed edge. Stores keep their existing overlay; the edge routes store traffic privately to AWS and Azure. Adding a third cloud later means one new private connection at the edge, not a new gateway in every store.

MCC Visual Reference Architecture & Use Cases-13.4 SD-WAN Integration.drawio

Bandwidth planning

Size the edge instance for the aggregate of all branch-to-cloud flows that transit it, plus any cloud-to-cloud traffic you hairpin through it. Because this is a consolidation point, its throughput must exceed the busiest branch by a wide margin – treat it as a small core node, not a branch device.

MCC components in this architecture

SD-WAN integration is a IZO™+ Multi Cloud Connect Flex pattern – the SD-WAN function 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 – SD-WAN – terminates your overlay and does underlay routing into each cloud; sized by vCPU (2/4/8/16 cores), Tata-managed or customer-managed, Tata-subscription or BYOL.

  • Virtual Cloud Connection – one private landing per cloud you reach.

  • Device Interconnection – only if you run a dual/clustered SD-WAN VNF pair.

From the IZO™+ Multi Cloud Connect side, this architecture uses a Fabric Port + Edge Connect + SD-WAN VNF + Virtual Cloud Connection(s); everything up to the Virtual Cloud Connection is delivered and billed by Tata Communications, while each cloud’s port/attachment and egress sit on your cloud bill. This page pairs with the IZO™+ Multi Cloud Connect Flex By Cloud Provider material.

Considerations

  • IZO™+ Multi Cloud Connect Flex is required - The SD-WAN function is an in-path VNF, so this is always IZO™+ Multi Cloud Connect Flex – not Direct.

  • Sizing - The VNF is a consolidation point for all branch-to-cloud (and cloud-to-cloud) flows that transit it – size its vCPU as a small core node, not a branch device.

  • Overlay vs underlay - The branch overlay terminates on the VNF; the cloud legs are private Virtual Cloud Connections – no public internet in the cloud path.

  • Vendor support - Cisco is the default VNF vendor; Palo Alto, Fortinet, Versa, VMware and Juniper are available via your Account Manager – confirm which SD-WAN platforms are certified before naming them.

  • HA - Upgrade the single VNF to a clustered pair joined by a Device Interconnection; honour any cloud-mandated dual-circuit requirement (for example Azure) as diverse Virtual Cloud Connections.

What’s on the cloud side

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

Related pages