Azure VNet, Subnet, and NSG Fundamentals: Plan Address Space, Read Rules, and Verify Traffic

An Azure virtual network can look deceptively simple in the portal: choose an address range, create a subnet, attach a network security group, and add a few rules. The difficult part is not clicking Create. It is being able to answer, before and after deployment:

Which component may initiate a connection?
Which destination and port does it actually need?
Which route carries the packet?
Which rule allows or denies it?
How do we prove both the required path and the forbidden path?

Beginners often treat a VNet as a private room, a subnet as a wall, and an NSG as a small firewall appliance. That mental model is incomplete. Resources in the same VNet can communicate through Azure system routes by default. Separating two resources into different subnets organizes addresses and creates policy-attachment points, but it does not automatically deny traffic between them. An NSG filters Layer 3 and Layer 4 flows, but it does not create routes, perform source network address translation (SNAT), resolve names, authenticate users, or prove that an application is listening.

This is the fifth detailed note in the 12-topic Module 1 study plan for Coursera’s Azure Cybersecurity Solutions and Microsoft Defender course. The Module 1 review provides the wider control map. The preceding private VM design note separated administration, application inbound, internet outbound, and Azure service access. This article now explains the VNet, subnet, and NSG building blocks that make those paths enforceable.

These are independent study notes, not a transcript, assessment answer, production deployment record, or substitute for an application-specific threat model. Product behavior and limitations were reviewed against official Microsoft documentation on August 11, 2026.

Explicitly out of scope

This article teaches IPv4 address planning and NSG evaluation through one simplified three-tier workload. It does not provide portal, CLI, PowerShell, Bicep, or Terraform deployment steps. Full IPv6 design, hub-and-spoke transit, user-defined route implementation, VPN and ExpressRoute configuration, Azure Firewall policy, WAF tuning, Private Link DNS, and operating-system hardening remain separate topics. Example ports express a learning contract, not a ready-to-deploy production rule set.

1. The decision this article helps you make

The practical question is:

How should a beginner divide one Azure VNet into subnets, translate an application’s required connections into least-privilege NSG rules, and prove that allowed and denied traffic behave as intended?

By the end, you should be able to:

• read /16, /24, and /29 CIDR notation without guessing;
• calculate usable Azure IPv4 addresses after platform reservations;
• choose address ranges that do not collide with future connected networks;
• divide a VNet by role, trust, scale, and lifecycle;
• explain why a subnet is not an automatic security wall;
• read every field in an NSG rule from left to right;
• predict which rule wins by direction and priority;
• explain stateful return traffic and existing-flow behavior;
• understand subnet-level and NIC-level NSG evaluation;
• use service tags and application security groups (ASGs) without hiding intent;
• convert a three-tier flow inventory into a small learning rule set; and
• validate configuration, simulated rule decisions, actual connectivity, and flow evidence separately.

The output is not “an NSG exists.” It is a compact evidence package:

Address plan
+ subnet allocation table
+ required-flow inventory
+ versioned NSG rules
+ effective rule and route exports
+ positive and negative test results
+ log destination and owner
+ review date and rollback method

2. One mental model for VNet, subnet, route, and NSG

Use a city analogy carefully.

Azure concept	City analogy	Technical job
VNet address space	The full city boundary and address plan	Defines which private IP ranges belong to the virtual network
Subnet	A district inside the city	Allocates a smaller CIDR range and provides a placement/policy scope
Network interface (NIC)	A building’s network entrance	Connects a VM to one subnet and receives private IP configuration
Route	A road sign and next intersection	Selects the next hop for a destination prefix
NSG	A traffic checkpoint	Allows or denies an L3/L4 flow by source, destination, port, protocol, and direction
DNS	An address directory	Resolves a name into an address
Guest firewall and listener	The building’s final door and service desk	Decide whether the operating system and application accept the connection

The analogy stops before it becomes misleading. Azure networking is software-defined Layer 3 networking, not a physical Ethernet segment. A subnet boundary does not contain an invisible firewall. Azure also reserves addresses and provides platform services in ways that differ from a home network.

The memory model is:

Address space says where an IP belongs.
A route chooses the next hop.
An NSG permits or denies the flow.
None of them proves that the application is listening.

3. Inventory connected networks before choosing a CIDR

Do not begin by selecting 10.0.0.0/16 because it is familiar. First inventory every network this VNet might need to reach during its expected lifetime. The table below is a completed learning example; a real record must contain the organization’s actual prefixes and evidence that every overlap check passed.

