SD-WAN Multicloud Secure Connectivity

Introduction

Imagine your organization runs critical applications across AWS, Azure, and Google Cloud simultaneously, while branch offices, campuses, and data centers all need fast, secure, and reliable access to every one of those cloud environments. The traditional approach of managing each cloud connection independently quickly becomes an operational nightmare: inconsistent security policies, manual configurations per cloud provider, and no unified visibility into traffic flows. This is precisely where SD-WAN multicloud connectivity transforms the game.

Modern enterprises are under pressure to onboard multiple clouds so they can shift applications where they perform best, scale on demand, and reduce costs. Yet the mandate from security teams is clear: all connections must be secure, with the data center serving as the gateway when needed. Bridging these two requirements demands an architecture that connects multiple clouds efficiently while maintaining end-to-end encryption and centralized policy control.

This article walks through the full spectrum of SD-WAN multicloud secure connectivity design. You will learn the cloud networking fundamentals, infrastructure transition considerations, architecture options for direct and interconnect-based access, and detailed integration patterns for AWS, Azure, and Google Cloud. We will also cover cloud-to-cloud connectivity, interconnect-based designs using carrier-neutral facilities, and the automated multicloud networking workflow that achieves secure connectivity in minutes. Every topology, protocol interaction, and design pattern discussed here is grounded in proven deployment architectures.

What Are the Cloud Models and Connectivity Options for SD-WAN Multicloud?

Before diving into specific architectures, it is essential to understand the cloud models and connectivity building blocks that underpin any SD-WAN multicloud design.

Cloud Models

Cloud Model	Description
Public Cloud	Infrastructure owned and operated by a cloud service provider, shared across tenants
Private Cloud	Dedicated cloud infrastructure operated for a single organization
Hybrid Cloud	Combination of public and private cloud with orchestration between them
Multi-Cloud	Use of multiple public cloud providers (e.g., AWS + Azure + Google Cloud) simultaneously

A multicloud strategy is the most common pattern for large enterprises today. Different business units may prefer different providers, acquisitions bring in new cloud footprints, and certain workloads perform better on specific platforms. The challenge is connecting all of these environments securely and efficiently.

Cloud Connectivity Options

The connectivity options available for reaching cloud workloads include:

Direct Connect (AWS) -- dedicated private connection from on-premises to AWS
Virtual Private Networks -- encrypted tunnels over the internet
ExpressRoute (Azure) -- private connectivity to Azure via a connectivity provider
Interconnect Services -- carrier-neutral facilities such as Megaport and Equinix
SD-WAN Fabric -- software-defined overlay that unifies all connectivity under centralized management

Cloud-Native Networking Services

Each cloud provider offers native networking constructs that SD-WAN integrates with:

Cloud Provider	Key Networking Services
AWS	Virtual Private Clouds (VPCs), Transit Gateway (TGW), AWS Cloud WAN
Azure	Virtual Networks (vNets), Virtual WAN (vWAN), Virtual Hub (vHub)
Google Cloud	Virtual Private Clouds (VPCs), Google Cloud Router (GCR), Network Connectivity Center

Understanding these native services is critical because the SD-WAN integration leverages them as the foundation for automated connectivity.

How Does Infrastructure Transition Drive SD-WAN Multicloud Adoption?

The journey toward SD-WAN multicloud does not happen in isolation. It reflects a broader infrastructure transition that enterprises undergo as they move workloads to the cloud.

The Traditional Network

In a traditional enterprise network, you have branches, campuses, B2B sites, headquarters, and data centers interconnected through:

Private WAN connections
Routing protocols such as BGP and IS-IS
Technologies like EVPN, MPLS, and IPsec
An SD-WAN fabric overlaying the transport

The data center has historically served as the central hub for all traffic, including cloud-bound traffic. But as cloud adoption grows, this model creates bottlenecks and adds latency for users who need direct cloud access.

The Business Drivers

Three distinct perspectives drive the transition:

CIO perspective: Cloud enables the business to scale, cut costs, and stay agile with market demands
Application teams: The business needs to onboard multiple clouds so applications can be shifted to the optimal platform
Network and security teams: Develop an architecture to connect multiple clouds efficiently while ensuring all connections are secure, with the data center serving as the gateway

These competing requirements create the need for an architecture that provides direct cloud access where appropriate, maintains security at every hop, and centralizes management through a single pane of glass.

