7 Jul, 2025
Understanding Azure SDN: Core Security Components and Best Practices
VMware , , ,

TL;DR: Quick Summary

Azure Software Defined Networking (SDN) delivers flexible, scalable, and secure virtual networking across Azure cloud and Azure Local (formerly Azure Stack HCI). This blog post explores Azure SDN’s core components—including Azure Firewall, Network Security Groups (NSGs), Application Security Groups (ASGs), service tags, and rule formatting—along with design and implementation best practices for each.

What is Azure SDN?

Azure SDN is Microsoft’s cloud-native virtual networking framework that abstracts and centrally manages networking resources. It enables:

  • Automated provisioning of virtual networks (VNets)
  • Traffic segmentation and filtering
  • Centralized security policy enforcement
  • Dynamic application-to-network mapping

Azure SDN powers both Azure Public Cloud and Azure Local through a consistent control plane enabled by tools like Azure Arc and Azure Network Manager.

Azure SDN Components and Definitions

Azure Firewall

Definition: A stateful, fully managed Layer 3–7 network security service that protects Azure VNets. Supports DNS filtering, FQDN rules, and threat intelligence.

Best Practices:

  • Use Azure Firewall Manager to manage rules across regions
  • Deploy in hub VNet with spoke VNets peered
  • Enable logging to Log Analytics or Sentinel
  • Use DNS Proxy for outbound filtering

Application Security Groups (ASGs)

Definition: Dynamic groupings of NICs based on logical application identity. Lets you define network security rules by application tier instead of static IPs.

Best Practices:

  • Use ASGs to represent app tiers (e.g., Web, App, DB)
  • Avoid mixing unrelated workloads in one ASG
  • Combine with NSG rules for dynamic filtering
  • Ensure consistent tagging for automation

Network Security Groups (NSGs)

Definition: A logical container of security rules that control inbound and outbound traffic at the subnet or NIC level. Operates at Layers 3 and 4.

