Start with the one-sentence idea, then build the picture slowly.

Azure VPN Gateway is a managed Azure service that sends encrypted traffic between an Azure virtual network and another network, or between an Azure virtual network and individual computers, across the public internet. The other network might be your office, your own data center, another Azure network, or even another cloud provider.

Let us explain the words. A network is a group of computers that can talk to one another. A virtual network, often shortened to VNet, is your own private network inside Azure, where you place servers, databases, and other resources. An on-premises network is a network that lives in your own buildings, such as an office or a server room. The word hybrid describes a setup that uses both on-premises and cloud resources together.

A VPN, short for virtual private network, creates a private, protected path across a public network. Encryption scrambles the data so that anyone who catches it on the way sees only nonsense. A gateway is a special device or service that sits at the edge of a network and controls the traffic going in and out. Put together, a VPN gateway is a guarded door that creates encrypted tunnels.

With Azure VPN Gateway, Microsoft runs the gateway machines for you. You choose the size and the settings, and Microsoft handles the underlying servers, their updates, and their replacement if something breaks. You do not log in to those machines.

To see why VPN Gateway helps, look at how people joined networks before.

Before the cloud, a company’s computers lived in its own buildings. When a second office opened, the company needed to connect the two. One choice was to rent a private line from a telephone company, a dedicated wire between the offices. It was reliable and private, but it was expensive and slow to arrange, sometimes taking weeks or months.

The internet is cheap but public

The internet already connected everything, and it cost much less than a private line. The problem was safety. Data on the public internet passes through many companies’ equipment. Without protection, it can be read or changed on the way. Sending business secrets openly across the internet was not acceptable.

The rise of the VPN

The VPN solved this. By adding encryption and checks on both ends, companies could use the cheap public internet as if it were a private line. For years, firms bought special hardware boxes, placed one in each office, and configured them to form tunnels. These boxes needed space, power, updates, and skilled people.

Then came the cloud

When companies began placing servers in Azure, they faced the same question again: how do the office computers talk safely to the servers in the cloud? A secure link was needed between the company’s network and its Azure virtual network. Buying and shipping a hardware box into a cloud data center is not possible. A cloud-based gateway is the answer.

Remote work adds another need

Besides joining whole networks, people also need to connect single computers, such as a worker’s laptop at home or in a café, to the company’s Azure resources. Doing this safely without exposing servers directly to the internet is another job for a VPN gateway.

Every service exists because someone had a painful problem. Here are the main ones.

A quick start for migrations

When a company starts moving workloads to Azure, it often needs a link within days, not months. A VPN gateway can be created in under an hour or so, and the on-premises side needs only a compatible VPN device or software. This makes it an ideal first step in a cloud journey.

A backup for a better link

Companies with an ExpressRoute private line often add a VPN as a backup. If the private line fails, traffic flows through the VPN. The VPN is slower but keeps the business running. Both can exist side by side on the same virtual network, as described in Chapter 14.

Connecting without opening the front door

Without a VPN, administrators who need to reach a server in Azure might open it to the whole internet, which invites attacks. With a VPN, the server can have only private addresses, and the administrator reaches it through the tunnel. This shrinks the attack surface greatly.

Ten building blocks. Learn these and the rest becomes easy.

Virtual network gateway

The virtual network gateway is the Azure resource that is the VPN gateway itself. Behind the scenes it consists of two or more virtual machines that Microsoft manages. These machines do only one job: handling VPN traffic.

Gateway subnet

A subnet is a smaller slice of a virtual network’s address space. The gateway must be placed in a special subnet that must be named GatewaySubnet. Nothing else should live there. It needs enough addresses for the gateway machines, and Microsoft recommends a reasonably roomy size so you can grow, so check the current guidance.

Local network gateway

The local network gateway is an Azure resource that represents the other side of the tunnel. It stores the public address of your on-premises VPN device and the list of private address ranges that live behind it. It is a description, not a real machine. Azure uses it to know where to send the tunnel and which traffic belongs inside it.

