Cloud networking uses the same ideas as networking in a home or office. Learning them once makes every later chapter easier.

Computers need addresses

For one computer to send information to another, each needs an address, just as a letter needs a street address. On the internet and inside private networks this address is called an IP address, short for Internet Protocol address. The most common form, IPv4, is written as four numbers separated by dots, such as 10.0.1.4. A newer form, IPv6, uses much longer addresses and exists because the world has nearly run out of IPv4 addresses.

Public and private addresses

Some addresses work on the open internet and are called public. Others are reserved for use inside private networks and are never routed on the open internet. Three ranges are set aside for private use: addresses beginning with 10, addresses from 172.16 through 172.31, and addresses beginning with 192.168. Azure virtual networks normally use these private ranges, which means the addresses you choose can be reused by many different organizations without clashing, because each lives inside its own walls.

Networks, subnets, and CIDR notation

A network is a group of addresses that belong together. A subnet is a smaller slice of that group, like a floor in the building. To describe the size of a network we use CIDR notation, which writes an address followed by a slash and a number, for example 10.0.0.0/16. The number after the slash says how many of the 32 bits in an IPv4 address are fixed to identify the network. The remaining bits are free to number individual machines. A smaller number after the slash means a larger network. A /16 holds 65,536 addresses, a /24 holds 256, and a /28 holds 16.

Routers, gateways, and firewalls

A router decides which path a packet should take to reach its destination, like a traffic officer at an intersection. A gateway is a router at the edge of a network that connects it to another network. A firewall is a guard that checks each packet against a rulebook and allows or blocks it. Azure provides each of these as software services, so you configure them rather than plug in physical boxes.

Ports and protocols

An address identifies a machine, but a machine runs many programs. A port number identifies which program should receive the traffic. Web servers usually listen on port 80 for plain traffic and 443 for encrypted traffic, secure remote administration on Linux uses port 22, and remote desktop on Windows uses 3389. A protocol, such as TCP or UDP, defines the rules of the conversation. Firewall rules in Azure are written in terms of addresses, ports, and protocols.

The virtual network is the fundamental building block for private networking in Azure, and almost every design starts with it.

The core definition

An Azure Virtual Network, usually called a VNet, is a logically isolated network in the Azure cloud that belongs to your subscription. Inside it you place resources such as virtual machines, container platforms, load balancers, and many platform services, and those resources talk to each other using private addresses. By default, nothing outside the VNet can start a conversation with something inside it, and the VNet cannot reach other VNets unless you explicitly connect them.

What a VNet gives you

Scope: region and subscription

A VNet belongs to exactly one region, such as Central India or West Europe, and exactly one subscription. It cannot stretch across regions. Resources in a VNet must be in the same region as the VNet, although the VNet spans all availability zones of its region. To connect networks in different regions you create separate VNets and link them with peering or gateways. This regional scope is one of the most important facts to remember when designing global applications.

Cost model

Creating a VNet and subnets is free. You pay for what you attach to it: virtual machines, public IP addresses, NAT gateways, firewalls, VPN gateways, and private endpoints each have their own charges. Data moving between VNets through peering, or leaving a region, is also billed. This means you can plan a rich network structure without paying for the structure itself, but the components inside it can become the largest part of a networking bill.

The first decision you make about a VNet is hard to change later, so it deserves the most careful thought.

Choosing the address space

When you create a VNet you give it one or more address ranges, called the address space, using the private ranges described earlier. The subnets you create must fit inside this address space. You can add more ranges later, but changing or removing a range that has peered connections or deployed resources can require disconnecting those connections first, which is disruptive. For this reason, plan address space as though you will live with it for years.

The overlapping address problem

Two networks that use the same addresses cannot be connected directly, because a router cannot tell which network a given address belongs to. This is the most common and most painful design mistake in cloud networking. It usually appears when an organization creates VNets with default ranges without coordination, then later wants to link them to each other or to the on-premises network, and discovers overlaps. Fixing it means re-addressing running systems, which can take months.

A practical planning method

Not too big, not too small

Planning too small forces painful expansions. Planning too large wastes the private address space that your organization shares across every environment. A balanced approach is to give each VNet enough room for expected growth plus a comfortable margin, while avoiding giant ranges for networks that will hold a handful of machines. Remember that platform services such as container clusters and some PaaS offerings consume many addresses per instance, which can quickly exhaust a small subnet.

IPv6 and dual-stack

