An Azure Virtual Network, shortened to VNet, is your own private, isolated network inside Azure, where your cloud resources can talk to each other, to the internet, and to your own offices under rules that you control.

First, what is a network?

A network is a group of computers that can send messages to each other. Each computer has an address, which works like a house number, so that messages reach the right place. Special devices such as switches and routers pass the messages along, and rules decide who is allowed to talk to whom. In an office, a network technician plugs in cables and configures these devices. In the cloud, there are no cables for you to touch. Everything is created with software.

What a virtual network is

A virtual network is a software version of the network you would build in a data center. Azure creates it for you, and it is logically isolated from every other customer’s network, even though it runs on shared physical hardware. Inside your VNet, you choose the range of addresses, divide it into smaller sections called subnets, and place resources such as virtual machines, databases, and containers into those sections. Resources in the same VNet can talk to each other privately by default.

What a VNet gives you

• Isolation. Your network is private. Nobody else can see into it unless you allow it.
• Private communication. Resources inside the VNet talk to each other over private addresses.
• Segmentation. You can divide the network into subnets, such as web, application, and database areas, and control traffic between them.
• Connectivity. You can connect to the internet, to other VNets, and to your own offices or data centers.
• Filtering and routing. You decide which traffic is allowed and which path it takes.
• Integration. Many Azure services, such as virtual machines, scale sets, Kubernetes, and databases, plug into a VNet.

To see why VNets matter, picture what the cloud would be like without them.

The problem of the open street

If every cloud server sat directly on the public internet, anyone in the world could try to connect to it. Databases that should speak only to a few trusted programs would be reachable by strangers. Companies would have to guard every single machine against attacks. This is like building every house in a city on the main road with no walls and no gates.

The problem of tangled traffic

Large systems have many parts that must talk to each other: web servers, application servers, queues, caches, and databases. If all of them share one flat space, one weak machine can be used to attack the others. Teams need a way to put walls inside the system, so that a problem in one part cannot easily spread to the rest.

The problem of connecting to the old world

Most companies already have offices and data centers with their own networks and their own addressing plans. When they move to the cloud, they do not move everything on the same day. For months or years, the old and the new must work together. They need a private, controlled bridge between them, and that bridge needs a network on the cloud side that they can plan like their own.

What the VNet solves

Networking has its own small language. Learn these words once, and the rest of this guide and the Azure documentation will read easily.

Private and public addresses

Addresses come in two families. Public addresses are unique across the whole internet and are used to be found from outside. Private addresses are used only inside networks, and many different networks can use the same ones at the same time without any conflict. Three ranges are reserved for private use: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Almost every VNet is built from these ranges.

Stateful filtering

The rules in a network security group are stateful. If you allow a request to go out, Azure automatically allows the reply to come back. You do not need a second rule for the return trip. This keeps rule lists short and easy to read.

A virtual network is rarely alone. It sits in the middle of a small city of services that bring traffic in, send traffic out, connect it to other places, and keep it safe.

flowchart TD
    USERS["Users on the Internet"] --> AGW
    subgraph VNET["Virtual Network 10.0.0.0/16"]
        AGW["Application Gateway with firewall in its own subnet"]
        subgraph WEB["Web subnet 10.0.1.0/24"]
            W1["Web VM 1"]
            W2["Web VM 2"]
        end
        subgraph APPS["App subnet 10.0.2.0/24"]
            A1["Application VM"]
        end
        subgraph DATA["Data subnet 10.0.3.0/24"]
            PE["Private endpoint to the database"]
        end
        GW["GatewaySubnet 10.0.255.0/27 for VPN or ExpressRoute"]
    end
    AGW --> W1
    AGW --> W2
    W1 --> A1
    W2 --> A1
    A1 --> PE
    NSG["Network security groups on each subnet"] -.-> VNET
    W1 -.-> NAT["NAT Gateway for outbound traffic"]
    NAT --> OUT["Internet destinations"]
    ONP["On premises network"] -->|"VPN or ExpressRoute"| GW
    VNET |"VNet peering"| PEER["Peered VNet in another region or subscription"]
    