Connection

A connection is the Azure resource that links a virtual network gateway to a local network gateway, or to another virtual network gateway. It holds the shared key and settings such as the type of tunnel and the security policy.

Shared key

The shared key, sometimes called a pre-shared key, is a secret text that both ends know. It lets each side prove it is the right partner. It must be long, random, and kept private.

Public IP address

The gateway needs a public IP address, which is the address on the internet where the other side sends its tunnel requests. The type of public address required has changed over time, so check the current rules for your gateway size.

IPsec and IKE

IPsec is a family of rules for encrypting and protecting data packets. IKE, short for Internet Key Exchange, is the process in which the two ends meet, agree on the rules, prove who they are, and create fresh secret keys. Azure supports IKE version 1 and version 2 for site-to-site tunnels, and version 2 is generally preferred.

BGP

BGP, the Border Gateway Protocol, is a way for networks to tell each other automatically which address ranges they can reach. With BGP, routes are learned and updated automatically instead of typed in by hand.

SKU

A SKU is the size and capability level of the gateway, such as its speed, number of tunnels, and features. Bigger SKUs cost more.

Route-based and policy-based

The VPN type says how the gateway decides which traffic goes into a tunnel. Route-based gateways use routing tables, and policy-based ones use fixed lists of address pairs. Azure VPN Gateway today mainly uses route-based, as explained in Chapter 6.

How the pieces fit together, from a laptop or office to a server in Azure.

Look at the diagram below. On the left is your on-premises network with a VPN device, which is a hardware box or software that speaks the same tunnel language as Azure. On the right is the Azure virtual network with a gateway subnet, where the Azure VPN gateway sits, and ordinary subnets where your servers live. A tunnel connects the two gateways across the public internet.

flowchart LR
    subgraph OnPrem["On-premises network"]
        PC["Office computers"] --> DEV["On-premises VPN device"]
    end
    subgraph Internet["Public internet"]
        TUN["Encrypted IPsec tunnel"]
    end
    subgraph Azure["Azure virtual network"]
        GW["VPN gateway in GatewaySubnet"] --> VM["Servers and databases"]
    end
    DEV --> TUN
    TUN --> GW
    LAP["Remote laptop"] -->|"Point-to-site tunnel"| GW

What is really behind the gateway

When you create a gateway, Azure deploys gateway instances into the gateway subnet. In a standard setup, there are two instances, one active and one on standby, so a failure of one can be handled by the other. In an active-active setup, both instances carry tunnels at once. In zone-redundant versions, the instances are placed in different availability zones, which are physically separate buildings inside one region.

The management side and the traffic side

You work through the Azure control plane: you create the gateway, connections, and settings using the portal, command line, or templates. The traffic itself flows through the gateway instances, which encrypt and decrypt it. If you change settings, the gateway may be briefly interrupted, and creating a gateway can take a good while, often thirty to forty-five minutes or more.

The on-premises side

The other end of the tunnel is your responsibility. You need a VPN device or software that is compatible with Azure’s requirements. Microsoft publishes lists of validated devices and configuration guides. You also need a public address for that device, or a way for it to be reached by the Azure gateway. Many problems come from mismatched settings on this side.

The shared responsibility model

Microsoft manages the gateway machines, including their patching and replacement, and the platform’s availability. You manage the configuration, shared keys, certificates, routes, address planning, the on-premises device, and the security of the resources behind the gateway.

What happens when two gateways build a tunnel and send data through it.

A site-to-site tunnel is created in two phases. Think of two strangers who want to talk privately in a crowded room. First, they need to agree on a language and prove who they are. Then they use that language to talk freely.

Phase one: building a safe channel for talking

