Azure NSG Rule Generator
Generate Azure NSG rules from CSV
NSG Rules
Format
name, priority, direction, access, port, protocol, source
Direction: Inbound/Outbound, Access: Allow/Deny
Generated Output
Enter rules to generate Azure NSG config
The Azure NSG Rule Generator creates Network Security Group rules from structured CSV input. Enter rules as rows with direction, priority, name, source, destination, protocol, port range, and action columns, and get Azure CLI commands, PowerShell commands, or ARM template JSON for automated, repeatable network security deployments in Azure.
Understanding Azure Network Security Groups
If you deploy workloads on Azure, Network Security Groups (NSGs) are the primary tool for filtering network traffic to and from your virtual machines, subnets, and network interfaces. An NSG contains a list of security rules that allow or deny traffic based on source, destination, port, and protocol. Unlike AWS security groups, Azure NSGs support explicit deny rules and use a priority-based evaluation model, giving you more granular control over traffic flow.
The priority system is what makes Azure NSGs both powerful and potentially confusing. Every rule has a priority number between 100 and 4096, and rules are evaluated from lowest number (highest priority) to highest number (lowest priority). The first matching rule determines the action. This means that a high-priority Allow rule can override a lower-priority Deny rule, and vice versa. If you set priority 100 to Allow HTTPS and priority 200 to Deny all traffic from the same source, HTTPS traffic gets through because priority 100 is evaluated first. Getting the priority ordering right is critical for your security posture.
Azure also provides service tags -- named groups of IP ranges that Azure manages automatically. Instead of manually tracking Microsoft's IP ranges for services like Azure Storage, Azure SQL, or the Azure Load Balancer health probes, you reference tags like Storage, Sql, or AzureLoadBalancer. When Microsoft updates those ranges, your NSG rules automatically apply to the new addresses. This is a significant operational advantage over manually maintained CIDR lists, especially for Azure PaaS services whose IP ranges change regularly.
How to Generate Azure NSG Rules from CSV
- Prepare your rule data in CSV format with columns: direction, priority, name, source, destination, protocol, port range, and action.
- Paste or upload the CSV into the generator.
- Select the output format: Azure CLI, PowerShell, or ARM template.
- Enter the NSG name and resource group.
- Copy the generated commands or template for deployment.
CSV Input Format and Generated Output
CSV Input
direction,priority,name,source,destination,protocol,port,action
Inbound,100,AllowHTTPS,*,*,Tcp,443,Allow
Inbound,110,AllowSSH,10.0.0.0/8,*,Tcp,22,Allow
Inbound,200,DenyScannersIn,198.51.100.0/24,*,*,*,Deny
Outbound,100,AllowSQL,*,10.1.0.0/16,Tcp,1433,Allow
Inbound,120,AllowHTTP,Internet,*,Tcp,80,Allow
Azure CLI Output
az network nsg rule create \
--resource-group myResourceGroup \
--nsg-name myNSG \
--name AllowHTTPS \
--priority 100 \
--direction Inbound \
--access Allow \
--protocol Tcp \
--destination-port-ranges 443 \
--source-address-prefixes '*' \
--destination-address-prefixes '*'
az network nsg rule create \
--resource-group myResourceGroup \
--nsg-name myNSG \
--name AllowSSH \
--priority 110 \
--direction Inbound \
--access Allow \
--protocol Tcp \
--destination-port-ranges 22 \
--source-address-prefixes '10.0.0.0/8' \
--destination-address-prefixes '*'
PowerShell Output
$rule1 = New-AzNetworkSecurityRuleConfig `
-Name "AllowHTTPS" `
-Priority 100 `
-Direction Inbound `
-Access Allow `
-Protocol Tcp `
-DestinationPortRange 443 `
-SourceAddressPrefix '*' `
-DestinationAddressPrefix '*' `
-SourcePortRange '*'
$rule2 = New-AzNetworkSecurityRuleConfig `
-Name "AllowSSH" `
-Priority 110 `
-Direction Inbound `
-Access Allow `
-Protocol Tcp `
-DestinationPortRange 22 `
-SourceAddressPrefix '10.0.0.0/8' `
-DestinationAddressPrefix '*' `
-SourcePortRange '*'
Azure NSG Source and Destination Types
| Type | Example | Description |
|---|---|---|
| CIDR block | 10.0.0.0/8 | Standard IP range notation |
| Service tag | Internet | Azure-managed tag for internet-routable IPs |
| Service tag | VirtualNetwork | All addresses in the VNet and peered VNets |
| Service tag | AzureLoadBalancer | Azure health probe source IPs |
| Service tag | Storage.EastUS | Region-specific Azure service IPs |
| Application security group | asg-webservers | Workload-based grouping |
| Wildcard | * | Any source or destination |
How Azure NSG Priority Works
Azure NSG rules are evaluated by priority number from lowest (highest priority) to highest (lowest priority). The first matching rule determines the action.
| Priority | Name | Action | Effect |
|---|---|---|---|
| 100 | AllowHTTPS | Allow | Evaluated first -- HTTPS traffic is allowed |
| 200 | DenyBadActors | Deny | Evaluated second -- blocks specific IPs |
| 4096 | DenyAllInbound | Deny | Default rule -- blocks everything else |
Key priority rules:
- Valid range:
100to4096 - Lower number = higher priority (evaluated first)
- Priority values must be unique within a direction (Inbound or Outbound)
- Azure reserves priorities
65000-65500for default rules
When to Use the Azure NSG Rule Generator
- VNet deployment -- Generate NSG rules for new virtual networks from a security requirements spreadsheet.
- Multi-tier applications -- Create rules for web, application, and database tiers with proper inter-tier access controls.
- Cross-cloud migration -- Convert AWS security group rules or on-premises firewall rules to Azure NSG format.
- Infrastructure as Code -- Generate ARM templates or Azure CLI scripts for version-controlled, repeatable NSG deployments.
- Compliance standardization -- Apply consistent NSG baselines across subscriptions and resource groups.
How Azure NSGs Differ from AWS Security Groups
| Feature | Azure NSG | AWS Security Group |
|---|---|---|
| Explicit deny | Yes (Deny action) | No (implicit deny only) |
| Priority ordering | Yes (100-4096) | No (all rules evaluated) |
| Default rules | Built-in allow/deny defaults | Implicit deny all |
| Service tags | Internet, VirtualNetwork, etc. | Prefix lists (limited) |
| Scope | Subnet or NIC level | Instance level |
| Stateful | Yes | Yes |
Practical Advice for Azure NSG Configuration
The biggest pitfall with Azure NSG priorities is leaving gaps that are too small. If you assign priorities 100, 101, 102 for your first three rules, you have no room to insert a rule between them later without renumbering. Use increments of 10 or 20 (100, 110, 120, ...) so you can always slot new rules between existing ones. This generator validates that your priorities do not conflict, but it cannot enforce good spacing -- that is a design decision you need to make upfront.
When working with multi-tier architectures on Azure, apply NSGs at the subnet level rather than the NIC level whenever possible. Subnet-level NSGs are easier to manage because they apply uniformly to all resources in the subnet, and you do not have to remember to attach the NSG to every new VM you deploy. NIC-level NSGs are useful for exceptions -- when one VM in a subnet needs different rules from the rest -- but they add complexity and are a common source of "why can't this VM connect?" troubleshooting sessions.
Service tags are one of Azure's best features for network security, but they are frequently underused. Instead of maintaining a list of Azure Storage IP ranges for your NSG rules, use the Storage service tag. Instead of looking up Azure SQL's IP ranges, use the Sql tag. For region-specific restrictions, append the region name: Storage.EastUS. Azure maintains these ranges automatically, so your rules never go stale. The only caveat is that service tags are not available in Network ACLs (only NSGs), so plan your network security architecture accordingly.
Frequently Asked Questions
What happens if two rules have conflicting actions at different priorities?
The rule with the lower priority number (higher precedence) wins. For example, if priority 100 allows HTTPS and priority 200 denies all traffic from the same source, HTTPS traffic is allowed because priority 100 is evaluated first.
Can I use multiple port ranges in a single NSG rule?
Yes. Azure supports multiple port ranges in a single rule using space-separated values: --destination-port-ranges 80 443 8080-8090. This reduces the total number of rules needed.
What are service tags and when should I use them?
Service tags are Azure-managed groups of IP ranges for Azure services. Instead of manually tracking Microsoft's IP ranges, use tags like Storage, Sql, or AzureActiveDirectory. Azure automatically updates the underlying IP ranges. This is especially useful for allowing traffic to Azure PaaS services.
How do I validate that priority numbers do not conflict? The generator checks for duplicate priorities within the same direction (Inbound or Outbound) and flags conflicts before producing output. Priorities must be unique per direction within an NSG.
What is the maximum number of rules in an Azure NSG? The default limit is 1000 rules per NSG (including default rules). This is substantially higher than AWS security groups (60 per direction). You can request a limit increase through Azure support if needed, but hitting 1000 rules usually indicates that your NSG design should be restructured.
How do I migrate from AWS security groups to Azure NSGs? The main differences are that Azure NSGs require explicit priorities (AWS evaluates all rules equally) and support explicit deny rules. Map each AWS allow rule to an Azure Allow rule with an ascending priority, add any deny rules you need (which AWS cannot express), and replace AWS prefix lists with Azure service tags where applicable.
Related Tools
- AWS Security Group Rule Generator - Generate AWS Security Group rules from CSV
- iptables Rule Generator - Generate iptables rules from CSV
- nftables Rule Generator - Generate nftables rules from CSV
- Rule Conflict Finder - Find duplicate, shadowed, or overlapping firewall rules
- Allowlist Builder - Build minimal CIDR allowlist from IP list