Read the diagram from the top. Users reach an application gateway, which sits in its own subnet and passes allowed requests to the web servers. The web servers talk to an application server in the next subnet, which reaches the database through a private endpoint in the data subnet. Network security groups filter the traffic at each step. Outbound requests to the internet go through a NAT gateway so that they leave from a stable address. Your on-premises network joins through the gateway subnet, and another VNet joins through peering.

The address and subnet layer

This is the skeleton. The address space gives the VNet its range, and subnets divide it. Every other component attaches to a subnet.

The filtering layer

Network security groups and, for deeper inspection, services such as Azure Firewall and web application firewalls decide which traffic is allowed. They are the guards at the gates and doors.

The routing layer

Azure creates default routes automatically. You can override them with route tables, for example to send all outbound traffic through a firewall. Routing decides which path a packet takes.

The connection layer

Peering, VPN gateways, ExpressRoute, and Virtual WAN join your VNet to other networks. They are the bridges and roads leading out of the neighborhood.

The name layer

DNS turns names into addresses. Azure provides DNS by default, and private DNS zones let you create your own internal names.

The management layer

Everything is created through Azure Resource Manager and can be managed with the portal, command line, or templates. Network Watcher and Azure Monitor provide visibility.

The address space is the single most important planning decision in a VNet. Once other things depend on it, it is hard to change.

Reading a CIDR range

An address range is written like 10.0.0.0/16. The first part is the starting address. The number after the slash tells you how many addresses the range holds. A smaller number after the slash means a bigger range. You do not need to calculate in your head. A few sizes cover most of what you will use.

Why usable is less than total

Azure keeps five addresses in every subnet for its own purposes: the first address names the network, the next is the default gateway, two more are used for Azure’s internal DNS mapping, and the last is the broadcast address. A /29 subnet with eight addresses therefore has only three left for your use. This catches many beginners who size subnets too tightly.

Choosing the private ranges

The three private ranges differ in size. The 10.0.0.0/8 range is huge, with over sixteen million addresses, and is the favorite for large companies. The 172.16.0.0/12 range holds about a million. The 192.168.0.0/16 range holds about sixty-five thousand and is common in home and small office networks. Azure also lets you use other ranges, but you should stay inside the private ones to avoid clashes with real internet addresses.

Addresses Azure does not allow

A few ranges cannot be used in a VNet because they have special meaning: multicast, broadcast, loopback, link-local, and the address Azure uses for its own internal DNS and health services. You will see an error if you try.

The golden rule: no overlaps

Two networks that must be connected cannot have overlapping address ranges. If your office uses 10.0.0.0/16 and your VNet also uses 10.0.0.0/16, a computer cannot tell which network a message is meant for. The same rule applies between VNets that you wish to peer and between VNets and the on-premises networks they connect to. The cheapest way to avoid this is to plan a single address map for the whole company, before building anything.

Subnets are where your resources actually live. Good subnet design makes security, growth, and troubleshooting much easier.

Why divide into subnets?

• Security zones. Different tiers get different rules. The data subnet can refuse everything except the application subnet.
• Organization. Resources with similar roles sit together, so you can find and manage them easily.
• Service requirements. Some Azure services need their own dedicated subnet.
• Routing control. A route table or NAT gateway can be attached to a subnet, affecting everything inside.

Special subnets with special rules

Several Azure services require a subnet of their own, sometimes with a required name or minimum size. Always check the current documentation, because requirements can change.

A typical layout

Sizing subnets

Count the resources you expect today, add what you might need in two or three years, and add room for upgrades, because rolling updates can briefly need extra addresses. Remember the five reserved addresses. Some services use many addresses: a Kubernetes cluster that gives every pod its own VNet address can use thousands. Plan generously, since a subnet that holds resources cannot easily be shrunk or moved.