Connected or future network	Current CIDR	Connection method	Owner	Overlap checked?
Corporate datacenter	10.0.0.0/16	ExpressRoute	Network team	Yes
Branch offices	172.16.0.0/16	Site-to-site VPN	Network team	Yes
Existing Azure production	10.20.0.0/16	VNet peering	Platform team	Yes
Disaster-recovery region	10.50.0.0/16 reserved	Global VNet peering	Platform team	Yes
AWS or Google Cloud	10.60.0.0/16 reserved	Future interconnect	Cloud platform team	Yes
Vendor network	192.168.50.0/24	VPN	Service owner	Yes

RFC 1918 provides three familiar private IPv4 ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Azure can also treat supported shared address space such as RFC 6598 100.64.0.0/10 as private in documented scenarios. “Private” does not mean “globally unique.” Thousands of organizations use the same ranges.

Two isolated VNets can technically reuse a CIDR. The problem appears when the organization later tries to connect them. Ordinary VNet peering requires non-overlapping address space, and overlapping hybrid or cross-cloud routes make the intended destination ambiguous. Readdressing running systems is much harder than reserving a non-overlapping block before deployment.

An address decision record should name the inventory date and approver:

Selected block: 10.40.0.0/16
Environment: learning example / production equivalent to be confirmed
Checked against: Azure, on-premises, DR, other clouds, vendors
Growth horizon: 24–36 months
Owner: platform networking
Review trigger: new peering, VPN, region, cloud, acquisition, or address expansion

4. Read CIDR without fear

CIDR notation combines a base address and a prefix length. In IPv4 there are 32 bits. The prefix says how many leading bits describe the network; the remaining bits describe addresses inside it.

Address count = 2 ^ (32 - prefix length)

CIDR	Host bits	Total IPv4 addresses	Azure-usable addresses after five reservations	Typical lesson
/16	16	65,536	Not normally used as one enormous workload subnet	Useful as a parent VNet block to subdivide
/24	8	256	251	Easy learning and general workload subnet example
/26	6	64	59	Required minimum for some dedicated platform subnets
/27	5	32	27	Small subnet with limited scale headroom
/29	3	8	3	Smallest supported IPv4 subnet; rarely a flexible production choice

A smaller prefix number represents a larger address block. /16 is much larger than /24. The prefix is not a resource capacity target; a service might require a particular minimum or consume several addresses during scale-out and upgrade.

For the learning VNet:

VNet: 10.40.0.0/16

Possible /24 child ranges:
10.40.0.0/24
10.40.1.0/24
...
10.40.255.0/24

This does not mean all 256 child ranges should be created immediately. It means the parent block leaves a structured space from which the team can allocate without overlap.

5. Create a non-overlapping address plan

Use a table rather than a diagram alone.

Allocation	CIDR	Purpose	State	Growth note
VNet	10.40.0.0/16	Entire workload network	Allocated	Must not overlap connected networks
snet-edge	10.40.0.0/24	Approved application frontend	Allocated	Platform-specific sizing must be rechecked
snet-web	10.40.10.0/24	Web-tier backends	Allocated	Scale-out and upgrade headroom
snet-app	10.40.20.0/24	Application-tier services	Allocated	Scale-out and blue/green headroom
snet-data	10.40.30.0/24	Database-tier hosts	Allocated	Private endpoints evaluated separately
snet-management	10.40.40.0/24	Approved management components	Reserved	Actual administration design is outside scope
Future platform/workloads	Remaining non-overlapping ranges	Growth, DR, or dedicated services	Reserved pool	Allocate only through IP management process

The gaps between examples are intentional. They make diagrams and summaries easier to read and leave room for related subnets. A production allocation might use different sizes and a centrally managed IP Address Management (IPAM) system. Azure Virtual Network Manager includes IPAM capabilities for larger estates; a small team can begin with a controlled register if ownership and review are real.

Do not copy 10.40.0.0/16 into production without checking the organization’s actual inventory. The example is documentation address planning, not a universal safe range.

6. Budget for Azure reservations and growth

Azure reserves five IPv4 addresses in every subnet:

Address position	Example in 10.40.10.0/24	Azure purpose
First	10.40.10.0	Network identifier
Second	10.40.10.1	Default gateway
Third	10.40.10.2	Azure DNS mapping
Fourth	10.40.10.3	Azure DNS mapping
Last	10.40.10.255	Reserved broadcast address

Therefore a /24 has 256 total addresses but 251 usable Azure resource addresses, not 254. A /29 has eight total and only three usable. Azure is a Layer 3 overlay and does not provide traditional broadcast or multicast behavior merely because the final address is reserved.

Sizing must also include:

• current VM and NIC count;
• temporary addresses during scale-out, rolling upgrades, blue/green deployment, or failover;
• private endpoints and platform instances that consume subnet addresses;
• required dedicated subnet sizes;
• monitoring, recovery, and management components;
• two- to three-year growth; and
• enough contiguous free space to expand without readdressing.