Azure supports dual-stack VNets, which carry both IPv4 and IPv6 addressing at the same time. IPv6 may be required by regulation, by mobile customers on IPv6-only networks, or by large-scale designs. Dual-stack increases design and testing effort, because security rules, routes, and monitoring must be considered for both address families. Introduce it deliberately, not by accident.

Subnets divide your VNet into zones that you can secure, route, and delegate separately.

Why subnets exist

Resources with similar roles and security needs belong together. A web tier may need to be reachable from the internet through a load balancer, an application tier may be reachable only from the web tier, and a database tier may be reachable only from the application tier. Placing each tier in its own subnet lets you attach different security rules and routes to each one and keeps the structure easy to understand.

The five reserved addresses

Azure reserves five addresses in every subnet. The first address is the network address, the second is used by the default gateway of the subnet, the third and fourth are used internally by Azure for mapping platform DNS, and the last is the broadcast address. This means a /24 subnet with 256 addresses has 251 usable ones, and a /28 with 16 has only 11. Account for this when sizing small subnets.

Subnet delegation

Some platform services need a subnet to themselves. Delegation hands a subnet to a specific service, such as a managed database, an app platform, or a container service, and lets that service create the network resources it needs inside it. A delegated subnet normally cannot be used for ordinary virtual machines. Plan separate subnets for delegated services and give them room to grow, because the service may add instances over time.

Subnets with required names

Several Azure services demand a subnet with a fixed name and a minimum size. Treat these as reserved from the start of your design.

How many subnets?

Resist both extremes. One giant subnet for everything makes security rules messy, because you cannot separate roles by address. Dozens of tiny subnets make operations complicated and waste address space. A good rule is to create subnets according to security and routing boundaries: one for each tier or service type that needs distinct rules, plus the special subnets that Azure services require.

A VNet is software-defined. Understanding the parts around it explains why Azure networking behaves the way it does.

Software-defined networking

Behind the scenes there are no physical cables dedicated to your VNet. Azure uses software-defined networking: the physical network of the data center carries traffic for many customers, and a software layer on each host machine adds and removes labels that keep customers’ traffic separated, applies security rules, and enforces routing. This is why you can create networks in seconds and change them without touching hardware.

The building blocks

flowchart TD
  SUB["Subscription"] --> VNET["Virtual Network 10.0.0.0/16"]
  VNET --> S1["Web Subnet 10.0.1.0/24"]
  VNET --> S2["App Subnet 10.0.2.0/24"]
  VNET --> S3["Data Subnet 10.0.3.0/24"]
  S1 --> NIC1["Network Interface and VM"]
  S2 --> NIC2["Network Interface and VM"]
  S3 --> PE["Private Endpoint for a Database"]
  NSG["Network Security Group"] -. filters .-> S1
  NSG2["Network Security Group"] -. filters .-> S3
  RT["Route Table"] -. steers .-> S2
        

Control plane and data plane

As with other Azure services, the control plane handles management actions such as creating a subnet or changing a rule, while the data plane carries your actual traffic. Configuration changes travel through Azure Resource Manager and are programmed into the software layer on the hosts, after which traffic flows without further involvement of the management system. If the portal is briefly unavailable, existing traffic keeps flowing.

The special platform address

Inside every VNet, a well-known platform address, 168.63.129.16, provides services such as Azure-provided name resolution and health probes for load balancers. You do not allocate it, but it is real, and blocking it with overly strict rules can break name lookups and load balancer health checks in confusing ways.

Following a single message from one machine to another shows how rules, routes, and names combine.

Step one: the name becomes an address

A program on one virtual machine wants to talk to a machine called orders-app. First it asks DNS for the address. The answer may come from Azure-provided resolution, from a private DNS zone linked to the VNet, or from a custom DNS server you configured. Many network problems that look like blocked traffic are in fact failed name lookups.

Step two: the sending host checks outbound rules

The packet leaves the application and reaches the virtual network card. The software layer on the host examines it against the outbound security rules that apply to the sender, both on the network interface and on the subnet. If a rule denies it, the packet is dropped right here, before touching the physical network.

Step three: the route is chosen

The software layer consults the route table that applies to the sender’s subnet. Azure builds a default set of system routes so that traffic inside the VNet goes directly to the destination, traffic to peered VNets and gateways follows connections you created, and traffic to unknown addresses goes toward the internet unless you override it. If you attached custom routes, the most specific matching route wins, and custom routes beat system routes when the specificity is equal.

Step four: delivery and inbound checks