Growing later

You can usually add a new address range to a VNet and create new subnets in it, even while the VNet is in use. Changing a subnet that already contains resources is limited. It is much easier to add new space than to fix cramped space, so keep part of your address range unassigned.

Let us follow one message from a virtual machine in one subnet to a virtual machine in another, and see what Azure does at every step.

sequenceDiagram
    participant A as VM A in the Web Subnet
    participant NA as NSG for the Web Subnet
    participant R as Azure Routing
    participant NB as NSG for the App Subnet
    participant B as VM B in the App Subnet
    A->>NA: Send a message to 10.0.2.4 on port 8080
    NA->>NA: Check outbound rules in priority order
    NA->>R: Allowed, pass on to routing
    R->>R: Choose the most specific matching route
    R->>NB: Deliver toward the App subnet
    NB->>NB: Check inbound rules in priority order
    NB->>B: Allowed, deliver the message
    B-->>A: The reply returns because the rules are stateful
    

Step by step

Default routes

Every subnet starts with system routes that Azure creates for you. They allow traffic to move between subnets in the same VNet, to the internet for any address not otherwise known, and, once you set them up, to peered networks and gateway-connected networks. You never see them in a table you wrote, but you can view them as the effective routes of a network interface.

Custom routes

Sometimes you need traffic to take a different path. A common example is sending all internet-bound traffic through a firewall first. You create a route table with a user-defined route and attach it to a subnet. The route says, “For this destination range, send traffic to this next hop.” Next hops can be a virtual appliance such as a firewall, a gateway, the VNet itself, the internet, or “none”, which drops the traffic.

Longest match wins

When several routes could apply, Azure chooses the most specific one, meaning the one with the longest prefix. A route for 10.0.2.0/24 beats a route for 10.0.0.0/16, which beats a route for everything. If prefixes are equal, user-defined routes win over routes learned from gateways, which win over system routes.

Network security groups are the main traffic filters inside a VNet. Understanding their rules and default behavior prevents most access problems.

What a rule contains

Each rule describes a kind of traffic and what to do with it. It has a name, a priority, a direction (inbound or outbound), a source, a destination, a protocol, a port, and an action: allow or deny. Priorities are numbers between 100 and 4096. A lower number is checked first, and as soon as a rule matches, no further rules are read.

The built-in default rules

These default rules have very large priority numbers, such as 65000 and above, so your own rules with smaller numbers always come first. The result is a sensible starting point: resources in the VNet can talk freely to each other, outsiders cannot get in, and the outside world is reachable for outbound traffic. Many security teams then add rules to tighten what is allowed inside the VNet too.

Where to attach a group

• On a subnet to apply the same rules to every resource inside it. This is the usual choice, since it is easy to see and hard to forget.
• On a network interface for exceptions that apply to one machine.
• When both exist, the traffic must pass both. For inbound traffic the subnet group is checked first, then the interface group. For outbound traffic the order is reversed.

Service tags and application security groups

Writing rules with long lists of addresses is tiring and fragile. Two features make rules readable. A service tag is a name for a group of addresses that Azure keeps up to date, such as Internet, VirtualNetwork, AzureLoadBalancer, or Storage. An application security group lets you give virtual machines a role name such as “web-servers” or “db-servers”, and then write rules between those names, no matter what addresses the machines have. When a new web server joins the group, the rules apply to it at once.

A sample rule set for a three-tier system

Most systems need to talk to the internet in two directions: letting users in, and letting servers reach out for updates, payments, and other services. Azure gives you several tools for each direction, and choosing wisely is part of good design.

Outbound: leaving the neighborhood

A virtual machine with only a private address still needs to reach outside services, for example to download a security update or call a payment provider. For this to work, the private address must be swapped for a public one on the way out, and swapped back on the way in. This swap is called source network address translation, or SNAT. It is the same trick your home router uses so that every phone and laptop in your house can share one public address from your internet provider.