“We need six VMs, so /28 is enough today” is not a design. The next deployment may need surge instances, parallel replacement, or a service whose minimum size is larger. Record the calculation and its growth assumption.

7. Split subnets by role, trust, scale, and lifecycle

Subnet design should express meaningful differences. Useful reasons to separate resources include:

• Application role: edge, web, application, data, management, and private endpoints have different required flows.
• Trust level: an internet-facing frontend and a database should not inherit one undifferentiated policy.
• Scale pattern: a stateless web tier can scale differently from a fixed management component.
• Lifecycle: platform-owned shared services and application-owned instances may change on different schedules.
• Routing requirement: a subnet may need a route table that directs egress through a firewall.
• Service requirement: Azure Firewall, Bastion, VPN Gateway, Route Server, and DNS Private Resolver have documented subnet naming or sizing requirements.
• Delegation requirement: some Azure services require a delegated subnet and restrict which other resources can share it.

Avoid both extremes:

One subnet for everything
→ simple initially, weak policy boundaries and difficult change ownership

One subnet for every VM
→ excessive objects, wasted reserved addresses, fragmented policy and operations

A good starting principle is to group components that share the same trust boundary, required flows, route behavior, scale pattern, and owner. Exceptions should be explicit rather than discovered in rule names such as TemporaryAllowAll2.

8. Reserve room for platform and future subnets

Some Azure services require a dedicated subnet or strongly recommended capacity. Current examples include:

Service	Current design reference	Beginner implication
Azure Firewall	Dedicated AzureFirewallSubnet, /26 minimum	Do not fill the VNet before planning central inspection
Azure Bastion	Dedicated AzureBastionSubnet, /26 minimum for current dedicated deployments	Reserve the correct name and capacity if Bastion is selected
VPN Gateway	GatewaySubnet, /27 or larger recommended	Hybrid connectivity consumes planned address space
Azure DNS Private Resolver	Dedicated inbound and outbound endpoint subnets, /28 minimum each	DNS design may require two additional subnets
Application Gateway v2	Dedicated subnet; /24 commonly recommended for scale	Frontend capacity is not just the current instance count
Private Endpoint	Consumes a private IP in a subnet; dedicated subnet not universally required	Count endpoints and decide an ownership pattern

These values can change and some services have SKU- or scenario-specific requirements. Treat this table as a planning prompt and verify the current product documentation before deployment.

The lesson is not “make every subnet /24.” It is “inventory platform requirements before allocating the easy ranges.”

9. A subnet is not an automatic security wall

Azure creates system routes that let resources in the same VNet reach one another by default. A subnet partitions addresses and provides attachment scope for NSGs and route tables, but creating snet-web and snet-data alone does not deny Web-to-Database traffic.

If an NSG exists, its default inbound rule at priority 65000 is AllowVNetInBound. The VirtualNetwork service tag is broader than “this subnet.” It can include the VNet address space and connected ranges such as peered VNets or on-premises networks, depending on topology and routes. Treating that default as least-privilege segmentation is unsafe.

Subnet separation only

Web 10.40.10.4 ───────────────► Database 10.40.30.4:1433
                  system route
                  no intended deny yet

Segmentation needs both:

1. an address and placement boundary that makes roles understandable; and
2. an enforcement rule that permits the required source, destination, protocol, and port while denying unintended neighboring paths.

This does not mean every pair of subnets requires a custom deny in every architecture. It means the team must inspect the actual applicable rules and prove the result instead of assuming the subnet name enforces intent.

10. Draw the three-tier reference architecture

The rest of this article uses one simplified topology.

Internet user
    │
    ▼ HTTPS 443
Approved reverse-proxy frontend
Learning assumption: Application Gateway v2
snet-edge 10.40.0.0/24
    │
    ▼ HTTPS 443
Web tier
snet-web 10.40.10.0/24
    │
    ▼ TCP 8443
Application tier
snet-app 10.40.20.0/24
    │
    ▼ TCP 1433
Database tier
snet-data 10.40.30.0/24

The intended application flow is sequential:

Edge → Web → App → Data

The following shortcuts should fail:

Internet ─X→ Web / App / Data directly
Edge     ─X→ App / Data directly
Web      ─X→ Data directly
App      ─X→ Data on an unapproved port

This learning topology assumes that Application Gateway v2 acts as a reverse proxy in snet-edge and opens a new connection to the Web backend. Another frontend can present a different source to the backend. For example, Azure Load Balancer preserves the original client source IP, and its load-balancing rule does not replace an applicable NSG permission. Recheck the selected product’s backend source semantics before copying the later NSG examples.

Ports 443, 8443, and 1433 are learning examples. A real application contract must identify the actual listener, encryption, authentication, health probe, source, destination, and availability requirements. SQL Server’s familiar port does not mean every data tier should expose TCP 1433.

