Azure Firewall vs NSG: Key Architectural Differences for Secure Traffic Management (HTTPS/RDP Use Cases)


2 views

When designing Azure network security, many engineers struggle with choosing between Azure Firewall and Network Security Groups (NSGs). While both control traffic flow, they operate at fundamentally different layers:

  • Azure Firewall: Stateful firewall-as-a-service at the network perimeter (Layer 7 application rules)
  • NSGs: Distributed stateless filters at subnet/NIC level (Layer 3-4 access control)

You should consider Azure Firewall when your architecture requires:

// Scenario requiring Azure Firewall
1. Centralized egress control across multiple VNets
2. FQDN filtering for outbound HTTPS traffic
3. Threat Intelligence-based filtering
4. Complex NAT rules for inbound RDP access
5. Integration with Azure Monitor for traffic analytics

Here's how rules differ for HTTPS/RDP management:

Feature Azure Firewall NSG
HTTPS Filtering FQDN-based rules (e.g., *.microsoft.com) IP/port only (TCP 443)
RDP Protection Application rules with TLS inspection Basic port 3389 allow/deny
Statefulness Stateful (tracks connections) Stateless (per-packet evaluation)

NSG rule for RDP restriction:

# Azure CLI example
az network nsg rule create \
  --resource-group MyResourceGroup \
  --nsg-name MyNSG \
  --name AllowRDPFromOffice \
  --priority 100 \
  --source-address-prefixes 203.0.113.0/24 \
  --destination-port-ranges 3389 \
  --access Allow \
  --protocol Tcp

Azure Firewall FQDN rule for HTTPS:

# ARM template snippet
{
  "type": "Microsoft.Network/azureFirewalls/applicationRuleCollections",
  "properties": {
    "rules": [
      {
        "name": "AllowAzureUpdates",
        "protocols": [
          { "protocolType": "Https", "port": 443 }
        ],
        "fqdnTags": [],
        "targetFqdns": [
          "*.windowsupdate.com",
          "*.microsoft.com"
        ],
        "sourceAddresses": ["10.0.0.0/16"]
      }
    ]
  }
}

For your specific architecture with multiple VNets, consider:

  • NSG management overhead grows exponentially with VNet count
  • Firewall provides cross-VNet traffic visibility
  • Advanced threat protection requires firewall capabilities
  • Pricing model differs (NSG: free, Firewall: ~$1.25/hour + data processing)

Most production architectures use both:

1. Azure Firewall for:
   - Internet-facing workloads
   - Shared services egress
   - Cross-VNet hub-spoke traffic

2. NSGs for:
   - East-West traffic segmentation
   - Resource-level microsegmentation
   - Compliance boundary enforcement

Azure Firewall operates as a fully stateful firewall-as-a-service (FWaaS) with built-in high availability, while Network Security Groups (NSGs) function as distributed layer 3/4 stateless packet filters. The fundamental distinction manifests in several technical dimensions:


// NSG Rule Example (JSON)
{
  "name": "Allow-HTTPS-Inbound",
  "properties": {
    "protocol": "Tcp",
    "sourcePortRange": "*",
    "destinationPortRange": "443",
    "sourceAddressPrefix": "Internet",
    "destinationAddressPrefix": "10.0.1.5",
    "access": "Allow",
    "priority": 100,
    "direction": "Inbound"
  }
}

// Azure Firewall Rule Example (ARM template snippet)
"networkRuleCollections": [{
  "name": "WebApp-Rules",
  "properties": {
    "priority": 200,
    "action": {
      "type": "Allow"
    },
    "rules": [{
      "name": "Allow-HTTPS",
      "protocols": ["TCP"],
      "sourceAddresses": ["*"],
      "destinationAddresses": ["10.0.1.5"],
      "destinationPorts": ["443"],
      "terminateTLS": false
    }]
  }
}]
Feature Azure Firewall NSG
Stateful inspection Yes No
TLS inspection Premium SKU No
Application FQDN filtering Yes No
Threat intelligence Integrated No
Centralized logging Azure Monitor Flow logs
DNAT support Yes No

Consider these architectural scenarios where Azure Firewall provides indispensable value:

  • Hub-spoke topologies: Centralized egress control for multiple VNets
  • PCI DSS compliance: Requirement for proper stateful inspection
  • Microservices architectures: Need for application-layer filtering between services
  • Hybrid connections: Consistent policy enforcement across on-prem and cloud

For HTTPS traffic management, Azure Firewall Premium enables deeper inspection:


# Configure TLS inspection via Azure CLI
az network firewall policy create \
  --name "fw-policy-prod" \
  --resource-group "rg-network" \
  --sku Premium \
  --tls-certificate "prod-certificate" \
  --key-vault-secret-id "https://kv-prod.vault.azure.net/secrets/tls-cert"

For RDP access, combine both solutions defensively:


# NSG to restrict source IPs
az network nsg rule create \
  --nsg-name "vm-nsg" \
  --name "Allow-RDP" \
  --priority 110 \
  --source-address-prefixes "203.0.113.12" "198.51.100.34" \
  --destination-port-ranges 3389 \
  --access Allow

# Azure Firewall to log all RDP attempts
az network firewall policy rule-collection-group collection add-filter-collection \
  --name "rdp-monitoring" \
  --policy-name "fw-policy-prod" \
  --rcg-name "default" \
  --rule-type NetworkRule \
  --rules "[{
    'name':'Log-RDP',
    'protocols':['TCP'],
    'sourceAddresses':['*'],
    'destinationAddresses':['10.0.0.0/8'],
    'destinationPorts':['3389']
  }]" \
  --action-type "Log"

For environments with 5-10 VNets, consider these financial factors:

  • Standard Azure Firewall: ~$1.25/hour fixed + $0.016/GB processed
  • NSG: No additional cost beyond standard networking
  • Operational savings from centralized management: ~30-40% reduced administrative overhead