When a growing business moves resources into AWS, Azure, or GCP, the question of how the office actually reaches them is rarely framed as an architecture decision. It should be. The cheap answer — a site-to-site VPN over the internet — works well, until the day it does not. The expensive answer — Direct Connect or ExpressRoute — is sometimes justified and sometimes a five-figure-a-month mistake. Here is how we think through it.
Most office-to-cloud connectivity is the product of an incremental decision. The first time someone needs to reach an EC2 instance from the office, they spin up a site-to-site VPN. It works. Time passes. More resources move into the cloud. Backups start running across that tunnel at 3 AM. A line-of-business app gets hosted there. The VPN is now carrying production traffic that nobody planned for it to carry, and the architecture question quietly becomes: do we keep accumulating workarounds, or design this properly?
This article walks through the three architectures we routinely evaluate with customers — and the questions that decide which one fits.
The phrase covers more than the obvious case. When a growing business has workloads in AWS, Azure, or GCP, the office may need to reach:
In each case the underlying question is the same: how does traffic from the office network reach a private cloud network, securely and reliably, without being exposed on the public internet?
The default. The office firewall opens an IPsec tunnel to the cloud provider's VPN gateway. Once the tunnel is up, the office LAN can reach the private cloud subnets as if they were on the other end of a long Ethernet cable.
Strengths. Cheap — often free apart from a small cloud-side gateway charge. Fast to deploy: hours, not weeks. Works with the existing firewall in nearly every case. Encrypted end-to-end without depending on the cloud provider's edge.
Weaknesses. Performance is whatever the public internet is doing. Latency can spike, throughput can drop, and you have no SLA on the underlying transport. A single tunnel on either side is a single point of failure unless you build redundancy in. The encryption cost on the office firewall becomes meaningful at higher throughput — tens of megabits is fine on a modest firewall, hundreds need a bigger box.
For most SMBs running modest cloud workloads — internal apps, backups, identity, the occasional database query — this is the right answer. The honest answer to "do we need something more?" is usually "not yet."
SD-WAN treats the office and one or more cloud regions as nodes in a software-defined overlay. The vendor (Fortinet, Palo Alto, Cisco Meraki, Versa, Aruba EdgeConnect, and others) provides a cloud-resident edge — sometimes as a vendor-managed point of presence, sometimes as a virtual appliance you run in your own VPC — and the overlay handles routing, path selection, and policy across the whole network.
Strengths. Multiple internet paths can be aggregated and used together; if one degrades, traffic shifts. Policy follows the application rather than the transport — voice gets one treatment, bulk gets another. One management plane covers the office WAN, the cloud edge, and any other sites in the same overlay. Failover between paths is usually seconds, not minutes.
Weaknesses. Vendor lock-in is real — the cloud-edge model is proprietary, and you cannot mix vendors. Licensing is per-site and per-feature, and it adds up. The underlying transport is still the public internet; SD-WAN makes it usable, it does not give you SLAs you did not already have. Operational complexity is higher than a basic VPN, and the team running it needs to understand the overlay's failure modes.
SD-WAN earns its cost when you have multiple sites talking to multiple cloud regions, when the application mix justifies application-level policy, or when you already operate it for other reasons and adding a cloud region is the natural next step.
A private circuit between the customer's network and the cloud provider, terminated at a colocation facility where the cloud provider has a presence. Traffic does not traverse the public internet at all. The product names vary by provider (AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect) but the architecture is the same.
Strengths. Predictable performance — latency, jitter, and bandwidth are governed by the carrier and the cloud provider, not by the public internet. Throughput scales to gigabits or tens of gigabits without the crypto overhead that a VPN imposes on a firewall. Compliance and security teams like it because production traffic does not touch the public internet. Long-lived, stable connections suit backups, replication, hosted desktops, and database access.
Weaknesses. Expensive. Both the cross-connect cost at the colocation facility and the cloud-provider port charges are non-trivial — budget several thousand dollars per month minimum, often more, depending on bandwidth, region, and whether you use a carrier reseller. Requires presence at a colocation facility that the cloud provider serves; if your office is not close to one, you need a carrier circuit to reach the colo, which adds cost and complexity. Lead times are weeks, not days. And a single circuit is still a single point of failure — true resilience means two circuits in independent paths, which roughly doubles the bill.
Direct connect is the right answer when there is sustained, predictable, high-throughput traffic to the cloud — replication, large-scale backups, real-time analytics, hosted desktops — or when regulatory or contractual requirements forbid the public internet for production data.
None of the three options is universally correct. The choice tends to be driven by a small set of unglamorous questions:
A useful mental model for where most SMBs sit:
Stage 1 — small SMB, single cloud presence. A single site-to-site VPN, with documented manual failover (or a second tunnel through a different ISP). Ninety-five percent of small businesses live here, and most should stay here for longer than they expect.
Stage 2 — multiple sites, multiple cloud regions. The VPN topology evolves into hub-and-spoke or full-mesh, typically managed through the cloud provider's transit fabric (AWS Transit Gateway, Azure Virtual WAN, GCP Network Connectivity Center). SD-WAN becomes a serious candidate when the application mix justifies it or when the team already runs it for the office WAN.
Stage 3 — sustained high-throughput, latency-sensitive, or regulated. Direct Connect / ExpressRoute / Interconnect, usually with redundant circuits for resilience, often paired with a VPN as a backup path. By this stage the cost is real and so is the justification for it.
The progression to Stage 2 happens when the business decides to be cloud-first. The progression to Stage 3 happens when a specific workload demands it — not when a vendor sells it.
A site-to-site VPN is not a sign of immaturity. For most SMBs it is the right call for a long time.
A connection-layer choice is also a resilience choice. Before signing off on any of the three architectures, walk through the same questions we would for any redundant design:
The cheap site-to-site VPN with a tested failover to a 4G backup link will, on the average bad day, outperform the expensive Direct Connect setup with no tested resilience.
Cloud-to-office connectivity is rarely about choosing the most sophisticated option. It is about matching the architecture to the actual traffic, the actual operational team, and the actual cost of an outage. A site-to-site VPN is not a sign of immaturity — for most SMBs it is the right call for a long time. SD-WAN is not always the answer just because it is fashionable. Direct Connect is not always the answer just because it is the most expensive. The right architecture is the one justified by what the business needs to do, today and a year from now — and the one the team running it can confidently operate when it matters.