Azure offers a few ways to do this outbound swap.

• A public IP address on the machine. The simplest way, but it also makes the machine reachable from outside unless rules block it. Fine for tests, rarely wise for production.
• A standard load balancer with outbound rules. Machines behind the load balancer share its public addresses for outbound traffic.
• A NAT gateway. A dedicated service attached to a subnet. Every machine in the subnet goes out through the gateway’s public addresses. This is the recommended choice for most new designs because it is simple and scales well.
• A firewall or virtual appliance. Traffic is sent there by a user-defined route, and the device does the translation and the inspection together.
• Default outbound access. In older setups, machines with no explicit outbound method were given a hidden, unstable public address by Azure. Microsoft has been moving away from this, and new virtual networks are being created without it. Treat it as something you should not depend on, and check the current announcements for the exact dates.

Why the NAT gateway is popular

A NAT gateway gives you a stable set of outbound addresses, which is useful when a partner asks you to add your addresses to an allowed list. It also blocks connections that start from the internet, because it only handles traffic that began inside. It works at the subnet level, so you attach it once and everything in that subnet benefits. You can give it one public address or several, or a block of addresses.

Port exhaustion

Each public address can keep only about sixty-four thousand simultaneous connections to the same outside destination, because each connection needs its own port number. A busy application that opens many short connections to one service can run out of ports, and new connections then fail in strange, random ways. The fixes are to add more public addresses to the gateway, to reuse connections instead of opening new ones, and to use private endpoints for Azure services so the traffic does not need translation at all.

Inbound: letting visitors in

For inbound traffic from the internet, you do not normally put a public address on every machine. Instead, you put a public entry point in front of them.

Public IP addresses

A public IP address is a separate Azure resource that you attach to a load balancer, gateway, firewall, or machine. Current designs use the Standard type, which is secure by default: it blocks all inbound traffic until a network security group explicitly allows it, and it supports availability zones. The older Basic type has been announced for retirement, so avoid it for new work and confirm the dates in current documentation.

A virtual network is not built once and forgotten. It moves through stages, from a planning sketch to a living, changing system, and finally to retirement. Knowing the stages helps you decide what to do when.

flowchart LR
    P["Plan the address map"] --> C["Create the VNet and subnets"]
    C --> S["Attach security groups and route tables"]
    S --> D["Deploy resources into subnets"]
    D --> L["Link to other networks by peering, VPN, or ExpressRoute"]
    L --> M["Monitor traffic and health"]
    M --> G["Grow, tighten rules, and clean up"]
    G --> M
    G --> R["Retire unused parts"]
    

The diagram shows a loop in the middle. After you deploy and connect things, you keep watching and adjusting. Growth and tightening happen again and again, and only at the very end do you retire parts that nobody uses.

Stage one: plan

Draw the address map, decide how many VNets you need, and decide how they will connect. Agree who owns each range. This is paper work, and it is the cheapest stage to make mistakes in.

Stage two: create

Build the VNet and its subnets using a template or code rather than clicking in the portal. Code can be reviewed, repeated, and stored. A network built by hand tends to drift away from what anyone remembers.

Stage three: protect

Attach network security groups and route tables before the first workload arrives, not after. A subnet that begins life with sensible rules never has a moment of being wide open.

Stage four: deploy and connect

Resources are placed in subnets and, if needed, the VNet is joined to others. Each new connection changes who can reach what, so rules should be reviewed whenever a connection is added.

Stage five: observe and adjust

This is the longest stage. You watch flow records, check for blocked traffic, review costs, and respond to changing needs. Address space is added, subnets are created, and unused rules are removed.

Stage six: retire

Delete what is no longer needed: old subnets, unattached public addresses, unused gateways, and forgotten peerings. Leftover pieces cost money and create risk, because nobody remembers what they are for.

What happens to data in transit