11. Write the traffic inventory before writing rules

Rules are implementation. Begin with flows and reasons.

ID	Purpose	Source	Destination	Protocol / destination port	Expected result	Owner	Failure impact
F01	Frontend delivery	snet-edge	Web tier	TCP 443	Allow	Edge team	User requests fail
F02	Application call	Web tier	App tier	TCP 8443	Allow	App team	Web requests fail
F03	Database call	App tier	Data tier	TCP 1433	Allow	Data team	Transactions fail
F04	Direct database shortcut	Web tier	Data tier	TCP 1433	Deny	Security owner	Limits lateral movement
F05	Wrong app port	Web tier	App tier	TCP 22	Deny	Security owner	Prevents unintended administration path
F06	Wrong database port	App tier	Data tier	TCP 3306	Deny	Security owner	Enforces actual application contract
F07	Direct public access	Internet	App and Data tiers	Any	Deny	Platform team	Prevents direct exposure

This table is deliberately incomplete for deployment. Add actual requirements for:

• DNS resolution;
• operating-system updates and package repositories;
• identity and time synchronization;
• monitoring and log export;
• backup and recovery;
• load-balancer or application health probes;
• vulnerability management;
• administration through the approved private path; and
• outbound application dependencies.

An owner must decide each dependency. “Allow any outbound because agents need things” is not a flow inventory.

12. Walk one packet from source to application

Suppose the Web tier calls app.internal.example on TCP 8443. Follow the dependencies in the documented outbound and inbound evaluation order.

1. DNS
   app.internal.example → 10.40.20.4

2. Source-side filtering
   Any applicable Web NIC/subnet outbound NSGs evaluate the new flow

3. Route selection
   Web NIC effective route for 10.40.20.4 → Virtual network next hop

4. Destination-side filtering
   Any applicable App subnet/NIC inbound NSGs evaluate the new flow

5. Guest operating system
   OS firewall permits TCP 8443

6. Listener
   Application is bound to the expected interface and TCP 8443

7. TLS and identity
   Certificate, client identity, and application authorization succeed

8. Application health
   The process can serve the requested operation and its dependencies

An NSG Allow proves only the network-filter decision for its scope. It does not prove that DNS returned the intended address, a route exists, the return path is valid, the guest firewall permits traffic, the service is listening, or authentication succeeds.

The inverse is also important. A correct route cannot override an NSG Deny. Troubleshooting must identify the failing layer instead of repeatedly changing the NSG.

13. What an NSG does—and does not do

An Azure Network Security Group is a distributed, stateful Layer 3 and Layer 4 traffic filter. It contains inbound and outbound rules and can be associated with supported subnets and VM network interfaces.

An NSG can decide:

• whether a new inbound or outbound flow is allowed or denied;
• based on source, source port, destination, destination port, and protocol;
• at subnet or NIC enforcement scope; and
• using IP/CIDR values, service tags, or application security groups where supported.

An NSG does not:

• create a route or select a network virtual appliance;
• provide SNAT or a stable outbound public IP;
• create a public or private endpoint;
• resolve DNS names or filter by arbitrary FQDN;
• inspect HTTP paths, SQL injection, malware, or TLS content;
• authenticate a user or workload identity;
• patch or harden an operating system;
• prove that a destination application is listening; or
• replace centralized firewall policy when the architecture requires inspection, egress governance, or cross-network operations.

This boundary is why “NSG is a cheaper Azure Firewall” is a poor comparison. They can both filter some packet attributes, but their enforcement, inspection, routing, logging, and operating models differ. The next Module 1 topics examine Azure Firewall separately.

14. Read an NSG rule from left to right

Every rule should be readable as a sentence.

Field	Example	Question it answers
Name	Allow-Web-To-App-8443	Why does this rule exist?
Priority	100	When is it evaluated relative to neighboring rules?
Direction	Inbound	Is the flow entering or leaving the protected resource?
Source	asg-web	Who initiates the connection?
Source port	*	Which client-side port can initiate it?
Destination	asg-app	Which role receives the connection?
Destination port	8443	Which service port is required?
Protocol	TCP	Which Layer 4 protocol is allowed?
Action	Allow	Is the matching flow accepted or rejected?

Read it aloud:

For inbound traffic, allow TCP connections initiated by Web-tier NICs from any client source port to App-tier NICs on destination port 8443, before lower-priority rules are considered.

Why the source port is usually *

A client commonly selects an ephemeral source port, such as 51542, when it connects to server destination port 8443. Restricting both source and destination to 8443 can accidentally describe a connection the client never makes.

Web client 10.40.10.4:51542 → App server 10.40.20.4:8443
                source port                         destination port