The packet is encapsulated, meaning wrapped with extra labels that keep your traffic separate from other customers, and carried across the physical network to the host that runs the destination machine. There, inbound security rules for the receiver’s subnet and network interface are checked. If they allow it, the packet is handed to the destination program, and the reply follows the same journey in reverse. Security rules are stateful, which means that when an inbound request is allowed, its response is automatically allowed back without a separate rule.

sequenceDiagram
  participant A as App on VM A
  participant D as DNS
  participant H1 as Host of VM A
  participant H2 as Host of VM B
  participant B as App on VM B
  A->>D: Where is orders-app
  D-->>A: Private address 10.0.2.5
  A->>H1: Send packet to 10.0.2.5
  H1->>H1: Check outbound security rules
  H1->>H1: Choose route from route table
  H1->>H2: Deliver across the Azure network
  H2->>H2: Check inbound security rules
  H2->>B: Hand packet to the application
  B-->>A: Reply returns automatically
        

Why this matters

When you understand the order of checks, troubleshooting becomes a short list: does the name resolve, is the outbound rule allowing it, does the chosen route point where you expect, and does the inbound rule allow it. Each question can be answered with built-in diagnostic tools, which we cover in the monitoring chapter.

Network security groups are the basic firewall of a VNet. Used well, they implement the principle of least privilege at the network level.

What a network security group is

A network security group, shortened to NSG, is a collection of security rules that allow or deny network traffic. You attach it to a subnet, to a network interface, or both. Each rule has a priority number, a direction, a source, a destination, a port range, a protocol, and an action. Rules are checked in order of priority, from the lowest number to the highest, and the first match decides the outcome. Custom rule priorities range from 100 to 4096.

Default rules

Every NSG includes default rules that you cannot delete but can override with higher-priority rules. They allow traffic between resources within the VNet, allow traffic from the Azure load balancer health probes, allow outbound traffic to the internet, and deny all other inbound traffic. This is why a new virtual machine with no public address is reachable from inside the VNet but not from outside.

Service tags and application security groups

Writing rules with raw address lists is fragile. A service tag is a named group of address prefixes managed by Microsoft for a service, such as storage or the internet, so that you write rules by name and Microsoft keeps the address lists current. An application security group, abbreviated ASG, lets you group network interfaces by role, such as web servers or database servers, and write rules between groups instead of between addresses. When a machine joins the group, the rules apply automatically.

Where to attach them

A common approach is to attach NSGs at the subnet level for consistent protection, and use network interface level rules only for exceptions. When both exist, inbound traffic is checked first against the subnet rules and then against the interface rules, while outbound traffic is checked first at the interface and then at the subnet. Both must allow the traffic, which makes the combined result stricter than either one alone, and is a frequent source of confusion.

Routing decides where each packet goes next. In Azure it works automatically for simple cases and gives you full control when you need it.

System routes

Azure creates default routes for every subnet without any action from you. They send traffic for the VNet address space directly to the destination inside the VNet, traffic for the internet to the internet exit, and traffic for certain private ranges that you do not use to nowhere. When you create peering, add gateways, or enable certain features, Azure adds more system routes automatically.

User-defined routes

When you need to override the default behavior, you create a route table and attach it to a subnet. A route has an address prefix and a next hop type. Common next hop types include a virtual appliance, which is a machine or firewall that forwards traffic, a virtual network gateway for connections to other networks, the virtual network itself, the internet, and none, which drops the traffic. The most frequent use is forcing outbound internet traffic through a central firewall by creating a route for all addresses with a next hop of that firewall.

How a route is selected

When several routes match, the most specific prefix wins. A route for a narrow range beats a route for a broad range. If the prefixes are identical, Azure prefers user-defined routes over routes learned through BGP, and BGP routes over system routes. Understanding this ordering explains why adding one small route can change the path of just a few machines while everything else continues as before.

Dynamic routing with BGP

Border Gateway Protocol, abbreviated BGP, lets networks announce which addresses they can reach so that routes update automatically instead of being typed by hand. VPN gateways and ExpressRoute use BGP to learn on-premises routes, and Azure Route Server lets virtual appliances exchange routes with the VNet. This removes manual maintenance in large environments, but it also means that a mistaken announcement from one network can redirect traffic, so route filtering and monitoring are important.

Forced tunneling and inspection

Many organizations require all outbound traffic to pass through a central inspection point. This is called forced tunneling when the traffic is sent back to the on-premises network, or simply centralized egress when it passes through a firewall in Azure. It improves visibility and control but adds latency, a possible bottleneck, and a single point of failure, so size and replicate the inspection layer accordingly.

