The previous lesson ended with an uncomfortable observation: everything Contoso Airlines has deployed so far — the legacy engine's VMs, the API scale set, the App Service applications and the boarding pass storage account — communicates over the internet. It works, but no serious architecture stays like that. And fixing it afterwards is far more expensive than doing it right from the start, because a virtual network's address space conditions everything that connects to it for years.

That is why every serious architecture starts with the network. Changing a VM's size takes two minutes; changing the address range of a virtual network with a hundred resources inside it and a VPN to two offices is a project with a service outage attached.

In this lesson you will design and deploy Contoso's complete network: the address space of vnet-contoso-pro with CIDR arithmetic explained from scratch, its four subnets, the network security groups that open only what is strictly necessary, private DNS resolution, peering between networks with the hub-and-spoke pattern, the decisive difference between service endpoints and Azure Private Link, how App Service connects to the network, and why nobody should expose SSH to the internet when Azure Bastion exists.

Cost warning: virtual networks, subnets and NSGs cost nothing. What does cost money are private endpoints (per hour and per data processed), static public IPs and, above all, Azure Bastion, which is billed by the hour from the moment it exists. The cleanup is at the end.

1. Why the network comes first
2. Virtual networks and address space
3. CIDR arithmetic without the pain
4. Subnet design for vnet-contoso-pro
5. Addresses reserved by Azure in every subnet
6. Network security groups (NSGs)
7. Service tags and application security groups
8. Public and private IPs, static and dynamic
9. DNS in Azure and private DNS zones
10. Virtual network peering and hub-and-spoke
11. Service endpoints versus Azure Private Link
12. App Service integration with the virtual network
13. Azure Bastion versus exposing SSH and RDP
14. Verification with Network Watcher
15. The complete topology and cleanup
16. Common Mistakes and Tips
17. Exercises
18. Conclusion

A virtual network (VNet) is your private network inside Azure: an isolated address space that you control, in which you place resources that can see each other and through which you decide what comes in and what goes out.

What the network determines, and why it comes first:

And a warning about what you cannot do: two networks with overlapping address spaces cannot be peered or joined by VPN. If you pick 10.0.0.0/16 because it is the example in every tutorial, and your Barcelona office uses 10.0.0.0/16, you have created a problem that can only be fixed by renumbering one of the two.

A VNet has one or more address spaces in CIDR notation, taken from the private ranges of RFC 1918:

Contoso Airlines' addressing plan, decided by Marta Ríos with the office VPN in mind (lesson 02-06):

Notice the discipline: separate /16 blocks with nothing overlapping, and gaps reserved between them for growth. This costs nothing now and avoids a painful migration three years from now.

Remember why the network lives in rg-contoso-red-pro and not alongside the applications: the grouping criterion from lesson 01-05 was lifecycle + environment, and the network outlives many generations of applications.

If CIDR already feels natural to you, skip to the next section. If not, this is the bare minimum, and three ideas are enough.

Idea 1: the number after the slash is the count of fixed bits. An IPv4 address has 32 bits. In 10.20.1.0/24, the first 24 bits are the network (fixed) and the remaining 8 identify the host (variable).

Idea 2: the more fixed bits, the smaller the network. A /24 is smaller than a /16. The arithmetic is direct: 2^(32 - prefix) addresses.

Idea 3: to carve things up, you move block by block. A /24 covers 256 addresses, so inside 10.20.0.0/16 the /24 subnets step one at a time through the third octet:

And if a subnet needs less, it is carved up with longer prefixes. Inside 10.20.250.0/24:

A mental rule that solves 90% of day-to-day cases: a /24 is "a block of 256 with the same third octet". Plan with /24 unless you know you need something else, and leave gaps between subnets for growth.

A subnet is a portion of the virtual network's address space where the resources are actually placed. You segment by function, because segmentation is what lets you apply different rules to each layer.

Reserved names that have to be respected to the letter, because Azure looks for them literally:

And a restriction with consequences: a subnet can be grown, but not if resources get in the way, and it cannot be shrunk with resources inside. Size with headroom.

