One network across every cloud

AWS here, GCP there, Azure for that one acquisition — OpenVLAN stitches them into a single private mesh.

One subnet router per cloud, that's the whole diagram

A single small instance in each VPC or VNet advertises its routes into the tailnet. No transit gateway attachments, no peering matrices, no per-region hub deployment — approve each route once in the console and every node on the mesh can reach every cloud.

  • ✓Ten-minute deployment per cloud, starting with whichever you touch most
  • ✓Instance sizing is modest — it's routing, not concentrating all traffic
  • ✓Multiple routers per cloud for redundancy, active-passive by default
subnet routers — live
aws-produs-east-1 · 10.1.0.0/162 routesUP
gcp-produs-central1 · 10.2.0.0/162 routesUP
azure-euwest-europe · 10.3.0.0/162 routesUP
aws-stagingus-west-2 · 10.8.0.0/161 routeUP

Overlapping CIDRs stop being a project

Two clouds both claiming 10.0.0.0/16 used to mean a renumbering marathon. On the mesh, workloads keep their addresses and you address them by MagicDNS name instead — the name resolves to the right place regardless of which provider's range it lives in.

MagicDNS — cross-cloud names
orders.apiaws-prod · internal LB10.1.4.11RESOLVES
ml-train.gcpgcp-prod · GPU pool10.2.7.30RESOLVES
sap-eu.legacyazure-eu · lifted VM10.3.1.5RESOLVES

The multi-cloud mess

Transit gateway sprawl

Every cloud has its own hub-and-spoke tax — per-attachment pricing, per-region deployment, per-vendor console. Subnet routers replace the whole diagram with one overlay.

Public endpoints "temporarily"

Cross-cloud calls over the internet with IP allowlists are the usual shortcut. The mesh makes them private links with identity instead.

Overlapping CIDRs

Two VPCs both claim 10.0.0.0/16? The tailnet's 100.64.0.0/10 space and MagicDNS names sidestep the renumbering project.

Ephemeral everything

Autoscaled clusters join and leave constantly. Ephemeral nodes auth with short-lived tokens and clean themselves up.

Typical wiring

# one subnet router per VPC / VNet
$ openvlan up --advertise-routes=10.1.0.0/16 # aws-prod
$ openvlan up --advertise-routes=10.2.0.0/16 # gcp-prod
$ openvlan up --advertise-routes=10.3.0.0/16 # azure-eu
 
# approve once in the console; every node sees all three
$ ping 10.2.4.11 # from laptop, via aws subnet router → gcp

Subnet router guide →

Who runs this

Platform teams

One flat private network under every workload, whatever provider it landed on.

Ephemeral everything

Autoscaled clusters join and leave constantly; ephemeral nodes auth with short-lived tokens and clean themselves up.

Terraform-native

Subnet routers, ACLs, and node tags all manageable as code alongside your existing infrastructure definitions.

One IP space

The tailnet's dedicated range means no more spreadsheet diplomacy over which cloud owns which CIDR.

Public endpoints "temporarily"

Cross-cloud calls over the internet with IP allowlists become private links with identity instead.

No transit exposure

Cloud-to-cloud traffic never touches a public IP or a shared transit network you don't control.

Per-workload identity

Each router carries a tag-based identity; compromise of one node doesn't grant reach into the others.

Egress you can audit

Every cross-cloud flow is logged with source identity — a paper trail no transit gateway gives you.

Migrating estates

Move workloads cloud-to-cloud without a dual-network transitional phase for the apps.

M&A integrations

Connect the acquired company's cloud to yours privately, before the org merge finishes.

Lift-and-shift staging

Stand up the target environment and let both sides talk during the move; cut over when ready.

Hybrid permanence

Some workloads will never leave the data center — the mesh treats it as just another site.

Multi-cloud FAQs

Do I pay egress on cross-cloud traffic?
Your providers' egress rates apply as usual — the mesh doesn't change billing. But direct private paths often cost less than hairpinning through public endpoints or transit hubs, and identity replaces the allowlist maintenance entirely.
How many subnet routers do I need?
One per network you want reachable, plus a second for redundancy anywhere it matters. A typical three-cloud setup runs five small instances total.
What about latency between clouds?
Traffic flows cloud-to-cloud over direct paths — usually faster than the transit-gateway detours, since there's no regional hub in the middle. Same-region pairs frequently see sub-millisecond overhead.
Can this replace our Transit Gateway entirely?
For private connectivity, yes — most teams keep the transit gateway only for VPC-to-VPC flows they haven't migrated yet, then decommission it. Cloud-native services that require it (private endpoints, some peering configs) keep working alongside.
Does it work with overlapping IP ranges?
Yes — that's one of the strongest reasons to run this. Addresses stay as-is and MagicDNS names sidestep the collision; the renumbering project gets cancelled.

Your clouds, one tailnet

Deploy the first subnet router in about ten minutes.