How your resources reach the internet, and how the internet reaches them, is one of the areas that changed most in recent years.

Inbound: public IP addresses and load balancers

For something inside your VNet to be reachable from the internet, it needs a public path. You can attach a public IP address directly to a machine, but a safer approach is to place a load balancer, application gateway, or other front door service in front, keep the machines on private addresses only, and expose just that front door. This limits the attack surface and lets you add inspection, encryption, and scaling in one place.

Outbound: the end of implicit access

Historically, any virtual machine in a VNet could reach the internet even without an explicit outbound configuration, because Azure quietly gave it a shared, unpredictable public address. This behavior is called default outbound access. Microsoft has been retiring it: new virtual networks are being created as private by default, and from a retirement date announced for 31 March 2026, new or redeployed machines that depend on the implicit behavior may lose outbound internet connectivity. Existing machines are expected to keep working for now, but depending on legacy behavior is risky. The lesson is that outbound connectivity should always be explicit.

The three explicit options

NAT Gateway in depth

NAT stands for network address translation, a method of letting many private addresses share a small number of public addresses when talking to the internet. A NAT Gateway is a managed service that you attach to one or more subnets. All outbound traffic from those subnets leaves through the gateway’s public addresses, so you can give partners a short, stable list of addresses to allow. Replies are accepted only for connections that your machines started, so it does not allow unsolicited inbound traffic. In January 2026 a newer StandardV2 version became generally available, offering zone redundancy so that outbound connectivity survives the loss of a single availability zone, double the throughput of the earlier version, and dual-stack support for both IPv4 and IPv6, at the same price as the Standard version. It requires matching StandardV2 public IP addresses.

Port exhaustion

Every outbound connection through a shared address uses a port number, and an address has a limited pool of them. Applications that open huge numbers of short-lived connections to the same destination can run out, causing intermittent failures. NAT Gateway handles this better than older mechanisms by allocating ports dynamically across the subnet, and adding more public addresses increases the pool. Reusing connections in your applications is the most effective remedy.

flowchart LR
  VM1["VM in Private Subnet"] --> NG["NAT Gateway"]
  VM2["VM in Private Subnet"] --> NG
  NG --> PIP["Static Public IP Addresses"]
  PIP --> NET["Internet Service"]
  NET -. replies to established connections only .-> NG
        

Peering connects two VNets so they behave as one network for traffic, using the private Microsoft backbone.

What peering does

Peering creates a direct link between two VNets. Machines in either one can reach machines in the other using private addresses, with the same low latency and high bandwidth as inside a single VNet, and without passing through a gateway or the public internet. Regional peering connects VNets in the same region, and global peering connects VNets in different regions. Peering can also connect VNets that belong to different subscriptions and even different tenants, if both sides approve.

Peering is not transitive

This is the rule to remember. If VNet A is peered to VNet B, and VNet B is peered to VNet C, then A and C cannot talk to each other through B by default. To allow it, you either create a direct peering between A and C, or you route the traffic through a firewall or router placed in B. This property keeps networks isolated unless you say otherwise, but it surprises teams who expect automatic chaining.

Peering settings that matter

Rules and costs

The two VNets must not have overlapping address spaces. Peering must be created in both directions, one from each side, and both must be connected for traffic to flow. Data transfer across peering is billed per gigabyte, with higher rates for global peering than regional peering, so chatty applications across regions can become expensive. Always check the current pricing and limits pages, because the number of peerings per VNet and prices evolve.

When many networks must connect, an organized topology keeps security and operations manageable.

The hub-and-spoke pattern

In hub-and-spoke, one central VNet, the hub, hosts shared services such as the firewall, the gateway to on-premises networks, the bastion host, and DNS. Several spoke VNets, each holding a workload or environment, are peered to the hub only. Traffic between spokes, or between a spoke and the outside world, passes through the hub, where it can be inspected and logged. This gives you one place to enforce policy and avoids duplicating expensive shared components in every workload network.

flowchart TD
  ONP["On-premises Network"] --- GW["VPN or ExpressRoute Gateway"]
  subgraph HUB["Hub VNet"]
    GW --> FW["Azure Firewall"]
    BAS["Azure Bastion"]
    DNSR["DNS Private Resolver"]
  end
  FW --- SP1["Spoke 1 Production App"]
  FW --- SP2["Spoke 2 Data Platform"]
  FW --- SP3["Spoke 3 Development"]
  FW --> INT["Internet via controlled egress"]
        

