Reaching Azure privately: VPN Gateway, ExpressRoute and endpoints

Three shapes of VPN connection

A VPN gateway is a resource you deploy into a virtual network, in a subnet Azure requires you to name GatewaySubnet, and it terminates encrypted tunnels that run across the public internet. It offers three shapes and the exam expects you to match them to a scenario. Point-to-site connects a single client device from wherever it happens to be, which is the answer whenever one remote person needs occasional private access and there is no VPN hardware at their end.

Site-to-site connects an entire on-premises network, and it needs a VPN device with a public address at the far end — which a home laptop is not, and that mismatch is how the two are told apart in a question. Network-to-network joins two virtual networks through gateways, for the cases where peering is not what you want. All three are tunnels over a path nobody controls, so all three are encrypted because they have to be, and all three inherit the internet's variability in throughput and latency.

ExpressRoute buys a path, not confidentiality

ExpressRoute is a private connection arranged through a connectivity provider: the traffic does not traverse the public internet at all, and the circuit is bought at a committed bandwidth rather than depending on whatever the internet is doing today. That is what makes it the answer for continuous bulk transfer, for predictable latency, and for regulators who object to public transit. It takes a provider and a lead time, which is why it is the wrong-sized answer for one developer working from home.

The distinction that makes the hard question: private and encrypted are two different words, and auditors usually mean the second. A site-to-site VPN encrypts because it crosses the public internet; ExpressRoute solves that problem by avoiding the internet rather than by encrypting, so its traffic is not encrypted by the platform. Where data must be confidential in transit you add that yourself — an encrypted tunnel run across the circuit, or TLS in the application — and needing both a private path and encryption is an ordinary design rather than a contradiction.

Public endpoints, and the private ones that replace them

Every platform service — a storage account, a database, a key vault — starts life with a public endpoint: a public name and a public address that anyone on the internet may at least attempt to reach, with authentication and firewall rules deciding who actually succeeds. Narrowing that firewall is a real control and it is not the same thing as making the service private, because the resource is still reached at its public address.

A private endpoint changes the address itself. It places a network interface holding a private IP from your own subnet in front of the service, so the service is reachable inside your network — and therefore over a VPN or an ExpressRoute circuit — while its public access can be switched off entirely. Name resolution has to follow the address, which is why a private DNS zone normally goes with it, otherwise the service's name still resolves to the public address it no longer uses.