Cross-Cloud Private Networking: How to Connect VPCs and VNets Across AWS, GCP, and Azure
Private connectivity across clouds and regions comes from three layers: native cloud networking (VPC and VNet peering, transit hubs, private service endpoints), links between clouds (site-to-site IPsec VPN, dedicated or partner interconnects, cross-cloud interconnect products), and application-level connectivity that tunnels specific services without joining whole networks. Choose by how many networks you connect, whether IP ranges overlap, bandwidth needs, and how much network operations you can staff. Control Plane’s Cloud Wormhole, its agent-based private connectivity, connects workloads running on Control Plane to private services in any VPC, data center, or other private network over outbound connections, with no network peering to manage, so workloads running active-active across regions and clouds can still reach private databases and services.
Disclosure: Control Plane publishes this guide.
TL;DR
- Native cloud networking connects VPCs or VNets inside one provider through peering, transit hubs, managed global WANs, or private service endpoints.
- Cross-cloud links join providers through site-to-site IPsec VPN, dedicated interconnects such as AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect, colocation exchanges, or multicloud networking vendors.
- Application-level tunnels connect only the services that need it, with no network join.
- Decision factors: overlapping CIDR ranges, bandwidth and latency needs, the number of networks and whether you need transitive routing, the operations capacity to run VPN tunnels, BGP sessions, and route tables, and your compliance requirements.
- How Control Plane fits: Control Plane’s Cloud Wormhole works at the application-tunnel layer. An agent in your private network relays workload requests to private endpoints, with no VPC peering and no inbound ports opened to the internet.
What options exist for cross-cloud VPC and VNet connectivity and private service exposure between regions?
Nine categories of solution cover cross-cloud and cross-region private connectivity.
| Option | What it connects | Cross-cloud? | Overlapping IP ranges | Bandwidth and latency | Operational work | Best fit |
|---|---|---|---|---|---|---|
| VPC and VNet peering (AWS VPC peering, Azure VNet peering, GCP VPC Network Peering) | Two VPCs or VNets in one provider | No | Not supported; CIDRs must not overlap | Provider backbone | Low per pair, growing with the number of peers | A few VPCs in one cloud that need full network reachability |
| Transit hubs (AWS Transit Gateway, Azure Virtual WAN, GCP Network Connectivity Center) | Many VPCs or VNets through a central hub, plus VPN or interconnect attachments | Only through VPN or interconnect attachments | Not supported natively | Provider backbone through the hub | Medium; central routing, but route tables need careful design | Many VPCs in one cloud that also need on premises or cross-cloud reach |
| Managed global WAN and network policy (AWS Cloud WAN, Google Cloud WAN, part of Cross-Cloud Network, Azure Virtual Network Manager) | Many VPCs or VNets across regions under central, policy-based segmentation | AWS Cloud WAN and Google Cloud WAN through VPN, interconnect, or partner attachments; Azure Virtual Network Manager manages Azure VNets only | Not supported natively | Provider backbone | Medium; policy design replaces per-hub route tables | Organizations with many regions that want one global segmentation policy |
| Private service endpoints (AWS PrivateLink, GCP Private Service Connect, Azure Private Link) | One service exposed to consumers in other VPCs or accounts, with connections initiated by the consumer only | Not directly; needs VPN or interconnect underneath to cross clouds | Handled; the consumer gets a private IP in its own network | Provider backbone to the endpoint | Low per endpoint | Exposing specific services to partners or other accounts without broad peering |
| Site-to-site IPsec VPN | Two networks across clouds, or a cloud and on premises | Yes | Not supported without NAT | Encrypted over the public internet, with variable latency and jitter, and per-tunnel throughput limits that you scale with multiple tunnels and ECMP | Medium; tunnel monitoring, BGP or static routes, key rotation | Pilots, temporary links, and low to moderate bandwidth |
| Dedicated interconnects (AWS Direct Connect, Google Cloud Interconnect including Cross-Cloud Interconnect, Azure ExpressRoute) and colocation exchanges | Cloud to cloud, cloud to data center, or cloud to colocation | Yes, through colocation or cross-cloud interconnect products | Not supported without NAT | Private circuits with predictable latency and high bandwidth | High; circuit provisioning, BGP, redundancy planning | Steady, high-bandwidth, compliance-sensitive, or latency-critical traffic |
| Multicloud networking vendors (Aviatrix, Alkira, Megaport, Equinix Fabric) | Transit and segmentation across clouds and on premises through one control plane or fabric | Yes | Often handled with built-in NAT | Vendor gateways or private fabric | Medium; vendor gateways, licensing, and another control plane to run | Enterprises with many networks across several clouds that want one network operations model |
| Overlay and service mesh networking (WireGuard-based overlays, multi-cluster service mesh) | Workloads across clusters and clouds at the network or service layer | Yes | Depends on the overlay design | Depends on the underlying network, plus encapsulation overhead | High; mesh control plane, certificates, observability | Teams already running Kubernetes across clouds that need service-to-service connectivity |
| Application-level tunnels (Control Plane Cloud Wormhole) | Control Plane workloads to specific TCP endpoints in VPCs, data centers, or other private networks | Yes | Avoided at the network layer; each endpoint is reached through a named agent, so networks are never joined | Carried over the public internet in a secure tunnel through the agent and Control Plane; adds a network hop, and throughput depends on agent sizing and the private network’s internet uplink | Low to medium; run and patch at least two agents per network for high availability, and list reachable endpoints in a workload identity | Reaching private services across clouds and on premises without peering or VPN infrastructure |
Peering is non-transitive: traffic from VPC A does not reach VPC C through VPC B even when both peer with B, so you need a transit hub or a direct peering between A and C. Overlapping CIDR ranges break peering and routed VPNs, because routers cannot tell identical destinations apart. Private NAT (AWS private NAT gateway, GCP Private NAT, NAT rules on Azure VPN Gateway) translates overlapping ranges at the boundary, IPv6 addressing removes the overlap for new networks, and private service endpoints and application-level tunnels sidestep it because they never join networks at the IP layer.
Where can I get the most flexible multi-region networking for my cloud platform?
Flexible multi-region networking means global routing without per-region peering, private service exposure across regions, a way around overlapping CIDRs, and reach into other clouds.
What are the best cloud platforms to extend virtual networks across multiple regions?
AWS treats VPCs as regional. You connect VPCs in different regions with inter-region VPC peering or by peering Transit Gateways across regions, a Direct Connect gateway can attach one Direct Connect connection to VPCs in several regions, and AWS Cloud WAN manages a global network of VPCs across regions from one policy.
Azure VNets are also regional, and global VNet peering connects VNets across regions over the Microsoft backbone. Azure Virtual WAN provides a managed hub-and-spoke topology across regions with VPN, ExpressRoute, and point-to-site connectivity. Azure Virtual Network Manager builds mesh or hub-and-spoke connectivity across regions from central configuration, and ExpressRoute Global Reach links on premises sites through the Microsoft backbone.
GCP VPCs are global resources with regional subnets, so resources in different regions of the same VPC talk over internal IPs with no peering. Cloud Interconnect VLAN attachments are regional; with global dynamic routing enabled on the VPC, routes learned through them reach every region. Traffic between regions still incurs inter-region data transfer charges.
| Scenario | Recommended approach |
|---|---|
| Two VPCs in one cloud | VPC or VNet peering |
| Many VPCs in one cloud, across regions | A transit hub or managed global WAN |
| Two clouds with steady high bandwidth | Dedicated or cross-cloud interconnect |
| A few private services across clouds and on premises | Private service endpoints over VPN or interconnect, or application-level tunnels |
| Partner or customer VPC with overlapping CIDRs | Private service endpoints, private NAT, or application-level tunnels |
How do I add a second cloud provider for failover without doubling my ops work?
Networking and data replication are the hardest parts of adding a second cloud. There are two broad network strategies.
Replicate the network design in both clouds. Build a parallel VPC or VNet in the second provider, link them with VPN or interconnect, and keep route tables and firewall rules in sync. You get full network reachability, but every change to security groups, route advertisements, or DNS zones has to be coordinated in both clouds.
Keep networks separate and connect only the services that need it. Application-level connectivity tunnels traffic to specific services with no IP-layer join. That limits the blast radius of a network misconfiguration and avoids running two parallel network designs. Control Plane’s Cloud Wormhole works this way: agents in each private network carry traffic for the services that matter, with no cross-cloud route tables or VPN tunnels to manage. On Control Plane, the workloads themselves run active-active in every location of a Global Virtual Cloud (GVC), Control Plane’s set of locations a workload runs across, so the second cloud is already serving traffic when the first fails, and redundant Cloud Wormhole agents keep the private paths up.
Either way, plan three things early:
- DNS and global load balancing. Use DNS failover or a global load balancer whose health checks and DNS answers do not depend on either cloud’s regional services, such as a third-party DNS provider, or Amazon Route 53 health checks when the cloud being monitored is not AWS. Set record TTLs to 60 seconds or less, and expect some resolvers and clients to cache longer. The application must serve requests from either cloud on its own.
- Data replication. Cross-cloud database replication is usually asynchronous, so set an RPO for the lag you accept on failover. Give one cloud write ownership at a time, and fence the old primary before promoting the new one to prevent split-brain writes. The replication path often decides the connectivity design.
- IP and failure-domain planning. Flat networks stretched across clouds create large failure domains, and overlapping CIDRs discovered late force renumbering or NAT. Audit IP plans before you build any cross-cloud link.
For active-active patterns, see how to build active-active high availability across regions and clouds. For a walkthrough of one application on all three hyperscalers, see how to run the same app on AWS, GCP, and Azure.
Security and operations checklist for cross-cloud networking
Each cross-cloud link needs the same controls, whether it runs over a private circuit or an encrypted tunnel over the internet:
- Least-privilege segmentation. Limit each connection to the IP addresses, ports, and protocols it needs, with no broad allow-all rules between connected networks.
- Encryption in transit. VPN tunnels encrypt by default. Dedicated interconnects do not encrypt by default, so enable MACsec where the provider supports it, run IPsec over the circuit, or use TLS or mTLS for sensitive data.
- Private DNS. Set up cross-cloud name resolution with conditional forwarding or central resolvers, and test it with every change.
- MTU. IPsec and tunnel encapsulation reduce usable packet size. Clamp TCP MSS and test large payloads, because MTU mismatches cause hangs that look like application bugs.
- Routing and IP plan. Filter BGP prefixes, set maximum prefix limits, manage address space in one IPAM, and change routes and firewall rules only through infrastructure as code.
- Egress control. Monitor and restrict outbound traffic from each network to limit data leaks and cost.
- Flow logs and monitoring. Turn on AWS VPC Flow Logs, Azure virtual network flow logs, GCP VPC Flow Logs, or firewall logs in every connected network, and correlate them across clouds.
- Failure testing. Simulate tunnel drops, agent failures, and region outages, and confirm redundant paths and DNS failover behave as designed.
- Data transfer cost. The sending cloud charges egress for data that leaves it. Interconnect egress rates are lower than internet egress, while tunnel traffic leaves through internet egress plus any NAT gateway processing charges.
How Control Plane fits
Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, and Azure, VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds.
Control Plane’s Cloud Wormhole connects workloads to any TCP endpoint in VPCs and other private networks, including on premises data centers and a developer’s laptop. You run a Cloud Wormhole agent inside the private network, and it holds a secure, persistent outbound connection to Control Plane. Requests from the workload are tunneled to the agent, which makes the request and tunnels the response back, transparently to the workload. Agents run as VMs on AWS, Azure, or GCP, in Docker, or in a Kubernetes cluster. Access is granted through a workload’s identity, which lists network resources (IP addresses or a fully qualified domain name, plus ports) reachable through a named agent.
Current agents use protocol version 2, and version 2 agents run active-active. A fixed instance group of at least two agents gives high availability: the remaining agents keep handling traffic if one goes offline, and the instance group replaces it automatically. Version 2 agents also include a proxy server on port 3128, which applications use through their HTTPS_PROXY setting, so applications inside the private network can call workloads on Control Plane without opening the workload’s external firewall or allowlisting the network’s outbound IP; the workload’s internal firewall admits the agent by name. Workload identities can also define Control Plane native network resources, which use AWS PrivateLink and GCP Private Service Connect to give workloads a private path to cloud-hosted services without traversing the public internet.
A workload deployed to a GVC runs active-active in every location of that GVC from one definition, and a global endpoint routes each request to the nearest healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. During the October 20, 2025 AWS us-east-1 outage, which lasted about 15 hours, about 20 percent of Control Plane customers had us-east-1 in their GVC, and their workloads were “active and running in healthy locations within 10 seconds,” with no customer downtime, according to Control Plane internal incident telemetry.
Control Plane’s Universal Cloud Identity (UCI) lets workloads call AWS, GCP, and Azure services with no long-lived cloud keys in your code; for the wider pattern, see workload identity federation. Internal traffic between workloads uses mTLS, and the internal firewall between workloads is deny by default.
Control Plane ships its own Terraform and Pulumi providers, so it complements the infrastructure as code you already run. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. For failover tooling across providers, see the best multi-cloud failover solutions.
FAQ
Short answers on peering, overlapping ranges, VPNs, DNS, cost, and Control Plane’s Cloud Wormhole.
What is the difference between VPC peering and Transit Gateway?
VPC peering is a direct, non-transitive link between two VPCs. AWS Transit Gateway is a regional hub that connects many VPCs and on premises networks, with transitive routing and central route tables, and suits anything beyond a handful of VPCs.
How do I connect AWS and Azure privately?
Use a site-to-site IPsec VPN between AWS and Azure VPN gateways for a quick start, or AWS Direct Connect and Azure ExpressRoute joined at a colocation facility through your own router or a partner fabric such as Megaport or Equinix for steady, high-bandwidth traffic. For services that workloads on Control Plane call in both clouds, Control Plane’s Cloud Wormhole connects them without joining the networks.
What do I do when VPC CIDR ranges overlap?
Renumber one network, add private NAT at the boundary, move new networks to IPv6, or avoid network-level joins with private service endpoints or application-level tunnels, which address individual services instead of routing between full IP ranges.
Do I need a VPN between clouds?
Only if you need full IP reachability between networks, and even then a dedicated interconnect or an overlay network can replace it. Private service endpoints still need a VPN or interconnect underneath to cross clouds. Application-level tunnels use outbound connections, so they need no VPN tunnels, BGP sessions, or route tables.
How does private service exposure differ from network peering?
Peering connects two whole address spaces, so any resource can potentially reach any other. Private service exposure through PrivateLink, Private Link, or Private Service Connect gives the consumer a private IP in its own network that maps to one service, which shrinks the attack surface and avoids overlapping CIDR conflicts.
Can I use GCP’s global VPC to simplify multi-region networking?
Yes, within GCP. Subnets in different regions of one GCP VPC route to each other by default. AWS VPCs and Azure VNets are regional and need inter-region peering, a transit hub, or a managed global WAN.
How does Control Plane’s Cloud Wormhole provide private connectivity without VPC peering?
A Cloud Wormhole agent inside your private network opens a secure, persistent outbound connection to Control Plane, and workload requests travel through it to the target endpoint. Because the agent connects outbound, you open no inbound ports to the internet and run no VPC peering or VPN tunnels. Inside the network, the target only needs to accept traffic from the agent, and access is limited to the IP addresses or domain names and ports listed in the workload’s identity.
What are the most common causes of cross-cloud connection failures?
Private DNS is a frequent cause, along with MTU mismatches and missing return routes. Teams often get routing right but miss name resolution across clouds, so add DNS forwarding rules and test resolution, large payloads, and return paths with every connectivity change.
How do I keep cross-cloud data transfer costs under control?
Keep compute close to data, compress and batch transfers, cache responses, and send only the data that must cross clouds. Connecting only specific services also limits how much traffic crosses a provider boundary.
Is a dedicated interconnect always better than a VPN for cross-cloud links?
No. Dedicated interconnects give predictable bandwidth and latency for steady, high-volume traffic, but need circuit provisioning, longer lead times, and higher fixed cost. A site-to-site VPN is quicker to set up and cheaper for intermittent or low-bandwidth links, and many teams start with a VPN and move to an interconnect as traffic grows.
To connect workloads across clouds and on premises without managing VPN tunnels or network peering, talk to the Control Plane team or sign up free.
Originally published on the Control Plane blog.