NSG vs Azure Firewall vs Azure Bastion: Layered Azure Network Security

Azure gives you three distinct network security tools that show up together constantly on AZ-104, and the exam’s favorite trick is describing a scenario that needs all three at once, then asking which one solves the specific piece being described. A Network Security Group (NSG) filters traffic at the subnet or NIC level using simple allow/deny rules. Azure Firewall centralizes filtering for an entire virtual network (or hub-and-spoke topology) behind one policy engine with threat intelligence built in. Azure Bastion solves a narrower problem entirely: it removes the need for a public IP address on a management VM, so RDP and SSH sessions never touch the internet at all. None of the three replaces the others; production Azure networks typically run all three layered together.

Network Security Groups: rule-based filtering at the edge

An NSG is a list of allow/deny rules attached to a subnet, a network interface, or both, and it evaluates every packet against the five-tuple: source, source port, destination, destination port, and protocol. Rules process by priority (100 to 4096, lower number first), and once traffic matches a rule, evaluation stops, so a specific low-priority-number rule always wins over a broader one with a higher number.

Every NSG ships with default rules you can’t delete, only override with higher-priority rules: allow traffic within the VNet, allow traffic from the Azure Load Balancer, and deny everything else, both inbound and outbound. NSGs are stateful: allowing outbound traffic on a port automatically allows the matching inbound response back in without a separate rule, and vice versa. Removing a rule that permitted a connection doesn’t cut existing sessions; it only blocks new connection attempts.

What an NSG does not do is inspect packet payloads, apply threat intelligence feeds, or understand application-layer protocols. It’s a fast packet filter, not an inspection engine. That’s the gap Azure Firewall fills.

Service tags and application security groups make NSG rules easier to maintain at scale: a service tag (like Storage or Internet) represents a group of IP prefixes Microsoft maintains for you, so a rule referencing Storage doesn’t need updating every time Microsoft’s ranges change. Application security groups let you group VMs logically (say, all your web-tier VMs) and write rules against the group instead of individual IP addresses, reducing how many explicit rules you hand-maintain as an environment grows, a topic closely tied to how Azure RBAC roles govern who can modify those rules in the first place.

Azure Firewall: centralized, threat-aware filtering

Azure Firewall is a fully stateful, cloud-native firewall-as-a-service with built-in high availability and no scaling to manage yourself. Where an NSG is distributed (you attach one per subnet or NIC), Azure Firewall is centralized: you deploy it once in a hub VNet, then route traffic from every spoke through it using user-defined routes, giving you one policy surface for an entire topology instead of dozens of NSGs to keep in sync. It inspects both east-west traffic (between VNets or subnets) and north-south traffic (to and from the internet or on-premises).

Azure Firewall ships in three SKUs, and the exam expects you to know roughly what separates them:

• Basic targets small and medium environments: alert-only threat intelligence mode, a fixed two-instance scale unit, and roughly 250 Mbps of recommended throughput.
• Standard adds full Layer 3 through Layer 7 filtering and threat intelligence sourced from Microsoft’s own threat feeds, with the ability to actually alert on and block traffic to or from known-malicious IPs and domains, updated in real time.
• Premium adds signature-based intrusion detection and prevention (IDPS), drawing on tens of thousands of signatures across dozens of categories to catch specific attack patterns like malware, phishing, and coin-mining traffic, updated continuously.

Azure Firewall Manager sits above all of this as a central console for managing firewall policies across multiple subscriptions and both VNet-based and Virtual WAN (Secure Virtual Hub) deployments, letting you apply one consistent rule set everywhere instead of configuring each firewall instance independently.

	Network Security Group	Azure Firewall
Scope	Per subnet or NIC	Centralized, typically hub VNet
Filtering	L3/L4, five-tuple allow/deny	L3-L7, plus threat intelligence and (Premium) IDPS
Threat intelligence	No	Standard and Premium SKUs
Cost model	Free	Hourly SKU charge plus data processing
Best fit	Baseline segmentation between subnets/resources	Centralized, policy-driven perimeter and east-west inspection

