3. Azure Network Security Group (NSG)

AWS and Azure handle network security in different ways. AWS splits things between Security Groups and NACLs, while Azure consolidates similar features into NSGs and adds ASGs for application‑centric grouping.

• Scope Perspective: While AWS Security Groups apply at the instance or ENI level and NACLs apply at the subnet level, Azure NSGs can be applied at either the subnet or NIC level.

In AWS, Security Groups operate at the instance or ENI level, giving you fine‑grained control over traffic to individual workloads. Network ACLs, on the other hand, apply at the subnet level, enforcing broad, stateless filtering that affects every resource inside that subnet. This creates a layered model: NACLs act as the coarse perimeter, while Security Groups provide precise, workload‑specific protection.

Azure blends these concepts differently. Network Security Groups (NSGs) can be applied at either the subnet or NIC level, allowing them to function like both AWS NACLs and AWS Security Groups, depending on where they’re attached.

• Statefulness Perspective: AWS NACLs are stateless, while AWS Security Groups are stateful; Azure NSGs follow the same stateful model as AWS Security Groups.

Stateful means the firewall remembers the details of a connection, while stateless means it treats every packet as unrelated and forgets everything that came before it. In other words, stateful means that if inbound is allowed, return outbound traffic is automatically allowed (and vice versa: if outbound is allowed, return inbound traffic is automatically allowed).

Security Groups are stateful, which means that they automatically allow return traffic for permitted connections. Network ACLs (NACLs), however, are stateless, so they evaluate every packet independently and require explicit rules in both directions for a flow to work. Because NACLs do not remember connection state, you must manually allow both inbound and outbound traffic for the same session, making them fundamentally different from Security Groups.

Azure Network Security Groups (NSGs) behave more like AWS Security Groups. Azure NSGs are stateful, meaning they track connection state and automatically allow return traffic without requiring a separate rule.

• Allow/Deny Rule Perspective: AWS Security Groups only support allow rules, while both AWS NACLs and Azure NSGs support explicit allow and deny rules.

You can only create allow rules on AWS Security Groups, meaning there is no deny rule option. Anything not explicitly permitted is automatically rejected. In contrast, AWS Network ACLs (NACLs) provide both allow and deny capabilities.

Azure Network Security Groups (NSGs) work similarly to NACLs in that they also support allow and deny rules.

• There is a subtle point here: Azure NSGs are stateful, but you can still block return traffic using a deny rule. Statefulness does not override an explicit deny.

When I first started deep diving into NSGs, I wondered why Azure includes deny rules in NSGs, since AWS Security Groups don’t have them and still work effectively. The reason is architectural: NSGs are the baseline network filtering layer in Azure, and without deny rules, Azure would have no easy way to block traffic at the network layer. As a result, Azure NSGs are stateful like Security Groups, but with an important twist: deny rules can still block return traffic. This means Azure’s statefulness can be overridden by an explicit deny, something that never happens with AWS Security Groups.

What does this mean in practice? NSGs automatically allow return traffic for any permitted inbound or outbound flow. However, this automatic return traffic is only allowed if no deny rule matches it. If a deny rule applies to the return path, Azure will block it even though the NSG is stateful. This is why understanding the interaction between statefulness and deny rules is important when designing Azure network security.

• What is Azure Application Security Groups (ASGs)?

AWS Security Groups can reference other Security Groups as sources or destinations. For example, you can configure a database Security Group to accept traffic only from a specific application Security Group attached to certain instances. Azure provides this through its Application Security Groups (ASGs).

Application Security Groups (ASGs) add a logical layer on top: instead of defining rules by IP or NIC, you group VMs by application role and reference those groups inside NSG rules. This makes Azure’s model more dynamic, especially in large or rapidly changing environments, because security rules follow the application structure rather than the underlying network layout.

AWS achieves the same kind of “logical workload grouping” by assigning instances to a Security Group and then using that group in another SG’s rules.

• Default Behavior and Baseline Rules of AWS Security Groups, NACLs, and NSGs

AWS Security Groups start with a simple default posture: all inbound traffic is denied, and all outbound traffic is allowed. AWS Network ACLs are stricter by default, denying all inbound and outbound traffic until rules are added.

Azure NSGs include built‑in system rules that always exist, such as allowing VNet‑to‑VNet traffic, allowing Azure Load Balancer probes, and denying inbound internet traffic by default. These system rules form a baseline policy that applies before any custom rules, making Azure’s default behavior more opinionated than AWS’s.

• Rule Evaluation Order

AWS Security Groups do not use rule numbers and do not evaluate rules in sequence. Instead, all rules are considered together, and if any rule allows the traffic, it is permitted. AWS NACLs use numbered rules, and the first matching rule determines the outcome, making rule order critical.

Azure NSGs also use numbered priorities, where lower numbers take precedence, and the first match wins. In this sense, NSGs behave more like NACLs than Security Groups when it comes to rule evaluation.

Conclusion

Let’s simplify everything and highlight the whole keypoints here. Azure Network Security Groups (NSGs) are stateful, like AWS Security Groups, but they can also use deny rules with allow rules like NACLs. Also, NSGs can be applied at both the subnet or NIC level, like a combination of AWS Security Groups (instance or ENI level) and AWS NACLs (subnet level). The feature of AWS Security Groups referencing other Security Groups as sources or destinations is a close concept with Azure Application Security Groups on Azure. Another point is that NSGs are stateful, but deny rules take priority over stateful return traffic (Inbound and Outbound asymmetry), which doesn’t exist in AWS Security Groups.