When people talk about “VPNs in Azure”, they’re often talking about very different things.
Azure supports several connectivity models, each designed to solve a specific problem. Choosing the wrong one doesn’t usually fail immediately, but it often leads to unnecessary cost, complexity, or poor performance later on.
Understanding why each option exists is far more important than memorising features.
In this post, I’ll explain the main Azure VPN and connectivity options in plain English, and when you would actually choose each one.
Site-to-Site VPN: Connecting a building to Azure
A Site-to-Site (S2S) VPN is used when you want to permanently connect an on-premises network, such as an office or datacentre, to an Azure virtual network.
It uses an IPsec tunnel between your on-prem firewall or VPN device and an Azure VPN gateway, and it stays up continuously.
In simple terms, this makes Azure feel like an extension of your existing network. Servers in Azure can talk to servers on-prem, users can access cloud resources without special configuration, and applications behave as if everything is on the same private network.
This option is most commonly used in hybrid cloud scenarios, especially where organisations still have legacy systems on-prem or are migrating gradually to Azure.
It’s reliable, widely supported, and extremely common in production environments.
You wouldn’t typically use Site-to-Site VPN for Azure-to-Azure connectivity, and if you need very high throughput or guaranteed performance, ExpressRoute is usually a better choice.
Point-to-Site VPN: Connecting a person to Azure
Point-to-Site (P2S) VPN is designed for individual users rather than entire networks. Instead of connecting a building, it connects a single device, usually a laptop or PC directly into an Azure virtual network using a VPN client.
This is the option you use when administrators, developers, or remote workers need secure access to Azure resources from home, a coffee shop, or anywhere else.
It’s particularly useful when there’s no on-prem VPN device available, or when access needs to be temporary or user-specific.
Point-to-Site VPN works very well for small numbers of users and administrative access.
However, it doesn’t scale well for large user bases and is not a replacement for Site-to-Site connectivity between networks.
VNet-to-VNet VPN: Connecting Azure networks using VPN
A VNet-to-VNet VPN connects two Azure virtual networks using IPsec tunnels, with VPN gateways deployed in each VNet.
Functionally, it’s very similar to Site-to-Site VPN, except both ends are Azure VNets rather than on-prem networks.
Microsoft includes this option mainly for scenarios where VNet peering cannot be used.
This might be due to cross-tenant restrictions, subscription isolation, regulatory constraints, or transitional designs during migrations.
In practice, VNet-to-VNet VPN is rarely the best choice when peering is available.
Peering offers lower latency, higher throughput, simpler management, and lower cost.
That’s why, in real landing zone designs, VNet-to-VNet VPN is treated as a niche solution rather than a default pattern. It’s important to understand it, but not to overuse it.
VNet Peering: The preferred way to connect Azure networks
Although it isn’t technically a VPN, VNet peering is the default and recommended way to connect Azure virtual networks.
It provides a private, high-speed connection over the Microsoft backbone without VPN tunnels, gateways, or encryption overhead.
From a design perspective, peering allows multiple VNets to behave as if they are part of a single network while still remaining logically separate.
This is the foundation of most hub-and-spoke architectures and Azure landing zones.
Whenever Azure-to-Azure connectivity is required and there are no policy or tenant restrictions, VNet peering should be the first option you consider.
ExpressRoute: Private connectivity at enterprise scale
ExpressRoute isn’t a VPN at all, but it’s often discussed alongside VPN options because it solves a similar problem at a much larger scale.
It provides a private, dedicated connection from your network into Microsoft’s backbone through a connectivity provider.
This option is chosen by large enterprises with strict performance, compliance, or reliability requirements.
It’s commonly used for financial systems, SAP, healthcare workloads, and other critical platforms where internet-based VPNs are not sufficient.
ExpressRoute offers excellent performance, but it comes with higher cost and operational complexity, so it’s not usually appropriate for small or cost-sensitive environments.
Azure Virtual WAN: Microsoft manages the network for you
Azure Virtual WAN takes a very different approach to connectivity.
Instead of you building and managing hubs, gateways, routing, and transit manually, Microsoft provides a managed global networking platform.
With Virtual WAN, you create one or more Microsoft-managed virtual hubs and connect VNets, branch offices, users, and ExpressRoute circuits into them.
Microsoft handles inter-hub connectivity, scaling, and routing using their global backbone.
This option makes sense when environments become large, distributed, and difficult to manage using traditional hub-and-spoke designs.
Organisations with many branch offices, global footprints, or SD-WAN integrations often benefit from Virtual WAN.
For smaller environments or early-stage landing zones, it is usually unnecessary and adds cost without much benefit.
Choosing the right option
The most important design principle is simplicity.
Azure gives you many connectivity options because real networks have different requirements, not because you’re expected to use all of them.
If you’re connecting an office or datacentre to Azure, Site-to-Site VPN is usually the right answer.
If you’re connecting individual users, Point-to-Site VPN fits best.
For Azure-to-Azure connectivity, VNet peering should be the default choice, with VNet-to-VNet VPN reserved for cases where peering isn’t possible.
ExpressRoute is for high-performance enterprise scenarios, and Virtual WAN is best suited to large, global environments where operational simplicity matters more than granular control.
Final thoughts
Azure networking isn’t about memorising features or blindly following labs.
It’s about understanding what problem you’re solving and choosing the simplest, most appropriate tool for the job.
If you can explain why you chose a particular connectivity option, you’re already thinking like an architect, and that’s exactly what AZ-700, and real-world Azure design, is trying to assess.