Azure Virtual Network Security: NSG Design, VNet Peering Security, and When to Use Azure Firewall vs NSG-Only
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Azure NSGs are stateful packet filters that are effective when designed deliberately but become security theater when configured reactively: a rule added to allow a specific connection that was not working, followed by another rule for a different connection that was blocked, eventually produces an NSG rule set that effectively allows everything because the troubleshooting rules are never removed and the default-deny intent of the original design is lost.
The secure NSG design starts with explicit topology decisions — which subnets exist, what traffic flows are required between them, and what is denied by default — before creating any rules. The rules implement those decisions rather than accumulating as reactive patches to connectivity problems.
Subnet design: security tiers before rule design
Every NSG rule design decision flows from the subnet topology decision made before the first rule is created. If your VNet has a single flat application subnet, NSG rules cannot create meaningful isolation between internet-facing components and databases because they share the same address space. This section covers designing subnets by security tier: a DMZ subnet for load balancers and Application Gateways, an application subnet for API and web servers, a data subnet for databases and storage, and a management subnet for Bastion and admin tooling. With that topology in place, the inter-subnet traffic flows become explicit and bounded, making it possible to write NSG rules that allow only what the design requires. It also covers using Azure service tags instead of hardcoded IP ranges so rules do not break when Microsoft rotates Azure service IP addresses.
Define data flow requirements between security tiers before creating NSG rules
Document the required traffic flows between subnets before creating any NSG rules: what source subnet needs to reach what destination subnet, on what ports, and for what purpose. A three-tier web application requires: internet to DMZ subnet on TCP 443 (HTTPS to Application Gateway), DMZ subnet to application subnet on TCP 8080 (Application Gateway backend pool), application subnet to data subnet on TCP 1433 (SQL connection), management subnet to all subnets on TCP 22/3389 (administrative access via Bastion). Every allowed NSG rule should correspond to a documented traffic flow requirement. Any rule that does not correspond to a documented requirement is a candidate for removal. This documentation process also surfaces implicit dependencies that need to be allowed — Azure VM agents, monitoring agents, and Windows Update require outbound HTTPS to Azure service tags.
Use service tags for Azure service destinations rather than IP address ranges
Replace hardcoded IP ranges in NSG rules for Azure service destinations with Azure service tags: use the AzureMonitor service tag instead of the Azure Monitor IP ranges, the Storage service tag for Azure Blob Storage, and the AzureActiveDirectory service tag for Microsoft Entra authentication endpoints. Service tags are maintained by Microsoft and automatically updated when service IP ranges change — a hardcoded IP range allow rule stops working when Microsoft rotates the IP range without notice. For outbound internet access from application servers, use the Internet service tag only as a last resort and prefer restricting to specific service tags (AzureMonitor, Storage, AzureKeyVault) with a deny Internet rule to catch unplanned outbound connections.
Monitoring: NSG flow logs and compliance validation
NSG rules that are never audited drift from their intended design as troubleshooting rules accumulate, subnets are repurposed, and new workloads are deployed without updating the rule documentation. NSG flow logs with Traffic Analytics make the actual traffic pattern visible so you can compare what is flowing against what the rules intend. This section covers enabling flow logs on all production subnet NSGs, using Traffic Analytics dashboards to identify denied connection patterns and unexpected allowed flows, and running quarterly Azure Policy audits that automatically flag NSG rules with wildcard source addresses or port ranges that indicate rules were written to fix a connectivity problem rather than implement a deliberate security design.
Enable NSG flow logs and Traffic Analytics on all production subnet NSGs
Configure NSG flow logs with Traffic Analytics on all production NSGs to gain visibility into what traffic is actually flowing through the network versus what your NSG rules intend. Traffic Analytics processes the raw flow logs and identifies the top traffic patterns, denied connection attempts, and cross-subnet flows, presenting them in Azure Monitor workbooks without requiring SPL or KQL query expertise. Review the Traffic Analytics dashboard weekly in the first 90 days after deploying new NSG rules to identify denied connection patterns that indicate legitimate traffic being blocked (causing application issues) and unexpected allowed traffic patterns that indicate NSG rules are more permissive than intended.
Audit NSG rules quarterly using Azure Policy to detect overly permissive rules
Azure Policy can audit NSGs for overly permissive rules automatically. Apply the built-in policy definition Audit unrestricted network access to storage accounts and similar policies that detect common NSG misconfigurations. Create a custom policy that audits NSGs for rules with source address prefix Any or * combined with a destination port range of * (any port), which is effectively a default-allow rule that negates the NSG's security value. Schedule a quarterly review of NSG rule sets using the Azure portal or Azure Resource Graph to list all NSG rules across all subscriptions, identify rules with permissive source ranges or port ranges, and evaluate whether each permissive rule is intentional and documented.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Azure VNet security requires NSG rule design that starts with documented traffic flow requirements between security tiers rather than reactive rules added to fix connectivity problems. Apply NSGs at both subnet and NIC levels for defense in depth, use service tags for Azure service destinations to avoid IP range maintenance, deploy private endpoints for PaaS services to eliminate public internet exposure, and enable NSG flow logs with Traffic Analytics to verify that traffic patterns match the intended NSG design. Use Azure Firewall in addition to NSGs when FQDN-based outbound filtering, threat intelligence-based blocking, or centralized policy management across multiple VNets is required — NSGs alone cannot provide those controls.
Frequently asked questions
How do I design Azure NSG rules for a default-deny architecture?
A default-deny Azure NSG architecture starts with the built-in default rules that deny all inbound traffic not matching an explicit allow rule (DenyAllInBound at priority 65500) and deny all outbound traffic not matching an explicit allow rule (DenyAllOutBound at priority 65500). On top of this base, add explicit allow rules with lower priority numbers for required traffic only. For an application subnet NSG: allow TCP 443 from the internet-facing load balancer subnet (source address prefix of the load balancer subnet, destination of the application subnet), allow TCP 1433 outbound from the application subnet to the data subnet (for SQL connections), allow TCP 443 outbound to AzureMonitor and Storage service tags (for logging and blob storage), deny all inbound from Internet at priority 400 (earlier than the default 65500 to create a visible rule), and deny all other traffic by relying on the default deny rules.
When should I use Azure Firewall instead of NSG-only for network security?
Use Azure Firewall (in addition to NSGs, not instead of them) when your security requirements exceed what stateful packet filtering can provide: FQDN-based outbound filtering (blocking all internet-bound traffic except specific FQDNs rather than IP ranges), threat intelligence-based filtering using Microsoft's threat feed, centralized network traffic logging and analysis across all VNets through a hub-and-spoke architecture, application rule policies that restrict outbound traffic by target URL category, and TLS inspection for outbound HTTPS traffic. NSG-only architectures are appropriate for simple network topologies where you control all traffic endpoints by IP range and port, all PaaS services use private endpoints (eliminating public internet outbound requirements), and you do not require centralized policy management across multiple VNets. Azure Firewall adds significant cost (around $1.25/hour plus data processing fees) and is justified when the security requirements exceed NSG capabilities.
How do I secure VNet peering between Azure virtual networks?
VNet peering creates a direct network path between two VNets that bypasses internet routing but does not bypass NSGs: NSG rules on subnets in the peered VNet still apply to traffic from the peering. Secure VNet peering by: applying NSGs to all subnets in both peered VNets that explicitly permit only required cross-VNet traffic rather than inheriting default-allow behavior, reviewing the peering configuration to ensure Allow gateway transit and Use remote gateways are configured only when an ExpressRoute or VPN gateway needs to be shared, and auditing peered VNet traffic using NSG flow logs to verify that only expected traffic is crossing the peering. In hub-and-spoke topologies, route all inter-spoke traffic through the hub Azure Firewall rather than permitting direct spoke-to-spoke peering that bypasses central inspection.
What is the difference between Azure service endpoints and private endpoints?
Service endpoints extend your VNet's identity to Azure PaaS services over the public Azure backbone: traffic from your VNet to Azure Storage using a service endpoint travels over the Microsoft network but exits through the public endpoint of the storage account (the storage.blob.core.windows.net public DNS name resolves to a public IP). Private endpoints assign a private IP address in your VNet to the PaaS service: traffic to Azure Storage using a private endpoint travels entirely over private addresses within your VNet and the storage account's public endpoint can be disabled entirely. Private endpoints are significantly stronger security controls because they eliminate the public endpoint exposure, support NSG rules using private IP addresses to restrict access to the PaaS service, and work with on-premises network connectivity through ExpressRoute or VPN. Use private endpoints for Azure Storage, SQL Database, Key Vault, and other PaaS services containing sensitive data; service endpoints are acceptable for lower-sensitivity use cases where private endpoint complexity is not warranted.
How do I design Azure VNet subnets for security tier isolation?
Design Azure VNet subnets using security tier isolation rather than application team ownership. Standard subnet tiers: a DMZ or internet-facing subnet containing only Application Gateways and Load Balancers that accept internet traffic (no application servers in this subnet), an application subnet containing application servers and API services that receive traffic only from the DMZ subnet, a data subnet containing databases and storage accounts that accept connections only from the application subnet, and a management subnet for jump boxes and management tools with separate access controls. Apply a subnet-level NSG to each subnet that enforces the allowed ingress and egress for that tier. This model ensures that a compromise of an internet-facing component is contained to the DMZ subnet and cannot directly reach the data subnet without crossing two additional NSG boundaries.
How do I enable and analyze Azure NSG flow logs?
NSG flow logs capture TCP and UDP connection attempts allowed and denied by each NSG. Enable flow logs by going to the NSG in the Azure portal, selecting NSG flow logs, and configuring a storage account destination with a retention period (90 days minimum for security investigation needs). Enable Traffic Analytics on the flow log configuration to process the raw flow logs and display them in Log Analytics and Azure Monitor workbooks — Traffic Analytics provides network topology visualization and identifies top talkers, top destination ports, and blocked connection patterns without requiring manual flow log parsing. To query flow logs directly, use Azure Log Analytics with the AzureNetworkAnalytics_CL table: query for blocked connections from specific source IPs, identify VMs making outbound internet connections to unusual destinations, and audit cross-subnet connection patterns.
How do I configure Azure Bastion for secure VM management without public IPs?
Azure Bastion provides browser-based SSH and RDP access to Azure VMs through the Azure portal without requiring public IP addresses on the VMs or inbound management ports (TCP 22, TCP 3389) open in NSGs. Deploy Azure Bastion by creating a dedicated AzureBastionSubnet (must be named exactly AzureBastionSubnet) in your hub VNet with a minimum /27 address space, then deploying an Azure Bastion resource in that subnet. Apply the Microsoft-recommended NSG rules to the AzureBastionSubnet: inbound from Internet on TCP 443 for HTTPS management sessions, inbound from GatewayManager service tag on TCP 443 and 4443 for control plane traffic, and outbound to VirtualNetwork on TCP 22 and 3389 for the SSH/RDP sessions to target VMs. VM NSGs can then deny all inbound on TCP 22 and 3389 from any source — the Bastion service connects from its subnet private IPs, not from the internet.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.