In the first phase, the two gateways meet using IKE. They agree on which encryption methods and checks they both support, they prove their identity using the shared key or certificates, and they use a clever mathematical method called Diffie-Hellman to create a secret that no listener can work out, even though the whole conversation happens in public. The result is a secure management channel between the two gateways.

Phase two: building the data tunnel

In the second phase, over the protected channel, the gateways agree on the settings for the actual data tunnel, which uses IPsec. They also decide which address ranges may use the tunnel. These agreed settings are called security associations. They create fresh keys for the data, and these keys are replaced regularly, so even if one were stolen, only a small amount of data would be exposed.

sequenceDiagram
    participant A as "Azure VPN gateway"
    participant B as "On-premises VPN device"
    A->>B: "Phase 1 - propose encryption methods"
    B->>A: "Phase 1 - accept and exchange secrets"
    A->>B: "Prove identity with shared key"
    B->>A: "Prove identity with shared key"
    Note over A,B: "Secure management channel is ready"
    A->>B: "Phase 2 - propose data tunnel settings"
    B->>A: "Phase 2 - accept settings"
    Note over A,B: "IPsec tunnel is up"
    A->>B: "Encrypted user data"
    B->>A: "Encrypted user data"

Encapsulation: wrapping packets

Data on a network travels in small pieces called packets. In an IPsec tunnel, each original packet is encrypted and then placed inside a new outer packet with the public addresses of the two gateways on the outside. This wrapping is called encapsulation. Anyone watching the internet sees only packets going between the two gateways, not the real sources, destinations, or contents. At the far end, the gateway removes the outer wrapper, decrypts, and delivers the original packet to its destination.

Route-based and policy-based

In a policy-based design, the gateway has a fixed list of rules saying that traffic between certain address ranges on one side and certain ranges on the other should go into the tunnel. This is simple but inflexible. In a route-based design, the tunnel is treated like a network interface. The gateway looks in its routing table, and if the best route for a packet points to the tunnel, it goes into the tunnel. This supports many tunnels, dynamic routing with BGP, and more flexible designs. Route-based is the standard choice for new designs, and policy-based support in Azure is limited to certain older options, so check the documentation for the current situation.

Keeping the tunnel alive

Gateways exchange regular small messages to confirm the other side is alive. If those stop, the tunnel is declared dead and rebuilt. Rekeying, which means creating new secret keys, happens at set intervals. If the two sides disagree about the interval or other timing settings, the tunnel may drop repeatedly, which is a common troubleshooting case.

Path size and fragmentation

Wrapping adds extra bytes to every packet. Networks have a maximum packet size, so large packets may have to be split. A setting called maximum segment size clamping can reduce the size of the data in each packet so that wrapped packets fit. If this is wrong, some connections work for small data but stall for large transfers, which puzzles many beginners.

The life of one packet, and the life of a VPN project.

The path of one packet

Imagine an accountant in the office opening a file on a server in Azure. The request leaves the accountant’s computer and reaches the office router, which sees that the destination is in the Azure address range and forwards it to the on-premises VPN device. The device encrypts and wraps the packet and sends it over the internet to the Azure gateway’s public address. The Azure gateway unwraps and decrypts the packet and drops it into the virtual network. Azure’s routing delivers it to the server. The reply travels the same path in reverse.

flowchart LR
    A["Plan address ranges and design"] --> B["Create virtual network and GatewaySubnet"]
    B --> C["Create public IP address"]
    C --> D["Create virtual network gateway"]
    D --> E["Create local network gateway"]
    E --> F["Create connection with shared key"]
    F --> G["Configure the on-premises device"]
    G --> H["Test the tunnel and routes"]
    H --> I["Monitor and operate"]
    I --> J{"Changes needed?"}
    J -->|"Yes"| B
    J -->|"No"| I

Routes make or break it

A connected tunnel does not mean traffic will flow. Both sides need routes that point to the tunnel for the other side’s ranges. With static routing, you list the ranges by hand. With BGP, the gateways learn them automatically. Most mysterious “tunnel is up but nothing works” problems are route problems or firewall problems, not tunnel problems.

