Before Lab 2.6 — Network Security Groups

Mitch Mommers25/05/2026About 5 min

Before Lab 2.6 — Network Security Groups

In Lab 2.6, you will add explicit inbound and outbound rules to the NSGs on the Day 2 subnets.

What is an NSG?

A Network Security Group is a stateful packet filter attached to a subnet or network interface. It holds a list of inbound and outbound rules, each with a priority, source, destination, protocol, port range, and action (Allow or Deny). Azure evaluates rules lowest-priority-number first — the first match wins.

Priority  Name                    Source        Destination   Port   Action
100       allow-https-inbound     *             *             443    Allow
200       deny-all-inbound        *             *             *      Deny
65000     AllowVnetInBound        VirtualNet    VirtualNet    *      Allow  (default)
65500     DenyAllInBound          *             *             *      Deny   (default)

Default rules

Every NSG starts with rules you cannot delete.

Default inbound:

Priority	Name	Effect
65000	AllowVnetInBound	Allow traffic within the VNet
65001	AllowAzureLoadBalancerInBound	Allow Azure load balancer probes
65500	DenyAllInBound	Deny everything else

Default outbound:

Priority	Name	Effect
65000	AllowVnetOutBound	Allow outbound within the VNet
65001	AllowInternetOutBound	Allow outbound to the internet
65500	DenyAllOutBound	Deny everything else

Custom rules with a lower priority number override these.

Where NSGs are attached

An NSG attaches to a subnet (covering all resources in it) or to a specific VM NIC. Subnet-level is the common case.

Two NSGs are pre-created and attached by Terraform in the Day 2 environment — both start with only the default rules:

Application Security Groups (ASGs)

An Application Security Group is a logical grouping of VMs (or VM NICs) that you can reference in NSG rules instead of using IP addresses.

Example without ASG

NSG Rule: Allow port 443 from 10.0.1.10, 10.0.1.11, 10.0.1.12 to 10.0.2.20, 10.0.2.21

If you add a new web server or database server, you need to update the NSG rule with the new IP address.

Example with ASG

ASG "web-tier": VM1, VM2, VM3
ASG "db-tier": VM4, VM5

NSG Rule: Allow port 1433 from ASG "web-tier" to ASG "db-tier"

When you add a new web server, you assign it to the "web-tier" ASG. The NSG rule automatically applies without modification.

ASG vs NSG vs App Service access restriction

	App Service Access Restriction	NSG	ASG
Layer	Application (PaaS)	Network (L3/L4)	Network (L3/L4)
Scope	One App Service	Subnet or NIC	Logical group of NICs
Applies to	App Services only	VMs, App Services (via private endpoints), any resource with NIC	VMs with NICs
Use case	Restrict callers to an App Service	Filter traffic at subnet/NIC level	Simplify NSG rules for multi-tier VM architectures
Example	"Allow only calls from VNet subnet X"	"Deny all inbound from internet to subnet Y"	"Allow web-tier VMs to reach db-tier VMs on port 1433"

When to use ASGs

Use ASGs when:

✅ You have a multi-tier VM-based architecture (web tier, app tier, db tier)
✅ VMs scale up/down frequently and you don't want to update NSG rules constantly
✅ You want readable NSG rules (source: web-tier instead of source: 10.0.1.10, 10.0.1.11, ...)

Do NOT use ASGs when:

❌ You're using PaaS services (App Services, Storage Accounts) — use App Service access restrictions and private endpoints instead
❌ You only have a few static VMs with fixed IPs — IP-based NSG rules are simpler
❌ You're filtering at the subnet level and don't need per-VM granularity

Why ASGs are not in Day 2 labs

This course focuses on PaaS security (App Services, Storage Accounts, Key Vault). These services don't have NICs that you can assign to ASGs.

The Day 2 architecture uses:

App Service access restrictions to control which callers can reach App Services
NSG rules for subnet-level filtering (defense in depth)

ASGs would be relevant in a VM-focused course (e.g., "Securing IaaS workloads") with multi-tier VM architectures.

App Service Environment (ASE) and NSGs

App Service Environment (ASE) is a single-tenant deployment of Azure App Service that runs directly in your VNet. Unlike multi-tenant App Services (which we use in this course), ASE apps are deployed into a dedicated subnet with direct network integration.

Key differences: Multi-tenant vs ASE

	Multi-tenant App Service	App Service Environment (ASE)