Rule Format:

  • Priority (100–4096)
  • Direction (Inbound/Outbound)
  • Access (Allow/Deny)
  • Protocol (TCP/UDP/*)
  • Source/Destination (IP, CIDR, tag, ASG)
  • Port Ranges (e.g., 80, 443, 1024–65535)

Best Practices:

  • Apply NSGs at subnet level for consistency
  • Use lowest necessary privileges per rule
  • Enable NSG flow logs
  • Use naming standards like NSG-App-Web-EastUS

NSG Rules and Format

Rule Format Example:

{
  "name": "AllowWeb",
  "properties": {
    "priority": 100,
    "direction": "Inbound",
    "access": "Allow",
    "protocol": "Tcp",
    "sourceAddressPrefix": "Internet",
    "sourcePortRange": "*",
    "destinationAddressPrefix": "10.0.0.4",
    "destinationPortRange": "80"
  }
}

Best Practices:

  • Use specific source/destination ranges when possible
  • Prioritize Deny All rules at the end of critical rule sets
  • Avoid overlapping rules that cause conflicts
  • Keep rule names consistent and descriptive

Service Tags

Definition: Named representations of groups of IP address prefixes managed by Microsoft. Common tags include Internet, AzureLoadBalancer, VirtualNetwork, and service-specific tags like Storage, Sql.

Best Practices:

  • Use tags to reduce dependency on hard-coded IPs
  • Keep rules readable and maintainable
  • Validate which regions and services are covered by each tag (Service Tag documentation)

Microsoft SDN Design Best Practices

NSGs

  • Apply NSGs to subnets by default; use NIC-level NSGs only for exceptions
  • Separate user-defined rules (UDRs) from platform default rules
  • Use diagnostic settings to log denied and allowed flows

ASGs

  • Use to abstract environment tiers (Web/App/DB/Monitoring)
  • Avoid tight coupling with IP-based rules—use ASGs instead
  • Implement in DevOps pipelines for consistent deployments

Tags

  • Use service tags for common Azure services
  • Avoid manually updating IPs when Microsoft updates address ranges
  • Combine tags and ASGs for layered security

Rules

  • Group rules by function (e.g., app access, management, outbound)
  • Use consistent priority ranges (e.g., 100–199 for app, 200–299 for infra)
  • Keep NSG rule sets small and targeted per environment

NSG Rule Strategy Table

Rule Group Priority Range Purpose Example Rule Names
App Access Rules 100–199 Web, app, DB-tier communication AllowWeb, AllowAppDB
Infra Access Rules 200–299 Management ports (RDP, SSH, WinRM) AllowRDP, AllowSSH
Monitoring Rules 300–399 Log collectors, metrics, Azure agents AllowLogAnalytics, AllowInsights
Outbound Rules 400–499 App/infra egress to Internet/Azure AllowWebOutbound, AllowAzureSQL
Deny Rules 4000–4096 Default deny all DenyAllInbound, DenyAllOutbound

Additional Best Practices

Common Misconfigurations to Avoid

  • Using overly permissive rules (e.g., * in both source and destination)
  • Forgetting to implement deny rules at the bottom of the rule set
  • Duplicating NSG rules across NIC and subnet layers without tracking precedence
  • Misconfigured rule priorities causing shadowing of critical rules
  • Disabling diagnostic logging and missing visibility into denied flows

Auditing and Compliance with Azure Policy

Azure Policy can help you enforce security best practices across NSGs and Firewall configurations. Use built-in policies such as:

  • “NSG should not allow RDP from Internet”
  • “Firewall rules should not allow unrestricted outbound traffic”
  • “Audit NSGs missing diagnostic settings”

Best Practice Tips:

  • Assign Azure Policy initiatives at the subscription or management group level
  • Combine with Azure Defender to auto-remediate violations
  • Export compliance state to regulatory dashboards or SIEM tools

NSGs:

  • Avoid overlapping NSGs at NIC and subnet level unless required for exception cases
  • Regularly audit NSG rules for stale ports or overly permissive rules
  • Use tags and ASGs to reduce rule maintenance

ASGs:

  • Limit ASG usage to 1000 NICs per region (current Azure limit)
  • Integrate ASGs with CI/CD pipeline tagging for dynamic assignment
  • Group by tier and lifecycle stage (e.g., asg-web-prod, asg-app-dev)

Azure Firewall:

  • Implement DNS Proxy for full Layer 7 control
  • Combine Firewall with NSGs to create layered defense (Firewall for egress, NSGs for east-west)
  • Use IP Groups for shared address sets across policies

PowerShell and Bicep Examples

Create NSG + Rules (PowerShell)

$nsg = New-AzNetworkSecurityGroup -ResourceGroupName "RG-Net" -Location "eastus" -Name "AppNSG"
Add-AzNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg -Name "AllowWeb" -Protocol "Tcp" -Direction "Inbound" -Priority 100 `
  -SourceAddressPrefix "Internet" -SourcePortRange "*" -DestinationAddressPrefix "*" -DestinationPortRange 80 -Access Allow
Set-AzNetworkSecurityGroup -NetworkSecurityGroup $nsg

Create ASG (PowerShell)

New-AzApplicationSecurityGroup -Name "asg-web-tier" -ResourceGroupName "RG-Net" -Location "eastus"

Bicep Template Example

resource nsg 'Microsoft.Network/networkSecurityGroups@2022-01-01' = {
  name: 'AppNSG'
  location: 'eastus'
  properties: {
    securityRules: [
      {
        name: 'AllowWeb'
        properties: {
          priority: 100
          direction: 'Inbound'
          access: 'Allow'
          protocol: 'Tcp'
          sourceAddressPrefix: 'Internet'
          destinationAddressPrefix: '*'
          destinationPortRange: '80'
          sourcePortRange: '*'
        }
      }
    ]
  }
}

resource asg 'Microsoft.Network/applicationSecurityGroups@2022-01-01' = {
  name: 'asg-web-tier'
  location: 'eastus'
}

Full Deployment Script Example

Below is a consolidated PowerShell script to deploy a VNet, subnet, NSG, ASG, and bind NSG to the subnet with sample rules:

# Variables
$location = "eastus"
$rg = "RG-SDN-Demo"
$vnetName = "DemoVNet"
$subnetName = "AppSubnet"
$nsgName = "AppNSG"
$asgName = "asg-web-tier"

# Create Resource Group
New-AzResourceGroup -Name $rg -Location $location

# Create VNet and Subnet
$vnet = New-AzVirtualNetwork -ResourceGroupName $rg -Location $location -Name $vnetName -AddressPrefix "10.0.0.0/16"
Add-AzVirtualNetworkSubnetConfig -Name $subnetName -AddressPrefix "10.0.1.0/24" -VirtualNetwork $vnet | Set-AzVirtualNetwork

# Create ASG
$asg = New-AzApplicationSecurityGroup -Name $asgName -ResourceGroupName $rg -Location $location

# Create NSG and Add Rule
$nsg = New-AzNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rg -Location $location
Add-AzNetworkSecurityRuleConfig -Name "AllowHTTP" -NetworkSecurityGroup $nsg -Direction Inbound -Priority 100 -Access Allow -Protocol Tcp `
  -SourceAddressPrefix "Internet" -SourcePortRange "*" -DestinationAddressPrefix "*" -DestinationPortRange "80"
Set-AzNetworkSecurityGroup -NetworkSecurityGroup $nsg

# Associate NSG to Subnet
$vnet = Get-AzVirtualNetwork -Name $vnetName -ResourceGroupName $rg
$subnet = Get-AzVirtualNetworkSubnetConfig -Name $subnetName -VirtualNetwork $vnet
Set-AzVirtualNetworkSubnetConfig -Name $subnetName -VirtualNetwork $vnet -AddressPrefix $subnet.AddressPrefix -NetworkSecurityGroup $nsg
$vnet | Set-AzVirtualNetwork

Final Thoughts

Azure SDN is more than just virtual networking—it’s a scalable, programmable fabric designed for hybrid, modern applications. When implemented with Azure Firewall, NSGs, ASGs, and service tags, you gain security, flexibility, and automation not easily achieved with traditional networking models.

Designing your NSG, ASG, and tagging strategy early is key to minimizing risk and maximizing agility as your environment scales.

*The thoughts and opinions in this article are mine and hold no reflect on my employer*

The post Understanding Azure SDN: Core Security Components and Best Practices first appeared on Digital Thought Disruption.

The post Understanding Azure SDN: Core Security Components and Best Practices appeared first on Digital Thought Disruption.