Changing a live gateway

Some changes, such as resizing the gateway within the same family or changing connection settings, may cause a short interruption. Others, such as moving between certain types, may need the gateway to be removed and rebuilt. Plan change windows, tell users, and keep a written record of the settings so a rebuild is quick.

The same gateway can serve three different kinds of connections.

Site-to-site

A site-to-site connection links two whole networks. The users in your office do not install anything. They simply use private addresses to reach Azure servers, and the VPN device does the work. The tunnel is intended to stay up all the time. It needs a compatible VPN device at the office, and a public address that Azure can reach, or a device that can start the connection itself.

Point-to-site

A point-to-site connection links one computer to Azure. A person starts the VPN client on a laptop, signs in, and gets a private path to the virtual network. This is ideal for remote workers, administrators, or small teams. It needs no special equipment at the user’s location.

Several sign-in methods are available, and the choice depends on the protocol:

For identity, you can use certificates, where each client holds a digital certificate issued by a certificate authority you trust. You can also use Microsoft Entra ID, which lets users sign in with their work accounts and supports conditional access and multi-factor checks, with the OpenVPN protocol. Another option is RADIUS, a long-standing sign-in server standard, often linked to an existing directory. Microsoft Entra sign-in tends to be the easiest to manage at scale for work accounts, but the options and supported clients change, so verify the current list.

VNet-to-VNet

You can join two virtual networks through VPN gateways in each. The connection works like a site-to-site connection, with Azure managing both ends. However, for most cases where two virtual networks only need to talk, a simpler tool called virtual network peering is usually faster, cheaper, and easier because it uses Microsoft’s backbone directly without gateways. VNet-to-VNet VPN is better when you specifically need encryption between networks on top of the connection, or in certain cross-subscription or cross-tenant arrangements. Check the current guidance on this choice.

Combining types on one gateway

One gateway can usually hold site-to-site, point-to-site, and VNet-to-VNet connections at the same time, within the limits of its size. The limits include the number of tunnels and the total speed, shared among all connections.

flowchart TD
    GW["Azure VPN gateway"]
    S1["Head office - site-to-site"] --> GW
    S2["Branch office - site-to-site"] --> GW
    P1["Remote worker laptop - point-to-site"] --> GW
    P2["Administrator laptop - point-to-site"] --> GW
    V1["Another Azure VNet - VNet-to-VNet"] --> GW
    GW --> NET["Resources in the virtual network"]

Choosing the right size so you do not overpay or run short.

The SKU determines how fast the gateway can move data, how many tunnels it supports, and which features it offers. Names and numbers change, so the table below shows the general shape only. Always read the current Azure tables before you decide.

Generations

Gateway SKUs come in generations, for example Generation 1 and Generation 2. Later generations typically offer higher throughput for the same family. You pick the generation when you create the gateway. Check the documentation for what is allowed together.

Understanding the numbers

The published speed of a SKU is an upper limit under good conditions, not a promise. Real speed depends on the packet size, the encryption settings, the internet path, and the on-premises device. Often the on-premises device or the internet connection at the office, not the Azure gateway, is the bottleneck. Test with realistic traffic before you rely on the numbers.

The tunnel count and the connection count

Each SKU supports a maximum number of site-to-site and VNet-to-VNet tunnels, and a maximum number of point-to-site connections. A busy remote-work setup with hundreds of laptops needs a bigger SKU than a small team does. Active-active designs use more tunnels for the same number of sites.

Resizing

Resizing within the same family and generation is usually possible without rebuilding, though a brief interruption may occur. Moving between some families may require deleting and recreating the gateway. Selecting a SKU with some headroom saves trouble later.

Sizing process

A tunnel is only a road. Routing is the set of signposts that tells traffic to use it.

