Introduction to Azure Network Security

Microsoft Azure offers a robust cloud platform, but securing your network infrastructure is critical to protect data, applications, and services from evolving threats. Two foundational components—Azure Firewall and Network Security Groups (NSGs)—provide granular control over traffic flows. When configured correctly, they form a powerful defense-in-depth strategy. This article outlines best practices for deploying and managing these tools to strengthen your Azure network security posture.

Understanding Azure Firewall and Network Security Groups

Azure Firewall is a fully managed, cloud-native firewall-as-a-service offering stateful inspection, application and network rule enforcement, and threat intelligence integration. It operates at the virtual network level and scales automatically to handle traffic. NSGs, by contrast, are distributed packet-filtering rules applied at the subnet or network interface (NIC) level. They act as a basic stateless or stateful filter (depending on rule direction) to allow or deny traffic based on source/destination IP, port, and protocol.

While both tools control traffic, they serve different layers. Azure Firewall provides centralized policy management and advanced features like TLS inspection, URL filtering, and FQDN-based rules. NSGs are ideal for simple, per-subnet or per-VM rules. Combining them gives you both breadth and depth in your security architecture.

Best Practices for Azure Firewall

Implement a Layered Security Approach

Do not rely solely on Azure Firewall. Use it in conjunction with NSGs, Web Application Firewalls (WAF), and Azure DDoS Protection. This creates overlapping controls so that if one layer fails, another still protects your resources. For example, an Azure Firewall can enforce egress policies for an entire virtual network, while NSGs restrict traffic between subnets within the same network.

Define Clear and Granular Rule Sets

Start with a default-deny posture for both inbound and outbound traffic, then explicitly allow only what is required. Use network rules for IP-based traffic and application rules for FQDN-based traffic (HTTP/HTTPS). Avoid overly broad rules (e.g., allowing all traffic from any source to any destination). Instead, specify exact source IP ranges, destination IPs, and ports. Regularly review rule priorities because rules are evaluated in order; misordered rules can accidentally allow or block traffic.

Enable Threat Intelligence-Based Filtering

Azure Firewall can consume Microsoft’s threat intelligence feeds to block traffic from known malicious IPs and domains. Enable this feature for both inbound and outbound traffic. It requires an additional cost but significantly reduces exposure to botnets, malware command-and-control servers, and phishing hosts. Set the alert mode to Alert and Deny to automatically block threats, and review the logs to refine your custom rule sets.

Regularly Update and Audit Rules

Network requirements change as applications evolve. Schedule periodic audits of Azure Firewall rules—quarterly or after any major deployment. Remove unused or overly permissive rules. Use Azure Policy to enforce tagging and prevent creation of rules that violate security baselines. Also, consider using infrastructure-as-code templates (e.g., ARM, Bicep, Terraform) to version your firewall policy and detect drift.

Monitor and Log Traffic Effectively

Send Azure Firewall logs to a Log Analytics workspace, Azure Storage, or Event Hubs. Use Azure Monitor and workbooks to visualize traffic patterns, detect anomalies, and set up alerts for spikes or denied connections. Enable application rule logs and network rule logs separately. For deeper analysis, integrate with Microsoft Sentinel or a third-party SIEM. Logging is essential for incident response and compliance audits.

Use DNS Proxy and FQDN Filtering

Azure Firewall can act as a DNS proxy, resolving domain names within virtual networks and applying FQDN rules for outbound traffic. This helps prevent data exfiltration by allowing only approved domains. Ensure your virtual machines use the firewall’s private IP as their DNS server to enforce FQDN-based policies.

Plan for High Availability and Scalability

Azure Firewall is a regional service that automatically scales with traffic, but you should deploy it in a hub virtual network with forced tunneling for outbound traffic. For mission-critical workloads, pair it with Azure Firewall Manager to manage multiple firewalls across subscriptions and regions. Consider deploying two Azure Firewalls in an active-active setup using a load balancer for extreme availability requirements.

Best Practices for Network Security Groups

Apply NSGs at the Appropriate Level

NSGs can be associated with subnets or individual NICs. As a rule of thumb, apply NSGs at the subnet level to enforce consistent policies across all resources within that subnet (e.g., a web tier subnet should only allow inbound HTTP/HTTPS from a load balancer). Use NIC-level NSGs for exceptions, such as allowing specific management traffic to a particular VM. Overlapping rules with subnet NSGs are evaluated—be sure to understand the evaluation order (subnet NSG rules are applied first, then NIC rules).

Follow the Principle of Least Privilege

Only allow the minimal traffic necessary for your application to function. For example, allow SSH or RDP only from a bastion host or management jump box, not from the internet. Use service tags (e.g., AzureLoadBalancer, Internet, VirtualNetwork) instead of wide IP ranges. For outbound rules, block all traffic by default and then permit only specific destinations and ports. This reduces the attack surface and limits lateral movement.

Use Descriptive Rule Names and Tags

Name your NSG rules clearly, indicating purpose, direction, and protocol (e.g., Allow-HTTP-Inbound-from-Internet-to-WebSubnet). Tag resources with environment, cost center, or application identifiers. This simplifies auditing, troubleshooting, and automation. Avoid vague names like Rule1 or temp.