What Are the Two Primary Architecture Options for SD-WAN Multicloud Connectivity?

There are two fundamental architecture options for connecting enterprise sites to cloud workloads. Each has distinct characteristics and trade-offs.

Architecture Option 1: Direct Access to the Cloud

In this model, branches, campuses, B2B sites, headquarters, and data centers connect directly to cloud workloads through the SD-WAN fabric. Security functions are applied at each site or at the cloud edge.

Key characteristics:

Each site has a direct path to cloud resources
Security is distributed across branches, campuses, and data centers
Lower latency for cloud-bound traffic since it does not need to traverse the data center
Requires security enforcement at every egress point

This architecture suits organizations where users at branch offices need low-latency access to cloud applications and where the security stack can be distributed.

Architecture Option 2: Via Cloud Interconnect

This model introduces a structured three-segment path:

Segment	Description
First Mile	Enterprise site to the interconnect point of presence (PoP)
Middle Mile	Interconnect backbone connecting to cloud provider entry points
Last Mile	Cloud provider entry point to the workload VPCs/vNets

Key characteristics:

Traffic flows through a defined path with security applied at each segment
Leverages carrier-neutral facilities (such as Megaport or Equinix) as intermediate transit points
Provides private, high-bandwidth connectivity to multiple clouds from a single interconnect
Security is enforced at the data center, interconnect, and cloud edge

Pro Tip: Architecture Option 2 is particularly valuable when you need to connect to multiple cloud providers from a single location, as the interconnect PoP gives you access to AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect simultaneously.

How Does the Multicloud Networking Workflow Automate SD-WAN Connectivity?

One of the most powerful aspects of SD-WAN multicloud design is the automated workflow that achieves secure connectivity in minutes rather than days or weeks. This workflow is orchestrated through the SD-WAN Manager and follows four distinct steps.

Step 1: Associate Cloud Provider Accounts

The first step is associating your cloud provider accounts (AWS, Azure, Google Cloud) with the SD-WAN Manager. This establishes the API-level integration that enables all subsequent automation. The SD-WAN Manager uses these credentials to discover resources, deploy virtual routers, and configure connectivity.

Step 2: Discover and Tag VPCs and vNets

Once the cloud accounts are associated, the SD-WAN Manager discovers all existing Virtual Private Clouds (VPCs in AWS and Google Cloud) and Virtual Networks (vNets in Azure). You then tag these resources to identify which ones should be connected through the SD-WAN fabric. Tagging enables granular control over which workloads participate in the overlay.

Step 3: Create Cloud Gateway (Catalyst 8000V) at the Closest Region

The SD-WAN Manager automatically deploys a Catalyst 8000V (C8KV) virtual router in the cloud region closest to your workloads. This virtual router serves as the cloud gateway, terminating SD-WAN tunnels from enterprise sites and establishing connectivity to cloud-native networking services.

Step 4: Build Connections Between VPCs/vNets and the Gateway

The final step maps the tagged VPCs and vNets to the cloud gateway. The SD-WAN Manager automates the creation of all required connections, including:

BGP peering sessions between the C8KV and cloud-native routers
IPsec/GRE tunnel establishment
Route redistribution between OMP (Overlay Management Protocol) and BGP

Pro Tip: This four-step workflow applies consistently across AWS, Azure, and Google Cloud. The SD-WAN Manager abstracts the cloud-specific differences, giving you a unified experience regardless of which provider you are connecting to.

Use Cases Enabled

The automated workflow supports several critical use cases:

Use Case	Description
Site to Multicloud	Enterprise sites connect to workloads in any cloud
Region to Region	Workloads in one cloud region connect to workloads in another region of the same provider
Cloud to Cloud	Workloads in one cloud provider connect to workloads in a different provider
Site to Site	Enterprise sites use the cloud provider backbone as transport
Inspection In and Between the Cloud	Security inspection applied to traffic within and between cloud environments using Multicloud Defense

SD-WAN Multicloud Integration with AWS

AWS integration is one of the most mature and feature-rich patterns in SD-WAN multicloud design. There are multiple architecture options depending on whether you use AWS Transit Gateway (TGW) or AWS Cloud WAN.

Site-to-Cloud with Transit Gateway (TGW)

This is the foundational pattern for connecting enterprise sites to AWS workloads.

Architecture components:

Netops Account: Hosts the Transit VPC containing the Catalyst 8000V (C8KV) or vMX virtual router
Cloudops Account: Contains the Workload VPCs where applications run
Transit Gateway (TGW): AWS-native service that acts as a hub for VPC connectivity
SD-WAN Manager: Orchestrates the entire deployment via API

How it works:

The C8KV in the Transit VPC establishes IPsec/GRE tunnels back to enterprise sites through the SD-WAN fabric
The C8KV runs BGP sessions with the Transit Gateway
Route redistribution converts OMP-to-BGP (toward AWS) and BGP-to-OMP (toward enterprise sites)
The TGW propagates a default route (0.0.0.0/0) toward the workload VPCs
All configuration is automated through the SD-WAN Manager API

The integration uses IKEv2 IPsec/GRE tunnels natively between the Transit VPC C8KV and the Transit Gateway, providing both encryption and overlay encapsulation.

Site-to-Cloud with AWS Cloud WAN

AWS Cloud WAN provides a more advanced alternative to TGW for organizations that need a globally managed network.

Key differences from TGW:

Uses a Core Network instead of a Transit Gateway
Supports IPsec or CONNECT (GRE) attachment types between the Transit VPC C8KVs and Cloud WAN
The Core Network spans multiple segments (S1, S2, S3, S4) for traffic isolation
Provides built-in global backbone connectivity

The integration pattern remains similar: C8KVs in the Transit VPC establish SD-WAN tunnels to enterprise sites and run BGP with the Cloud WAN Core Network for route exchange.

Region-to-Region with TGW

When workloads span multiple AWS regions, you need region-to-region connectivity.

With Transit Gateway:

Each region has its own Transit VPC with C8KV instances
Each region has its own TGW
TGW peering connects the two regional TGWs
IPsec/GRE tunnels connect each C8KV to the SD-WAN Manager
The SD-WAN Manager automates the entire peering configuration via API

For example, you might have workload VPCs in us-east-1 and us-west-2, each with their own Transit VPC and TGW, connected through TGW peering.

Region-to-Region with Cloud WAN

Cloud WAN simplifies region-to-region connectivity significantly:

Each region has a Transit VPC with C8KV instances
Instead of TGW peering, a Cloud WAN backbone segment provides native inter-region connectivity
Core Network Edge instances in each region handle the routing
The backbone segment eliminates the need for manual peering configuration

Site-to-Site Across AWS Global Network with TGW

This powerful use case leverages the AWS global network as backbone transport between enterprise sites in different geographies.

Example scenario: Enterprise sites in the United Kingdom (eu-west-2, London) connecting to enterprise sites in the United States (AWS Central US).

Architecture:

Transit VPCs with C8KVs deployed at AWS PoPs in both regions
TGW-to-TGW peering builds the backbone between regions
SD-WAN tunnels from enterprise sites terminate at the nearest Transit VPC
Traffic traverses the AWS backbone between regions

Key considerations:

Control policy or multi-region fabric is required for traffic redirection
The architecture provides global connectivity that is on-demand and high-performance

Site-to-Site Across AWS Cloud WAN

Cloud WAN elevates the site-to-site pattern with a more dynamic architecture:

Transit VPCs in each region connect to the Cloud WAN Core Network
The Core Network provides backbone segments for traffic isolation
You can define separate Production VRF and Test VRF segments within the Cloud WAN
This architecture is described as a high-performance, dynamic design

Pro Tip: When choosing between TGW and Cloud WAN for your AWS SD-WAN integration, consider that Cloud WAN provides built-in global backbone, native segmentation with VRFs, and simplified region-to-region connectivity. TGW is more established and may be preferred for single-region deployments.

SD-WAN Multicloud Integration with Azure

Azure integration leverages the Virtual WAN (vWAN) and Virtual Hub (vHub) constructs that are native to the Azure platform.

Site-to-Cloud with Azure vWAN

The Azure site-to-cloud pattern uses vWAN and vHub as the cloud-side networking backbone.

Architecture components:

vWAN: Azure's managed wide-area networking service
vHub: Regional hub within the vWAN that provides connectivity
Catalyst 8000V (C8KV): Deployed as a Network Virtual Appliance (NVA) within the vHub
Workload vNets: Virtual networks containing application workloads across subscriptions
vHub-to-vNet peering: Connects workload vNets to the hub

How it works:

C8KV Network Virtual Appliances are hosted directly in the vHub
The C8KVs run BGP with the vHub control plane to learn vNet route mappings
SD-WAN tunnels connect the vHub C8KVs back to enterprise sites
Route redistribution handles OMP-to-BGP and BGP-to-OMP translation
All configuration is automated through the SD-WAN Manager API

This is a clean integration because the C8KV sits inside the Azure-managed hub, getting native visibility into all peered vNets without additional routing complexity.

Site-to-Cloud with Azure (Meraki Integration)

For organizations using the Meraki SD-WAN platform, Azure integration follows a slightly different pattern:

vMX virtual appliances are hosted in a Transit vNet (not in the vHub)
Workload vNets connect to the Transit vNet via vNet peering
Azure Route Server (ARS) provides dynamic route exchange
eBGP sessions run between the vMX appliances and the ARS
SD-WAN tunnels connect back to enterprise sites and data centers

This transit vNet model provides flexibility for organizations that need to maintain separation between the SD-WAN overlay and the Azure-managed networking services.

Region-to-Region with Azure

Connecting workloads across Azure regions follows a straightforward pattern:

Each region (e.g., Azure East US and Azure West US) has its own vWAN with a vHub
C8KV NVAs in each vHub establish BGP peering with each other
Workload vNets in each region peer to their local vHub
The SD-WAN Manager automates the inter-region configuration via API

Site-to-Site Across Azure Global Network

Azure's global backbone can serve as transport between enterprise sites in different countries, similar to the AWS pattern.

Example scenario: Enterprise sites in the United States (Azure East US) connecting to sites in the United Kingdom (Azure UK South).

Architecture:

Each region has its own vWAN instance
C8KV NVAs in each vWAN terminate SD-WAN tunnels from local enterprise sites
SD-WAN tunnels with Azure public IPs on the NVAs traverse the Azure backbone
Control policy or multi-region fabric is required for traffic redirection

Key characteristics:

Global connectivity that is on-demand and high-performance
Leverages Azure's private backbone rather than the public internet
Provides consistent performance with Azure SLAs

Pro Tip: When deploying SD-WAN tunnels across Azure regions for site-to-site connectivity, the tunnels use Azure public IPs on the NVAs but the traffic itself traverses the Azure backbone network, not the public internet. This gives you the performance benefits of a private backbone with the flexibility of overlay networking.

SD-WAN Multicloud Integration with Google Cloud

Google Cloud integration centers on the Google Cloud Router (GCR) and the Network Connectivity Center, which provide the cloud-native routing and hub services.

Site-to-Cloud with Google Cloud

Architecture components:

Netops Project: Hosts the WAN VPC and Site-to-Cloud VPC containing the C8KV
Cloudops Project: Contains the Workload VPCs
Google Cloud Router (GCR): Provides dynamic routing within Google Cloud
Network Connectivity Center: Hub service with spoke connections
SD-WAN Manager: Orchestrates deployment via API

How it works:

The SD-WAN Cloud Hub (C8KV) is hosted on Google Cloud
It runs BGP from the service VPN to Google Cloud Routers to learn and advertise routes
The Network Connectivity Center connects multiple spokes (Spoke 1, Spoke 2) to the hub
SD-WAN tunnels connect the C8KV back to enterprise sites
Route redistribution handles OMP-to-BGP and BGP-to-OMP translation

The Google Cloud integration is distinctive because it uses the Network Connectivity Center as the central hub, with GCR providing the BGP routing plane.

Region-to-Region with Google Cloud

For multi-region deployments within Google Cloud:

A WAN VPC spans the regions (e.g., us-west4-a in Las Vegas, Nevada and us-east4-a in Ashburn, Virginia)
Workload VPCs and Site-to-Site VPCs exist in each region
The SD-WAN Manager automates the inter-region configuration via API

Site-to-Site Across Google Cloud Global Network

Google Cloud's backbone provides another option for site-to-site connectivity between geographically distributed enterprise sites.

Example scenario: Enterprise sites in the United States (us-central1) connecting to sites in Australia (australia-southeast).

Architecture:

WAN VPCs and Site-to-Site (S2S) VPCs deployed in each region
C8KV instances in each region
Google Cloud Router with Network Connectivity Center providing spoke connectivity (Spoke 1, Spoke 2)
SD-WAN tunnels from enterprise sites terminate at the nearest cloud gateway