Traffic between resources inside a VNet travels on Microsoft’s network and does not cross the public internet. Even so, you should treat the network as something that can fail or be misused, and encrypt sensitive data with TLS between your own services. Traffic that crosses between datacenters on Microsoft’s backbone is typically protected by the platform, but you should check current documentation on exactly what is encrypted by default, since the details differ between features.

Data does not “live” in a VNet. A VNet stores no application data of its own. It only carries traffic. What it does keep is configuration: ranges, rules, routes, and connections. That configuration is what you protect and back up as code.

One VNet is rarely enough. Companies run many applications, many environments, and many regions. Peering joins separate VNets so they can talk privately.

What peering is

Peering creates a direct, private link between two VNets. Once connected, resources in each can reach those in the other using private addresses, as if they were in the same network. The traffic travels over Microsoft’s backbone, not the public internet, and it has low delay and high speed. Peering works between VNets in the same region and across regions, which is called global peering. It can also join VNets in different subscriptions and even in different Microsoft Entra tenants, with proper permissions.

Rules you must know

• No overlapping address space. Peered VNets must have different ranges.
• Peering is non-transitive. If A is peered with B, and B is peered with C, A cannot reach C through B. You must peer A with C directly or use a central device to route between them.
• Peering works in both directions only when both sides are set up. Each VNet needs its own link pointing at the other.
• Network security groups still apply. Peering does not remove your filters. The default rules treat the peered network as part of the virtual network, so you may need extra rules to restrict it.
• You pay for data that crosses a peering. Charges are per gigabyte, and they are higher for global peering. Check current prices.
• Limits exist. Each VNet can have a maximum number of peerings, so very large designs need a different approach. Confirm the current limit.

Gateway transit

If one VNet has a VPN or ExpressRoute gateway, other peered VNets can use it to reach your offices, instead of each building its own expensive gateway. The VNet with the gateway enables allow gateway transit, and the other enables use remote gateways. This is the heart of the most popular design pattern.

Hub-and-spoke

In a hub-and-spoke design, one central VNet, the hub, holds shared services such as the gateway, firewall, DNS, and management tools. Many spoke VNets, each for an application or team, are peered to the hub. Traffic between spokes is sent through the hub’s firewall using user-defined routes, so it is inspected and logged. This gives order, shared cost, and a single place to enforce rules.

Tools that help at scale

Azure Virtual Network Manager lets you group many VNets and apply connectivity and security rules to the whole group at once, instead of configuring each peering by hand. Azure Virtual WAN offers a Microsoft-managed network backbone with hubs that handle branches, VPNs, ExpressRoute, and VNet connections. Both are worth a look when you manage dozens of networks. The exact features and pricing change over time, so confirm them in current documentation.

Many companies keep part of their systems in their own offices or data centers. Hybrid connectivity joins those networks to the VNet so the two feel like one.

Site-to-site VPN

A VPN gateway is a service that sits in the gateway subnet and builds an encrypted tunnel across the public internet to a VPN device in your office. Everything that goes through the tunnel is scrambled, so even though the road is public, the content is private. It is quick to set up, relatively inexpensive, and good for smaller needs, backups, and as a standby path. Speed depends on the gateway size you pick, and internet quality affects delay and reliability.

Gateways come in several sizes, called SKUs. Larger ones give more throughput and more tunnels, and some can span availability zones. Names and limits change from time to time, so check current documentation before choosing.

Point-to-site VPN

A point-to-site connection lets a single laptop connect securely to the VNet from anywhere, for example a developer working from home. It uses the same gateway and signs the user in with certificates, Microsoft Entra ID, or similar means.

ExpressRoute

ExpressRoute is a private line between your premises and Microsoft, set up with a connectivity provider. It does not use the public internet, so it offers steadier delay, higher speeds, and a different security profile. It is often chosen for large data transfers, strict business needs, and systems that cannot tolerate internet unpredictability. It costs more and takes longer to arrange, because a physical circuit is involved.

Using both together

Many companies run ExpressRoute as the main path and a VPN as a backup. If the private line fails, traffic flows over the VPN. This combination needs careful routing so that traffic prefers the better path under normal conditions.

