Last year, I helped an e-commerce company review their architecture. They ran production on AWS, disaster recovery on Alibaba Cloud, and analytics on Google BigQuery. Sounded smart—multi-cloud, avoid lock-in, pick the best tool for each job.
But when I asked how they connected these clouds, the tech lead scratched his head: "Uh… just a site-to-site VPN over the internet. Data volume isn't huge."
I followed up: "What's your cross-cloud latency?"
He pulled up a dashboard and went quiet. AWS to Alibaba Cloud averaged 80ms, spiking to 200ms during peak hours. Data sync jobs timed out constantly. Disaster recovery drills? Never once succeeded—because the network never worked when they needed it.
This is the awkward truth about multi-cloud: the strategy looks great on slides, but it dies on the network.
Today, let's talk about cross-cloud communication. Not a "how to configure IPsec" tutorial, but a guide to help you decide: When should you use VPN, when should you pay for Direct Connect, and are those cloud interconnect products actually worth it?
01 The Three Ways to Connect Clouds
Here are your options, stripped of marketing fluff.
Option 1: Public internet VPN.
Cheapest, most common. You spin up two VM instances (one in each cloud), install IPsec software, and tunnel traffic between them. Pros: no extra cost beyond VMs and bandwidth. Cons: unstable, latency jitter, no bandwidth guarantees.
Option 2: Dedicated connections (Direct Connect, ExpressRoute, etc.).
AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, Alibaba Cloud高速通道. You lease a physical cross-connect from a network provider into the cloud provider's backbone. Pros: stable, low latency, SLA-backed. Cons: expensive, weeks to provision, complex setup.
Option 3: Third‑party SD‑WAN.
Services like Aryaka, Megaport, or PacketFabric build their own global network and let you connect clouds via their backbone. Pros: better than VPN, simpler than raw Direct Connect, unified management. Cons: another vendor, another bill.
No single winner—it all depends on your specific needs.
02 Myth #1: VPN Is Free – Did You Do the Math?
Most teams pick VPN because it looks "free." But run the numbers:
VM cost: You need instances on both sides, sized to handle encryption. IPsec is CPU‑hungry. That's a few hundred dollars a month, minimum.
Bandwidth cost: Public internet traffic is still metered by cloud providers. Cross‑region and cross‑continent bandwidth adds up fast.
Operations cost: Who fixes the tunnel when it drops? Who troubleshoots route flapping? When you get paged at 3 AM, is that still "free"?
I once worked with a startup that used VPN to save money on Direct Connect. Their data sync failed every day, and two engineers rotated on‑call to restart jobs. After three months, they did the math: the time they spent on VPN babysitting was worth more than the Direct Connect fee.
Counter‑intuitive truth: VPN can be the most expensive option—you just don't see the cost on an invoice.
03 Myth #2: Direct Connect Is Always Faster
This one sounds logical—private line, no internet congestion, of course it's faster.
Not necessarily.
Direct Connect routes traffic through the cloud provider's backbone, but that backbone might not be geographically optimal for your path. Your traffic could hairpin through a distant regional hub before reaching the destination. Meanwhile, the public internet—after decades of optimization—sometimes finds a shorter route.
Real data point: A Shanghai‑based company measured latency to AWS Tokyo. Over the public internet, average ping was 45ms. Their Direct Connect path? 55ms—because the circuit first hauled traffic to Beijing before crossing to Japan.
Lesson: Never assume. Test before you commit. Most cloud providers offer test IPs. Ping them for two weeks, collect P95 and P99, then decide.
04 Myth #3: Cloud Interconnect Products Solve Everything
AWS has Transit Gateway, Alibaba has CEN, Azure has Virtual WAN. These are powerful tools—but they're designed for single‑cloud networking. Cross‑cloud is an afterthought.
Here's what they actually do:
Transit Gateway lets you connect hundreds of VPCs inside AWS and route between them.
CEN does the same inside Alibaba Cloud.
But when you need to reach another cloud, you're still on the hook for the physical link. TGW doesn't magically create a tunnel to Azure. You still need VPN or Direct Connect for that last mile.
These products simplify intra‑cloud routing, not inter‑cloud connectivity. Don't buy them thinking they'll solve cross‑cloud.
05 So How Do You Choose?
Here's a decision framework that's saved my clients from expensive mistakes.
Step 1: Characterize your traffic.
Occasional batch sync, latency‑tolerant? VPN is fine.
Real‑time API calls (e.g., cross‑cloud database reads)? You need Direct Connect or SD‑WAN.
Disaster recovery? Absolutely go with dedicated links—you never want failover to fail because the network dropped.
Step 2: Consider distance and geography.
Same region (e.g., both clouds in Virginia)? Local Direct Connect can give you <2ms latency.
Cross‑region but same continent? Test internet first—it might surprise you.
Cross‑continent? Internet latency is high but predictable; Direct Connect might shave 20–30ms, but at a cost.
Involving mainland China? Compliance gets tricky—dedicated links must use approved跨境 channels.
Step 3: Look at your budget and team.
Low budget, strong networking team? VPN + BGP dynamic routing can be surprisingly robust.
Medium budget, want less ops? Consider managed SD‑WAN.
High budget, mission‑critical? Dual Direct Connect + BGP for automatic failover.
06 Advanced: BGP + Dual Links for HA
If your cross‑cloud traffic is business‑critical, you can combine VPN and Direct Connect using BGP.
Set up two tunnels: one over VPN, one over Direct Connect. Run BGP on both, advertising the same prefixes. BGP will prefer the Direct Connect path (shorter AS path). If the Direct Connect fails, BGP automatically switches to VPN. When it recovers, traffic shifts back.
This gives you automatic failover without waking up at 3 AM. Configuration is complex, but once it's running, it's rock solid.
07 Three Questions to Ask Yourself
Before you pick any option, ask:
Does it really need to be real‑time?
Many cross‑cloud use cases can be asynchronous: message queues, event buses, batch replication. If you can decouple, you might not need low‑latency networking at all.Have you measured actual latency and loss?
Don't trust published numbers. Spin up instances, run ping and traceroute for two weeks. Networks are black magic—data beats theory.What's the five‑year TCO?
Direct Connect has installation fees, recurring port charges, and egress costs. VPN has instance costs and human overhead. Spreadsheet both over five years. The answer might surprise you.
Back to that e‑commerce company. We redesigned their network: core transactions over Direct Connect, analytics over VPN, BGP gluing them together for failover. Cost doubled, but incidents dropped from weekly to zero.
The tech lead later told me: "I used to think networking was 'just make it work.' Now I realize—choose the wrong network architecture, and everything else is just a patch."
Multi‑cloud isn't the goal; stability is. The network is what holds your clouds together. Choose wisely, and it's invisible. Choose poorly, and you'll be firefighting forever.
How stable is your cross‑cloud glue today?