Key insight: SD-WAN leverages the cloud service provider's backbone (Google NCC) to extend the SD-WAN fabric from any site to any other site. Control policy or multi-region fabric is required for traffic redirection, consistent with the AWS and Azure patterns.

How Does Cloud-to-Cloud SD-WAN Multicloud Connectivity Work?

One of the most complex yet valuable use cases is connecting workloads across different cloud providers. When your applications are distributed across AWS, Azure, and Google Cloud, you need reliable, secure connectivity between them.

Cloud-to-Cloud Over the Internet

In this architecture, the SD-WAN fabric extends between cloud environments over the internet.

Architecture:

AWS: Transit VPC with C8KV connects to the TGW via GRE/BGP, which peers with workload VPCs
Azure: vWAN vHub hosts the NVA, which connects to workload vNets via vNet BGP peering
Google Cloud: WAN VPC and Site-to-Cloud VPC host the C8KV, connecting to workload VPCs in the Cloudops Project
Internet: SD-WAN tunnels between the cloud gateways traverse the public internet
SD-WAN Manager: Centrally orchestrates all three cloud environments via API

Traffic flow:

A workload in AWS needs to reach a workload in Azure
Traffic reaches the C8KV in the AWS Transit VPC
The C8KV forwards traffic through an SD-WAN tunnel over the internet to the NVA in the Azure vHub
The Azure NVA delivers traffic to the destination workload vNet

This model provides cloud-to-cloud global connectivity that is on-demand and high-performance, with the SD-WAN overlay handling encryption, path selection, and policy enforcement.

Pro Tip: While cloud-to-cloud over the internet is the simplest deployment model, the internet path introduces variable latency and potential reliability concerns. For mission-critical inter-cloud traffic, consider the interconnect-based approach described in the next section.

SD-WAN Multicloud Connectivity via Carrier-Neutral Facilities

For organizations that require private, high-performance connectivity between clouds without relying on the public internet, carrier-neutral facilities such as Megaport and Equinix provide an ideal middle-mile solution.

Site-to-Multicloud via Megaport or Equinix

This architecture uses a colocation or PoP facility as the central interconnect point for reaching multiple cloud providers.

Architecture components:

Colocation/PoP: Physical presence at a Megaport or Equinix facility
C8KV: Deployed at the interconnect facility
SD-WAN Tunnel: First-mile connectivity from enterprise sites to the PoP
AWS Direct Connect: Private VIF connecting to Transit/Workload VPCs via Direct Connect Gateway (DXG)
Azure ExpressRoute: Private connectivity to Transit/Workload vNets via ExpressRoute Gateway and Microsoft Edge Router
Google Cloud Interconnect: Direct connectivity to GCR in Transit VPC and workload VPCs

How it works:

Enterprise sites establish SD-WAN tunnels to the C8KV at the colocation facility (first mile)
The C8KV connects to each cloud provider through their respective private interconnect services
BGP sessions exchange routes between the C8KV and cloud-native routers
Route redistribution handles OMP-to-BGP and BGP-to-OMP translation

This architecture gives you a single physical point of presence that provides private connectivity to all three major cloud providers simultaneously.

Fully Encrypted Site-to-Multicloud via Interconnect

For maximum security, a fully encrypted variant of the interconnect architecture adds encryption across every segment:

SD-WAN tunnels encrypt the first mile from enterprise sites to the PoP
The C8KV at the colocation facility connects to:
- AWS: Via DXG Private VIF to an Interconnect VPC, then through the TGW to workload VPCs
- Azure: Via ExpressRoute to the Microsoft Edge Router, through the vWAN/vHub to workload vNets
- Google Cloud: Via Interconnect to S2C VPC and workload VPCs
BGP provides dynamic route exchange across all segments
End-to-end encryption ensures data confidentiality even over private interconnect links

Site-to-Site via Equinix and Megaport

The interconnect facility can also serve as backbone transport for site-to-site connectivity between geographically distributed enterprise sites.

Example scenario: UK branches connecting to Australia branches through Megaport or Equinix PoPs.

Architecture:

London PoP: Equinix or Megaport facility with C8KV, terminating SD-WAN tunnels from UK enterprise sites
Sydney PoP: Equinix or Megaport facility with C8KV, terminating SD-WAN tunnels from Australian enterprise sites
The two PoPs connect through the interconnect provider's backbone
SD-WAN Manager automates the entire configuration via API