Routing is the process of deciding which path a packet takes to reach its destination. Each network device keeps a routing table, a list saying “for addresses in this range, send packets that way”. For the tunnel to work, both sides need correct routes.

Static routing

With static routing, you type the address ranges by hand. In Azure, the local network gateway lists the on-premises ranges, and Azure adds routes to those ranges through the tunnel. On the office side, you add routes to the Azure ranges through the VPN device. It is simple and predictable for small, stable setups. But every time a range is added or removed, someone must update both sides, and mistakes are common.

Dynamic routing with BGP

BGP lets the two gateways tell each other automatically which ranges they can reach. When you add a new subnet on one side, the other side learns it without any manual change. BGP also allows smart failover between multiple tunnels, because a route can be withdrawn when a tunnel fails and another path takes over. Each side needs an identifier called an autonomous system number, and the peers need addresses to talk to each other. BGP needs a SKU that supports it.

How Azure decides among routes

Azure builds a routing table for each subnet from several sources: system routes, routes learned from peering, routes from the gateway, and any custom routes you add. If several routes match an address, the one with the longest, most specific range wins. If ties remain, there is a defined order of preference among sources, so check the current rules when mixing sources. Routes you define yourself, called user-defined routes, can override defaults, for example to force traffic through a firewall appliance.

Gateway transit with peering

Often, you place the gateway in a central “hub” virtual network, and connect “spoke” networks through peering. With the settings that allow the spoke to use the hub’s gateway, called gateway transit, the spoke networks can reach the on-premises network through the same tunnel without needing gateways of their own. This hub-and-spoke pattern saves money and keeps management in one place.

flowchart TD
    OP["On-premises network"] -->|"Site-to-site tunnel"| HUB["Hub VNet with VPN gateway"]
    HUB -->|"Peering with gateway transit"| SP1["Spoke VNet 1 - applications"]
    HUB -->|"Peering with gateway transit"| SP2["Spoke VNet 2 - databases"]
    HUB -->|"Peering with gateway transit"| SP3["Spoke VNet 3 - testing"]

Forced tunneling

Forced tunneling means sending all internet-bound traffic from Azure resources back through the on-premises network, so that the company’s own security tools can inspect it. It is done by advertising a default route toward the tunnel. It can improve control but adds delay and loads the tunnel, and it can break services that need direct internet access. Test it carefully.

Overlapping address ranges and NAT

When two networks have overlapping ranges, for example after a company merger, you can use network address translation, or NAT, to present one side’s addresses as different ones. Azure VPN Gateway supports NAT rules for such cases. NAT solves the problem but adds complexity, so avoid overlaps in the first place when you can.

Gateways, internet links, and devices can fail. Good design expects it.

High availability means that the connection keeps working even when one part fails. A single tunnel through a single device across a single internet link has many points of failure. The aim is to remove them one by one.

Active-standby: the default

By default, a gateway has two instances. One is active and carries all the tunnels. The other waits as a standby. If the active one fails or is under planned maintenance, the standby takes over. The tunnels drop briefly and then reconnect, which may take from a few seconds to longer. For many workloads this is acceptable.

Active-active

In an active-active gateway, both instances are active, each with its own public address, and each can hold tunnels. Your on-premises device builds a tunnel to each instance. If one instance fails, the traffic continues through the other with less interruption. This design usually uses BGP so that routes follow the working tunnels.

Zone-redundant gateways

The AZ versions of the gateway SKUs spread the instances across availability zones in a region. If one building suffers a power or cooling problem, the gateway carries on from another. These need the matching type of public address, and the region must support zones.

Redundancy on the on-premises side

Azure’s resilience is wasted if your office has a single VPN device and a single internet line. A strong design uses two devices, ideally with two internet providers, each making tunnels to Azure.

