In today’s digital landscape, many organizations are increasingly adopting multicloud strategies, leveraging the strengths of multiple cloud providers to achieve flexibility, redundancy, and global reach. This typically includes Microsoft Azure, but also extends to Amazon Web Services (AWS), Google Cloud Platform (GCP), Oracle Cloud Infrastructure (OCI), and others.

Managing multiple clouds introduces a variety of challenges—governance, security, identity, application architecture, data placement, operations, and DevOps—that must all be considered in tandem. In this article, however, we’ll focus specifically on network connectivity within and between clouds, while keeping in mind that a complete multicloud strategy also requires consistent governance and unified security management.

Networking in Azure

In Azure, the Virtual Network (VNet) is the foundational building block for network deployment. Each VNet:

• Exists within a specific Azure subscription and cannot span subscriptions.

• Resides within a single Azure region, meaning it cannot span across regions.

• Is defined by one or more IPv4 address ranges, and optionally, IPv6 ranges.

You deploy resources such as virtual machines (VMs), containers, and services into this virtual network. Many Azure resources are not inherently part of a VNet, yet you can integrate them for private connectivity—bypassing public endpoints and reducing exposure to the internet.

Subnets and Integration

A VNet is divided into subnets, where resources are deployed. There are two main ways to integrate Azure services into your VNet:

1. Delegated Subnets – Certain Azure services (like databases) can be deployed into a subnet that has been delegated to that specific service. This allows private IP-based access from within the VNet.

2. Private Endpoints – These are specialized network interfaces that connect to Azure PaaS services privately, assigning an IP address from your subnet. This enables secure, private connectivity to specific service instances.

In both cases, IP-based connectivity extends to services outside the VNet while maintaining private, secure access.

DNS Resolution and Security

DNS resolution plays a critical role in connectivity. Since most connections use TLS encryption, proper name resolution is essential so that DNS names match TLS certificates. Azure provides Private DNS Zones and supports conditional forwarding to ensure smooth resolution across connected VNets and on-prem environments.

Hybrid Cloud Connectivity

Most organizations already operate in hybrid environments, combining on-premises infrastructure with cloud services. When connecting on-prem networks to Azure, there are two main types of connectivity:

1. Public Connectivity

2. Private Connectivity

The Microsoft Global Network

Microsoft operates a vast global backbone network that interconnects all Azure regions.

• Over 165,000 miles of fiber optic and undersea cables connect more than 60+ Azure regions.

• There are 185+ global network points of presence (PoPs), also known as carrier-neutral facilities, that allow Microsoft to interconnect with other networks and the public internet.

This global network is used for both public and private connectivity to Azure services.

Private Connectivity: ExpressRoute

For private, high-performance connections, Azure provides ExpressRoute.
Here’s how it works:

• Organizations connect from their on-premises datacenter to a point of presence (PoP) where Microsoft’s global network is accessible.

• A carrier or service provider facilitates this connection and establishes a cross-connect to Microsoft’s routers within the PoP.

• An ExpressRoute Gateway is deployed in your Azure VNet to manage traffic between the two environments.

Each ExpressRoute circuit consists of two physical connections for resiliency—connected to different routers in the same facility. For even greater reliability, ExpressRoute Metro connects through two different buildings within a city, reducing the risk of total failure from a single site outage.

For organizations with strict uptime requirements, having multiple ExpressRoute circuits in geographically separate PoPs is recommended.

Public Connectivity: Site-to-Site VPN

An alternative (or backup) to ExpressRoute is a site-to-site VPN.

• It uses an encrypted tunnel over the public internet between an on-premises VPN device and an Azure VPN Gateway.

• While simpler and cheaper, this approach introduces higher latency, jitter, and variable performance, making it unsuitable for critical production workloads.

• However, it can serve as a failover connection for ExpressRoute.

Connecting Multiple Virtual Networks

Since VNets are limited to individual regions and subscriptions, enterprises typically have many VNets across their environment. To avoid complexity, Azure supports:

• VNet Peering – Directly connects VNets for seamless routing, provided IP address ranges don’t overlap.

