Azure Network Security: NSGs, Firewall & DDoS Explained

Azure network security relies on three layered controls: Network Security Groups (NSGs) for subnet and NIC level traffic filtering, Azure Firewall for centralized Layer 3 to Layer 7 inspection, and Azure DDoS Protection for defending public IP addresses against volumetric attacks. Most production environments use all three together rather than choosing just one.

If you are building toward a cloud security engineer role, understanding how these controls fit together is not optional. It is core material on the SC-500 exam and it is one of the first things a hiring manager will ask about in a technical interview. This guide breaks down what each control actually does, where they overlap, and how to combine them in a real Azure environment.

Network Security Groups (NSGs): the first layer

A Network Security Group is a free, stateful packet filter that operates at Layer 3 and Layer 4 of the OSI model. You attach an NSG to a subnet, a network interface, or both, and it evaluates traffic against a list of allow and deny rules based on source and destination IP address, port, and protocol.

Key characteristics of NSGs:

• Stateful: if you allow inbound traffic on a connection, the matching outbound response is automatically allowed, and vice versa.
• Priority-based: rules are evaluated in priority order (100 to 4096, lower numbers evaluated first), and processing stops at the first match.
• Default rules: every NSG ships with default rules that allow traffic within a virtual network and from the Azure load balancer, and deny all other inbound traffic from the internet.
• No application awareness: NSGs cannot inspect packet contents, block based on URL or file type, or apply threat intelligence feeds.

NSGs are excellent for micro-segmentation: separating a web tier from a database tier, restricting management ports like RDP (3389) and SSH (22) to a bastion subnet, or enforcing that only specific services can talk to each other inside a virtual network. They are not designed to be your only line of defense against internet-facing threats.

Azure Firewall: centralized, application-aware inspection

Azure Firewall is a fully managed, stateful firewall as a service that inspects traffic from Layer 3 through Layer 7. Instead of managing dozens of NSGs scattered across subnets, Azure Firewall gives you a single choke point with centralized policy, logging, and threat intelligence.

Azure Firewall ships in three SKUs, and the one you choose depends on workload sensitivity:

Capability	Basic	Standard	Premium
Best for	Small and midsize workloads	Most production environments	Highly regulated or sensitive workloads
Throughput	Fixed, lower scale	Autoscale up to 30 Gbps	Autoscale up to 100 Gbps
Threat intelligence	Alert only	Alert and deny	Alert and deny
Web category filtering	FQDN based	FQDN based	Full URL based
TLS inspection	No	No	Yes
Intrusion detection (IDPS)	No	No	Yes, signature based

According to Microsoft Learn, Azure Firewall Standard covers most organizations with enterprise features like threat intelligence, DNS proxy, and web category filtering, while Azure Firewall Premium adds TLS inspection and signature-based intrusion detection with tens of thousands of continuously updated signatures. Premium is generally the right choice for workloads that fall under standards such as PCI DSS, where inspecting encrypted traffic is a compliance requirement, not a nice to have.

NSG versus Azure Firewall: when to use which

The honest answer is both, deployed together. A common architecture pattern is:

1. Azure Firewall (or a hub-and-spoke topology with Firewall in the hub) inspects and filters all traffic entering or leaving the virtual network perimeter.
2. NSGs enforce east-west segmentation between subnets and resources inside the network.
3. Application Security Groups group virtual machines by role (web, app, data) so NSG rules stay readable as the environment grows.

Relying on NSGs alone leaves you without application-layer inspection or threat intelligence. Relying on Azure Firewall alone without NSGs means a compromised resource inside your network has an easier path to move laterally, since Azure Firewall is typically focused on perimeter traffic, not intra-subnet communication.

Azure DDoS Protection: defending the perimeter

Distributed denial of service attacks try to overwhelm a public endpoint with traffic volume rather than exploit a vulnerability. Azure addresses this with DDoS Protection, and it is important to understand what you get for free versus what requires a paid plan.

Basic protection is automatically enabled for every public IP address in Azure at no additional cost. It provides always-on traffic monitoring and real-time mitigation against common network-layer attacks, using the scale of Microsoft's global network.

Paid protection adds capabilities that most production, customer-facing applications need. Per Microsoft's DDoS Protection documentation, the paid tiers are:

• Network Protection: covers all public IP resources across a virtual network for a fixed monthly cost that includes protection for a set number of public IPs, adds DDoS Rapid Response support during an active attack, cost protection guarantees, and discounts on Web Application Firewall usage. This is generally the more cost-effective option once you are protecting more than roughly 15 public IP resources.
• IP Protection: a lighter-weight, per-IP paid tier aimed at smaller deployments that need core DDoS protection without the full Network Protection feature set.

For any production workload with a public-facing web app, API, or load balancer that customers depend on, paid DDoS protection combined with a Web Application Firewall in front of Azure Firewall or Application Gateway is the standard recommendation, not an optional add-on.

How these controls map to real Azure architectures

A typical hub-and-spoke design for a mid-size organization looks like this:

• Hub virtual network: contains Azure Firewall (Standard or Premium), a VPN or ExpressRoute gateway, and DDoS Network Protection on the hub's public IPs.
• Spoke virtual networks: contain application workloads, each with its own NSGs applied at the subnet level for segmentation between tiers.
• Route tables: force all spoke traffic through the hub firewall, so nothing bypasses inspection.
• Microsoft Sentinel: ingests firewall and NSG flow logs for detection and investigation, tying network security back to the broader Entra ID, Defender, and Sentinel stack.

This layered approach, sometimes called defense in depth, is exactly the kind of design decision covered in SC-500 exam objectives and it mirrors what you will be expected to build in a real Azure security role.

Common mistakes to avoid

• Treating NSGs as sufficient perimeter defense. They filter by IP and port only and have no visibility into application-layer threats.
• Skipping paid DDoS protection on customer-facing IPs. Basic protection helps, but it lacks the rapid response and cost protection guarantees that matter during an actual attack.
• Leaving management ports open to the internet. RDP and SSH should be restricted through NSGs, Azure Bastion, or just-in-time VM access, never left open on 0.0.0.0/0.
• Forgetting to route spoke traffic through the hub firewall. Without forced tunneling via route tables, spokes can bypass centralized inspection entirely.

Frequently asked questions

Do I need Azure Firewall if I already have NSGs configured? Yes, in most production environments. NSGs handle Layer 3 and 4 segmentation well, but they cannot inspect application-layer traffic, apply threat intelligence, or provide centralized logging across a large environment the way Azure Firewall does. The two are complementary, not competing, controls.

Is Azure DDoS Protection Basic enough for a production application? Basic protection is automatically on for every public IP and helps against common volumetric attacks, but it lacks DDoS Rapid Response support, cost protection guarantees, and Web Application Firewall discounts. For a customer-facing application where downtime has real business impact, the paid Network Protection or IP Protection tier is the standard recommendation.

What is the difference between Azure Firewall Standard and Premium? Standard covers most enterprise use cases with threat intelligence, DNS proxy, and FQDN-based web filtering, scaling to 30 Gbps. Premium adds TLS inspection, signature-based intrusion detection and prevention (IDPS), and full URL-based web filtering, and is generally required for workloads subject to standards like PCI DSS.

Which certification covers Azure network security topics like this? Since AZ-500 retired on August 31, 2026, the current path is SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads, which retains most of AZ-500's identity, network, and Defender for Cloud content while adding AI workload security domains.

Can Network Security Groups block traffic based on domain name or URL? No. NSGs filter strictly on IP address, port, and protocol. If you need to filter by FQDN or full URL, that requires Azure Firewall's application rules and web categories, with Premium adding full URL-based inspection over HTTPS.

What is the fastest way to learn how to design an Azure network security architecture hands-on? Reading documentation only gets you so far. Building a hub-and-spoke topology yourself, with real NSGs, an Azure Firewall instance, and DDoS Protection enabled, is the fastest way to internalize how the pieces fit together, which is why hands-on labs matter more than slides for this material.

Build this skill hands-on

Reading about NSGs, Azure Firewall, and DDoS Protection is a starting point, not the finish line. PrimeSec Academy's curriculum includes hands-on labs where you configure real Azure network security architectures from scratch, alongside AWS and Google Cloud equivalents, as part of a full Cloud & AI Platform Security Engineer training path. If you are not sure whether you are ready, take the eligibility quiz to see where you stand.