Routing between networks

Gateways can learn routes dynamically using a protocol called BGP, the Border Gateway Protocol. With BGP, your office and Azure tell each other which address ranges they hold, so new networks are discovered automatically. Without it, someone must update the lists by hand. BGP is strongly recommended for anything beyond a very small setup.

People remember names; computers need addresses. DNS is the service that connects the two, and when it breaks, everything seems broken even though the network is fine.

The default behavior

Every VNet comes with a built-in name service provided by Azure. It lives at the special address 168.63.129.16, which is reachable from inside every VNet. Virtual machines in the same VNet can find each other by name without extra setup. For many small systems this is enough.

Private DNS zones

When you want your own internal names, such as orders.internal.example, you use an Azure Private DNS zone. You link the zone to one or more VNets, and only those VNets can see the names. You can add records yourself, or switch on auto-registration so virtual machines add their own names when they start and remove them when they are deleted.

Custom DNS servers

If you have your own DNS servers, for example Windows domain controllers, you can tell the VNet to use them instead. This is common in hybrid companies that need names from their offices to resolve in Azure and the other way around. Be careful: if the custom servers are unreachable, name lookups fail for every machine in the VNet. Always run at least two, in different places.

Azure DNS Private Resolver

The DNS Private Resolver is a managed service that forwards DNS questions between Azure and your on-premises network. It has inbound endpoints that your office servers can ask, and outbound endpoints with rules that decide where to send specific names. It replaces the old habit of running forwarding servers on virtual machines, which needed patching and care.

DNS and private endpoints

This is where beginners most often stumble. When you create a private endpoint for a storage account, the service name, such as mystorage.blob.core.windows.net, must now resolve to the private address in your subnet instead of the public one. That requires a private DNS zone for that service, linked to your VNet. If you forget, the name still resolves to the public address, and your traffic goes the wrong way or gets blocked.

Azure storage, databases, and many other services normally have public addresses. There are two ways to reach them from your VNet without exposing that traffic more than necessary.

Service endpoints

A service endpoint is a switch you turn on for a subnet. It tells Azure that traffic from this subnet to a given service, such as Storage, should travel over Microsoft’s backbone and should carry the subnet’s identity. The service can then be locked down so it accepts requests only from chosen subnets. The destination still has a public address, but it refuses everyone else.

Private endpoints and Private Link

A private endpoint goes a step further. It creates a network interface with a private address inside your subnet that maps to one specific resource, such as one storage account or one database server. Azure Private Link is the technology behind it. Your applications connect to that private address, and the service’s public access can be turned off completely. The private endpoint can also be reached from peered VNets and from your offices over a VPN or ExpressRoute.

Which to choose

For quick, low-cost protection inside one region, service endpoints are easy. For stricter security, hybrid access, and the ability to close the public door entirely, private endpoints are usually the better answer. Many security standards now call for private endpoints on data services. Microsoft’s guidance and the supported services list change, so check current documentation.

Private Link for your own services

You can also offer your own service to other VNets or other companies through Private Link. Consumers create a private endpoint that points to your service behind a standard load balancer. This is a clean way to share an application without peering whole networks or exposing address ranges.

Network policies on private endpoint subnets

By default, network security group and route rules do not fully apply to traffic going to private endpoints. A setting on the subnet can turn on those network policies, so your rules and routes also affect the private endpoint traffic. Check current behavior before depending on it.

No single control makes a network safe. Good security stacks several layers so that when one fails, another still stands. This idea is called defense in depth.

Layer by layer

Network security groups versus Azure Firewall

These two are not rivals; they do different jobs. A network security group is a simple, free filter that works on addresses, ports, and protocols, and it is attached to subnets and interfaces. Azure Firewall is a managed, central service that understands names, categories of websites, and threat intelligence, keeps logs in one place, and works across many VNets. Most serious designs use both.

Zero trust thinking