• Hub-and-Spoke Topology – A centralized hub network connects to multiple spoke VNets. The hub hosts shared services (DNS, firewalls, gateways) and external connectivity.

• Azure Virtual WAN – A managed networking service that simplifies connectivity at scale by automating hub creation and route management.

• Azure Virtual Network Manager – Enables mesh connectivity or centralized route management across multiple VNets.

This model ensures efficient, scalable interconnection between VNets and on-premises resources.

Extending Connectivity to Other Clouds

Now that we’ve covered Azure and hybrid connectivity, let’s examine multicloud interconnectivity—connecting Azure to other cloud providers like AWS, GCP, or OCI.

Every major cloud provider has an equivalent networking model:

• AWS: Virtual Private Cloud (VPC)

• GCP: Virtual Private Cloud (VPC)

• OCI: Virtual Cloud Network (VCN)

Just like Azure, these networks can connect to the internet or to private connectivity solutions.

VPN Connectivity Between Clouds

A straightforward method of connecting Azure to another cloud is through site-to-site VPN.

• Each cloud deploys a VPN gateway and establishes an encrypted tunnel over the internet.

• This provides secure connectivity but suffers from latency, bandwidth limits (typically up to 1 Gbps), and variable performance.

It’s a practical but not optimal solution for high-performance, low-latency workloads.

Private Connectivity Between Clouds

Each major cloud also offers private connectivity services similar to Azure ExpressRoute:

• AWS Direct Connect

• Google Cloud Interconnect

• Oracle FastConnect

All of these connect to carrier-neutral facilities (PoPs), often the same ones used by Microsoft, allowing cross-cloud interconnectivity within the same city or metro region.

The guiding principle:
Choose geographically close regions (e.g., Azure London and AWS London) to minimize latency.
Traffic flows from each cloud’s internal network to the shared PoP, through cross-connects, and then into the corresponding virtual networks.

Connection Options

There are two main approaches to establishing private cloud-to-cloud connections:

1. Direct Connections (Dedicated)

   • Using services like ExpressRoute Direct, you manage your own routers and connections.

   • Offers up to 100 Gbps of bandwidth and full BGP routing control.

   • Suitable for large enterprises comfortable managing network hardware.

2. Cloud Exchange Providers

   • Simplified connectivity via colocation providers such as Equinix, Megaport, or others.

   • They manage the complex routing and cross-connects for you.

   • Ideal for organizations wanting managed multicloud interconnectivity.

You can also configure VPN connections as backups to private links for additional resilience.

Special Case: Azure–Oracle Interconnect

Microsoft and Oracle jointly offer the Oracle Interconnect for Azure, which combines ExpressRoute and FastConnect with region-paired PoPs. This setup delivers exceptionally low latency—for example, between Azure London and OCI London.

Performance and Optimization

To further optimize performance:

• Enable ExpressRoute FastPath, which allows traffic to bypass the gateway and go directly to resources in peered VNets.

• Maintain consistent DNS resolution for encrypted connections (e.g., via conditional forwarding and private DNS zones).

• Always implement redundancy—multiple circuits in separate PoPs—to avoid single points of failure.

Security, Governance, and Monitoring

While this article focuses on networking, multicloud connectivity must always include:

• Centralized security monitoring – Aggregate all signals (logs, metrics, alerts) into one platform for unified visibility.

• Consistent governance – Azure Arc can extend governance, policy, and compliance across other clouds and on-prem environments.

• Identity management – Ensure consistent authentication and access controls across all connected environments.

Conclusion

Multicloud connectivity doesn’t rely on hidden technologies or “magic” links—it’s built on practical networking principles. Whether connecting Azure to on-premises or Azure to AWS, GCP, or OCI, you have two main options:

1. Encrypted VPN over the public internet – Simple but limited by speed and latency.

2. Private connectivity through dedicated circuits – More complex but offers enterprise-grade performance and reliability.

No matter which method you choose, the fundamentals remain the same:
plan for redundancy, ensure consistent DNS and governance, and maintain visibility across all clouds.

That’s the essence of multicloud networking—a robust, resilient architecture that bridges platforms while maintaining security and control.