Restrict the destination service port. Restrict the source address or role. Limit source ports only when the protocol contract genuinely requires it.

For inbound traffic through a public IP, NSG evaluation occurs after Azure translates the public destination to the private address. For outbound, the NSG evaluates the private source before public translation. Use the VM’s private IP, subnet CIDR, or ASG—not its public IP—as the workload endpoint in the rule model.

15. Lower number wins, and first match stops

Custom NSG rule priorities range from 100 through 4096. A lower number is evaluated first. Once traffic matches a rule in that NSG, evaluation in that NSG stops.

Consider:

Priority	Rule	Result for Web → App TCP 8443
100	Allow Web to App TCP 8443	Matches and allows; evaluation stops
200	Deny Web to App TCP 8443	Never evaluated for that flow
4000	Deny remaining VirtualNetwork inbound	Never evaluated for that flow

Now reverse the first two actions:

Priority	Rule	Result
100	Deny Web to App TCP 8443	Matches and denies immediately
200	Allow Web to App TCP 8443	Never evaluated

Priority 100 is not “more secure” than priority 200. It is simply earlier. The result depends on the matching conditions and action.

Leave intentional gaps—such as 100, 200, 300, and 4000—so urgent rules can be inserted without renumbering everything. Do not rely on names or portal display order; evaluate the numeric priority and direction.

Two custom rules cannot use the same priority in the same direction within one NSG. Infrastructure as code and review checks should detect accidental conflicts and overly broad shadowed rules.

16. Read the six default rules before trusting segmentation

Azure creates six default rules inside each NSG you create. They are not an invisible NSG attached to every VNet.

Default inbound rules

Priority	Name	Source	Destination	Protocol / port	Action
65000	AllowVNetInBound	VirtualNetwork	VirtualNetwork	Any	Allow
65001	AllowAzureLoadBalancerInBound	AzureLoadBalancer	Any	Any	Allow
65500	DenyAllInbound	Any	Any	Any	Deny

Default outbound rules

Priority	Name	Source	Destination	Protocol / port	Action
65000	AllowVnetOutBound	VirtualNetwork	VirtualNetwork	Any	Allow
65001	AllowInternetOutBound	Any	Internet	Any	Allow
65500	DenyAllOutBound	Any	Any	Any	Deny

You cannot delete these defaults, but a custom rule at 100–4096 is evaluated first and can override their practical result.

Three corrections matter:

1. AllowVNetInBound is not least privilege. The VirtualNetwork tag can include peered and connected ranges beyond the local subnet.
2. AllowInternetOutBound does not create internet connectivity. It permits filtering if a valid route and explicit or legacy outbound mechanism exist. For API versions released after March 31, 2026, subnets created as part of a new VNet default to defaultOutboundAccess=false. Existing VNets are not changed automatically, and older API versions can retain the earlier implicit behavior. Inspect the real subnet and egress design.
3. AzureLoadBalancer represents platform health-probe traffic, not all customer traffic through a load balancer. Backend data traffic retains the original source context documented for the service.

There is another separate default: Standard public IP frontends are secure by default for inbound traffic until an NSG explicitly permits it. When the frontend belongs to a Standard Load Balancer, the load-balancing rule and the applicable NSG permission are both required. Do not confuse that public-IP behavior with the six default rules that exist only inside an NSG.

17. Understand stateful return traffic

NSGs keep flow state. If a new App-to-Database TCP 1433 connection is allowed, the response packets for that established flow do not require a mirrored Database → App allow rule.

New flow initiation
App 10.40.20.4:52341 → Data 10.40.30.4:1433
NSG rule evaluates and allows

Stateful response
Data 10.40.30.4:1433 → App 10.40.20.4:52341
Return traffic is allowed for the established flow

This does not allow the Database tier to initiate an unrelated new connection back to the App tier. A new reverse-direction flow is evaluated against the applicable rules in its own direction.

Rule changes also affect new connections. Removing an SSH allow rule does not necessarily terminate an existing SSH flow. The session can remain until it closes or its state expires. A test that reuses an old connection can therefore make a new deny look ineffective.

After a rule change:

1. retain the change timestamp and rule version;
2. close or distinguish the existing test session;
3. initiate a genuinely new connection;
4. test the required allow and prohibited deny cases; and
5. inspect the matching rule and logs.

Stateful does not mean “automatically secure.” It means return packets for a permitted conversation are tracked.

18. Subnet NSG and NIC NSG evaluation

An NSG can be associated with a subnet, a supported VM NIC, or both.

For inbound traffic, documented processing is:

Source → Subnet NSG → NIC NSG → Guest OS / application

For outbound traffic:

Guest OS / application → NIC NSG → Subnet NSG → Next hop