The old idea was that anything inside the network was trusted. Modern thinking assumes that an attacker may already be inside, so every connection should be checked, and every service should allow only what it needs. Segmentation, private endpoints, and identity checks all support this approach.

A network is like electricity: nobody thinks about it until it fails, and then nothing else works. Planning for failure is part of the design.

What a VNet itself survives

A VNet is a regional construct, and the platform keeps it running across the region’s datacenters. A VNet and its subnets are not tied to one availability zone; they span all the zones in the region. That means a single zone failure does not delete your network. What can fail are the things you place in it, and the paths that connect it.

Availability zones

Many regions have separate physical locations called availability zones, each with its own power, cooling, and networking. Spreading machines, gateways, firewalls, and load balancers across zones protects you from the loss of one location. When you choose public IP addresses, gateways, and firewalls, pick the zone-redundant options where they are offered.

Multiple regions

If a whole region has trouble, only a design with another region can continue. This usually means a second VNet in another region with its own copies of the application, peered or connected to the first, and a global traffic manager such as Front Door or Traffic Manager choosing which region serves users. Address ranges for the two regions must not overlap.

Redundant connections

• Gateways: use zone-redundant gateway options, or an active-active setup with two tunnels.
• ExpressRoute: use two circuits, ideally via different providers or locations, and consider a VPN as backup.
• Firewalls: deploy in zone-redundant mode so a single failure does not cut all traffic.
• DNS: run at least two custom servers or use the managed resolver.
• Outbound access: zone-aware NAT gateway setups should be checked against current guidance, since a NAT gateway attached to a subnet has its own zone behavior.

The network as a single point of failure

Central pieces, such as a hub firewall, carry traffic for many applications. If they fail, everything behind them is affected. Size them for peak load with room to spare, spread them over zones, and test failures regularly, not only on paper.

Infrastructure as code for recovery

If a network is lost or damaged, rebuilding it from stored templates is much faster and safer than remembering what it looked like. Keep all network definitions in version control. Resource locks can also protect critical network parts from accidental deletion.

A network you cannot see is a network you cannot fix. Azure gives you tools to watch traffic, test connections, and find out exactly why something is blocked.

Network Watcher

Network Watcher is a collection of diagnostic tools that is enabled per region. It is the first place to go when something does not connect. Its most useful tools are:

Flow logs

A flow log is a record of the connections that passed through the network: who talked to whom, on which port, and whether the traffic was allowed. Historically, flow logs were collected at the network security group level. Microsoft has been introducing virtual network flow logs, which record traffic at the VNet level and cover more cases, and has announced a move away from the older group-level logs. The exact timeline for retirement and the migration steps should be checked in current documentation before you plan.

Flow logs are stored in a storage account. With Traffic Analytics, the logs are processed in a Log Analytics workspace to show top talkers, busiest ports, blocked traffic, and traffic between regions, in charts you can browse.

Other signals to collect

• Metrics from gateways, firewalls, NAT gateways, and load balancers, such as throughput, dropped packets, and SNAT port use.
• Diagnostic logs from firewalls and gateways sent to a Log Analytics workspace.
• Activity logs showing who changed a network resource and when.
• Alerts for events such as a tunnel going down, a sudden traffic spike, or a configuration change.

What to watch

The VNet is free, but the services around it are not. Network costs often surprise teams because they are spread across many small meters.

What costs nothing

• The virtual network, its subnets, and the address space.
• Network security groups, route tables, and application security groups.
• Traffic between resources inside the same VNet and the same region, as a general rule.
• Inbound data from the internet into Azure.

What costs money

Where the big surprises come from

• Data crossing regions. A chatty application split across two regions can create large peering and egress bills.
• Forgotten test gateways. A gateway or firewall left running in a test subscription costs money every hour of every day.
• Everything through the firewall. Sending bulk traffic, such as backups, through a firewall billed per gigabyte adds up quickly. Consider exceptions where policy allows.
• NAT gateway for Azure services. Traffic to storage through a NAT gateway is charged per gigabyte, but a private endpoint or service endpoint can avoid that path.