flowchart LR
    subgraph OP["On-premises network"]
        D1["VPN device 1"]
        D2["VPN device 2"]
    end
    subgraph AZ["Azure active-active zone-redundant gateway"]
        I1["Gateway instance 1 - zone A"]
        I2["Gateway instance 2 - zone B"]
    end
    D1 --- I1
    D1 --- I2
    D2 --- I1
    D2 --- I2
    I1 --> V["Virtual network resources"]
    I2 --> V

Protecting against failures in the tunnel itself

You can also combine a VPN with another path. A common pattern is to use ExpressRoute as the main path and a VPN as a backup. Another is to build site-to-site VPNs through two different providers. The backup path must be tested regularly or you may find it broken when it is needed.

Planned maintenance

Microsoft periodically updates the gateway machines. In active-standby, this causes brief reconnections. Design applications to retry on short interruptions, and your on-premises device to reconnect quickly. Scheduling-related options for maintenance may exist, so check current features.

Test failover

Practise by turning off one tunnel or one device in a test window and watching what happens. Measure how long the interruption lasts, which applications notice, and whether routes switch as expected. Write down the results. It is far better to find surprises in a drill than in a real outage.

A tunnel that is not configured safely is only a hole with a nice name.

Encryption and integrity

An IPsec tunnel provides confidentiality, meaning others cannot read the data, and integrity, meaning others cannot change it without being detected. It also gives authentication, meaning each end proves it is who it claims to be. Choosing strong algorithms for each of these matters. Old, weak choices should be avoided.

Default and custom IPsec policies

Azure has a default set of algorithms that it proposes and accepts. You can define a custom IPsec and IKE policy on a connection to require specific algorithms, key strengths, and lifetimes, such as when your compliance rules demand a particular combination. Both ends must agree on the same choices or the tunnel will not come up. Keep a written copy of the policy shared with your network team.

Shared keys and certificates

The shared key protects the tunnel’s identity. Choose a long, random key. Do not reuse it across connections, do not send it in plain email, and change it on a schedule or whenever someone who knew it leaves. Store it in a secure secret vault. For point-to-site connections using certificates, protect the private keys on each laptop, and know how to revoke a lost laptop’s certificate.

Controlling who can reach what

A VPN tunnel makes two networks neighbours, but neighbours should not have keys to every door. Use network security groups, which are filters that allow or deny traffic by address, port, and direction, to limit what VPN users and remote sites can reach. For deeper inspection, route VPN traffic through a firewall appliance or Azure Firewall using user-defined routes. Follow the rule of least privilege, which means giving access only to what is needed.

flowchart TD
    U["Remote user or office device"] --> AUTH{"Tunnel authentication passed?"}
    AUTH -->|"No"| DENY["Connection refused"]
    AUTH -->|"Yes"| GW["VPN gateway"]
    GW --> FW["Firewall or network security group rules"]
    FW -->|"Allowed"| RES["Permitted resources"]
    FW -->|"Denied"| BLOCK["Traffic dropped and logged"]

Point-to-site user security

For remote users, use strong identity. With Microsoft Entra sign-in, you can require multi-factor authentication, restrict by device health, and block risky sign-ins through conditional access. Keep the list of allowed users current, remove departed staff promptly, and use groups to decide who may connect. Give different groups different address pools, if supported, to apply different rules to each.

Do not expose management

The VPN gateway itself should not be open to extra services. Keep the gateway subnet free of other resources, and do not place user-defined routes or network security groups on it unless the documentation clearly allows it, because wrong rules there can break the gateway.

Security checklist

• Use strong, unique shared keys and store them in a secure vault.
• Prefer IKE version 2 and modern algorithms, and use custom policies where compliance needs them.
• Limit access behind the tunnel with network security groups and firewalls.
• Use Microsoft Entra sign-in with multi-factor checks for remote users where possible.
• Revoke access quickly for lost devices and departed staff.
• Send gateway logs to a central workspace and review them.
• Control who can change gateways and connections using role-based access and change review.
• Keep the on-premises device updated, because it is part of your security too.
• Avoid overly broad address ranges in tunnel definitions.