If both levels apply, every applicable NSG must allow the new flow. A subnet allow cannot override a NIC deny, and a NIC allow cannot override a subnet deny. The first blocking level stops the packet.

The same principle applies to communication between VMs in one subnet. Intra-subnet traffic does not bypass NSG evaluation.

Microsoft recommends avoiding simultaneous subnet and NIC NSGs when one level can express the requirement. Two levels create more places for rules to conflict and more difficult troubleshooting. A beginner-friendly starting model is:

Uniform tier policy → subnet NSG
Exceptional NIC rule → use only with a documented requirement and owner

Do not infer processing from the order in which legacy flow-log records happen to appear. Inspect the aggregate effective rules and both configured scopes.

19. Use service tags, ASGs, and advanced rules without hiding intent

Service tags represent managed IP prefix sets

A service tag such as Storage, AzureLoadBalancer, or VirtualNetwork represents a Microsoft-managed group of IP prefixes. Microsoft updates the addresses so teams do not hardcode a changing list.

A service tag is not:

• a Microsoft Entra identity;
• a tenant or subscription boundary;
• one specific service resource instance;
• proof that traffic is encrypted or authenticated; or
• a replacement for the destination service’s firewall, identity, and authorization.

Use a regional tag where the service supports it and the requirement is regional. Avoid broad AzureCloud or VirtualNetwork permissions without understanding their current scope. Service tags simplify IP maintenance; they do not make an overly broad requirement safe.

Application security groups represent NIC roles

An ASG groups VM NICs by workload role, such as asg-web, asg-app, or asg-data. An NSG rule can then express:

Allow asg-web → asg-app TCP 8443
Allow asg-app → asg-data TCP 1433

The rule survives private-IP changes and scale operations as NIC membership changes. ASGs do not group human users, Azure resources of every type, or NICs arbitrarily across VNets. ASG members and ASG-to-ASG rule use must respect the same-VNet constraints.

Augmented rules reduce rule count

An augmented NSG rule can combine multiple explicit IP addresses, CIDR ranges, and port ranges in one rule. Use this when the combined items have the same purpose, owner, action, and lifecycle. Do not compress unrelated exceptions into one unreadable rule merely to reduce count, and do not assume multiple service tags can be mixed arbitrarily in one field.

Central admin rules may be evaluated before local NSGs

In an enterprise managed through Azure Virtual Network Manager, Security Admin Rules can apply before local NSGs. An admin Deny stops traffic, Always Allow can bypass NSG evaluation, and Allow lets evaluation continue to the NSG. If a local NSG appears correct but the result differs, include central admin rules in the evidence review.

Azure platform endpoints require caution

Azure uses host virtual addresses such as 168.63.129.16 and 169.254.169.254 for different platform functions. The former participates in services such as Azure-provided DNS, health probes, DHCP, and VM platform communication; the latter is the non-routable Instance Metadata Service endpoint. Do not add raw-IP denies from an internet threat list without understanding Azure platform dependencies. Dedicated tags such as AzurePlatformDNS, AzurePlatformIMDS, and AzurePlatformLKM exist for specific controls. Denying them can disrupt their named dependencies: Azure-provided DNS, IMDS/managed identity, and Windows licensing. VM Agent WireServer traffic to 168.63.129.16 on TCP 80 and 32526 is not subject to NSGs and must instead remain allowed in the guest firewall.

20. Translate the three-tier intent into learning rules

The following inbound rules illustrate the policy. They assume subnet-level NSGs, the earlier CIDRs, and separate documented flows for management and platform dependencies.

NSG	Priority	Source	Source port	Destination	Destination port	Protocol	Action
nsg-web	100	10.40.0.0/24	*	10.40.10.0/24	443	TCP	Allow
nsg-web	4000	VirtualNetwork	*	10.40.10.0/24	*	Any	Deny
nsg-app	100	10.40.10.0/24	*	10.40.20.0/24	8443	TCP	Allow
nsg-app	4000	VirtualNetwork	*	10.40.20.0/24	*	Any	Deny
nsg-data	100	10.40.20.0/24	*	10.40.30.0/24	1433	TCP	Allow
nsg-data	4000	VirtualNetwork	*	10.40.30.0/24	*	Any	Deny

The allow comes before the remaining connected-network deny. Sources outside VirtualNetwork that do not match another custom allow eventually reach DenyAllInbound at 65500.

An ASG version can replace fixed workload CIDRs with roles:

asg-web → asg-app TCP 8443 Allow
asg-app → asg-data TCP 1433 Allow

The CIDR table is easier for learning, while the ASG form can better express a scaling VM role. The correct choice depends on supported resources and ownership.