Cloud-to-Cloud via Megaport or Equinix

The most sophisticated interconnect use case connects workloads across different cloud providers through the carrier-neutral facility, bypassing the public internet entirely.

Architecture:

C8KV deployed at the SDCI (Software-Defined Cloud Interconnect) PoP with high availability (HA)
Three service VPN interfaces, one for each cloud provider
AWS: Service VPN 1 interface connects via DXG and Transit VIF to Transit Gateway and workload VPCs (172.31.0.0/16)
Azure: Service VPN 1 interface connects via ExpressRoute Gateway to vNets in vWAN (172.16.0.0/16)
Google Cloud: Service VPN 1 interface connects via Interconnect to GCR in Transit VPC and workload VPCs (192.168.0.0/16)
BGP sessions run between the C8KV and each cloud provider's native routing service
SD-WAN Manager automates the entire deployment via API

IP addressing example from the reference architecture:

Cloud Provider	Workload Subnet
AWS	172.31.0.0/16
Azure	172.16.0.0/16
Google Cloud	192.168.0.0/16

Pro Tip: The cloud-to-cloud via interconnect model provides the highest performance and most predictable latency for inter-cloud traffic. By deploying the C8KV with HA at the SDCI PoP, you get resilient connectivity to all three cloud providers through private links, with the SD-WAN Manager providing centralized automation and visibility.

Comparing SD-WAN Multicloud Design Patterns Across Providers

To help you select the right architecture for your environment, here is a comprehensive comparison of the integration patterns across all three cloud providers.

Site-to-Cloud Comparison

Feature	AWS	Azure	Google Cloud
Cloud Hub Service	Transit Gateway or Cloud WAN	vWAN / vHub	Network Connectivity Center
SD-WAN Router Location	Transit VPC	vHub (as NVA)	WAN VPC
Route Exchange	BGP with TGW or Core Network	BGP with vHub control plane	BGP with Google Cloud Router
Tunnel Type	IPsec/GRE (IKEv2)	SD-WAN tunnels	SD-WAN tunnels
Workload Connectivity	TGW-to-VPC attachment	vHub-to-vNet peering	NCC spoke connections
Account Separation	Netops / Cloudops accounts	Subscriptions	Netops / Cloudops projects

Region-to-Region Comparison

Feature	AWS (TGW)	AWS (Cloud WAN)	Azure	Google Cloud
Inter-Region Mechanism	TGW peering	Backbone segment	vWAN-to-vWAN BGP peering	WAN VPC spanning regions
Complexity	Moderate	Low	Low	Low
Native Segmentation	No	Yes (VRFs)	No	No

Site-to-Site Comparison

Feature	AWS	Azure	Google Cloud
Backbone	AWS global network	Azure backbone	Google NCC backbone
Traffic Redirection	Control policy or multi-region fabric	Control policy or multi-region fabric	Control policy or multi-region fabric
Performance	On-demand, high-performance	On-demand, high-performance	On-demand, high-performance

A consistent theme across all three providers is the requirement for control policy or multi-region fabric to handle traffic redirection in site-to-site scenarios. This is a fundamental SD-WAN design consideration regardless of which cloud provider serves as the backbone.

Security and Compliance in SD-WAN Multicloud Design

Security is not an afterthought in SD-WAN multicloud design; it is woven into every layer of the architecture.

Encryption and Tunnel Security

All SD-WAN tunnels use IPsec encryption by default, ensuring that data in transit is protected regardless of the transport (internet, cloud backbone, or private interconnect). The integration with AWS specifically uses IKEv2 IPsec/GRE tunnels between the Transit VPC C8KV and the Transit Gateway.

Multicloud Defense for Inspection

The architecture supports Multicloud Defense for security inspection both within and between cloud environments. This capability enables:

Traffic inspection at the cloud edge before it reaches workloads
Inter-cloud traffic inspection as data moves between providers
Consistent security policy enforcement across all cloud environments

Segmentation

Cloud WAN on AWS supports native segmentation with separate VRFs (e.g., Production VRF and Test VRF), allowing you to isolate traffic flows within the cloud backbone. This segmentation extends the SD-WAN fabric's existing segmentation capabilities into the cloud environment.

Centralized Policy Management