Azure Virtual WAN

Azure Virtual WAN is a managed service that builds and operates the hub for you and adds automated branch connectivity, site-to-site VPN, ExpressRoute, and transitive routing between connected networks. It suits large organizations with many branches and regions, where running your own hubs would require significant manual effort. The trade-off is less low-level control and a different pricing model.

Azure Virtual Network Manager

Azure Virtual Network Manager is a governance service for managing many VNets at scale. You group VNets by subscription, tag, or other criteria into network groups, and then apply connectivity configurations, such as hub-and-spoke or mesh, and security admin rules centrally. Security admin rules are evaluated before NSG rules and can enforce baseline protection, such as blocking certain ports everywhere, which individual teams cannot override. This turns network policy from a hope into a guarantee.

Most organizations keep some systems outside Azure. Hybrid connectivity makes both worlds feel like one network.

Site-to-site VPN

A site-to-site VPN uses a VPN Gateway in a dedicated gateway subnet to build encrypted tunnels across the public internet to a device in your office or data center. It is quick to set up, relatively inexpensive, and good for moderate bandwidth. Performance depends on the internet path, so latency and throughput can vary. Gateways can be deployed in zone-redundant form and in active-active configuration for better resilience.

Point-to-site VPN

Point-to-site connections let an individual computer, such as an engineer’s laptop, establish an encrypted tunnel into the VNet. It is useful for remote administration and small teams, but it is not intended as a permanent solution for large numbers of users, where private access through identity-based services is usually a better fit.

ExpressRoute

ExpressRoute provides a private, dedicated connection from your network to Microsoft through a connectivity provider. Traffic does not travel over the public internet, which gives more predictable latency, higher bandwidth options, and a service level agreement. It is the common choice for large data transfers, regulated industries, and mission-critical hybrid systems. It costs more and takes longer to provision than VPN.

Resilience patterns

Critical environments often use ExpressRoute as the primary path with a site-to-site VPN as a backup, or two ExpressRoute circuits in different locations. Dynamic routing with BGP lets the network switch to the backup path automatically when the primary fails. Test these failovers regularly, because a backup that has never been exercised often fails on the day it is needed.

Storage, databases, and many other Azure services have public addresses by default. Service endpoints and Private Link let your VNet reach them privately.

The problem

Platform-as-a-service offerings such as storage accounts, managed databases, key vaults, and messaging services are reached through public endpoints. Even though traffic to them from Azure resources stays on the Microsoft network, the services are still addressable from the internet, and your firewall rules must manage that exposure. Many organizations want the services to be reachable only from their private networks.

Service endpoints

A service endpoint extends your subnet’s identity to a supported service, so the service can be configured to accept connections only from that subnet. Traffic takes an optimized path over the Microsoft backbone. However, the service still has its public address, and traffic from on-premises networks does not benefit from the endpoint. It is simple and free, but it is a subnet-level trust feature, not true private addressing.

Private endpoints and Private Link

A private endpoint places a network interface with a private IP address from your subnet in front of a specific service instance, such as one particular database server. Azure Private Link is the technology behind it. Your applications connect to that private address, the traffic stays entirely inside your network and the Microsoft backbone, and you can disable the public endpoint of the service completely. Because the endpoint is just an address in your subnet, it is reachable from peered networks and from on-premises networks over VPN or ExpressRoute, and NSG and route policies can apply to it, subject to the feature settings.

VNet integration versus private endpoints

These two ideas are often confused. Private endpoints control inbound access to a service from your network. VNet integration or injection places a service’s outbound traffic or instances in your network, for example an app platform sending its calls through your subnet, or a managed database server deployed into a delegated subnet. Some services support one, some the other, and some both. Read the service’s networking documentation to learn which applies to your design, as we saw with managed databases that offer both a private access mode and private endpoints.

flowchart LR
  APP["Application VM in Your Subnet"] --> PEP["Private Endpoint 10.0.3.10"]
  PEP -->|Private Link over Microsoft backbone| SVC["Platform Service Instance"]
  ONP["On-premises Client"] -->|VPN or ExpressRoute| PEP
  PUB["Public Internet"] -. blocked when public access is disabled .-> SVC
        

Names glue everything together. Most mysterious networking faults are actually naming faults.

Azure-provided DNS

By default, machines in a VNet use a DNS service provided by Azure, reachable at the special platform address mentioned earlier. It resolves the internal names of machines in the same VNet and resolves public internet names. It needs no setup, but it does not resolve names across separate VNets or from on-premises networks, and it offers limited control.