In a /24 subnet you do not get 256 addresses, nor 254, but 251. Azure reserves five in every subnet:

So the first assignable address in snet-web is 10.20.1.4. This matters when you size right to the limit: a /29 subnet has 8 addresses and only 3 usable. If you planned "eight servers in a /29", they do not fit.

A network security group is a list of stateful filtering rules applied to a subnet or to a NIC. Stateful means that if you allow an inbound connection, the outbound response is allowed automatically; there is no need to write the reverse rule.

Each rule has:

Every NSG comes with invisible rules that cannot be deleted, only overridden with lower priorities:

Two consequences to internalize:

1. By default, all traffic within the VNet is allowed, even between different subnets. Segmentation is not automatic: you have to write it.
2. By default, everything can go out to the internet. If you want to prevent that, you have to deny it explicitly.

The denegar-resto-vnet rule with priority 4000 is the key piece of the segmentation: it is evaluated before the default 65000 rule that allowed all internal traffic, but after the priority 100 rule that authorizes the web layer. The result is exactly what we were after: snet-app only listens to snet-web.

Checking the effective rules, including the invisible ones:

Writing IP ranges by hand ages badly: the IPs of Azure services change, and so do those of your machines. Azure offers two abstractions so that you do not depend on them.

A service tag represents a set of IP prefixes that Microsoft keeps up to date for you.

An ASG is a logical label that groups NICs. Instead of writing rules per IP range, you write rules between groups: "whatever is in asg-web can talk to whatever is in asg-api". When you add a machine to the group, it inherits the rules without touching the NSG.

This is how you keep rules readable as the network grows: they read like business sentences, not like lists of octets.

About public IP SKUs: Standard is the current one (always static, closed by default — it needs an NSG that explicitly allows the traffic — and zone-compatible). The Basic SKU has been retired. Always use Standard.

One outbound nuance that confuses a lot of people: a VM without a public IP can still reach the internet through Azure's default outbound access, using an IP you do not control and which Microsoft is retiring for new networks. For predictable, auditable outbound traffic you use a NAT Gateway, which gives the whole subnet a fixed outbound IP and prevents SNAT port exhaustion.

Inside a VNet, Azure provides automatic DNS resolution: machines on the same network resolve each other by host name without you configuring anything, through the virtual server at 168.63.129.16 (an address that shows up in every Azure diagnostic and is worth recognizing).

That automatic resolution has limits: it does not work between peered networks and it does not resolve private service names. That is what private DNS zones are for.

Now any resource on the network resolves motor.interno.contosoairlines.example to 10.20.4.10. With --registration-enabled true, VMs also register themselves as they are created.

Private zones are essential for Private Link: they are the mechanism by which sql-contoso-reservas-pro.database.windows.net stops resolving to a public IP and starts resolving to an IP in your subnet. We look at that now.

Public DNS (registering contosoairlines.example and publishing its records to the world) is Azure DNS, and it is covered in lesson 02-06.

Peering connects two virtual networks so that they see each other as if they were one: private traffic over Microsoft's backbone, low latency, with no gateways and no internet in between.

Characteristics you need to know:

• It works within a region and between regions (global peering).
• It is not transitive: if A peers with B and B with C, A does not see C. This is the point that surprises people the most and the one that shapes the hub-and-spoke topology.
• The address spaces cannot overlap.
• It is billed by data transferred in both directions.
• It has to be created in both directions: two commands, one per network.

The two important options: --allow-gateway-transit on the hub means "you may use my VPN gateway", and --use-remote-gateways on the spoke means "I will use it". Thanks to that pair, a single VPN gateway in the hub provides connectivity to every spoke, instead of paying for one per network. That is the pattern's main economic argument.

Because peering is not transitive, production and development do not see each other even though both see the hub. That is not a limitation: it is exactly the isolation property we want, and it comes for free.

Here is the most important decision of the lesson, and the one that solves the problem we opened with: Contoso's database and storage account are reachable from the internet.

