Azure networking: virtual networks, subnets, peering, DNS, VPN Gateway, ExpressRoute and endpoints

Why this matters

Almost nothing in Azure works alone. Virtual machines talk to databases, web servers talk to storage, and most companies still have offices and datacenters of their own that need to reach their Azure resources. Azure networking decides who can reach what, over which path, and whether that path crosses the public internet. It is also where many security mistakes are made: a database left on an internet-facing address, or a port opened to everyone.

A manager needs to know the difference between a VPN over the internet and a private ExpressRoute circuit, because the two differ greatly in cost, set-up time and predictability. A salesperson needs to explain to a bank how its traffic can reach Azure without touching the internet. A junior administrator needs to know that two virtual networks cannot talk until they are peered, that peered networks cannot overlap, and that a private endpoint is how a storage account disappears from the internet. Getting these wrong means applications that cannot find each other, or data that anyone can reach.

The lesson

Virtual networks, subnets, peering, Azure DNS, VPN Gateway and ExpressRoute

Azure virtual networks. An Azure virtual network (VNet) is a private, isolated network in Azure. Resources inside it, such as virtual machines, communicate with each other using private IP addresses, and they are isolated from other customers' resources. If a company wants its VMs in one region to talk privately to each other, it creates a virtual network. It does not need a VPN gateway or an ExpressRoute circuit for that; those connect Azure to networks outside it.

Facts about virtual networks that are tested:

• A virtual network exists in one region and one subscription. It cannot span several regions, and it cannot belong to several subscriptions. Its subnets can, however, span the availability zones of that region (lesson 5).
• You choose its address space, a range of private IP addresses.
• One virtual network can hold many subnets.
• To connect virtual networks in different regions, you use global peering or a VPN gateway.

Subnets. A subnet is a range of IP addresses carved out of the virtual network's address space. Subnets segment the network. A company that wants separate segments for web servers and database servers creates two subnets, so it can apply different traffic rules to each. Resource groups do not do this: they organise resources for management and billing (lesson 6), not network traffic.

• A subnet stays inside one virtual network, in one region.
• Resources in different subnets of the same virtual network can communicate by default, with no gateway needed.
• A network security group (NSG) can be associated with a subnet. An NSG holds allow and deny rules based on source, destination, port and protocol, and once associated with a subnet it filters traffic to every resource in it. To let a web subnet accept inbound internet traffic only on HTTPS port 443, you associate an NSG with that rule.

Virtual network peering. Peering connects two virtual networks so that resources in each can reach the other using private IP addresses. Traffic between peered networks stays on the Microsoft backbone network; it never crosses the public internet. Peering works within a region and, as global virtual network peering, between regions. Two rules matter:

• The peered networks must have address spaces that do not overlap.
• No ExpressRoute circuit or VPN is needed for peering.

Peering connects Azure virtual networks to each other. It does not connect an on-premises network to Azure.

Azure DNS. Azure DNS hosts DNS zones on Microsoft's global name servers. A company can manage the DNS records for its internet domain with the same credentials, access control and billing as its other Azure resources.

• Public DNS zones answer queries from the internet for a company's domain.
• Private DNS zones resolve names inside the virtual networks linked to them. VMs in two peered virtual networks can find each other by host name through a private zone, without the company running its own DNS servers. A public zone would expose those internal names instead.
• An alias record set points directly at an Azure resource, such as a public IP address, and updates itself if that resource's address changes.
• Azure DNS cannot buy or register domain names. A domain is bought from a registrar (or as an App Service domain), and its records can then be hosted in Azure DNS.

Azure DNS is a global service, not one you place in a region. Azure Bastion, which gives secure browser-based remote access to VMs, is unrelated to name resolution.

Azure VPN Gateway. A VPN gateway sends encrypted traffic between an Azure virtual network and another network over the public internet, through encrypted tunnels. It supports three kinds of connection:

• Site-to-site: connects a whole on-premises network, such as a head office, to a virtual network. The office needs its own VPN device, which is separate from the Azure gateway.
• Point-to-site: connects an individual computer, running VPN client software, to the virtual network. This suits remote employees on their own laptops with no VPN device at home.
• VNet-to-VNet: connects two Azure virtual networks through gateways.