Azure Private DNS zones

A private DNS zone is a DNS domain visible only inside the VNets that you link to it. It is the standard way to host names for internal services and is essential for private endpoints, because the public name of a service, such as the name of a database server, must resolve to the private address when queried from inside your network. Linking the same private zone to several VNets lets them all resolve the same private names. Auto-registration can add machine names to the zone automatically.

Custom DNS servers and DNS Private Resolver

Organizations with existing DNS infrastructure may point their VNets to their own DNS servers. This works but adds machines to operate and patch. Azure DNS Private Resolver is a managed service that fills the gap: an inbound endpoint lets on-premises networks resolve Azure private names, and outbound endpoints with forwarding rules let Azure machines resolve on-premises names, without running your own forwarders.

Spreading traffic across machines gives you scale and resilience, and Azure offers several services for different layers.

Layers of load balancing

Networks are described in layers. Layer 4 deals with addresses and ports, and does not look inside the messages. Layer 7 understands application messages such as web requests and can decide based on the web address, headers, or cookies. Azure provides different services for each, and often you combine them.

Public versus internal

A public load balancer has an internet-facing address and distributes incoming traffic to private machines. An internal load balancer has only a private address inside your VNet, and distributes traffic between tiers, such as from the web tier to the application tier. Using internal load balancers between tiers keeps all inner traffic private and makes each tier independently scalable.

Health probes

A load balancer regularly checks each backend machine using a health probe, and sends traffic only to those that respond correctly. Choosing a probe that actually reflects the health of the application, rather than just the machine, prevents sending users to a machine whose application has failed. Remember that probes come from the platform address, so security rules must allow them.

No single control is enough. Strong designs stack several layers so that one failure does not become a breach.

Azure Firewall

Azure Firewall is a managed, scalable, stateful firewall that sits in its own subnet, usually in the hub. Unlike an NSG, which works at the level of addresses and ports, it can filter by domain names, categories of websites, and, in higher tiers, inspect encrypted traffic and detect known threats. It provides centralized logging of both allowed and denied traffic. It is the usual choice for controlling and recording outbound and east-west traffic across many spokes.

DDoS protection

A distributed denial of service attack floods a service with traffic from many sources to make it unavailable. Basic protection is automatically part of the Azure platform. Higher tiers of Azure DDoS Protection add tuning to your own traffic patterns, attack analytics, alerts, and cost protection for resources attached to protected VNets, which matters for internet-facing applications that cannot tolerate downtime.

Azure Bastion

Azure Bastion lets administrators connect to machines using a browser or a client tool through a managed service, without giving machines public addresses and without opening administrative ports to the internet. Connections travel over an encrypted channel, and sign-in can use organizational identity. It removes one of the most common attack paths in the cloud.

Web application firewall

A web application firewall inspects web requests for patterns such as injection attempts and cross-site scripting. It can run on Application Gateway or Front Door and protects the application layer, which network rules cannot see.

Zero trust thinking

The traditional idea was a hard outer shell and a soft inside: once you were in the network, you were trusted. Zero trust assumes that attackers may already be inside, so every request must be verified using identity, device health, and context, and every connection must be limited to what is needed. For networking, this means micro-segmentation with subnets and security rules, private endpoints instead of public exposure, central logging, and identity-based access rather than address-based trust.

You cannot protect or fix a network you cannot see. Azure includes a toolbox that makes the invisible visible.

Azure Network Watcher

Network Watcher is the central collection of diagnostic and monitoring tools for VNets. It does not carry your traffic. It observes and tests. Its tools answer specific questions, and learning which tool answers which question saves hours.

Flow logs

Flow logs record information about the traffic that passes through your network, such as source and destination addresses, ports, protocols, and whether the traffic was allowed or denied. Historically these were collected at the NSG level. Microsoft is steering customers toward virtual network flow logs, which are collected at the VNet, subnet, or network interface level and cover traffic that older NSG-based logs could miss. Check Microsoft’s current retirement notices for NSG flow logs and plan your migration accordingly. Flow logs feed into traffic analytics, which turns raw records into charts of top talkers, blocked attempts, and unusual patterns.

Metrics and alerts

Azure Monitor collects metrics from gateways, firewalls, load balancers, and NAT gateways. Useful signals include gateway tunnel status, bandwidth utilization, firewall throughput and rule hits, load balancer health probe status, and NAT gateway connection and port usage. Alerts on these signals tell you about problems before users do.

Reusable patterns save design time. Known anti-patterns save outage time.