The practical difference that settles it: with a service endpoint, somebody holding the storage account key can still get in from anywhere the firewall authorizes; and the offices connected by VPN cannot use it. With a private endpoint, the resource has an IP inside your network, it can be closed off from the world entirely and the offices reach it over the VPN.

Contoso chooses private endpoints for the sql-contoso-reservas-pro database and for the sttarjetascontosopro account. The added cost is small compared with exposing passengers' data.

Step 3 is the one most people forget and the one that causes the classic failure: you create the private endpoint, close public access and the application stops working, because it still resolves the name to the public IP that is now closed. Without the linked private DNS zone, Private Link is worth nothing.

Verification from a VM on the network:

The private zones for the services Contoso will use: privatelink.blob.core.windows.net (Storage), privatelink.database.windows.net (SQL, module 3), privatelink.vaultcore.azure.net (Key Vault, 04-03) and privatelink.azurewebsites.net (App Service).

With App Service you have to distinguish two directions, and confusing them is a source of lost hours.

Practical details: outbound integration requires the Basic tier or above, the delegated subnet is for the exclusive use of that plan, and by default only traffic to private addresses is routed (to force all outbound traffic through the network you set WEBSITE_VNET_ROUTE_ALL=1, which is what Contoso does in production so that outbound traffic is auditable).

In lesson 02-01 we opened port 22 to the internet with --nsg-rule SSH and warned that it was temporary. The time has come to do it properly.

Important cost warning: Bastion is billed by the hour as long as it exists, plus outbound traffic. In a lab, create it, use it and delete it the same day. In production, its cost compares favorably with managing public IPs and surviving an incident caused by exposed SSH.

A cheaper alternative for occasional administration: az ssh vm with Microsoft Entra ID and the corresponding extension, or a simple tunnel over a point-to-site VPN, which is exactly what Marta Ríos will use from home (lesson 02-06).

When something does not connect, guessing is expensive. Network Watcher tells you exactly which rule is blocking what.

test-ip-flow is the tool to use before touching any rule: it gives you the name of the rule that decides, so you stop changing things at random. And NSG flow logs, which send everything allowed and denied to Log Analytics, are the basis of the analysis you will see in lesson 07-02.

Cleaning up what bills:

A residual-spend check: az network public-ip list --query "[?ipConfiguration==null]" -o table and az network private-endpoint list -o table.

• Using 10.0.0.0/16 because it is the tutorial's example. It is the range half of corporate internet uses; the day you build the office VPN, it will overlap. Plan the addressing before creating anything.
• Sizing subnets right to the limit. Azure reserves 5 addresses per subnet and growing one with resources inside is problematic. Leave headroom.
• Forgetting the mandatory names. GatewaySubnet and AzureBastionSubnet are written exactly like that; with any other name, the service does not deploy.
• Assuming that subnets are isolated by default. The AllowVnetInBound rule allows all internal traffic. Segmentation has to be written.
• Getting the priority order wrong. Evaluation goes from lowest to highest and the first match wins. A Deny rule with priority 100 overrides an Allow with priority 200.
• Writing IP ranges where a service tag would do. The IPs of Azure services change; the tags update themselves.
• Expecting peering to be transitive. It is not. In hub-and-spoke, the spokes do not see each other (and normally that is what you want).
• Creating the peering in one direction only. It stays in the Initiated state and does not work until the reverse link exists.
• Creating a private endpoint without its private DNS zone. The name still resolves to the public IP and, once you close public access, the application stops working. It is Private Link's number one failure.
• Leaving Azure Bastion running in a lab. It is billed by the hour even if you do not use it.
• Debugging connectivity by trying rules out. az network watcher test-ip-flow gives you the guilty rule in one command.
• Tip: document the addressing plan in a file in the repository, alongside the scripts. The network is the part of the architecture the most people need to consult and the fewest people remember.
• Tip: apply NSGs to subnets, not to individual NICs, except in justified cases. Per-NIC rules get forgotten and create invisible holes.

Contoso is opening a third office in Seville and also wants a virtual network for load testing, isolated from production.

