Azure NSG / ASG Design Guide: Network Security Group Rules & Application Security Group Patterns

NSG (Network Security Group) is a stateful firewall that controls traffic inside a VNet. It is applied at the subnet or NIC level and defines Inbound/Outbound rules based on IP/Port/Protocol. ASG (Application Security Group) is a complementary feature that logically groups NSG rule targets - you create role-based groups like Web Tier, App Tier, and DB Tier, then reference those groups in NSG rules instead of IP addresses, which dramatically simplifies rule management. The standard pattern is to use both together: NSG is the control engine, ASG is the logical grouping layer. In any enterprise VNet you should always leverage ASGs to keep NSG rules maintainable.

NSG rules are evaluated in ascending order of priority (100-4096), and the first matching rule wins. 100 is the highest priority, 4096 the lowest. Three Default Rules ship at 65000-65500: AllowVnetInBound, AllowAzureLoadBalancerInBound, DenyAllInBound (Inbound) and AllowVnetOutBound, AllowInternetOutBound, DenyAllOutBound (Outbound). These can be overridden by custom rules. The canonical design hierarchy is: 100-200 for ultra-high priority emergency blocks, 1000-3000 for normal Allow rules, 4000 for a custom default Deny, and leave the Default Rules untouched. Spacing priorities out leaves room to insert new rules later without renumbering existing ones.

Service Tags are predefined IP address range groups for Azure services provided by Microsoft (60+ tags such as AzureCloud, Internet, VirtualNetwork, AzureKeyVault, AzureMonitor, Storage). They are used in NSGs and Azure Firewall Network Rules instead of raw IPs, and Microsoft auto-updates the ranges, so operational overhead is zero. FQDN Tags are FQDN groups used in Azure Firewall Application Rules (such as Microsoft365, WindowsUpdate, AzureBackup), HTTP/HTTPS only, fewer in number than Service Tags but covering the most common scenarios. NSGs only support Service Tags - FQDN Tags are exclusive to Azure Firewall. A common pattern: implement 'allow outbound from this subnet only to the Storage service' with Service Tag = Storage in an NSG.

Subnet-level is the recommended approach. A subnet-level NSG applies uniformly to every resource in the subnet, which makes management easy and scalable. A NIC-level NSG is applied directly to an individual VM's NIC, and is meant for exception rules that apply to a specific VM only. Implementation pattern: configure baseline security with a subnet-level NSG, then add NIC-level NSGs only for VM-specific extras (when both subnet and NIC NSGs are applied, evaluation is AND-based - only traffic permitted by both passes). Best practice for any new VNet is to always configure a subnet-level NSG and reserve NIC-level NSGs for exceptions.

ASGs (Application Security Groups) create role-based logical groups: you associate an ASG with a VM's NIC, then reference the ASG as Source/Destination in NSG rules. A standard design has 4-5 ASGs: WebTier-ASG (web server VMs), AppTier-ASG (application VMs), DBTier-ASG (database server VMs), and MgmtTier-ASG (jumpboxes and management VMs). Example NSG rules: 'Internet -> WebTier-ASG TCP 80/443 Allow', 'WebTier-ASG -> AppTier-ASG TCP 8080 Allow', 'AppTier-ASG -> DBTier-ASG TCP 1433 Allow'. The payoff: you can manage security per role without worrying about VM IPs, and rules do not need to change when Auto Scale dynamically adds or removes VMs.

NSG Flow Logs is a feature that records every flow passing through an NSG to a Storage Account in JSON format. It captures Allowed/Denied verdicts, source/destination IPs, ports, protocols, timestamps, and byte counts. Traffic Analytics (a paid Network Watcher feature) aggregates and visualizes these flows, with reports for Top Talkers, anomaly detection, and threat detection. Sending flows to Microsoft Sentinel integrates them into SOC analytics, where KQL queries can flag anomalies (for example, unexpected outbound traffic or a spike in Denied flows). Flow Logs v2 is the current version with aggregated reports; v1 is legacy. In production, Flow Logs are mandatory for compliance regimes (PCI DSS, HIPAA) and forensic investigation, with at least a 90-day retention as the standard.

Common pitfalls: 1) Leaving the default Allow Outbound to Internet in place - every VM can reach the internet, creating data-exfiltration risk; add proper Deny rules. 2) Special subnet names (AzureBastionSubnet, GatewaySubnet) impose NSG constraints - Bastion subnets require specific rules, and NSGs are not recommended on Gateway subnets. 3) Ignoring Service Tag update timing - Microsoft refreshes IP ranges monthly, and brand-new IPs may be temporarily blocked. 4) Packing NSG rule priorities too densely makes later additions painful; leave gaps of 1000. 5) Skipping ASGs and hard-coding IPs breaks rules as soon as Auto Scale fires. 6) No Flow Logs means you cannot diagnose incidents. Catching these at design time dramatically reduces operational cost downstream.

AZ-700 (Network Engineer Associate) covers NSGs and ASGs in depth, with frequent questions on rule design, Service Tags, Flow Logs, Traffic Analytics, and ASG patterns. AZ-104 (Administrator) covers the basics in Domain 4; AZ-305 (Solutions Architect Expert) covers security design from an architect's perspective; SC-100 (Cybersecurity Architect Expert) covers zero-trust networking and microsegmentation; SC-500 (formerly AZ-500, GA September 2026) covers Azure security implementation. Understanding NSGs and ASGs is a non-negotiable skill for any engineer working with Azure.