Helpful patterns

flowchart LR
  U["Users"] --> FD["Front Door and WAF"]
  FD --> AG["Application Gateway in Web Subnet"]
  AG --> APP["App Tier Subnet"]
  APP --> DATA["Private Endpoints in Data Subnet"]
  APP --> FW["Hub Firewall for Outbound"]
  FW --> NET["Internet or Partners"]
  ONP["On-premises"] --- GW["Gateway in Hub"]
  GW --- APP
        

Frequent anti-patterns

A well-designed network performs predictably and survives failures. Knowing the boundaries helps you design inside them.

What determines network speed

Within a VNet, there is no artificial bandwidth limit for the VNet itself. Speed is set by the size of the virtual machine, because each size has a maximum network throughput, and by physical distance and the number of hops between endpoints. A very large machine can move far more data than a small one. Choosing a larger size to get more bandwidth is common for data-heavy workloads.

Accelerated networking

Accelerated networking lets a machine’s network traffic bypass part of the host software layer by using hardware support on the physical server. It reduces latency, jitter, and CPU use and is available on most modern sizes. For performance-sensitive workloads it should be turned on and verified.

Latency and placement

Latency, the time a message takes to travel, grows with distance. Placing chatty components in the same region, and in the same availability zone when they exchange very frequent small messages, reduces delay. Proximity placement options exist for the most latency-sensitive cases. Always weigh latency benefits against the resilience you give up by concentrating resources.

Availability zones

A VNet spans all availability zones of its region, and subnets are not tied to a single zone. Zone resilience comes from the resources you place in it: spreading machines across zones, and choosing zone-redundant gateways, load balancers, and NAT gateways. A design that puts every machine in one zone is vulnerable no matter how robust the VNet is.

Limits and quotas

Azure sets limits for the number of VNets per subscription, subnets per VNet, peerings per VNet, rules per NSG, routes per route table, and private endpoints per network, among others. Many can be raised through support requests, and the numbers change over time. Check the official limits page during design for large estates, because a hard limit discovered late is expensive to work around.

The VNet is free, but what you attach to it is not. Knowing the main cost drivers prevents surprises.

The main cost drivers

Practical savings

Centralize expensive shared components in a hub rather than copying them into every workload network. Delete orphaned resources such as unattached public IP addresses, unused network interfaces, and forgotten gateways, which keep billing quietly. Use tags to attribute network costs to the teams that cause them. Compare the cost of a firewall in every spoke against one shared firewall with the added peering traffic, because the cheaper design depends on traffic patterns.

These illustrative composites show how the building blocks combine. They are examples, not descriptions of named customers.

These habits separate a calm, auditable network from a tangle that nobody wants to touch.

A calm, ordered method beats guessing when connectivity breaks at an inconvenient moment.

Work through the path in order

Every connectivity problem sits somewhere along the path between source and destination. Walk that path in order: does the name resolve, does the source’s outbound rule allow the traffic, does the route lead to the right next hop, does anything in between such as a firewall allow it, does the destination’s inbound rule allow it, and is the destination application actually listening? Using the diagnostic tools to answer each step removes guesswork.

flowchart TD
  P["Connection fails"] --> D{"Does the name resolve to the expected address?"}
  D -->|No| D1["Check DNS server setting, private DNS zone links, and forwarding rules"]
  D -->|Yes| O{"Does IP flow verify allow outbound traffic?"}
  O -->|No| O1["Fix NSG or admin rule on the source side"]
  O -->|Yes| R{"Does next hop point where expected?"}
  R -->|No| R1["Fix route table, peering state, or BGP routes"]
  R -->|Yes| F{"Does the firewall or appliance allow it?"}
  F -->|No| F1["Fix firewall rule or return path"]
  F -->|Yes| I{"Does the inbound rule allow it?"}
  I -->|No| I1["Fix NSG on the destination side"]
  I -->|Yes| A["Check that the application is listening and healthy"]
        

Common symptoms and likely causes

Asymmetric routing

Asymmetric routing occurs when the request goes through one path and the reply returns by another. Stateful devices such as firewalls, which track conversations, will drop replies they never saw the request for. The symptoms are connections that start and then hang. The fix is to make both directions use the same inspection path, usually by adjusting route tables on both sides.

A good network design decays quickly without ownership, rules about who may change what, and repeatable processes. This chapter covers the human and organizational side of virtual networking.

Who may change the network?

