Virtual Network in Azure: Your Private Network in the Cloud
A beginner-friendly guide to Azure Virtual Network, the foundation that lets your cloud servers talk to each other, to your office and to the internet safely, explained step by step with everyday analogies.
Imagine a large shopping mall with thousands of shops. The mall is shared by many businesses, yet each business wants its own locked back rooms, its own staff corridors and its own delivery door. Some rooms may talk to each other, some must stay hidden from the public, and a few need a special private tunnel to the owner’s head office across town. A virtual network is the part of the cloud that builds these private rooms and corridors for your servers.
In this guide we begin with the very first question, “what is a network?”, and slowly move to address planning, security rules, routing, connecting to your office and designing a whole company layout. No earlier networking knowledge is required. Every new word is explained when it first appears.
1What Is an Azure Virtual Network?
A Virtual Network, shortened to VNet, is your own private, isolated network inside Azure.
A network is simply a group of computers that can send messages to each other. In an office, cables and switches connect the computers. In the cloud there are no cables that you can touch, so Azure builds the network with software. That software-built network is called a virtual network.
When you create a VNet, Azure gives you a private bubble. Inside the bubble, your virtual machines, databases and other services can find and talk to each other using private addresses. Other customers of Azure cannot see inside your bubble, even though their bubbles run on the same physical hardware. You decide who and what may enter or leave.
A VNet belongs to one region and one subscription. It spans all the availability zones of its region, which means one VNet can hold servers that sit in different buildings of the same region without any extra work. The VNet itself is free, and you pay mainly for the resources that use it and for some optional features such as gateways and data transfer.
Think of a gated housing society. The society has its own boundary wall, its own internal roads and house numbers, and a guard at the gate. Residents visit each other freely inside, while outsiders need permission to enter. A VNet is the gated society, and your servers are the houses.
Words you will meet again and again
Address Space
The range of private addresses that the whole VNet is allowed to use.
Subnet
A smaller slice of the address space, used to group resources with a similar purpose.
Network Security Group
A list of allow and deny rules that acts as a firewall for subnets and network cards.
Route Table
A set of directions that tells traffic which way to travel to reach each destination.
Peering
A direct, fast link that joins two VNets so they behave like one network.
Private Endpoint
A private address inside your VNet that connects you to an Azure service such as storage or a database.
2Why Do We Need a Virtual Network?
Without a private network, every cloud server would sit directly on the open internet.
Imagine putting a database that holds customer records on a public address that anyone in the world can try to reach. Automated programs scan the internet around the clock looking for exactly such servers. Even a strong password is a risky shield when the front door is open to everybody.
A VNet solves several problems at once. It gives your resources private addresses that do not exist on the public internet. It lets you separate the web servers that customers touch from the databases that only your own applications should reach. It lets you connect the cloud to your office as if the cloud were another branch building. And it gives you a single place to apply rules about who may talk to whom.
Isolation
Your resources live in a boundary that other customers cannot enter. This is the base of every secure cloud design.
Private communication
Servers inside the VNet talk to each other over Microsoft’s network using private addresses, without crossing the public internet.
Controlled internet access
You decide which resources may be reached from the internet, and which may go out to it.
Connection to your own offices
A VNet can be joined to your corporate network, so cloud and office systems work together as one environment.
Many Azure services, such as virtual machines, Kubernetes clusters and application environments, need a VNet to run in. Learning VNet first makes every other Azure topic easier.
3Address Space and CIDR Made Simple
Choosing the address range is the first and most important design decision you will make.
Every computer on a network needs an address, like a house number, so that messages can find it. An IPv4 address is written as four numbers separated by dots, for example 10.0.1.4. A VNet is given a block of such addresses to hand out to its resources.
The size of the block is written with CIDR notation, which is a slash followed by a number. The number tells you how many addresses are in the block. The smaller the number after the slash, the bigger the block. A block written as 10.0.0.0 with a slash 16 holds about sixty-five thousand addresses, while a slash 24 holds 256 and a slash 29 holds only 8.
| CIDR size | Total addresses | Usable in an Azure subnet | Typical use |
|---|---|---|---|
| /16 | 65,536 | Large pool | A whole VNet |
| /24 | 256 | 251 | A normal subnet |
| /26 | 64 | 59 | A small subnet or a bastion subnet |
| /27 | 32 | 27 | Gateway subnet for a small VPN |
| /29 | 8 | 3 | Smallest subnet allowed |
Think of a block of flats numbered 1 to 256. The CIDR number says how large the block is. A bigger block can host more families, but if you build a big block on land you may need later for other buildings, you will run short of space for them.
Use private ranges only
Internet standards set aside three ranges for private use. They are 10.0.0.0 slash 8, 172.16.0.0 slash 12 and 192.168.0.0 slash 16. These addresses are never used on the public internet, so every company can safely reuse them inside its own network. Azure VNets should use these ranges.
Choosing address ranges that overlap with another VNet or with your office network. Overlapping networks cannot be peered or connected through a VPN. Fixing an overlap later usually means rebuilding resources. Keep a central list of all ranges used by your company and plan them before creating anything.
Leave room to grow. A VNet can have more than one address range added later, but a generous plan from the beginning keeps life simple. It is cheaper to waste unused private addresses than to renumber a running system.
4Subnets: Dividing the Network into Zones
A subnet is a smaller neighbourhood inside your VNet.
A VNet is rarely used as one big flat space. You divide it into subnets, and each subnet receives a portion of the VNet’s address range. Resources placed in a subnet get their addresses from that portion. The main reason for subnets is organisation and control. Resources of the same kind, such as web servers, are grouped together, and rules can be applied to the whole group at once.
In an office building, the reception area is open to visitors, the staff floor needs a badge, and the server room needs a special key. Each area is a subnet, and each has its own door rules.
A typical layout
Web Subnet
Holds servers that receive requests from users, usually behind a load balancer or gateway.
Application Subnet
Holds the business logic servers that only the web tier may talk to.
Data Subnet
Holds databases and caches that only the application tier may reach.
Management Subnet
Holds tools for administrators, such as a secure remote access service.
flowchart TD
I["Internet"] --> W["Web Subnet"]
W --> A["Application Subnet"]
A --> D["Data Subnet"]
M["Management Subnet"] -.-> W
M -.-> A
M -.-> D
Rules you should know
- Five addresses are reserved — in every subnet Azure keeps the first four and the last address for its own use, so a small subnet has fewer usable addresses than you might expect.
- Special names — certain services need a subnet with an exact name, such as one for a VPN gateway, one for the Azure Firewall and one for the Bastion service.
- Subnets cannot overlap — each address belongs to exactly one subnet.
- Subnet delegation — some managed services ask for a subnet that is handed over to them, and the subnet can then hold only that service.
Making subnets too small. Services such as Kubernetes can consume many addresses, and a subnet that is full cannot take a new resource. Resizing a subnet that already holds resources is difficult, so size generously.
5IP Addresses and Network Interfaces
Resources join a VNet through a network card, and that card owns the addresses.
A virtual machine does not plug into a subnet directly. It has a virtual network interface card, called a NIC. The NIC sits in a subnet and holds the machine’s private IP address. A single virtual machine can have several NICs, and a NIC can hold several addresses, though most beginners need only one of each.
Private IP Address
Reachable only inside the VNet and networks connected to it. Every resource in a VNet has one.
Public IP Address
An optional address reachable from the internet. It is attached only to resources that must be visible from outside.
Dynamic and static
A private address can be dynamic, which means that Azure picks the next free address and may change it if the resource is stopped and started again, or static, which means that the address stays fixed. Servers that other systems depend on, such as a domain controller or a database, should use static addresses so that nobody has to chase a moving target.
A private address is your flat number inside the housing society. A public address is the society’s street address that the postman uses. Most residents only ever need the flat number, and the society uses one gate address for everybody who needs to be reached from the street.
Avoid giving a public address to individual servers. Place servers behind a load balancer, an application gateway or a firewall, and let that single front door carry the public address.
6Network Security Groups: The Traffic Rulebook
A Network Security Group decides which messages may enter or leave a subnet or a network card.
A Network Security Group, called an NSG, is a list of rules. Each rule says whether to allow or deny traffic, in which direction it travels, from where to where, using which protocol and on which port. A port is like a numbered door on a computer. Web traffic normally uses one door, secure web traffic another, and remote administration yet another.
Priority
Each rule carries a number between 100 and 4096. Rules are checked from the lowest number to the highest, and the first rule that matches wins.
Source and destination
Where the traffic comes from and where it is going, given as addresses, ranges, service labels or application groups.
Protocol and port
The type of traffic and the door number it wants to use.
Action
Allow or deny. Once a rule matches, no further rules are looked at.
Default rules
Every NSG starts with default rules that cannot be removed. Inside the VNet, traffic between resources is allowed. Traffic from Azure’s load balancing service is allowed. Everything else coming from the internet is denied, while outgoing traffic to the internet is allowed. You add your own rules, with lower numbers, to open exactly what you need.
An NSG is the guard’s checklist at a society gate. The guard reads the list from the top. The first line that fits the visitor decides if they pass or not. A line near the top that says “allow plumber” is read before a later line that says “deny all strangers”.
Application Security Groups
Writing rules with raw addresses becomes painful as servers come and go. An Application Security Group lets you give a name to a group of servers, such as “web-servers”, and then write rules using that name. When a new web server joins the group, the existing rules apply to it immediately.
Opening the remote administration ports to the entire internet. Attackers try passwords against these ports within minutes of a server appearing. Allow administration only from trusted addresses, or better, use a secure access service so that the ports are never exposed at all.
Attach an NSG to each subnet rather than to individual network cards. One rule set per subnet is easier to read, audit and keep consistent.
7Routing: How Traffic Finds Its Way
Allowing traffic is not enough, because the network must also know where to send it.
Routing is the process of choosing the path for each message. Azure builds a set of default routes for every subnet automatically, called system routes. They make sure that resources in the same VNet can reach each other, that peered networks and connected office networks can be reached, and that anything else heads towards the internet.
Sometimes the default path is not what you want. A company may need every message going to the internet to pass through a security appliance first. You can then create a route table with user-defined routes, attach it to a subnet and say “send all traffic for this destination to that appliance”. The most specific matching route is always chosen. If two routes are equally specific, user-defined routes win over system routes.
flowchart LR
VM["Virtual Machine in App Subnet"] --> RT["Route Table"]
RT -->|"default: 0.0.0.0/0"| FW["Firewall Appliance"]
FW --> NET["Internet"]
RT -->|"10.0.0.0/16"| VN["Same VNet"]
Routing is like a road sign at a junction. By default, the sign points to the highway. If the city decides that every truck must stop at a checkpoint first, it puts a new sign that redirects trucks to the checkpoint before they reach the highway.
A route for a narrow range, such as one small subnet, beats a route for a huge range, such as “everything”. This is why a single “everything goes to the firewall” route still leaves traffic inside the VNet unaffected.
Creating a route that sends traffic to an appliance that is not set up to forward it, or that points back to itself. Traffic then disappears, which looks like a mysterious outage. Always test a new route with one non-critical subnet first.
8Name Resolution and DNS
Humans use names, but networks use numbers, and DNS translates between the two.
It is easy to remember a name like “orders-db” and hard to remember a number such as 10.0.3.5. The Domain Name System, called DNS, is the phone book that turns names into addresses. If you do nothing, Azure provides a built-in name resolution service for resources inside a VNet, and the address of this built-in service is the same in every VNet.
Azure-Provided DNS
Works out of the box for names within the VNet. Simple, but limited in features.
Azure Private DNS Zones
Lets you create your own private domain names, such as one for your internal applications, that only your linked VNets can resolve.
Custom DNS Servers
Use your own DNS servers, often to resolve names of office systems as well. Common in hybrid setups.
Azure DNS Private Resolver
A managed service that forwards DNS questions between Azure and your office network without running your own servers.
When private endpoints are used, the service name must resolve to the private address and not the public one. Wrong DNS is the number one reason why a private endpoint seems to “not work”. Always verify name resolution first when connectivity fails.
DNS is the contact list in your phone. You tap a friend’s name and the phone dials the number. If the list has the wrong number, the call goes to a stranger, even though the friend’s phone works perfectly.
9Inside the Machine: How a Packet Travels
Following one message from one server to another shows how all the parts fit together.
Azure’s virtual network is an overlay. This means that your private addresses are carried inside the real physical network of Microsoft’s data centres, wrapped up like a letter inside an outer envelope. Software on every host machine, called the virtual switch, applies your NSG rules and routes, wraps the message, and sends it to the correct physical host. At the destination, the outer envelope is removed and the message reaches the target server. You never see this, which is why your private network seems to behave like a simple cable.
Message created
The application on the web server wants to talk to the application server and sends a message to its private address.
Outbound rules checked
The virtual switch on the web server’s host checks the outbound NSG rules for the source subnet and network card.
Route chosen
The routes for the subnet decide the next stop. For traffic inside the VNet, the next stop is the destination itself.
Inbound rules checked
At the destination host, the inbound NSG rules for the receiving subnet and card are applied.
Delivery
If every check passes, the message arrives at the application server. The reply is allowed back automatically because the rules are stateful, meaning that Azure remembers the conversation.
sequenceDiagram
participant W as Web Server
participant S1 as Virtual Switch A
participant S2 as Virtual Switch B
participant A as App Server
W->>S1: Send message to private address
S1->>S1: Check outbound NSG and route
S1->>S2: Wrapped message over physical network
S2->>S2: Check inbound NSG
S2->>A: Deliver message
A-->>W: Reply allowed automatically
Think of sending a letter between two flats in a large estate through the estate’s internal courier. The courier checks the sender’s permission, puts the letter in a bigger bag marked with the delivery route, and at the other end a second guard checks it before handing it over.
10VNet Peering: Joining Networks Together
Separate VNets cannot see each other until you connect them, and peering is the simplest way.
Different teams, applications or environments often live in different VNets. By default, these networks are completely separate. VNet peering creates a direct link between two VNets so that resources in either can reach the other using private addresses. The traffic travels over Microsoft’s backbone network, so it is fast and does not touch the public internet.
Regional Peering
Joins two VNets in the same region with very low delay.
Global Peering
Joins VNets in different regions, which helps with multi-region designs and disaster recovery.
Rules of peering
- No overlapping address ranges — the two VNets must use different ranges.
- Peering works in both directions — a link must be created from each side, although the portal can create both at once.
- Peering is not transitive — if A is peered with B and B with C, then A cannot automatically talk to C.
- Charges apply for data — traffic crossing a peering is billed per gigabyte, and global peering costs more than regional peering.
- Security rules still apply — peering opens the path, but NSGs still decide what may pass.
Two housing societies build a private road between their gates. Residents of either society can use it without going out to the public street. But if society B also builds a road to society C, residents of A still cannot drive to C unless a third road is built or B lets them pass through.
With the right settings, a peered VNet can use the VPN gateway of its neighbour to reach the office network. This way one gateway serves many VNets and saves money.
11Connecting Your Office to Azure
Most companies keep some systems in their own offices, so the cloud needs a bridge to them.
A network that mixes office systems and cloud systems is called a hybrid network. Azure offers three common ways to build the bridge, and the right one depends on speed, reliability and budget.
Point-to-Site VPN
One individual computer, such as a developer’s laptop, creates an encrypted tunnel to the VNet. Ideal for remote workers and small teams who need occasional access.
Site-to-Site VPN
A VPN device in your office builds an encrypted tunnel to an Azure VPN gateway over the public internet. The whole office network can then talk to the VNet. It is quick to set up and relatively cheap, but speed and delay depend on the internet.
ExpressRoute
A private, dedicated circuit between your office or data centre and Microsoft through a connectivity provider. It does not use the public internet, offering steadier performance, higher speeds and predictable delay. It costs more and takes longer to arrange.
| Feature | Point-to-Site | Site-to-Site VPN | ExpressRoute |
|---|---|---|---|
| Who connects | Single device | Whole office network | Whole office or data centre |
| Path | Public internet, encrypted | Public internet, encrypted | Private dedicated circuit |
| Performance | Moderate | Good, varies with internet | High and predictable |
| Cost and effort | Low | Medium | Highest |
| Best for | Remote users | Branch offices, backups | Large and critical workloads |
flowchart LR
L["Remote Laptop"] -->|"Point-to-Site tunnel"| G["VPN Gateway in GatewaySubnet"]
O["Office Network"] -->|"Site-to-Site tunnel"| G
X["Data Centre"] -->|"ExpressRoute circuit"| E["ExpressRoute Gateway"]
G --> V["Azure VNet"]
E --> V
A gateway needs its own special subnet named exactly as Azure requires, and it takes a good while to create. Plan it early, and avoid putting other resources in that subnet.
12Private Access to Azure Services
Azure services such as storage and databases live outside your VNet, so we need a safe way to reach them.
Many Azure services, called platform services, have public addresses by default. If your server inside the VNet wants to read from a storage account, the traffic would normally go to that public address. Two features exist to keep this traffic private.
Service Endpoints
Extend your subnet’s identity to the service over Microsoft’s backbone. The service can then be told to accept connections only from that subnet. The service still keeps its public address.
Private Endpoints
Create a network card with a private address inside your own subnet that points to one specific service instance. The service can then turn off public access completely.
| Question | Service Endpoint | Private Endpoint |
|---|---|---|
| Service gets a private address in your VNet | No | Yes |
| Reachable from the office over VPN | Not directly | Yes |
| Can public access be switched off fully | Not fully; restricted to chosen subnets | Yes |
| Extra cost | None | Charged per endpoint and for data processed |
| Setup effort | Low | Higher, needs correct DNS |
A service endpoint is a special lane on the public road that only your society’s cars may use to reach the bank. A private endpoint is a private door from inside your society straight into a dedicated counter of the bank, so you never step on the public road at all.
Private endpoints are the stronger and more flexible choice and are preferred for sensitive data. Service endpoints are a simple and free first step when budgets are tight and the service is reached only from within Azure.
13Going Out to the Internet Safely
Private servers still need to download updates and call outside services, so outbound traffic needs a plan.
A server without a public address can still start connections to the internet if the network gives it a path out. In the past, Azure supplied a hidden default outbound address for such servers. This default is being phased out for newly created networks, because it gave no control and could change without warning. You should therefore choose an explicit outbound method on purpose.
NAT Gateway
A managed service that gives all resources in a subnet one or more fixed public addresses for outgoing traffic. It is simple, scalable and ideal when you need a stable address that partners can add to their allow lists.
Azure Firewall
A managed firewall that inspects traffic, filters it by address and domain name, and logs it. Use it when you must control and audit which sites your servers can reach.
Load Balancer Outbound Rules
A public load balancer can also provide an outbound path for the servers behind it, with some limits on the number of simultaneous connections.
Public IP on the Server
Technically possible, but it exposes the server directly to the internet and is discouraged for anything except tests.
Residents of a society should not each hand out personal gate numbers. Instead, the society uses one main exit gate with a register. A NAT gateway is that single exit gate, and a firewall is the same gate with a guard who also checks where each person is going.
Relying on the old default outbound access. If a new network no longer provides it, servers may suddenly be unable to reach update servers or licensing services. Configure an explicit outbound method before going live.
14Security: Defence in Layers
A secure network never relies on a single control.
Perimeter protection
Use a web application firewall or Azure Firewall at the edge to inspect and filter incoming and outgoing traffic. Turn on DDoS protection for public-facing networks, to absorb floods of fake traffic.
Segmentation
Split the network into subnets and use NSGs so that a problem in the web tier cannot freely spread to the data tier.
Private access
Use private endpoints, so storage and databases are not exposed on public addresses.
Safe administration
Use Azure Bastion, a managed service that lets administrators open a remote session in the browser without exposing management ports on the servers.
Visibility
Collect flow logs and firewall logs, and raise alerts on suspicious patterns.
A bank has a guarded entrance, a separate teller area, a locked vault, cameras and an alarm. A thief who passes the first door still faces many more barriers. Network security follows the same idea.
The idea of zero trust
Older thinking said “everything inside the network is trusted”. Modern practice says “trust nothing by default”. Even servers inside your VNet should only talk to the exact peers they need, and every request should be verified. Tight NSG rules and private endpoints put this idea into daily practice.
Leaving the default “allow everything within the VNet” behaviour untouched. If one server is compromised, the attacker can roam freely. Add deny rules between tiers, and allow only the connections that are really needed.
15Monitoring, Logging and Troubleshooting
When something cannot connect, good tools turn guessing into quick answers.
Azure Network Watcher is a collection of tools for understanding and fixing network problems. It works at the network level, so it does not look inside the data, only at how the path behaves.
IP Flow Verify
Tells you whether a particular message would be allowed or denied and names the exact rule responsible.
Next Hop
Shows where the traffic from a server will go next, which exposes wrong routes quickly.
Connection Troubleshoot
Tests whether one resource can reach another and shows where along the path the trouble occurs.
Flow Logs
Records information about the traffic passing through the network, such as who talked to whom and whether it was allowed. Useful for audits and for finding unusual behaviour.
Topology View
Draws a picture of the network and its connections, which helps in understanding an inherited environment.
Alerts and Metrics
Track gateway health, tunnel status and data volumes, and send a message when something looks wrong.
Confirm the basics
Are both resources running and do they have the addresses you expect?
Check name resolution
Does the name resolve to the right private address?
Check the rules
Use IP flow verification to see whether an NSG on either side blocks the traffic.
Check the route
Use next hop to confirm that traffic leaves in the right direction.
Check the far end
Make sure the application is actually listening and that no local firewall inside the server blocks the connection.
Enable flow logging before you need it. When a security incident happens, history that was never recorded cannot be recovered.
16Design Patterns That Work Well
Teams around the world keep returning to a few proven layouts.
Pattern: Hub and Spoke
One central “hub” VNet holds shared services such as the firewall, VPN gateway, DNS and Bastion. Several “spoke” VNets, one per application or team, are peered to the hub. Traffic between spokes and to the internet passes through the hub, where it can be inspected. It saves cost and gives one place to apply company-wide rules.
Pattern: Three-Tier Subnets
Web, application and data tiers sit in separate subnets with NSG rules that allow traffic only in one direction down the chain.
Pattern: Landing Zone
Large organisations prepare a ready, governed network structure with agreed address ranges, policies and logging. New projects are simply placed into it, so every team starts safe.
Pattern: Separate Environments
Production, testing and development use different VNets, often in different subscriptions, so that a mistake in testing can never touch live data.
Pattern: Multi-Region Pair
Two regions each host a VNet that is globally peered, supporting disaster recovery and serving users from the nearest region.
flowchart TD
ON["On-premises Network"] --> HUB["Hub VNet: Firewall, Gateway, DNS, Bastion"]
HUB --> S1["Spoke 1: Web Application"]
HUB --> S2["Spoke 2: Data Platform"]
HUB --> S3["Spoke 3: Shared Tools"]
HUB --> NET["Internet through Firewall"]
17Real-World Examples
Virtual networks sit quietly behind almost every serious Azure deployment.
Online retail
A shop places its public website behind an application gateway, keeps application servers in a private subnet and its database reachable only through a private endpoint. During sales, the network absorbs traffic spikes without exposing internal systems.
Banks and insurers
Financial companies use ExpressRoute to link their data centres to Azure privately, a hub-and-spoke design with a central firewall, and strict segmentation to meet regulatory audits.
Hospitals
Patient systems run in isolated subnets with no public addresses, reachable from clinics through site-to-site VPN tunnels, and all access is logged.
Software vendors
A software company gives each customer environment its own spoke network, so that one customer’s data and traffic are fully separate from another’s.
Remote and hybrid workforces
Employees use point-to-site connections or secure browser sessions through Bastion to reach internal tools without opening administration ports to the world.
Data and AI platforms
Analytics teams keep storage, compute clusters and databases inside private networks and use private endpoints, so valuable data never travels across the public internet.
Advantages
- Strong isolation and private addressing
- Fine control over traffic with rules and routes
- Easy joining of VNets, offices and Azure services
- Fast communication over Microsoft’s backbone
- No charge for the VNet itself
Disadvantages / Trade-offs
- Address planning mistakes are costly to fix
- A VNet is limited to one region
- Peering is not transitive, so large setups need careful design
- Gateways, firewalls and private endpoints add cost
- Misconfigured rules and DNS can be hard to diagnose without practice
18Anti-Patterns to Avoid
These shortcuts regularly lead to breaches, outages and expensive rebuilds.
Problem
Teams pick address ranges at random, and later discover that two networks, or the VNet and the office, use the same range.
Why It’s Harmful
Overlapping networks cannot be peered or joined by VPN. The only fix is to renumber and move resources, which means downtime and risk.
Correct Approach
Keep a central register of address ranges for the whole company and allocate from it before creating any network.
Problem
Remote administration ports are opened to the whole internet for convenience.
Why It’s Harmful
Automated attackers find open ports within minutes and try endless password guesses. One weak password gives them a foothold in the network.
Correct Approach
Use Azure Bastion or a VPN for administration, and never expose management ports on public addresses.
Problem
All resources are placed in one big flat subnet with no internal rules.
Why It’s Harmful
If any server is compromised, the attacker can reach every other server directly, turning a small incident into a major breach.
Correct Approach
Use separate subnets per tier, attach NSGs, and allow only the specific flows your application needs.
Problem
Every server receives its own public IP address “to make things easy”.
Why It’s Harmful
The attack surface grows with each address, there is no single place to inspect traffic, and outbound addresses become impossible to manage.
Correct Approach
Expose only a front door, such as a load balancer, application gateway or firewall, and keep servers private. Use a NAT gateway for outbound traffic.
Problem
Platform services such as storage and databases are left reachable from the whole internet.
Why It’s Harmful
Even with passwords, the service is exposed to scanning, brute-force attempts and mistakes in access settings.
Correct Approach
Use private endpoints, turn off public access where possible, and verify DNS so that names resolve to private addresses.
19Best Practices and a Starter Checklist
Walk through these steps whenever you design a new network.
Plan addresses first
Choose non-overlapping private ranges with room to grow, and record them in a central register.
Design subnets by purpose
Group resources by role and size each subnet generously, remembering the five reserved addresses.
Apply least-privilege rules
Attach an NSG to every subnet, deny by default, and open only the flows that are needed. Use application security groups for readability.
Keep servers private
Avoid public addresses on servers. Expose only gateways and load balancers.
Plan outbound access
Choose a NAT gateway or firewall deliberately, instead of depending on defaults.
Use private endpoints and good DNS
Reach platform services privately, and link private DNS zones to the right networks.
Log and monitor
Enable flow logs, collect firewall logs and set alerts for gateway and tunnel health.
Govern with policy and tags
Use Azure Policy to stop risky settings, and tag networks with an owner and purpose.
Overlapping ranges, subnets that are too small, public IPs on every server, wide-open administration ports, forgetting DNS for private endpoints, assuming peering is transitive, and building everything by hand in the portal instead of using repeatable templates.
20Frequently Asked Questions
No. A VNet is the whole private network, and a subnet is a slice of it. A VNet contains one or more subnets, and every resource is placed in a subnet.
Yes, by default the routes and the default NSG rules allow it. You restrict this by adding NSG rules or routes when you want separation between tiers.
You can add more ranges, and in many cases modify them, but a range that is in use by subnets with resources is hard to change. Peered networks may also need to be re-synced. Planning properly at the start avoids this.
Peered traffic travels over Microsoft’s private backbone and does not cross the public internet, but it is not an encrypted tunnel in the way a VPN is. Applications should use their own encryption, such as TLS, for sensitive data.
An NSG is a simple, free rule list that filters by address, port and protocol. Azure Firewall is a managed, central service with richer features such as filtering by domain name, threat intelligence and detailed logs. Many designs use both.
Yes, through global VNet peering or through VPN gateways. Remember that traffic between regions is billed and has higher delay than traffic inside one region.
The most common cause is DNS. The name must resolve to the private address, so check that a private DNS zone is linked to your network. After that, check NSG rules and whether the service’s firewall allows the connection.
Use a point-to-site VPN for full network access, or Azure Bastion for browser-based sessions to specific machines. Both avoid opening management ports to the whole internet.
The VNet itself is free. You pay for things attached to it, such as gateways, firewalls, NAT gateways, public IP addresses, private endpoints and data moving through peerings or out of Azure.
There is no single answer. A common approach is one VNet per application environment or per team, joined by a hub. Too many tiny networks make management hard, and one giant network makes isolation hard. Aim for a balance that matches your teams and security needs.
21Summary and Key Takeaways
An Azure Virtual Network is the private foundation on which almost everything else in Azure is built. You choose an address range, divide it into subnets, protect each subnet with security rules, steer traffic with routes and resolve names with DNS. You join networks together with peering, link them to your offices with VPN or ExpressRoute, and reach Azure services privately through endpoints. Careful planning of addresses and layers, combined with monitoring and good habits, turns a simple virtual network into a safe and scalable base for any workload.
Key Takeaways
- A VNet is your private bubble — it is isolated, regional, free to create and the base for most Azure resources.
- Plan addresses before anything else — use private ranges, avoid overlaps and leave room to grow, because mistakes here are the costliest.
- Subnets organise and protect — group resources by role, size generously and remember Azure reserves five addresses in every subnet.
- NSGs and routes control traffic — rules are checked by priority, routes by specificity, and both should follow the principle of least privilege.
- Connect deliberately — peering is fast but not transitive, while VPN and ExpressRoute link the cloud to your offices.
- Keep platform services private — prefer private endpoints with correct DNS, and give servers a planned outbound path through NAT or a firewall.
- Layer, log and verify — combine firewalls, segmentation, Bastion and flow logs, and use Network Watcher tools to troubleshoot quickly.