Combine NSGs with Azure Security Center / Defender for Cloud

Enable Azure Defender (now Microsoft Defender for Cloud) to receive recommendations on NSG configurations, such as exposing management ports to the internet or missing service tags. Defender for Cloud can trigger adaptive network hardening, which automatically adjusts NSG rules based on traffic patterns. Review these recommendations frequently and automate remediation with Azure Policy or automation runbooks.

Test Rules in a Staging Environment Before Production

Changes to NSGs can immediately disrupt applications. Deploy and validate NSG rules in a non-production environment that mirrors your production configuration. Use IP flow verify in Azure Network Watcher to test traffic flows and confirm that the intended rules are working. After testing, apply changes via CI/CD pipelines with approval gates to reduce human error.

Document and Version Control NSG Configurations

Store NSG rule definitions in source control (e.g., Git) as ARM templates, Bicep, or Terraform. This provides an audit trail and enables rollback if a misconfiguration occurs. Also document the business justification for each rule, especially exceptions to the default-deny policy. This helps future administrators understand why a rule exists.

Regularly Review Default Rules

When you create an NSG, Azure adds default rules (e.g., AllowVnetInBound, AllowAzureLoadBalancerInBound, DenyAllInBound). Understand these defaults and do not assume they are sufficient. For example, the default rule AllowVnetInBound allows all traffic within the virtual network—consider whether your application needs inter-subnet communication. If not, override with a higher-priority deny rule.

Integrating Azure Firewall and NSGs

To maximize security, combine Azure Firewall and NSGs rather than treating them as alternatives. A common architecture places Azure Firewall in a hub virtual network (the “hub”) and peer spoke virtual networks (the “spokes”) containing your workloads. In each spoke, apply NSGs to subnets to enforce east-west traffic rules. Centralized egress and ingress traffic flows through the Azure Firewall, allowing you to enforce outbound policies for all spokes. This hub-and-spoke design simplifies management while maintaining isolation.

For example, allow only HTTPS traffic from the Azure Firewall’s public IP to the internet, and use NSGs on the web subnet to only allow traffic from the firewall’s private IP. Additionally, use NSGs on the application subnet to only accept traffic from the web subnet. This creates a controlled chain: Internet → Azure Firewall → Web Subnet → Application Subnet → Database Subnet. No subnet directly accesses the internet.

Ensure that forced tunneling is enabled for all spokes so that internet-bound traffic goes through the firewall. Also configure user-defined routes (UDRs) to direct traffic accordingly. Test thoroughly to avoid asymmetric routing, which can break connectivity.

Additional Measures to Enhance Network Security

Beyond firewalls and network security groups, a comprehensive Azure network security strategy includes:

  • Secure Remote Access with Azure Bastion: Avoid exposing RDP or SSH ports to the internet. Azure Bastion provides secure, managed access to VMs directly from the Azure portal, tunneling through TLS and bypassing public IPs. It eliminates the need for jump boxes and reduces attack surface.
  • VPN or ExpressRoute for Hybrid Connectivity: Use site-to-site VPN or Azure ExpressRoute to connect on-premises networks securely. Do not rely solely on public internet. ExpressRoute provides dedicated private connectivity with higher reliability and lower latency.
  • Azure DDoS Protection: Enable Azure DDoS Protection on virtual networks to guard against volumetric attacks. The Basic tier is free and automatically enabled; the Standard tier provides adaptive tuning, attack analytics, and cost protection.
  • Web Application Firewall (WAF): Deploy Azure WAF with Application Gateway or Front Door to protect web applications from common exploits like SQL injection, cross-site scripting, and HTTP floods. WAF complements Azure Firewall by focusing on application-layer threats.
  • Network Segmentation and Micro-Segmentation: Use virtual networks, subnets, and NSGs to segment workloads. For deeper isolation, consider Virtual Network Service Endpoints or Private Link to access PaaS services without exposing them to the public internet.
  • Regular Security Assessments: Use Azure Policy to enforce compliance rules, and run periodic network security assessments with tools like Azure Network Watcher’s Connection Monitor, NSG Flow Logs, and Traffic Analytics. Identify open ports, unused rules, and anomalous traffic patterns.
  • Education and Awareness: Train your team on Azure networking concepts and security best practices. Foster a culture of “security as code” where network rules are reviewed, tested, and deployed through automated pipelines.
  • Incident Response and Log Retention: Enable diagnostic settings for all network resources and retain logs for at least 90 days (or as required by compliance). Use Microsoft Sentinel to investigate incidents and build automated responses.

For more details, refer to the Microsoft Azure Well-Architected Framework – Network Security and the Azure network security overview.

Conclusion

Securing an Azure environment requires intentional design, continuous monitoring, and periodic refinement. Azure Firewall and Network Security Groups are indispensable tools, but they must be configured with purpose and precision. By following the best practices outlined here—layering defenses, enforcing least privilege, logging everything, and integrating with other Azure security services—you can build a network that resists attacks, adapts to changing threats, and supports your business objectives. Start small, test changes, and scale your security posture as your cloud footprint grows.