You cannot manage what you cannot see. Here is what to watch and how to find faults.

Monitoring means continuously checking the health and behaviour of your system. Metrics are numbers measured over time. Logs are written records of individual events. VPN Gateway sends metrics to Azure Monitor and can send logs to a central workspace through diagnostic settings. Alerts are automatic messages triggered when a number crosses a line you choose.

Logs worth collecting

VPN Gateway offers several diagnostic log categories, such as those for gateway events, tunnel events, route changes, IKE negotiation messages, and point-to-site sessions. The IKE logs are especially useful when a tunnel will not come up, because they show where the negotiation failed. Logs can grow large and cost money to store, so choose what to keep and set a retention period. Check the current list of categories in the documentation.

Built-in diagnostic helpers

Azure provides troubleshooting helpers in the portal, including a tool that checks the gateway and connection state and suggests problems, and network diagnostic tools that can capture packets or test connectivity paths. Use them as a first step before reading logs in detail.

The usual suspects

When a tunnel will not connect or traffic will not flow, work through a standard list. Most issues are one of these causes.

Telling who is at fault

If the tunnel state is down, the fault is in negotiation or reachability. If the tunnel is up but traffic fails, the fault is in routing or filtering. If it works but is slow, look at bandwidth limits, packet loss, the internet path, or the on-premises device’s processing power. This three-way split quickly points you in the right direction.

Azure offers several ways to connect networks. Compare before you choose.

Features and product positioning change over time. Confirm the current capabilities and limits of each in the documentation.

VPN Gateway versus ExpressRoute

VPN Gateway is quick and cheap to start, uses existing internet connections, and is encrypted by design. But its speed and delay vary with the internet. ExpressRoute uses a private circuit from a provider, offering steadier delay and higher speeds, but takes longer to arrange and costs more. Encryption is not automatic on a private circuit by default, so sensitive data may still need its own protection. Many firms use both: ExpressRoute for the main flow and VPN as a backup. The two can coexist on the same virtual network, with a gateway of each kind.

VPN Gateway versus Virtual WAN

For a handful of connections, a standard VPN gateway in a hub-and-spoke design is simple and enough. For dozens or hundreds of branches, multiple regions, and the need for automated configuration and routing, Virtual WAN provides a managed hub that handles scale and complexity. It brings extra cost and its own concepts. Choose it when manual management becomes the bigger problem.

VPN Gateway versus peering

If both sides are Azure virtual networks, peering is generally the first choice because it avoids the gateway cost, the tunnel overhead, and the speed limits. Use VNet-to-VNet VPN only when you have a particular reason, such as a need for an extra encryption layer or a scenario where peering is not suitable.

A simple decision guide

flowchart TD
    Q1{"What are you connecting?"} -->|"Azure VNet to Azure VNet"| P["Use virtual network peering first"]
    Q1 -->|"On-premises to Azure"| Q2{"Need very high steady speed and low delay?"}
    Q1 -->|"Individual remote users"| PS["Use point-to-site on VPN Gateway"]
    Q2 -->|"Yes"| ER["Use ExpressRoute with VPN backup"]
    Q2 -->|"No"| Q3{"Many branches across regions?"}
    Q3 -->|"Yes"| VW["Consider Azure Virtual WAN"]
    Q3 -->|"No"| VG["Use site-to-site on VPN Gateway"]

Layering them together

A typical mid-sized design uses a hub virtual network with a VPN gateway for the office link, peering to spoke networks, a firewall in the hub to inspect traffic, and point-to-site for administrators. As the company grows, ExpressRoute is added for the heavy flow and the VPN becomes the backup. Each service does the job it is best at.

Every design choice gives something and takes something. Be honest about both sides, including the bill.

What makes up the bill