This is not a production deployment template. Before the priority-4000 deny, a real design must add narrowly defined rules for approved management, health probes, monitoring, backup, identity, and other documented inbound dependencies. Outbound rules and explicit egress policy also require a separate flow inventory. A broad deny without dependency tests can create an outage; omitting it without understanding AllowVNetInBound can leave unintended lateral paths.

21. Evaluate packets like the NSG

Practice first-match evaluation against the learning rules.

Case A: Edge → Web TCP 443

Source 10.40.0.4, destination 10.40.10.4, TCP 443
→ nsg-web priority 100 matches
→ Allow; stop evaluating nsg-web

Case B: Edge → Web TCP 80

Priority 100 does not match destination port
→ Priority 4000 matches remaining VirtualNetwork inbound
→ Deny

Case C: Web → App TCP 8443

Source 10.40.10.4, destination 10.40.20.4, TCP 8443
→ nsg-app priority 100 matches
→ Allow

Case D: Web → Data TCP 1433

Source is Web, not the allowed App subnet
→ nsg-data priority 100 does not match
→ priority 4000 VirtualNetwork deny matches
→ Deny

This is the critical shortcut test. Without an applicable custom deny, a same-VNet flow might reach default AllowVNetInBound.

Case E: App → Data TCP 1433

nsg-data priority 100 matches
→ Allow

Case F: App → Data TCP 3306

Priority 100 does not match destination port
→ Priority 4000 matches
→ Deny

Case G: Data response to the permitted App request

Response belongs to the established App → Data TCP 1433 flow
→ Stateful return traffic is permitted
→ No mirrored new-flow rule is required

Case H: The allow rule was just removed

Old connection may continue
New connection is evaluated against the changed rules
→ Close or distinguish the old session and test again

For every case, also ask whether a NIC NSG or central admin rule applies. Evaluating only the visually closest subnet NSG is not enough.

22. Prove both allowed and denied paths

Use four evidence layers.

Layer 1: configuration evidence

• Export the VNet address space and subnet allocations.
• Confirm the actual NSG-to-subnet and NSG-to-NIC associations.
• View Effective security rules for each relevant VM NIC; this aggregates subnet, NIC, and applicable central admin rules.
• View Effective routes and use Network Watcher Next hop to confirm the selected path.

Layer 2: simulated rule decisions

Network Watcher IP flow verify evaluates TCP or UDP direction, local/remote address, and ports against applicable NSG and admin rules. It returns allow or deny and the matching rule. Use NSG diagnostics for ICMP and scenarios such as scale sets that IP flow verify does not cover.

An Allowed result is not an end-to-end application test. It does not prove the route, guest firewall, listener, TLS, identity, or application health.

Layer 3: real positive and negative connections

Test	Expected result	Evidence
Edge → Web TCP 443	Succeeds	Application request plus matching path evidence
Edge → Web TCP 80	Fails	New connection result plus matching deny rule
Web → App TCP 8443	Succeeds	curl, Test-NetConnection, or approved client test
Web → App TCP 22	Fails	New connection result and rule decision
Web → Data TCP 1433	Fails	Shortcut denial evidence
App → Data TCP 1433	Succeeds	Application/database handshake evidence
App → Data TCP 3306	Fails	Wrong-port denial evidence
Internet → App/Data	Fails	Exposure inventory, public edge check, and connection result

Test from realistic source NICs. A laptop test outside Azure does not prove Web-to-App segmentation. After rule changes, use new connections.

Layer 4: operating evidence

For new designs, use Virtual Network flow logs where the workload is supported. They record Layer 4 flow metadata such as the five-tuple, direction, state, rule, bytes, and packets to Azure Storage. They do not capture packet payloads and do not support every Azure service.

NSG flow logs can no longer be newly created after June 30, 2025 and are scheduled to retire on September 30, 2027. Existing stored records follow their storage retention, but a new 2026 monitoring design should use Virtual Network flow logs. Avoid duplicate collection and cost by following Microsoft’s migration order when both logging types touch the same workload.

23. Operate changes as policy, not portal memory

Every rule should have:

• a business or technical purpose;
• source and destination owner;
• protocol and port contract;
• rule priority rationale;
• creation and review date;
• ticket or decision reference;
• positive and negative test;
• monitoring destination;
• expiry for temporary exceptions; and
• rollback procedure.

Use infrastructure as code and policy checks where practical. A portal screenshot can help a reviewer, but it cannot prove current associations, effective rules, or behavior after drift.

Address and subnet checklist

• The CIDR was checked against Azure, on-premises, DR, other clouds, and vendor networks.
• Every subnet is inside the VNet address space and does not overlap another subnet.
• Five Azure-reserved IPv4 addresses are included in capacity calculations.
• Scale-out, upgrades, failover, private endpoints, and platform services have headroom.
• Subnets represent role, trust, routing, scale, lifecycle, or service requirements—not arbitrary names.
• Required dedicated subnet names and current minimum sizes were rechecked.
• Unallocated ranges and their owner are recorded.