The two aren’t a choice between one or the other. A well-designed VNet typically layers NSGs on individual subnets for baseline segmentation, with Azure Firewall in a hub VNet handling centralized, threat-aware filtering for traffic crossing the perimeter or moving between spokes, an architecture that also depends on the non-transitive nature of VNet peering and the UDRs that route spoke traffic through the hub in the first place.

Azure Bastion: eliminating the public IP on management VMs

Bastion solves a different problem from either of the above: how do you RDP or SSH into a VM for management purposes without ever giving that VM a public IP address, and without exposing port 3389 or 22 to the internet at all? Azure Bastion is a fully managed PaaS service you deploy once into a VNet (using a dedicated AzureBastionSubnet), and it brokers browser-based RDP/SSH sessions through the Azure portal over TLS on port 443, or through the native RDP/SSH client already on your machine for the Standard and Premium tiers. The target VM keeps only a private IP address; Bastion is what’s internet-facing, not the VM itself, which removes the VM entirely from port-scanning exposure.

Azure Bastion is available in four SKU tiers: Developer, Basic, Standard, and Premium.

• Developer is free, runs on shared Microsoft infrastructure, needs no dedicated subnet, and supports one VM at a time. Built for dev/test, not production, and available only in select regions.
• Basic is a dedicated deployment into your VNet with fixed capacity, suited to production environments with moderate connection volume. It requires the dedicated AzureBastionSubnet and a Standard-SKU public IP.
• Standard adds host scaling (control how many instances back the deployment), native client support (your own RDP/SSH client with Microsoft Entra ID authentication and file transfer), shareable links, IP-based connections, and custom ports.
• Premium adds everything in Standard plus session recording for compliance, and it’s the only tier supporting a private-only deployment with no public IP on the Bastion host at all.

	NSG	Azure Firewall	Azure Bastion
Solves	Rule-based traffic filtering	Centralized, threat-aware perimeter filtering	Removing public IPs from management VMs
Applies to	Subnets and NICs	VNet/hub perimeter, east-west and north-south	RDP/SSH sessions to specific VMs
Deployment model	Free, per subnet/NIC	Single centralized instance, hub VNet	Single instance per VNet, four SKU tiers
What it does NOT do	Threat intelligence, payload inspection	Removing public IPs from individual VMs	General traffic filtering between subnets

How the AZ-104 exam tests this

• A scenario wants a VM’s RDP/SSH ports never exposed to the internet, with no VPN client and no public IP on the VM. That’s Azure Bastion, not an NSG rule restricting the source IP, since an NSG rule still requires the VM to have a public IP for direct RDP/SSH.
• A scenario wants traffic evaluated against threat intelligence feeds, or wants IDPS signature matching. That’s Azure Firewall (Standard for threat intelligence, Premium for IDPS), not an NSG, which has no concept of IP reputation or attack signatures.
• A scenario describes basic segmentation between subnets, or blocking a specific port from a specific source range. That’s an NSG; reaching for Azure Firewall here over-engineers the answer.
• A scenario needs compliance-grade session recording of administrative RDP/SSH sessions. That requires Bastion’s Premium SKU specifically; Basic and Standard don’t include session recording.
• A scenario asks for centralized policy management across many subscriptions and both VNet and Virtual WAN deployments. That’s Azure Firewall Manager, layered on one or more Firewall instances.
• A scenario wants native RDP/SSH client connectivity, not just the portal’s browser-based client, or a fully private Bastion deployment. Native client needs Standard or Premium; private-only needs Premium specifically.

Recognizing which of the three problems a scenario is describing (filter traffic, centralize and enrich that filtering, or eliminate exposure for management access) is most of what this domain tests. To see how AZ-104 mixes these three services with the rest of the networking domain, work through AZ-104 practice questions covering NSGs, Azure Firewall, and Bastion side by side.