The Azure VPN gateway itself is deployed into a dedicated subnet of the virtual network, named GatewaySubnet. It does not live in each VM, in the company's office or in a management group.

ExpressRoute. Azure ExpressRoute extends an on-premises network into the Microsoft cloud over a private connection supplied by a connectivity provider. Its traffic does not travel over the public internet. Compared with a VPN, it gives more reliable speeds, higher bandwidth and more consistent latency. That is why a financial company that wants predictable performance and no internet path chooses it. A VPN is quicker and cheaper to set up but less predictable, because it rides the internet.

• ExpressRoute Global Reach links on-premises sites that each have their own ExpressRoute circuit, so two offices in different countries can exchange data over the Microsoft network.
• ExpressRoute Direct connects directly to Microsoft's network at very high speeds, for the largest needs.
• A site-to-site VPN is commonly kept as a backup path, so on-premises traffic still reaches Azure if the ExpressRoute circuit fails.

Two methods connect an on-premises network to a virtual network: VPN Gateway and ExpressRoute. Peering, DNS zones and network security groups do not create that connection.

How the pieces fit together. Picture a retailer with a head office and an online shop in Azure. Its shop runs in one virtual network in UK South, split into a web subnet and a database subnet, each with its own network security group: the web subnet accepts HTTPS from the internet, and the database subnet accepts traffic only from the web subnet. A second virtual network in UK West holds a standby copy and is joined to the first by global peering. A private DNS zone linked to both networks lets every VM find the others by name, while a public zone in Azure DNS holds the shop's internet records. The head office reaches both networks over ExpressRoute, with a site-to-site VPN kept as the backup path, and staff working from home use point-to-site VPN. Each service does one job, and none of them can stand in for another.

Public and private endpoints

An endpoint is the address a client uses to reach a service. Many Azure services, such as storage accounts and databases, can be reached in two ways.

A public endpoint is reachable from the internet, through a public IP address or a public DNS name. A customer-facing website must have one, because customers anywhere on the internet need to reach it. Access can still be limited with firewalls and authentication, but the address itself is internet-facing.

A private endpoint is a network interface with a private IP address in a subnet of your virtual network, connected through Azure Private Link to a specific service, such as one storage account. Resources in the virtual network reach the service through that private address, so traffic stays on the private network and never needs an internet-facing address. Once a private endpoint is in place, public network access can be turned off, and the service disappears from the internet entirely.

A typical case: a company keeps data in a storage account and wants VMs in its virtual network to reach it with no internet-facing address. It creates a private endpoint for the storage account in a subnet and disables public access. A public endpoint would be exactly the internet-facing address it is trying to remove, and a point-to-site VPN connects laptops, not a service. With a VPN or ExpressRoute in place, on-premises users can reach the private endpoint too.

The deciding question is simple. Must people on the internet reach it? Then it needs a public endpoint. Should only resources on your private network reach it? Then use a private endpoint. Lesson 11 covers the wider security model this fits into.

What the exam is really asking

Most questions in this area describe a connection and ask which service makes it. Match the path:

• Resources in Azure talking privately: a virtual network. Two VNets talking privately: peering, regional or global.
• Segmenting one network: subnets, each with its own network security group.
• Office to Azure over the internet, encrypted: a site-to-site VPN. One laptop to Azure: point-to-site.
• Office to Azure with no internet and consistent latency: ExpressRoute. Backup for ExpressRoute: a site-to-site VPN. Office to office through two circuits: ExpressRoute Global Reach.
• Name resolution inside VNets: an Azure private DNS zone. A record that follows an Azure IP: an alias record.
• A service reachable only from your network: a private endpoint.

The common traps are swapping VPN Gateway (internet) and ExpressRoute (private), expecting peering to reach an on-premises site, allowing overlapping address spaces, believing a virtual network can span regions or subscriptions, assuming Azure DNS registers domains, and thinking a public IP filters traffic. Filtering is an NSG's job.