NSG checklist

• Every NSG association is known at subnet and NIC scope.
• Rules can be read as source → destination → protocol/port → action.
• Source ports are not accidentally restricted to server destination ports.
• Lower-number priorities and first-match shadowing were reviewed.
• The scope of VirtualNetwork, Internet, and AzureLoadBalancer tags is understood.
• Required allow rules appear before any broad connected-network deny.
• Outbound requirements are reviewed instead of relying blindly on AllowInternetOutBound.
• NIC and subnet NSGs are not combined without a documented reason.
• Central Security Admin Rules are included when Azure Virtual Network Manager governs the VNet.
• Temporary Any rules have an owner and automatic or dated removal.

Validation and operations checklist

• Required paths succeed from the real source.
• Neighboring forbidden paths fail from the real source.
• Tests use new connections after rule changes.
• Effective security rules and effective routes are retained with timestamps.
• IP flow verify or NSG diagnostics identifies the expected matching rule.
• Guest firewall, listener, TLS, identity, and application health are tested separately.
• Virtual Network flow logs, retention, access, cost, and review owner are defined where applicable.
• Alerts exist for dangerous broad rules, association removal, and unexplained policy changes.
• Rollback restores the previous known rule set without leaving an emergency allow open.
• A reassessment trigger covers new peering, address expansion, scale, service, or workload dependencies.

24. Self-review questions and one-minute memory card

Questions

1. Why does a /24 provide 251 usable Azure IPv4 addresses rather than 254?
2. Why should connected and future networks be inventoried before choosing a VNet CIDR?
3. Why does dividing Web and Data into separate subnets not automatically deny Web-to-Data traffic?
4. What separate questions do an address plan, route, NSG, and application listener answer?
5. Which five fields form the NSG flow tuple?
6. If priority 100 denies and priority 200 allows the same flow, which result wins?
7. Why is an NSG source port commonly * for a client-to-server rule?
8. Why does a permitted response not require a mirrored rule in a stateful NSG?
9. Why might an SSH session continue after its allow rule is deleted?
10. What order applies to subnet and NIC NSGs for inbound and outbound traffic?
11. How is a service tag different from an ASG?
12. Why might VirtualNetwork be broader than the current VNet subnet?
13. What should you inspect when IP flow verify says Allowed but the application still fails?
14. Why are both positive and negative tests necessary?
15. Which current flow-log type should a new 2026 design use?

Memory card

Plan the space → separate roles → name every flow
→ allow only the required path → prove both allow and deny.

Address plan = where addresses can exist
Subnet = placement and policy scope, not an automatic wall
Route = where the packet goes next
NSG = whether the L3/L4 flow may pass

Lower number wins.
First match stops.
Return traffic is stateful.
Reconnect after a rule change.

NSG Allowed ≠ application healthy.
Subnet separated ≠ traffic denied.

The final memory line is:

Secure VNet design begins with non-overlapping addresses, turns named application flows into narrowly scoped rules, and proves both what can connect and what cannot.

The next Module 1 detailed note will compare Azure Firewall Basic, Standard, and Premium before later notes examine routing, DNS, rules, logging, and validation. It remains planned until the complete English and Korean article pair is ready; no empty route is linked.

References

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: Azure virtual networks and subnets
• Microsoft Learn: IP address planning for Azure virtual networks
• Microsoft Learn: Virtual networks and virtual machines
• Microsoft Learn: Azure Virtual Network FAQ
• Microsoft Learn: Network security groups overview
• Microsoft Learn: How network security groups filter traffic
• Microsoft Learn: Network security groups and application security groups
• Microsoft Learn: Application security groups
• Microsoft Learn: Service tags overview
• Microsoft Learn: Azure virtual network traffic routing
• Microsoft Learn: Azure virtual network peering
• Microsoft Learn: How an application gateway works
• Microsoft Learn: Azure Load Balancer concepts
• Microsoft Learn: Default outbound access
• Microsoft Learn: Azure public IP addresses
• Microsoft Learn: What is IP address 168.63.129.16?
• Microsoft Learn: Azure Instance Metadata Service
• Microsoft Learn: Azure Virtual Network Manager Security Admin Rules
• Microsoft Learn: Effective security rules overview
• Microsoft Learn: IP flow verify overview
• Microsoft Learn: Diagnose VM traffic filtering
• Microsoft Learn: Diagnose a VM routing problem
• Microsoft Learn: Network Watcher connection troubleshoot
• Microsoft Learn: Virtual Network flow logs
• Microsoft Learn: Migrate from NSG flow logs to Virtual Network flow logs