A simple routine

Experienced architects record their big choices as short decision notes. Here are common decisions for virtual networks, written in that style, so you can see how the reasoning goes.

Patterns that work

Anti-patterns to avoid

This chapter gathers the lessons that most teams learn the hard way. Learn them the easy way, by reading them first.

Best practices

• Plan addresses first. Build a single register and check every new range against it.
• Give subnets room. Leave at least a third of the address space free for growth.
• Segment by role. Use separate subnets for web, application, data, management, and platform services.
• Attach a network security group to every subnet that supports it, and write rules by role using application security groups and service tags.
• Keep machines private. Give public addresses only to front-door services.
• Use private endpoints for data services and turn off public access where possible.
• Control outbound traffic. Use a NAT gateway or firewall and avoid reliance on any default outbound behavior.
• Use code. Define networks in templates and deploy through reviewed pipelines.
• Log and alert. Enable flow logs, diagnostics, and alerts for connectivity and configuration changes.
• Use policy. Enforce rules such as required tags, allowed regions, and forbidden public addresses.
• Document the intent. Write why each rule or route exists, in its name or description.
• Test failure. Practice losing a zone, a gateway, or a DNS server.

Common mistakes

Let us look at typical ways organizations use virtual networks. These are common patterns described in general terms, not accounts of any named company.

A typical online retailer

A retail company runs a website, an order system, and a database. The website sits behind an application gateway with a web application firewall. Web servers live in one subnet, order services in another, and the database is reached through a private endpoint in a third. A NAT gateway gives the order service a fixed outbound address that the payment provider has approved. During a sale, scale sets add web servers automatically, and the web subnet is large enough to hold them. The team had to learn early that a subnet sized only for the usual load cannot grow during peak days.

A typical bank moving gradually

A financial company keeps its core systems in its own data center and moves new applications to Azure. An ExpressRoute circuit joins the two, with a VPN as backup. A hub VNet holds the gateway, a firewall, and DNS resolvers. Each application lives in a spoke, and all traffic between spokes and to the office passes through the firewall for inspection and logging. Databases use private endpoints, and public access is disabled by policy. Auditors can follow traffic through the central logs.

A typical software company with many teams

A software firm gives each product team its own subscription with a spoke VNet, created from a standard template through a pipeline. Address ranges are handed out from a central register. Azure Policy blocks public addresses on virtual machines and requires network security groups on subnets. Virtual Network Manager helps connect new spokes to the hub automatically. Teams move fast because the safe network is the easy path.

A typical container platform

A team runs Kubernetes on Azure. With the Azure CNI networking option, every pod can receive an address from the subnet, which can consume thousands of addresses very quickly. The team sizes the subnet accordingly, or chooses an overlay mode that conserves addresses, and checks current documentation for the differences. The lesson is that container platforms can consume address space many times faster than virtual machines.

Platform services that use your network

Landing zones

A landing zone is a pre-built, governed foundation, with networks, policies, identity, and logging already in place, where new workloads can land safely. Microsoft’s Cloud Adoption Framework describes reference designs for these. Larger organizations often start here rather than building networks one project at a time.

When something cannot connect, guessing wastes hours. A calm, ordered approach finds the cause quickly.

A method that works

Common symptoms and likely causes

Quick answers to questions that beginners ask most often.

A virtual network is the foundation of nearly everything you build in Azure. It is free, flexible, and powerful, and it rewards careful planning at the start.

In this guide you met the VNet as a private neighborhood inside Azure, learned how addresses and subnets divide it, followed a message across it, and saw how security groups, routes, and DNS shape what happens. You compared peering, VPNs, and ExpressRoute for connecting networks, and service endpoints and private endpoints for reaching Azure services privately. You saw how to layer security, plan for failure, watch the network, control cost, and avoid the classic mistakes.