VPN Gateway is generally billed by the hour for the gateway, based on its SKU, for as long as it exists, whether or not traffic flows. There are also charges for the public IP address and for data leaving Azure, called outbound data transfer. Data entering Azure is typically not charged, but check the current rules. Point-to-site connections above the included number may add charges in some SKUs. Prices vary by region and change over time, so use the Azure pricing calculator.

Ways to save

• Share one gateway. Use a hub-and-spoke design so that many networks share a single gateway.
• Right-size. Pick a SKU that fits the real peak and review it as use changes.
• Delete unused gateways. A forgotten test gateway keeps billing every hour.
• Use peering between Azure networks. It avoids gateway costs for network-to-network links.
• Reduce chatty traffic. Compress, cache, or move data processing closer to the data to cut outbound volume.
• Avoid unneeded redundancy in test environments. Reserve zone-redundant, active-active designs for production.

The central trade-off

The big trade-off is cost and speed of setup versus performance and predictability. A VPN gets you connected quickly and cheaply, but you accept the behaviour of the internet. A private circuit gives steadier performance but needs more time and money.

Simplicity versus control

Static routes are simple but need manual updates. BGP is more flexible but adds a protocol you must understand and monitor. Pick the simpler tool for small stable setups and the dynamic one as the network grows.

Security versus convenience

Wide-open tunnels make life easy for users but increase risk. Narrow rules and strong sign-in make life safer but may add some friction. The right answer is the least access that still lets people do their jobs.

Proven shapes to copy, and common shapes to avoid.

Patterns that work

Anti-patterns

An anti-pattern is a common solution that looks sensible but causes trouble. Here are the usual ones.

A practical list you can print and keep next to your desk.

Best practices

• Plan addresses first and keep them unique across all sites and networks.
• Choose route-based gateways and a SKU with headroom, avoiding retiring or very limited SKUs.
• Design for failure. Use active-active, zone-redundant gateways where the business needs it, and redundant on-premises devices.
• Use BGP when you have many networks or need automatic failover.
• Match both ends exactly. Document and review the encryption, integrity, lifetime, and timing settings.
• Protect secrets. Use strong keys, vaults, and rotation, and revoke lost certificates quickly.
• Apply least privilege with network security groups and a firewall behind the gateway.
• Use Microsoft Entra sign-in and multi-factor checks for remote users where supported.
• Prefer peering for connecting Azure networks to each other.
• Monitor tunnel state, traffic, packet drops, and BGP status, and alert early.
• Test failover and large transfers before production, including packet size behaviour.
• Keep configuration as code so rebuilds are quick and changes are reviewed.
• Review limits and retirements in the documentation regularly, since SKUs and features evolve.

Common mistakes

Four typical situations, described as illustrative examples, showing when the service fits.

The stories below are illustrative composites of the kinds of situations where teams commonly use Azure VPN Gateway. They are not claims about any particular company, but they reflect the reasoning real architects use.

Short answers to the questions beginners ask most often.

Everything important, in one place.

Azure VPN Gateway is a managed service that builds encrypted tunnels between Azure virtual networks and your offices, data centers, other networks, and individual users across the public internet. It consists of a virtual network gateway placed in a gateway subnet, a local network gateway that describes the other end, and a connection that holds the shared key and settings. The two ends negotiate with IKE and carry data with IPsec. Routes, either static or learned through BGP, decide which traffic uses the tunnel. Active-active and zone-redundant designs, with redundant devices on your side, keep the link alive through failures. Network security groups and firewalls limit what the tunnel can reach, and logs and metrics reveal what is happening.

Remember the picture we began with: two towns joined by a private tunnel under a dangerous highway. A tunnel is only useful if both ends are built to match, if the guards check everyone who enters, if there is a second tunnel for emergencies, and if someone regularly walks through to make sure it still works. Treat Azure VPN Gateway the same way: plan the addresses, match the settings, limit the access, build in redundancy, and test it before you need it.