1. Assign address spaces to the Seville office and to the new vnet-contoso-pruebas network, consistent with the existing plan and with no overlaps.
2. Divide vnet-contoso-pruebas into three /24 subnets with names consistent with the course's naming convention.
3. How many usable addresses does each /24 subnet have? And a /27?
4. Explain why you cannot use 10.20.0.0/16 for the test network.

Write the NSG rules (with priorities) that implement exactly this policy for vnet-contoso-pro:

1. snet-web accepts 443 from the internet and nothing else.
2. snet-app accepts 8080 from snet-web only; no other internal traffic.
3. snet-datos accepts 1433 from snet-app only.
4. snet-gestion accepts nothing from the internet; administration from Bastion only.
5. snet-app can go out to Azure SQL in West Europe, but not to the rest of the internet.

Describe, with the corresponding commands, the steps to make sql-contoso-reservas-pro unreachable from the internet and reachable only from snet-app:

1. Prepare the subnet.
2. Create the private endpoint.
3. Configure DNS resolution.
4. Close public access.
5. Verify that resolution returns a private IP.

Explain as well what would happen if you skipped step 3.

Solution 1:

1. Addressing consistent with the existing plan:

2. Subnets:

3. A /24 has 256 addresses, minus the 5 Azure reserves: 251 usable. A /27 has 32, minus 5: 27 usable.

4. Because 10.20.0.0/16 is already the space of vnet-contoso-pro. Two networks with overlapping ranges cannot be peered or connected by VPN, and the routing would be ambiguous. Even if you were not going to peer them today, reusing the range closes that door forever.

Solution 2:

A detail on point 5: the outbound rule to SQL must have a lower priority number (200) than the general denial (4000), or the legitimate traffic would be blocked.

Solution 3:

If you skip step 3, the private endpoint exists and has its IP, but the name sql-contoso-reservas-pro.database.windows.net still resolves to the public IP. As soon as you run step 4, the application will try to connect to that now-closed public IP and will fail with a connection timeout, with no clue at all pointing at DNS. It is Private Link's most frequent and most baffling failure.

You now have the platform's third leg. You know why the network comes first and which decisions get frozen for years. You can handle private address spaces, enough CIDR arithmetic to carve a /16 into subnets with no overlaps, and you know the five addresses Azure reserves in every subnet. You have designed and deployed vnet-contoso-pro with snet-web, snet-app, snet-datos, snet-gestion and the mandatorily named AzureBastionSubnet and GatewaySubnet subnets. You write NSG rules understanding priorities and the default rules — including the most dangerous one, AllowVnetInBound, which means segmentation is not automatic — and you use service tags and application security groups so that rules do not depend on IP lists. You can tell public from private IPs and static from dynamic, with their effect on the bill. You know how Azure's DNS resolution works and what private DNS zones are for. You understand peering and its lack of transitivity, which is exactly what shapes the hub-and-spoke pattern and lets you pay for a single VPN gateway. And you have made the decision that most protects passengers' data: private endpoints with their DNS zone for the database and the storage account, rather than service endpoints. On top of that, you have connected App Service to the network, you have replaced exposed SSH with Azure Bastion and you know how to diagnose with Network Watcher instead of guessing.

One piece is left to close the module, and it is the one that connects Azure with Contoso Airlines' real world. The Barcelona and Palma offices are still outside this network: their staff cannot reach the private resources you have just locked down, the legacy check-in system still lives on premises, and Marta Ríos cannot administer anything from home without exposing something. At the same time, a customer buying a ticket from South America suffers the latency of crossing the Atlantic on every request to West Europe.

In the module's last lesson, Hybrid Connectivity and Global Delivery, we solve both ends: a point-to-site VPN for Marta and a site-to-site one for the offices, with their gateways and their CLI deployment; ExpressRoute and when it justifies its price; Azure Virtual WAN as the evolution of hybrid hub-and-spoke; and global delivery of the site with Azure Front Door, Azure CDN and Traffic Manager, including the data transfer out charges that surprise everyone the first time they read a bill.