Azure uses role-based access control, abbreviated RBAC, to decide who can do what with each resource. Networking mistakes are among the most damaging, because one wrong rule or route can take down many applications or expose sensitive systems. A healthy approach is to give a small central network team the right to manage VNets, peerings, gateways, firewalls, and route tables, while application teams receive the right to join their resources to approved subnets but not to alter the structure. Azure has built-in roles for network contributors and a permission to join a subnet, which lets teams use a subnet without being able to change it.

Azure Policy as guardrails

Azure Policy evaluates resources against rules that you define and can block, audit, or automatically repair non-compliant ones. For networking, useful policies include denying public IP addresses on machine network interfaces, requiring a network security group on every subnet, restricting which regions can host VNets, requiring flow logs on production subnets, and demanding that platform services disable public access. Policies turn standards from documents that people forget into controls that the platform enforces.

Infrastructure as code

Clicking in a portal creates networks that nobody can reproduce or review. Defining them in templates, using tools such as Bicep, ARM templates, or Terraform, brings the benefits of software development: version history, peer review, automated testing, and the ability to rebuild an environment identically in another region. Networks defined this way also make disaster recovery planning realistic, because the recovery region can be created from the same definitions. Keep sensitive values such as shared keys out of templates and in a secrets service instead.

Tags, naming, and documentation

Consistent names make a network readable. A common convention includes the resource type, the workload, the environment, and the region, so that a name immediately tells an operator what it is and where it lives. Tags record owner, cost center, and criticality so that questions such as who owns this subnet and who pays for this gateway have instant answers. Keep a simple diagram of each environment up to date and store it next to the templates.

Change management

Protecting against accidents

Resource locks prevent accidental deletion of critical networking resources such as gateways, VNets, and firewalls. Alerts on changes to routes and security rules record who made them and when, using the activity log, so that unexpected edits are noticed quickly. Regular reviews of unused public addresses, orphaned interfaces, and outdated rules prevent slow drift.

No. Creating VNets and subnets is free. You pay for the resources attached to them, such as gateways, firewalls, NAT gateways, public addresses, private endpoints, and for data transfer across peerings and out of Azure.

No. A VNet exists in a single region. To connect regions, create a VNet in each and join them with global peering or gateways.

Yes, you can add ranges, but changing or removing ranges that are already used by subnets or peerings can require extra steps and brief disruption. Plan carefully at the start.

Most likely it relied on default outbound access, which is being retired for new and redeployed machines. Give the subnet an explicit outbound path such as a NAT Gateway, a firewall, or a load balancer with outbound rules.

Peering traffic stays on the Microsoft backbone network and does not cross the public internet. If your compliance rules require additional encryption between applications, add it at the application or platform level.

An NSG is a basic, free, distributed filter based on addresses, ports, and protocols, attached to subnets or interfaces. Azure Firewall is a managed central service that adds domain-based filtering, threat intelligence, and rich logging. Many designs use both.

If you only need to restrict a service to your subnets and are fine with the service keeping a public address, a service endpoint works. If you need a private address, access from on-premises, and the ability to disable public access entirely, use a private endpoint.

The private DNS zone is probably missing or not linked to the VNet doing the lookup, or a custom DNS server is not forwarding to Azure. Fix name resolution first.

Use hub-and-spoke when you want full control and have a moderate number of networks. Consider Virtual WAN when you have many branches and regions and prefer Microsoft to operate the hub and automate connectivity.

Enough to reflect security and routing boundaries, plus the special subnets Azure services require. Avoid one flat subnet and avoid dozens of tiny ones.

It provides isolation, but protection comes from the controls you add: segmentation rules, firewalls, private access, identity-based sign-in, and monitoring. Security is built in layers.

Follow the path in order: name resolution, outbound rule, route, intermediate devices, inbound rule, and finally the application. Use Network Watcher tools to test each step.

An Azure Virtual Network is the private, software-defined foundation on which almost every secure Azure design is built. It is free to create, bound to a region and subscription, and divided into subnets where you attach rules and routes. Around it sits a family of services: peering and gateways to connect networks, NAT Gateway and firewalls to control outbound traffic, private endpoints and private DNS to keep platform services off the public internet, load balancers to distribute traffic, and monitoring tools to see what is happening. The enduring lessons are simple. Plan addresses before you build, make every path explicit, segment by role, keep platform services private, and test your failovers. Because Azure networking evolves quickly, including the retirement of default outbound access, the arrival of zone-redundant NAT Gateway, and the move from NSG flow logs to virtual network flow logs, treat official documentation as the final word and treat this guide as your map.