5.5 Virtual Networks, Subnets, and Network Security Groups

Segment Azure Networks with VNets, Subnets, and NSGs

Azure Virtual Network (VNet) provides the private network foundation for Azure resources. It lets resources such as virtual machines communicate securely with each other, the internet, and on-premises networks while using familiar networking concepts (address spaces, subnets, routing). For SC-900 the main idea is not advanced routing — it is that VNets and subnets provide logical containment, and NSGs provide traffic filtering within that containment.

Subnets divide a VNet's address space into smaller segments. A simple three-tier workload might place web servers in one subnet, application services in a second, and data services in a third. Segmentation alone does not create a complete security boundary, but it gives you places to apply controls. Network security groups (NSGs) are the core Azure feature in this chapter for allowing or denying traffic at subnet or network-interface (NIC) scope. An NSG can be associated with a subnet (covering everything in it) or with an individual NIC (covering one VM), and both can apply at once.

How NSG Rules Work: the 5-Tuple, Priority, and State

An NSG contains security rules that allow or deny inbound or outbound traffic. Each rule is built on the classic 5-tuple plus a priority and an action:

Rules are evaluated in priority order, and processing stops at the first match for that traffic. This is why priority planning matters: a broad allow rule at a lower priority number can short-circuit a later, higher-numbered deny rule, leaving the deny ineffective. Azure also adds default rules (such as allowing intra-VNet traffic and outbound to the internet, denying everything else) at very high priority numbers; your custom rules sit at lower numbers and override them. Application security groups (ASGs) let you group VMs by role and reference that group in rules instead of hard-coding IPs.

NSGs are stateful. If you allow an outbound flow to a destination on a port, the return traffic is permitted automatically — you do not need a matching inbound rule for the response. The same applies in reverse for permitted inbound flows. This is exam-relevant because it distinguishes NSGs from a naive stateless packet filter that would require explicit rules for both directions.

NSG vs Azure Firewall, and Segmentation Strategy

NSGs are not the same as Azure Firewall. If a question asks for central inspection, logging, FQDN/application rules, or threat intelligence across multiple networks, Azure Firewall is the better fit. If a question asks to allow web-subnet traffic to an app subnet, deny direct database access from the web tier, or filter inbound management traffic to a VM subnet, an NSG is the direct match. In real designs the two combine: NSGs do local subnet/NIC filtering while Azure Firewall provides centralized, stateful, environment-wide policy.

NSGs are also not a complete segmentation strategy by themselves. Segmentation starts with VNets, subnets, and architecture boundaries; NSGs then enforce traffic rules inside those boundaries. Additional controls — private endpoints (to reach PaaS services over a private IP), user-defined routes (to force traffic through a firewall), and service tags (named groups of Microsoft service IP ranges) — strengthen the design, but SC-900 usually just asks for the basic purpose of the named service.

Quick rules for the exam:

• Use VNets as private network containers for Azure resources.
• Use subnets to divide address space and group related resources.
• Use NSGs to allow or deny inbound and outbound 5-tuple traffic at subnet or NIC scope.
• Use Azure Firewall when the prompt asks for centralized managed firewall policy.
• Remember NSGs are stateful and priority-ordered (first match wins, lowest number first).

Service Tags, Application Security Groups, and a Worked Rule Set

Two features make NSG rules far easier to manage at scale, and both can appear in scenarios. Service tags are Microsoft-maintained named groups of IP ranges for Azure services — for example, Internet, VirtualNetwork, AzureLoadBalancer, Storage, or Sql. Instead of tracking changing Microsoft IP ranges, you reference the tag and Azure keeps it current. Application security groups (ASGs) group VMs by role (such as web or db), so a rule can say "allow web to reach db on 1433" without listing individual IPs; as you add VMs to the role, the rules apply automatically.

Picture a two-tier rule set on an application subnet's NSG:

Because the allow at priority 100 is evaluated before the broad deny at 200, web-tier traffic to the app tier on 443 is permitted, while all other inbound internet traffic is denied. Reorder those two and the deny would never let the web traffic through — the classic priority trap.

NSG Limitations the Exam Tests

Know what an NSG cannot do, because distractors exploit it. An NSG does not inspect packet content (no SQL-injection or malware detection — that is WAF and Defender). It does not do FQDN/domain-based filtering or centralized cross-network policy (that is Azure Firewall). It does not provide DDoS mitigation, store secrets, or manage identities. And NSG rules are limited to the 5-tuple plus tags/ASGs — they are filters, not a full firewall. When a stem needs anything beyond simple subnet/NIC allow-deny, the answer usually escalates to Azure Firewall, WAF, DDoS Protection, or an identity/data service.