NSGs, ASGs, and Azure Firewall: Put the Control in the Right Place
Azure network security becomes confusing when every control is described as something that “allows or denies traffic.” Network security groups do that. Azure Firewall does that. Application security groups influence rules that do that. Yet these controls live at different points in the traffic path and solve different operational problems.
The fastest way to make the design understandable is to stop comparing feature lists and start tracing packets. Where does the traffic originate? Where is it going? Which subnet or network interface does it traverse? Does it need centralized inspection? Does policy need to reference application roles rather than IP addresses? Does traffic cross a hub, the internet, or an on-premises boundary?
Those questions are part of AZ-104 administration because an Azure administrator must know not only how to create an NSG rule, but where a control belongs and how multiple controls interact. Poor placement creates either gaps or a troubleshooting maze.
NSGs are distributed filters close to Azure resources
A network security group contains stateful allow and deny rules for inbound and outbound traffic. It can be associated with a subnet, a network interface, or both. Rules evaluate properties such as source, destination, protocol, port, and priority.
That makes NSGs well suited to segmentation close to workloads. A web subnet can accept traffic on the application port while rejecting unnecessary inbound connections. A database subnet can allow application traffic while denying direct access from unrelated networks. Outbound rules can constrain where workloads connect.
The strength of this model is locality. Policy can be attached to the same subnet or NIC boundary where workloads live. The weakness is that a large environment can accumulate many independently managed rule sets if teams do not standardize them.
NSGs also include default rules, so administrators should understand the effective rule order rather than assuming an empty custom rule list means “no traffic.” The important operational skill is reading the whole effective policy in context.
When an NSG is attached at both the subnet and NIC, the effective result reflects both layers. An allow at one layer does not magically override a deny that applies at the other. That is another reason to keep the policy model intentional: two independently maintained NSGs can create a control that is technically valid but difficult for operators to reason about during an outage.
Application security groups make NSG rules follow application roles
IP addresses are a poor long-term description of application architecture. Instances are rebuilt, private addresses change, and horizontally scaled tiers add or remove interfaces. Application security groups let administrators group supported network interfaces by application role and then use those groups as sources or destinations in NSG rules.
Instead of writing a rule that says “10.20.3.7 and 10.20.3.8 may connect to 10.20.4.12 on this port,” the policy can express “web-tier members may connect to database-tier members on the required port.” The platform maintains the relationship as interfaces are added to or removed from the groups.
ASGs do not replace NSGs. They are an abstraction used inside NSG rules. They make those rules easier to align with application intent and reduce dependence on explicit IP lists.
There are scope constraints, including requirements around the virtual networks of participating interfaces. Those constraints matter when architects try to use ASGs as a universal cross-network identity system. They are useful precisely because they simplify a defined virtual-network security model, not because they make every address boundary disappear.
Azure Firewall is a centralized network security service
Azure Firewall is a managed, stateful firewall service designed for centralized control of network traffic. It can sit in a hub or other shared network location and inspect traffic that is deliberately routed through it. It supports network and application rules, threat-intelligence features, logging, and other capabilities that go beyond the basic distributed filtering model of an NSG.
This makes it suitable for policies such as controlling outbound internet access across many spoke networks, enforcing centralized ingress or egress rules, and applying shared security policy where a hub-and-spoke architecture routes traffic through a common inspection point.
The key phrase is “routed through it.” Azure Firewall cannot inspect traffic that never traverses the firewall. Creating the resource does not automatically make every virtual network use it. User-defined routes, hub topology, peering behavior, and service-specific traffic paths determine whether packets actually pass through the centralized control.
This is why deeper AZ-700 networking knowledge becomes valuable. Firewall policy and routing architecture are inseparable when centralized inspection is expected.
Distributed filtering and centralized inspection usually complement each other
Teams sometimes ask whether they should use NSGs or Azure Firewall, as if one must replace the other. In many production designs, both are useful because they protect different boundaries.
An NSG can enforce least-privilege communication at a subnet or NIC boundary even if traffic never leaves the virtual network. Azure Firewall can enforce organization-wide egress policy as traffic moves through a shared hub. If the central firewall is misrouted or bypassed accidentally, the NSG still provides local segmentation. If an NSG is broader than intended, the central firewall can still constrain internet or cross-network flows.
Defense in depth is useful when the controls are understandable and independently justified. Duplicating the same complicated rule set in three places merely multiplies failure modes. The design should assign each layer a purpose.
For example, local NSGs can express “which application tiers may talk,” while Azure Firewall expresses “which external destinations may be reached and which cross-spoke flows require centralized approval.” That division is easier to operate than copying every port rule into both systems.
Service tags represent groups of IP address prefixes associated with Azure services. They help administrators avoid manually maintaining large lists of service addresses in network rules. Application security groups represent the organization’s own workload roles inside a virtual-network context.
The distinction matters because both features reduce hard-coded addresses, but they describe different subjects. A service tag might represent Azure Storage or another platform service. An ASG might represent the application servers that need to reach it.
Good NSG rules use the most stable and meaningful abstraction available. If a rule can reference a supported service tag rather than a changing list of Microsoft-owned prefixes, use the service abstraction. If a rule can reference an application group rather than a set of VM addresses, use the application abstraction.
The result is policy that survives normal infrastructure change without becoming so abstract that nobody can tell what it permits.
Traffic-path diagrams expose policy mistakes before troubleshooting does
Before adding a firewall rule, draw the path. A request from an on-premises client to an Azure VM might traverse VPN or ExpressRoute, a hub, a network virtual appliance or Azure Firewall, peering, a subnet NSG, and a NIC NSG. Return traffic may follow a different route if user-defined routes or asymmetric designs are involved.
Without that path, teams often modify whichever control they can see first. They add an NSG allow rule even though Azure Firewall is blocking the connection. They loosen the firewall when DNS is resolving the service to the wrong endpoint. They change routes when the application is actually rejecting the request.
Effective security-rule tools, network watcher capabilities, flow information, firewall logs, and route inspection can narrow the problem. The useful sequence is packet path first, then policy evaluation at each boundary.
The Azure Network Engineer role goes deeper into that relationship between routing, connectivity, private access, and security controls because a network policy only works when traffic actually reaches it.
Centralized controls change the ownership model
A subnet-level NSG can often be owned by the team responsible for that application boundary. A central firewall usually has broader impact. One rule change can affect many subscriptions or spokes, so governance, review, logging, and change management become more important.
This creates a natural split between platform and workload responsibilities. The platform team may own the hub, shared firewall policy, and baseline controls. Application teams may own workload-specific NSGs inside their landing zones. Security teams may define mandatory egress restrictions or threat-intelligence settings.
The design should make that split explicit. If every application team can modify the central firewall, the shared control loses consistency. If only a central team can change every local NSG, routine application delivery may become unnecessarily slow. Delegation should follow blast radius.
This concern is also part of AZ-500 security engineering: technical enforcement and administrative privilege have to be designed together.
Security rules are only useful if operators can determine what they are doing. A denied connection should be diagnosable. An unexpected outbound flow should be visible somewhere. A rule that has not matched traffic for months should be reviewable as a possible cleanup candidate.
Azure Firewall provides logging that can feed monitoring and analysis systems. NSG-related flow visibility and network troubleshooting tools can help establish whether traffic reached a boundary and how rules affected it. The exact logging configuration should reflect the organization’s investigation needs and retention requirements.
Logging also helps policy design. If a team plans to tighten egress, observing current destinations before enforcement can reveal legitimate dependencies. If a rule is being removed, historical evidence can show whether anything has used it recently.
The goal is not to collect every packet forever. It is to retain enough evidence to answer operational questions without guessing.
Security rules should express intent clearly enough to survive staff turnover
Network policies tend to live longer than the people who create them. A rule called “temp-allow-2” with a broad address range and no owner is future incident material. Names, descriptions, priorities, and grouping should make the reason for a rule understandable.
Application security groups can improve that clarity by replacing IP lists with workload roles. Service tags can replace vendor address lists. Central firewall policies can group related rules by purpose. NSGs can remain focused on local segmentation rather than becoming a dumping ground for every exception in the environment.
Documentation should also record the expected path. A rule that looks redundant in isolation may be an intentional secondary control. Conversely, two apparently independent rules may create an accidental bypass when combined with routing.
Put each control where its scope matches the risk
NSGs are strong for distributed filtering at subnets and network interfaces. ASGs make those NSG rules follow application structure instead of individual IP addresses. Azure Firewall provides centralized, managed inspection for traffic routed through a shared control point.
For an Azure Administrator, the practical question is not which product is “better.” It is whether each control sits at the boundary where it can enforce the intended policy without creating unnecessary complexity.
That judgment is easier when administrators understand Azure networking architecture as a traffic-flow problem. Trace the packet, identify the trust boundary, choose the smallest useful scope, and then place the control. The right security design is the one where operators can explain both why a packet is allowed and exactly where it would be stopped if policy changed.