Network model	Public by default, requires VNet integration for outbound	Fully integrated into your VNet subnet
Inbound control	Access restrictions (IP rules, service endpoints)	NSG rules on the ASE subnet
Outbound control	VNet integration + `WEBSITE_VNET_ROUTE_ALL=1`	NSG rules on the ASE subnet
NSG applicability	NSG can filter VNet-routed traffic only	NSG filters ALL traffic to/from ASE apps
Isolation	Shared infrastructure, logical isolation	Dedicated infrastructure, physical isolation
Cost	Pay per app/plan (~$50-200/month)	Pay for ASE (~$1,000/month minimum) + apps
Use case	Standard web apps, APIs	Regulatory compliance, network-isolated workloads

Why ASE matters for NSGs

With multi-tenant App Services (used in this course):

NSG can filter VNet-routed outbound traffic (when WEBSITE_VNET_ROUTE_ALL=1 is enabled)
NSG does NOT filter inbound traffic to the app's public endpoint (use access restrictions instead)

With App Service Environment:

NSG can filter ALL inbound and outbound traffic (because the app runs in your subnet)
NSG rules apply the same way as they do for VMs
You can use ASGs to group ASE apps if needed

Example NSG rule for ASE:

Allow HTTPS from Application Gateway subnet to ASE subnet
Source: 10.0.4.0/24 (App Gateway subnet)
Destination: 10.0.5.0/24 (ASE subnet)
Port: 443
Action: Allow

This works because ASE apps have direct subnet presence, unlike multi-tenant apps which only use VNet integration for outbound routing.

When to use ASE

Use ASE when:

✅ Regulatory requirements mandate network-isolated app hosting
✅ You need full control over NSG rules for both inbound and outbound traffic
✅ You have many apps and can amortize the ~$1,000/month ASE base cost

Do NOT use ASE when:

❌ Multi-tenant App Service + private endpoints + access restrictions meet your requirements
❌ Cost is a primary constraint (ASE is 10-20x more expensive)
❌ You only have 1-2 apps (ASE cost doesn't justify the isolation)

For this course: We use multi-tenant App Services because they're more common, more cost-effective for learning, and demonstrate the PaaS security controls most organizations need. ASE is a specialized solution for high-compliance scenarios.

NSG vs App Service access restriction

	NSG	App Service access restriction
Layer	Network (subnet)	Application (App Service)
Scope	All resources in the subnet	One App Service
Enforced by	Azure networking fabric	App Service platform
Visibility	Azure Monitor / NSG flow logs	App Service logs
Applies to	Any protocol / port	HTTP/HTTPS only

An NSG blocks before the packet reaches the application. An access restriction is evaluated by the App Service after the packet arrives. Both are useful; neither replaces the other.

Service tags

NSG rules can reference service tags instead of individual IPs — named groups that Microsoft maintains:

Tag	Meaning
`VirtualNetwork`	The entire address space of the VNet
`AzureLoadBalancer`	Azure internal load balancer health probes
`Internet`	Any public IP address
`AzureCloud`	All Azure datacenter IP ranges

NSG limitations with PaaS services

An important limitation to understand: NSG rules only filter traffic that flows through the subnet. For PaaS services like Storage Accounts and Key Vault:

Traffic to the private endpoint (private IP address, e.g., 10.0.2.x) flows through the subnet → NSG rules apply
Traffic to the public endpoint (e.g., *.table.core.windows.net) bypasses the VNet entirely → NSG rules do NOT apply

This means:

Critical implication: If someone accidentally re-enables public access on a Storage Account or Key Vault, the NSG will not block it. NSG cannot provide defense-in-depth against misconfigurations of PaaS service-level settings.

You must rely on:

Service-level controls (disabling public access)
Azure Policy (prevent re-enabling public access)
Proper change management processes

What to look for in Lab 2.6

Lab 2.6 checklist

Both NSGs exist and are associated with their subnets
Default rules only — no custom rules yet (this is the starting state)
Custom inbound deny rule on the private endpoints subnet is saved and has a priority below 65000
Re-enabling public access on storage makes it publicly accessible again (NSG does NOT block it)
Custom outbound rule on the app integration subnet restricts egress as intended
Effective security rules in the Portal show the custom rules merged with the defaults

NSG limitation demonstrated in Lab 2.6

Lab 2.6 demonstrates that NSG rules do NOT provide defense-in-depth against accidentally re-enabling public access on PaaS services. The NSG only filters traffic to the private endpoint NICs in the subnet, not traffic to public endpoints that bypass the VNet.