Azure Site-to-Site VPN and ExpressRoute Implementation

For most SMB and mid-market workloads — office-to-Azure access, administration, file and application traffic — a properly designed VPN is enough, and it is a fixed $2,450 delivered in a week. ExpressRoute earns its monthly circuit cost in specific circumstances: latency-sensitive workloads, sustained heavy data movement, or compliance requirements that mandate traffic never touching the public internet. The comparison table on this page is the same logic we use on scoping calls, and if you do not need ExpressRoute we will tell you exactly that.

The complete single-site Site-to-Site VPN: design document, Azure VPN gateway on a current zone-redundant SKU, local network gateway and connection configuration, IPsec/IKE policy matched to your firewall, BGP or static routing, a working session with your firewall administrator to configure the on-premises end, failover validation, a latency/throughput baseline, and as-built documentation with a runbook. Excluded and stated plainly: carrier charges, Azure's own gateway and bandwidth charges, multi-site topologies, and ExpressRoute — the latter two are quoted.

No, and we will not pretend it works that way. Multi-site connectivity is a routing design problem: how sites reach Azure and each other, whether BGP propagates routes or static tables are maintained, and at some site count whether Azure Virtual WAN is the more honest architecture. We quote multi-site work from the actual topology — often it is less than three times the single-site price, sometimes the right answer is a different design entirely.

The Azure-side work is measured in days; the circuit is measured in weeks. Provisioning runs through your connectivity provider — contract, physical or logical circuit delivery, then provider-side configuration — and that lead time belongs to the carrier, not to us or Microsoft. The pattern we recommend when timing matters: deploy the Site-to-Site VPN now, run production over it, and cut over to ExpressRoute when the circuit is delivered, keeping the VPN as the failover path afterward.

Yes — that coordination is a deliverable, not a favor. We bring exact parameters to a working session with your firewall administrator or vendor: IKE version, encryption and integrity algorithms, DH groups, lifetimes, and traffic selectors, matched to what your device supports. Both ends get configured by people in the same conversation, and both ends' final settings land in the as-built documentation.

Any device capable of route-based IPsec — which covers current firewalls from the mainstream vendors — with IKEv2 preferred. Microsoft publishes validated-device guidance and we confirm your specific model and firmware during scoping. Where a device is old, policy-based-only, or lacks BGP support, we say so up front: sometimes the design adapts, and sometimes the honest recommendation is to fix the firewall first.

BGP where your device supports it: routes propagate automatically, failover converges without human intervention, and adding networks later does not mean editing route tables on both ends. Static routing is perfectly serviceable for a stable single-site topology and remains fully supported in the design — the decision is made explicitly during design, based on your device and how much your network changes, not by default.

Our fee is one-time. Ongoing costs are Microsoft's meters on your subscription: VPN gateway hours for the SKU we deploy, plus standard bandwidth charges for traffic leaving Azure. The design includes an estimate against Microsoft's current price list for your expected usage — we deliberately do not print gateway prices on this page because Microsoft revises them, but you will have the number in writing before you approve the design.

Layers, chosen deliberately in design. The gateway itself deploys on a zone-redundant SKU, so Microsoft's platform survives zone-level failures. The tunnel is validated for re-establishment after interruption — we test it rather than assume it. Beyond that, options scale with your needs: redundant tunnels to a second on-premises device, active-active gateway configurations, and ultimately ExpressRoute with VPN failover. The design states which layers you are getting and which you declined, so resilience is a documented decision.

The Azure-side build touches nothing on-premises, so it is invisible to users. The on-premises change is the firewall configuration session — new tunnel configuration on an existing device, which on modern firewalls does not interrupt other traffic. If we are replacing an existing improvised VPN, cutover is sequenced in a maintenance window with the old path kept as rollback until the new one is validated.

No — that is point-to-site VPN or, increasingly, no VPN at all: identity-based access through Entra and Conditional Access often serves remote workers better than network tunnels. This engagement connects networks to networks. If remote-user access is part of your picture, raise it on the scoping call and we will point at the right pattern honestly, including when it is not a VPN.

The runbook is written for exactly that moment: health checks to run, the usual causes in order of likelihood, and what to restart or re-key on each end. Operating the connection is yours after handover by design — no forced retainer. If you want someone watching it instead, our Azure Resource Monitoring and Maintenance service covers the connection as part of the monitored estate, as a separate, explicit engagement.