Academmia

Azure Virtual Networking Components and Their Purpose

az-900•mixed•

Azure architecture and services

Azure Virtual Networking Components and Their Purpose

Short Summary

In this lesson, you’ll learn the core Azure virtual networking building blocks and what each one is for. You’ll understand how an Azure Virtual Network (VNet) and subnets create private address spaces and segmentation. You’ll also learn how name resolution (Domain Name System (DNS)) differs from connectivity options such as peering, Azure VPN Gateway, and Azure ExpressRoute.

Learning Objectives

By the end of this lesson, you will be able to:

  • Explain what an Azure Virtual Network (VNet) is and why it is logically isolated by default.
  • Describe what a subnet is and how it segments a VNet using Internet Protocol (IP) address ranges.
  • Differentiate virtual network peering from gateway-based connectivity.
  • Clarify what Domain Name System (DNS) does (name resolution) versus what networking services do (traffic connectivity).
  • Select between Azure VPN Gateway and Azure ExpressRoute based on “encrypted over the public internet” versus “private connectivity”.

Core Concepts

Azure Virtual Network (VNet)

An Azure Virtual Network (VNet) is your private network boundary in Azure. It is logical (software-defined), not physical cables or switches you manage.

Key idea: separate VNets are isolated from each other by default. If two VNets need to communicate, you explicitly connect them (for example, by peering or by using a gateway-based option).

Subnets

A subnet is a slice of a VNet’s IP address space. Think of it as: “this IP range belongs to this part of my network.”

Subnets help you segment workloads inside a VNet (for example, web tier vs. app tier vs. database tier). This segmentation is what enables tighter control over which traffic should be allowed between tiers.

Network Security Groups (NSGs)

A Network Security Group (NSG) is a set of inbound and outbound rules that filter network traffic. You commonly use NSGs to control flows:

  • between subnets (tier-to-tier),
  • into or out of a subnet,
  • to or from specific resources (depending on how you associate the NSG).

Virtual network peering

Virtual network peering connects two VNets so resources can communicate using private IP addresses.

A helpful mental model:

  • Peering is Azure-to-Azure connectivity that doesn’t require you to set up an encrypted tunnel.
  • It’s different from a VPN because it isn’t “internet tunnel connectivity”; it’s a direct private connection between VNets.

DNS: name resolution, not connectivity

Domain Name System (DNS) translates names into IP addresses (for example, app.contoso.com → 10.1.2.4). DNS helps you find a destination, but it doesn’t connect the networks.

In Azure:

  • Azure DNS is used to host public DNS zones.
  • Azure Private DNS provides private DNS zones for name resolution inside VNets and connected networks.

Azure VPN Gateway

A Virtual Private Network (VPN) encrypts traffic over an untrusted network (commonly the public internet). Azure VPN Gateway provides encrypted connectivity using Internet Protocol Security (IPsec) and Internet Key Exchange (IKE).

Typical uses:

  • connect on-premises (on-prem) networks to a VNet (site-to-site),
  • connect individual devices/users (point-to-site),
  • connect VNets using VPN when peering isn’t the chosen approach.

Azure ExpressRoute

Azure ExpressRoute provides private connectivity to Azure through a connectivity provider. The key idea: it’s designed to avoid traversing the public internet, which is why it’s often chosen for production workloads that want more predictable connectivity characteristics than an internet-based VPN.

Practical Understanding

Practical Situation 1: “I need a private network space in Azure”

You want multiple Azure resources to communicate privately, using private IP addresses, and you want control over the IP ranges. You also want the default assumption to be isolation from other networks.

How to think about it: Start with an Azure Virtual Network (VNet). Define an address space, then place resources into subnets. Treat the VNet as your private network boundary in Azure.

Common misunderstanding: Assuming a VNet is physical network hardware. It’s a logical network you define and control.

Practical Situation 2: “I want segmentation between tiers inside one app”

You have a web tier, an application tier, and a database tier. You want clear separation so you can control which traffic is allowed between tiers.

How to think about it: Use subnets to place each tier in a separate IP range inside the same VNet. Then apply traffic control using a Network Security Group (NSG) to allow only the flows you want (for example, web → app, app → database).

Common misunderstanding: Treating subnets as “folders” for organizing resources. A subnet is an IP range boundary used for segmentation and network controls.

Practical Situation 3: “Two VNets need to talk privately, without VPN tunnels”

You have two VNets (same region or different regions) and you need private communication using private IP addresses. You prefer not to deploy gateway resources and you want a straightforward Azure-to-Azure connection.

How to think about it: Use virtual network peering for direct VNet-to-VNet connectivity inside Azure. Use NSGs if you want to restrict which subnets or resources can talk across that connection.

Common misunderstanding: Thinking peering and VPN Gateway are the same thing. Peering connects VNets directly; VPN Gateway is encrypted tunneling.

Practical Situation 4: “Connect on-premises to Azure: internet tunnel vs private circuit”

You need to connect an on-premises (on-prem) datacenter to Azure. Sometimes “encrypted over the public internet” is acceptable; other times you need “private connection that avoids the public internet” for production.

How to think about it: If the requirement says “encrypted over the public internet,” think Azure VPN Gateway (IPsec/IKE). If the requirement says “private connection” and “doesn’t traverse the public internet,” think Azure ExpressRoute (provider-based private connectivity).

Common misunderstanding: Equating “encrypted” with “private.” A VPN can be encrypted and still run over the public internet; ExpressRoute is private connectivity via a provider.

Common Pitfalls

  • Mistake: Confusing VNets with physical networks and assuming they are connected by default. Correction: A VNet is a logical network boundary, and separate VNets are isolated unless you explicitly connect them.

  • Mistake: Treating subnets as “folders” for resources. Correction: A subnet is an IP address range inside a VNet, commonly used for segmentation and applying network controls.

  • Mistake: Treating VNet peering as the same as a VPN gateway connection. Correction: Peering is direct VNet-to-VNet connectivity; a VPN gateway uses IPsec/IKE tunneling (often over the public internet).

  • Mistake: Mixing up DNS with networking connectivity. Correction: DNS resolves names to IPs; it doesn’t create network connectivity between VNets or between on-premises and Azure.

  • Mistake: Mixing up VPN Gateway and ExpressRoute. Correction: VPN Gateway is encrypted connectivity over the public internet; ExpressRoute is private connectivity through a provider that avoids the public internet.

Check Your Understanding

  1. In your own words, explain why two VNets in the same subscription still do not automatically communicate.
  2. Draw a quick diagram of a single VNet with three subnets (web/app/db). Write one example of an allowed flow and one example of a blocked flow (based on NSG rules).
  3. Describe one scenario where peering is a better fit than a VPN gateway, and explain the key reason.
  4. Write two sentences that clearly separate “name resolution” from “network connectivity” in Azure.
  5. Given a requirement that says “must not traverse the public internet,” explain which service you would choose and why.

Further Reading