Azure Network Security Groups (NSG)

What is Azure Network Security Group?

An Azure Network Security Group is a rule-based security control used to filter network traffic in Azure. It allows you to define inbound and outbound rules based on source, destination, protocol, and port.

In simple terms, an NSG is like a traffic checkpoint. It checks packets against a list of rules and decides whether to allow or deny them.

NSGs are commonly associated with Azure subnets or with individual network interfaces attached to virtual machines and other workloads.

Why Azure NSG matters

Azure networking without traffic filtering quickly becomes messy or unsafe. NSGs matter because they bring structure to security decisions and help reduce unnecessary exposure between workloads.

Azure NSG in the 5 Ws

What is Azure NSG?

It is a rule-based traffic filter in Azure used to allow or deny inbound and outbound network traffic.

Why do teams use it?

Teams use NSGs to reduce exposure, control connectivity, and apply security intent to subnets or individual workloads.

When should you use it?

Almost any non-trivial Azure environment should use NSGs somewhere, especially when different workload types need different access patterns.

Where does it fit?

It fits at subnet level, NIC level, or both, depending on how granular you need the traffic control to be.

Who works with it?

Cloud engineers, DevOps teams, Azure administrators, network engineers, platform teams, and security teams all work with NSGs.

How does it work?

Azure evaluates NSG rules in priority order and checks whether a packet matches the rule conditions. The first matching rule determines whether that traffic is allowed or denied.

How Azure NSGs work

Azure NSGs contain inbound and outbound security rules. Each rule usually evaluates:

• source IP address or source range
• source port
• destination IP address or destination range
• destination port
• protocol such as TCP, UDP, or Any
• priority number
• action, such as Allow or Deny

When traffic tries to enter or leave a resource, Azure compares the packet against NSG rules in priority order. The first rule that matches is applied.

Traffic flow idea

Incoming packet
   ↓
Check NSG rules by priority
   ↓
Match source, destination, protocol, and ports
   ↓
First matching rule wins
   ↓
Allow or Deny

Rule components: IPs, ports, and protocol explained

Many NSG problems happen because people remember “allow or deny” but forget that Azure matches traffic using several fields together. A rule is not only about opening a port. It is about which source can use which protocol and port to reach which destination.

Why source and destination IPs matter

A rule that allows port 443 is not enough if the source is wrong. For example, you may want to allow HTTPS only from the internet to a web subnet, but not from every internal subnet to every internal resource. The source field decides who is allowed to initiate that traffic.

Why destination port matters more than people think

In many app designs, the important port is the destination port. For example:

• HTTPS traffic usually targets destination port 443
• HTTP traffic usually targets destination port 80
• SSH traffic usually targets destination port 22
• RDP traffic usually targets destination port 3389
• SQL Server traffic often targets destination port 1433

Why source port is often set to Any

In many common NSG rules, the source port is left as Any because client systems typically use temporary ephemeral source ports. What usually matters most is the destination service port.

Common ports you will see in NSG rules

NSGs are often used to control access to common application, management, and database ports. This table helps make the rule logic more practical.

NSG rules and priority

Rule priority is one of the most important parts of NSG behavior. Lower numbers are evaluated first, so a rule with priority 100 is checked before a rule with priority 200.

Why priority matters so much

Rule order controls behavior. Even a very specific allow rule is useless if a broader deny rule with higher priority is matched first.

Subnet-level NSG vs NIC-level NSG

Azure NSGs can be attached to a subnet or to a network interface. Understanding the difference is important for clean design and troubleshooting.

Common Azure NSG use cases

Real-world Azure NSG examples

Example 1: Public web, private app, private database

A company allows internet source traffic to destination port 443 on the web subnet, allows the web subnet to reach the app subnet on destination port 8080, and allows only the app subnet to reach the database subnet on destination port 1433.

Example 2: Restricted admin access

An infrastructure team allows SSH on destination port 22 or RDP on destination port 3389 only from a jump host subnet or approved corporate source range.

Example 3: Shared services environment

A central platform team uses subnet-level NSGs for common rules and applies NIC-level NSGs only for special-case workloads.

Example 4: Internal API platform

APIs in one subnet are exposed only to internal application sources on specific destination ports, not directly to the internet.

Example 5: Enterprise migration workload

During cloud migration, NSGs are used to mimic on-premises segmentation so teams can move applications in phases without exposing all traffic paths by default.

Azure NSG best practices

• Keep rules as simple and readable as possible.
• Use clear naming that reflects rule purpose.
• Document why a rule exists, not just what it does.
• Be deliberate with priority numbers.
• Prefer subnet-level consistency unless there is a real need for NIC-level exceptions.
• Review broad allow rules carefully.
• Keep production rules tighter than non-production where appropriate.
• Align NSGs with subnet purpose and architecture intent.
• Match source IPs, destination IPs, and ports carefully instead of assuming “open port = correct rule.”
• Regularly review old rules to remove unnecessary exceptions.

Common Azure NSG mistakes

Troubleshooting Azure NSG issues

When traffic fails in Azure, NSGs are often one of the first places to inspect. But the goal is not only to ask “is the port open?” You also need to check which rule matches first, where the NSG is attached, and whether the source and destination fields are correct.

Basic troubleshooting sequence

1. Check whether the NSG is attached to the subnet, NIC, or both.
2. Review inbound and outbound rules separately.
3. Check rule priorities carefully.
4. Confirm source and destination addresses match the intended rule.
5. Confirm the destination port is the actual service port being used.
6. Review whether route tables or firewalls are also affecting the path.
7. Check whether the workload is in the subnet you expect.

Useful troubleshooting questions

• Which rule is matching first?
• Is the traffic inbound or outbound?
• Is the NSG applied at subnet level, NIC level, or both?
• Is the source IP or source subnet actually what you think it is?
• Is the destination IP, subnet, or destination port actually correct?
• Could another control like routing or firewall be the real issue?

Troubleshooting mindset

Traffic blocked?
 ├─ Check NSG association
 ├─ Check inbound/outbound direction
 ├─ Check rule priority
 ├─ Check source and destination match
 ├─ Check destination port
 └─ Check route/firewall dependencies

Official Microsoft Azure documentation

These official Microsoft Azure references are useful if you want deeper platform details, implementation guidance, and service-specific documentation for Network Security Groups and related Azure networking controls.

• Network Security Groups overview
• Tutorial: Filter network traffic with a network security group
• Application security groups
• Diagnose a network traffic filter problem
• Azure Virtual Network overview