Azure virtual network explained for app builders: subnets, private endpoints and DNS in one picture

Sooner or later, an app or flow you build has to reach something that isn't on the internet: a database behind a private endpoint, a Key Vault with public access off, a VM that a security team locked down. That's when the conversation turns to VNets, subnets, NSGs and private DNS zones, usually in a ticket from the network team. This is the Azure virtual network explained for people who build apps, flows and agents rather than networks: the five pieces that matter, how a request finds its way through them, and the handful of rules behind most "it works from my laptop but not from the app" problems. Each section links to the guide that goes deeper.

Pause animation

1. 1App in subnet A looks up the database's name
2. 2Private DNS zone answers with the private endpoint's address
3. 3Network security groups on both subnets allow the traffic
4. 4The private endpoint in subnet B passes it to the database

A virtual network and its subnets

A virtual network (VNet) is a private address range you own in one Azure region, such as 10.20.0.0/16. You divide it into subnets (10.20.1.0/24, 10.20.2.0/24 and so on), and resources get their private addresses from a subnet. Things to know:

• Azure takes five addresses in every subnet: the first four (network address, default gateway, two for Azure DNS) and the last. A /24 has 251 usable addresses, and the smallest subnet, a /29, has just 3.
• Plan for growth and for neighbours. Ranges mustn't overlap with each other, with on-premises networks you'll connect, or with networks you'll peer. Re-addressing later is painful.
• Some services need a subnet of their own, handed to them by delegation: App Service integration, Container Apps, DNS Private Resolver, and Power Platform. A delegated subnet can't hold anything else. Some platform subnets also need fixed names: GatewaySubnet for VPN and ExpressRoute gateways, AzureFirewallSubnet for Azure Firewall.
• Networks connect by peering. Two peered networks can reach each other's addresses. Peering isn't transitive: if A is peered with B and B with C, A can't reach C through B, which is why hub-and-spoke designs route through a firewall or gateway in the hub.

Network security groups decide what gets through

A network security group (NSG) is a list of allow and deny rules on a subnet or a network interface. Each rule matches source, source port, destination, destination port and protocol.

• Rules run in priority order, lowest number first, from 100 to 4096, and the first match wins. A broad allow at priority 100 makes every narrower rule below it pointless.
• Every NSG has six default rules you can't delete, at priorities 65000 and up: traffic within the virtual network is allowed, outbound internet is allowed, and all other inbound traffic is denied (DenyAllInBound).
• With an NSG on both the subnet and the VM's network interface, both must allow the traffic. Inbound, the subnet's is checked first; outbound, the interface's.
• The VirtualNetwork service tag is broader than it sounds: it includes peered networks and on-premises ranges connected through a gateway.

Never open RDP (3389) or SSH (22) to the internet. Reach VMs through Azure Bastion or a VPN.

Private endpoints bring a service inside

Azure's platform services (Storage, SQL Database, Key Vault, Cosmos DB) live on public addresses. A private endpoint gives one specific resource a private address inside your subnet, through a read-only network interface. Traffic between them stays on Microsoft's network, and the service can then switch public access off entirely.

Microsoft recommends private endpoints (Private Link) for new designs. Two details catch people out: each sub-resource needs its own endpoint (a storage account's blob and file, or blob and dfs for Data Lake), and creating an endpoint doesn't by itself block the public address; you switch public access off on the service.

DNS is half of every private endpoint

Your app doesn't change its connection string. It still asks for mydb.database.windows.net, and public DNS points that name to a privatelink name. A private DNS zone called privatelink.database.windows.net, linked to your virtual network, then answers with the endpoint's private address. Anything that resolves the name some other way, such as a network without the link, a custom DNS server that doesn't forward to Azure, or a machine in your office, gets the public address and is refused. That's the most common private endpoint failure, and it has its own guide: private endpoint resolves to a public IP. From your own data centre you also need a way to ask Azure's DNS, covered in private endpoint DNS from on-premises.

Getting out to the internet

Outbound is changing. Subnets created in the portal are already private, and subnets in new virtual networks created with API versions released after 31 March 2026 are private by default: a VM in one has no internet access, not even for Windows Update, until you give it an explicit way out. A NAT Gateway on the subnet is the recommended one, and it gives you fixed outbound addresses to allow-list. Existing networks keep their old behaviour. The details, and how to tell which you have, are in Azure VM has no outbound internet access.

Where Power Platform fits

Power Platform runs in Microsoft's network, not yours. To let its Dataverse plug-ins and supported connectors (SQL Server, Key Vault, Blob Storage, custom connectors and more) reach private resources, you delegate a subnet in each of two Azure regions to Power Platform, and link it to a Managed Environment. Calls then start from your subnet and follow your DNS and your network rules. Sizing, regions and the settings you can't change later are in the virtual network support checklist. For which Azure service to pick for a Power Platform job, start at Power Platform and Azure.

Sources

• Azure Virtual Network FAQ, Microsoft Learn (the five reserved addresses, subnet sizes, NSG and route order)
• IP address planning for Azure virtual networks, Microsoft Learn (usable addresses, non-overlapping ranges, dedicated subnets)
• Azure network security groups overview, Microsoft Learn (rule properties, priorities, default rules)
• Troubleshoot network security group misconfigurations, Microsoft Learn (subnet and interface order, the VirtualNetwork tag)
• Virtual network peering, Microsoft Learn
• What is a private endpoint?, Microsoft Learn (one endpoint per sub-resource, public access still to be switched off)
• Private access to Azure PaaS services, Microsoft Learn (private endpoints compared with service endpoints)
• Azure Private Link FAQ, Microsoft Learn
• Default outbound access in Azure, Microsoft Learn
• Microsoft Azure VNet support overview, Microsoft Learn (Power Platform)