The SD-WAN Manager serves as the single point of policy definition and enforcement. Whether traffic flows from a branch to AWS, between Azure regions, or across clouds through an interconnect, the same policy framework applies. This eliminates the inconsistencies that arise when each cloud environment is managed independently.

Frequently Asked Questions

What is the fastest way to establish SD-WAN multicloud connectivity?

The automated multicloud networking workflow through the SD-WAN Manager achieves secure connectivity in minutes. The four-step process involves associating cloud provider accounts, discovering and tagging VPCs/vNets, creating a cloud gateway (C8KV) at the closest region, and building connections between workloads and the gateway. All configuration is handled via API, eliminating manual cloud-side setup.

Should I use AWS Transit Gateway or AWS Cloud WAN for SD-WAN integration?

Both options are fully supported. Transit Gateway is the more established option and works well for single-region or simple multi-region deployments. AWS Cloud WAN provides a built-in global backbone, native segmentation with VRFs (Production VRF, Test VRF), and simplified region-to-region connectivity through backbone segments rather than TGW peering. Cloud WAN also supports CONNECT (GRE) attachments in addition to IPsec.

How does route exchange work between SD-WAN and cloud providers?

Route exchange uses BGP as the common protocol between the SD-WAN C8KV and cloud-native routing services (TGW, Cloud WAN Core Network, Azure vHub, Google Cloud Router). The SD-WAN overlay uses OMP (Overlay Management Protocol), so route redistribution handles the translation: OMP-to-BGP for routes advertised toward the cloud, and BGP-to-OMP for routes learned from the cloud and advertised toward enterprise sites.

Can SD-WAN connect workloads across different cloud providers?

Yes. Cloud-to-cloud connectivity is a supported use case. You can connect workloads across AWS, Azure, and Google Cloud either over the internet (using SD-WAN tunnels between cloud gateways) or through carrier-neutral facilities like Megaport or Equinix (using private interconnect links). The interconnect approach provides more predictable performance and avoids internet variability.

What is the role of Megaport and Equinix in SD-WAN multicloud design?

Megaport and Equinix serve as carrier-neutral interconnect facilities where you can deploy C8KV instances to create a central connectivity hub. From a single PoP, you can establish private connections to AWS (via Direct Connect), Azure (via ExpressRoute), and Google Cloud (via Interconnect). This eliminates dependence on the public internet for inter-cloud and site-to-cloud traffic, providing higher performance and predictable latency.

Is control policy required for site-to-site connectivity across cloud backbones?

Yes. When using any cloud provider's backbone (AWS, Azure, or Google Cloud) for site-to-site connectivity between enterprise locations, control policy or multi-region fabric configuration is required for traffic redirection. This ensures that traffic from one enterprise site is correctly steered through the cloud backbone to reach the destination enterprise site rather than following default routing paths.

Conclusion

SD-WAN multicloud secure connectivity transforms the way enterprises connect their branches, campuses, data centers, and cloud workloads. Rather than managing each cloud provider's networking independently, the SD-WAN fabric provides a unified overlay that abstracts the complexity of AWS Transit Gateways, Azure vWAN, and Google Cloud Network Connectivity Centers into a consistent, automated workflow.

The key takeaways from this comprehensive guide are:

Two architecture options exist for cloud connectivity: direct access and interconnect-based access, each with distinct trade-offs for latency, security, and operational complexity
The four-step automated workflow (associate accounts, discover/tag resources, deploy cloud gateway, build connections) applies consistently across all cloud providers and achieves secure connectivity in minutes
Each cloud provider has native integration patterns: AWS uses TGW or Cloud WAN, Azure uses vWAN/vHub, and Google Cloud uses GCR with Network Connectivity Center
Cloud-to-cloud connectivity can be achieved over the internet or through private interconnect facilities like Megaport and Equinix
Site-to-site across cloud backbones is possible with all three providers but requires control policy or multi-region fabric for traffic redirection
Security is built in through IPsec encryption on all tunnels, Multicloud Defense for inspection, and centralized policy management through the SD-WAN Manager

Mastering these design patterns is essential for any network professional working with modern enterprise architectures. Whether you are preparing for a certification exam or designing a production multicloud network, understanding how SD-WAN integrates with each cloud provider's native services will set you apart.

Explore the SD-WAN courses available on NHPREP to build hands-on skills with these architectures and advance your career in cloud networking and security.