Zone the land before you build
Before a town has buildings it has a plat: a surveyor's drawing that fixes the boundary, divides the ground into parcels, and marks where the fences and roads will run. Nobody pours a foundation first and works out the property lines afterward. A virtual network is that plat for your cloud — the address space you claim, the parcels you carve from it, and the fences you post between them — and the discipline is the same: you draw it before you build, because redrawing it after machines are living on it is expensive and disruptive.
Phase One gave Campux an identity model and governance. Now it needs somewhere for resources to actually live and talk to one another privately. That somewhere is a virtual network.
- VNet
- A virtual network — your own private, isolated slice of Azure's network, defined by an address space you choose. Resources inside it reach each other privately; nothing outside gets in unless you allow it.
Two properties make it the foundation of everything in this phase. It is private by default — resources in a VNet talk to each other over private addresses, and the outside world is walled off until you open a door. And it is regional — a VNet lives in one region, a fact you met obliquely in Class Six when a Google network spanned regions and an Azure one did not. Get the plat right and the rest of Phase Two is building on solid parcels; get it wrong and every later class inherits the mistake.
CIDR without tears
Address space is written in CIDR notation, and the only part you must be fluent in is what the slash means. 10.20.0.0/16 is an address followed by a prefix length: the /16 says the first sixteen bits are fixed and the rest are yours to fill. The smaller the number after the slash, the larger the space — because fewer fixed bits leave more free ones.
| Prefix | Total addresses | Usable as one subnet | Typical use |
|---|---|---|---|
| /16 | 65,536 | 65,531 | A whole VNet address space |
| /24 | 256 | 251 | A comfortable subnet |
| /27 | 32 | 27 | A small subnet |
| /29 | 8 | 3 | The smallest Azure allows |
Note the "usable" column, because it hides a trap worth memorising: Azure reserves five addresses in every subnet, not the two you might expect from classic networking.1 The first and last of the range go to protocol conformance, and three more are taken for the platform's own gateway and DNS plumbing. A /24 therefore gives you 251 addresses, not 256, and a /29 — the smallest subnet Azure permits — yields a mere 3. Size a subnet to exactly the number of machines you have today and you will be redrawing the plat by spring.
The practical rule: claim a generous private range for the VNet, then cut subnets larger than you think you need, because addresses are free and renumbering is not. Stay inside the private ranges reserved for this — the 10.x, 172.16–31.x and 192.168.x blocks — and never overlap the range of a network you might one day connect to, or the day you bridge them the addresses will collide and one side becomes unreachable.
Subnets are boundaries, not shelves
A subnet is a slice of the VNet's address space, but thinking of it as merely "where addresses come from" misses the point. A subnet is a boundary — the unit at which you attach security rules and hand pieces of the network to particular jobs. You divide by role, not by tidiness.
- Subnet
- A range carved from the VNet, into which resources are placed. It is the level where network security rules attach and where certain services can be delegated exclusive use.
Divide along the lines that matter for security and blast radius, exactly as resource groups divided by lifecycle in Class Seven. A web tier that faces the world, a data tier that must never face the world, and a management tier for administrative access are three different trust levels, so they become three different subnets — each with its own fence. Putting all three in one subnet is the network equivalent of one big resource group named "rg1": it works until the day you need to say "the database may be reached only by the web tier," and discover you drew no line to enforce it on.
Subnets are also where you delegate parts of the network to Azure services that demand their own — a database service, a gateway, a container platform will each ask for a subnet of its own, sometimes an empty one reserved in advance. This is another reason to survey generously: the plat must leave room for parcels you will only build on later.
NSGs, priority, and the rules already there
A fence is only a fence if it decides what crosses it. On Azure that fence is the network security group — a list of allow-and-deny rules, evaluated in order, attached to a subnet or an individual network interface.
- NSG
- A network security group — an ordered set of rules that permit or block traffic by source, destination, port and protocol. Attach it to a subnet to fence every resource inside at once.
Two mechanics decide everything an NSG does. First, priority: each rule has a number from 100 to 4096, and Azure evaluates them lowest number first, stopping at the first match. A rule at priority 100 that allows traffic wins over a rule at 300 that would deny the same traffic — the deny never gets read. Order is not decoration; it is the logic. Second, the default rules you did not write but must know are there:
| Direction | Rule | Priority | Effect |
|---|---|---|---|
| Inbound | Allow VNet in | 65000 | Allow traffic from within the VNet |
| Inbound | Allow load balancer in | 65001 | Allow Azure's load balancer |
| Inbound | Deny all in | 65500 | Block everything else |
| Outbound | Deny all out | 65500 | Block, after allowing VNet and internet out |
These sit at very high numbers — the lowest priority — so any rule you write with a normal number overrides them. The consequence worth internalising: inbound from the internet is denied by default, because "Deny all in" at 65500 catches anything your rules did not explicitly allow. You do not open a subnet by removing a fence; you open it by writing a specific, higher-priority allow. And you cannot delete the defaults, only outrank them — which is a safety net, not a nuisance.2
ASGs: name what you mean
Write NSG rules against raw IP addresses and you build a fence that forgets why it exists. "Allow 10.20.1.4 to reach 10.20.2.7 on 1433" is correct today and unreadable in a year — and the day the web servers get new addresses, every rule that named the old ones quietly breaks. Application security groups fix this by letting you name the thing instead of its location.
- ASG
- An application security group — a named label you attach to network interfaces, so NSG rules can say "from the web servers to the database servers" instead of naming fragile IP addresses.
Name what you mean, not where it lives.
With ASGs, you tag the web-tier interfaces as asg-web and the data-tier as asg-data, then write one rule: allow asg-web to reach asg-data on the database port. Add a web server next year and it inherits the rule the moment you tag it — no addresses to update, no rule to rewrite, no fence silently pointing at a machine that moved. The rule now reads like the intention behind it, which is the same virtue as a good resource name from Class Seven: the next engineer, or you in eighteen months, can read what it means without decoding what it does.3
Surveying Campux's first VNet
You claim 10.20.0.0/16 for Campux's production VNet — a generous private range that will not overlap the office network you will bridge to the POS system in Class Fifteen. From it you survey three parcels: app at 10.20.1.0/24 for the storefront's web tier, data at 10.20.2.0/24 for its database, and mgmt at 10.20.3.0/24 for administrative access. Each is a /24 — far more than six people's storefront needs today, which is the point.
The fences follow the trust levels. The data subnet's NSG allows inbound only from the asg-web group on the database port and denies the rest — so the database is reachable by the web tier and by nothing on the internet, enforced by a line on the plat rather than a promise in a meeting. The management subnet stays closed to the world entirely; how you actually reach it safely is the subject of this class's first situation. Campux now has ground to build on, zoned before a single virtual machine exists.
That opens Phase Two. Next you put compute onto these parcels.
The official module, and a CAMPUX overview
Introduction to Azure virtual networks
learn.microsoft.com/training/modules/introduction-to-azure-virtual-networks/
Fencing depth: Secure your virtual network (docs)
learn.microsoft.com/azure/virtual-network/secure-virtual-network
A short walkthrough of surveying a VNet, subnets by role, and NSG rules will live here. Video to be added.
Survey a VNet the CLI way
You will lay out the plat: a VNet, two subnets by role, and an NSG whose one rule admits the app tier to the data tier and nothing else. Build the fences before any machine exists — exactly the discipline of this class.
Open Cloud Shell — the >_ icon in the top bar — and choose Bash. (Locally: install the Azure CLI and run az login.)
Create a group, then a VNet with an app subnet, and add a data subnet:
az group create --name rg-campux-lab --location westeurope az network vnet create --resource-group rg-campux-lab --name vnet-lab \ --address-prefixes 10.30.0.0/16 \ --subnet-name app --subnet-prefixes 10.30.1.0/24 az network vnet subnet create --resource-group rg-campux-lab \ --vnet-name vnet-lab --name data --address-prefixes 10.30.2.0/24
What just happened: a /16 of private land, cut into two /24 parcels. Each /24 offers 251 usable addresses, not 256 — Azure reserves five per subnet, the trap from §2.Create an NSG and add one inbound rule: allow the app subnet to reach the data subnet on the database port:
az network nsg create --resource-group rg-campux-lab --name nsg-data az network nsg rule create --resource-group rg-campux-lab --nsg-name nsg-data \ --name allow-app-to-sql --priority 100 --direction Inbound --access Allow \ --protocol Tcp --source-address-prefixes 10.30.1.0/24 \ --destination-port-ranges 1433
On screen: priority 100 is evaluated before the default rules at 65000+. You are not deleting the fence, you are writing a higher-priority gate in it.Attach the NSG to the data subnet so it fences everything placed there:
az network vnet subnet update --resource-group rg-campux-lab \ --vnet-name vnet-lab --name data --network-security-group nsg-data
The lesson: the NSG guards the subnet, so any resource dropped into data inherits the fence at once — you secured a boundary, not a machine.Tear down:
az group delete --name rg-campux-lab --yes --no-wait
Draw the plat by hand
Now survey it by clicking, because the Create blade shows the address space and subnets as the map they are. Use a throwaway resource group.
Go to portal.azure.com and sign in.
In the search bar at the top, type Virtual networks, select it, then click + Create.On screen: a create flow with a tab specifically for IP addresses — the plat. That tab is where the whole class lives.
Basics tab: subscription, a throwaway resource group, name vnet-lab, region.
IP addresses tab: set the address space to 10.30.0.0/16, then add two subnets — app (10.30.1.0/24) and data (10.30.2.0/24).On screen: the portal shows "usable addresses" per subnet — and it is 251 for a /24, not 256. Seeing the five-address reservation printed is the fastest way to remember it.
Review + create, then Create. When it is ready, open the VNet.
Now the fence: search Network security groups, + Create one named nsg-data, then open it, add an Inbound security rule (source = the app subnet range, destination port 1433, Allow, priority 100), and under Subnets associate it to the data subnet.On screen: the NSG's inbound list already shows three default rules at 65000, 65001 and 65500 that you did not write — including DenyAllInBound. Your rule at 100 sits above them and is read first.
Tear down: delete the throwaway resource group.
Portal wording drifts; if a label here does not match your screen, the anchors are the Virtual networks service, its IP addresses tab, and the NSG's inbound rules and Subnets blades.
Read the plat and the fence on their blades
Open the network you drew and let each blade confirm a fact from the class.
Open the VNet → Address space, then Subnets.On screen: the /16 and its /24 parcels, each showing usable addresses and which NSG guards it. This is Figure 6 in the portal.
Open the NSG → Inbound security rules and read top to bottom.On screen: your rule at priority 100, then the three immovable defaults at 65000/65001/65500. Rules are read lowest-number-first and stop at the first match — the fact behind most "the deny isn't working" incidents.
If you have a VM or NIC in the VNet, open its Effective security rules (under Networking).On screen: the merged view of every rule actually applied to that interface — subnet NSG plus any NIC NSG. This is the blade you open first when traffic is blocked and you cannot see why.
Drawing the wall before the fire
A workload is landing and someone asks "where does it go?" You carve a virtual network and subnets that reflect tiers — web, app, data — so segmentation exists before there is anything to protect. When security later asks to isolate the database, the boundary is already drawn; you are tightening a wall, not building one under fire.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
C. A /24 is 256 addresses, and Azure reserves five of them — the first, the last, and three for its own gateway and DNS plumbing — leaving 251. B is the answer from classic on-premises networking, where only two are lost; it is the trap for anyone who learned subnetting before the cloud. The five-address reservation is small, but on a tightly sized subnet it is exactly the margin that turns "room for a few more machines" into "renumber everything."
B. Azure's smallest permitted subnet is a /29 — 8 addresses, of which 5 are reserved, leaving 3. C and D describe prefixes that are legal in classic networking but too small for Azure, precisely because the five-address reservation would leave zero or negative usable space. The lesson behind the number: subnets have a floor, and sizing near it leaves no room to grow, so cut them larger than today's need.
Lowest-number-first with first-match, internet denied by default, and lower numbers override higher. The two false statements are the dangerous ones: the default rules cannot be deleted — only outranked by a lower-numbered rule, which is a safety net — and an NSG attaches to a subnet or a network interface, most usefully the subnet so one fence guards everything inside. Miss the first-match rule and you will write a deny that a lower-numbered allow silently swallows, which is the next drill.
NSG inbound — campux mgmt subnet
Pri 100 Allow RDP 3389 source: Any
Pri 200 Allow HTTPS 443 source: Internet
Pri 300 Deny RDP 3389 source: Any
Priority 100. Because Azure evaluates lowest-number-first and stops at the first match, the Allow RDP at 100 matches inbound RDP and wins — the Deny at 300 is never reached. D is the seductive misreading: the deny looks protective, but a rule that never gets evaluated protects nothing. RDP (3389) is now open to the entire internet on the management subnet, the most sensitive parcel of all.
Consider the consequence. Management ports exposed to Any are among the most-scanned, most-brute-forced targets on the internet; this one line is how a network is compromised within hours of going live. The fix is not to add another deny — it is to delete the broad allow and, if RDP is needed at all, permit it only from a specific known address, or reach the box a safer way entirely. Reading rules in priority order, not top-to-bottom, is the skill this drill trains.
"For a day" is how permanent holes are born. The rule that opens 3389 to Any tonight is the rule still open next quarter, because closing it depends on someone remembering, and management ports exposed to the whole internet are scanned and attacked within hours — not days. The promise is sincere and irrelevant; the risk lands long before anyone forgets to keep it.
Refuse the shape, not the need. The developer needs to reach a machine, which is reasonable; opening it to the planet is not the only way. If a temporary rule is truly warranted, scope it to their specific source address, never Any — a fence with one named gate, not a missing wall.
Offer the real answer. Reach the box without a public port at all: a bastion host that brokers the connection through the portal, or just-in-time access that opens the port to one address for a fixed window and closes it automatically. The good version of "for a day" is a mechanism that expires on its own, not a human promising to undo a risk they can already no longer see.
Grant the appeal, then show what it costs. One subnet is fewer objects, true. But a subnet is the boundary where security attaches, so collapsing three trust levels into one throws away the very line you would need to say "the database may be reached only by the web tier." You cannot fence between machines that share a parcel — the simplicity buys you an estate you cannot segment.
Name the concrete failure. In one flat subnet, a web server compromised from the internet sits in the same unfenced space as the database and the management box; the attacker's next step is trivial because nothing stands between them. Separate subnets with NSGs mean a breach of the web tier still faces a locked door to the data tier — the blast-radius thinking from Class Seven, applied to the network.
Reframe "simple." Three subnets divided by role is not more complex; it is complexity placed where it does work. The plat is drawn once and enforced automatically thereafter, whereas a flat network is simple only until the first incident, when its simplicity is exactly what makes the incident total. Survey by trust level, and simplicity and safety stop being in tension.
Five things worth carrying out of this class
- A VNet is a plat: private and regional, surveyed before machines exist. Redrawing it after they arrive is the expensive path.
- Azure reserves five addresses per subnet, and the smallest is a /29. Size generously — addresses are free, renumbering is not.
- Subnets are boundaries divided by role and trust, not shelves sorted by tidiness. The web, data and management tiers are three fences.
- NSG rules run lowest-number-first and stop at the first match; internet inbound is denied by default and defaults cannot be deleted.
- ASGs name workloads instead of addresses, so rules read as intent and survive machines being replaced.
- Five, not the two of classic networking: Azure takes the first address of the range, the last, and three more for the default gateway and its internal DNS mapping. The exact roles matter less than the count — subtract five from any subnet's theoretical size to get what you can actually assign, and never size a subnet with no headroom above today's machine count. ↩
- One evolving detail worth a flag: Azure has been retiring the implicit outbound internet access that new virtual machines historically received, pushing toward explicit outbound methods instead. The default inbound deny is stable and is the security fact to hold; treat default outbound behaviour as something to verify against current documentation when you design egress, because it is mid-change. ↩
- NSGs govern traffic at the network layer — source, destination, port, protocol — and are the first fence, not the only one. Application Gateway's web firewall in Class Thirteen inspects the content of web requests, and private endpoints in Class Fourteen remove the public door altogether. Layer them; an NSG is necessary and rarely sufficient on its own. ↩