Networking Network security

Network Security Group

Network Security Group means an Azure rule set that filters inbound and outbound network traffic for subnets or network interfaces. You see it when teams restrict application ports, isolate workloads, permit administration, block unwanted traffic, or document network segmentation. Think of it as a prioritized traffic filter near the workload, not complete application security. It matters because the setting changes how teams design, secure, operate, and troubleshoot the workload. Before changing it in production, know the owner, dependency, evidence, expected result, and rollback path.

Source: Microsoft Learn - Azure network security groups overview Reviewed 2026-05-30

Exam trap: Adding a lower-priority allow rule that never runs because a higher-priority deny rule already matches the traffic.
Production check: List effective rules on the actual NIC before changing the NSG you think controls the workload.

Practice this topic Microsoft Learn

Article details and learning context

Aliases: NSG
Difficulty: fundamentals
CLI mappings: 5
Last verified: 2026-05-30
Article depth: field-manual-complete

Learning paths Learn Networking and Private Access Network Security Group

Related context Learning path: Networking and Private Access Surf route: Network and private access path Prerequisite chain: Network isolation chain

Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

A Network Security Group is a rulebook for traffic around Azure virtual network resources. It decides which inbound or outbound connections are allowed or denied for a subnet or network interface. The rules use priorities, directions, protocols, ports, and source or destination ranges. In plain English, an NSG is one of the first controls that keeps a VM, AKS node subnet, private endpoint subnet, or application tier from being reachable by everything on the network. It is simple, but mistakes are unforgiving.

Why it matters

Network Security Groups matter because a single broad allow rule can expose management ports, databases, or internal APIs to the wrong network. They are also a common cause of outages when a legitimate dependency is blocked during a migration or subnet redesign. For learners, NSGs teach the difference between identity authorization and network reachability. For operators, they provide a practical boundary that can be audited, scripted, and tested. For architects, they shape tier separation between web, application, data, management, and integration networks. Strong NSG design reduces attack surface while keeping troubleshooting possible, because responders can explain why a packet should or should not pass.

Official wording and source

Open Microsoft Learn

Technical context

Technically, a Network Security Group sits in the virtual networking security layer and is evaluated on traffic entering or leaving associated subnets or network interfaces. Rules are stateful, processed by priority, and stop at the first match. NSGs work with service tags, application security groups, augmented rules, private IPs, public-to-private translation, and default rules created by Azure. They do not replace firewalls, identity controls, route tables, private endpoints, or application authorization. They are often governed through Azure Policy and inspected with Network Watcher.

Exam context

AZ-104 Microsoft Azure Administrator Associate AZ-700 Microsoft Azure Network Engineer Associate LAB Azure exam scenario lab practice

What to know

operator field manual with architecture, governance, CLI, and case-study depth

Compare with

Application security group Azure Firewall Route table

Where it is used

Where you see it

In a subnet or network interface blade, the NSG appears as the associated security group that controls inbound and outbound packet filtering. during access reviews.
In rule tables, operators see priorities, source and destination prefixes, service tags, application security groups, protocols, ports, directions, and allow or deny actions. during change approval meetings.
In Network Watcher diagnostics, effective security rules and test-ip-flow results show whether a specific connection is allowed, denied, or shadowed. during packet troubleshooting sessions.

Common situations

Block direct internet access to management ports while still allowing approved Bastion, VPN, or private administration paths.
Separate web, application, and data tiers so only documented ports and trusted source ranges can cross each boundary.
Use service tags or application security groups to simplify rules without hardcoding every platform or workload address.
Troubleshoot blocked application traffic by testing the exact five-tuple before changing firewall, DNS, or code settings.
Audit and remove temporary migration rules that were created for cutovers but should not remain in production.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Research clusters stop exposing SSH to the internet Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A university research computing group let dozens of project teams create Linux VMs, and a monthly scan found SSH open to the internet on several grant-funded clusters.

Goals

Remove direct internet SSH exposure from research subnets.
Keep approved administrators productive through private access.
Create audit evidence for grant security reviews.
Prevent project owners from reintroducing broad rules.

Approach using Network Security Group

The cloud platform team redesigned NSGs around subnet roles. Research compute subnets denied inbound Internet traffic by default, allowed SSH only from a Bastion subnet, and used application security groups for approved management hosts. Azure Policy audited NSGs with Any-source management ports, while CLI scripts exported rules and associations for each project. Network Watcher test-ip-flow became part of the onboarding checklist, proving that an administrator path worked without reopening public SSH. Temporary exception rules required an expiration tag and were reviewed weekly. Existing project VMs were not rebuilt; the risk was reduced by changing the subnet and NIC rule model around them.

Potential outcomes

Internet-exposed SSH findings dropped from 37 to zero within ten business days.
Research administrators kept access through Bastion with no public VM IP requirements.
Grant security evidence collection fell from three days to four hours.
Weekly exception review removed 18 stale rules in the first month.

What to learn

Network Security Groups are most valuable when they express a clear access boundary and make risky exceptions visible.

Scenario 02 Warehouse scanners regain access without opening the database tier Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A logistics company moved inventory services to Azure and found handheld scanners timing out after a subnet migration, while the database subnet remained intentionally isolated.

Goals

Restore scanner API traffic before the next shipping window.
Avoid direct scanner or warehouse network access to databases.
Identify the exact blocked five-tuple quickly.
Document tier boundaries for future facility rollouts.

Approach using Network Security Group

Operators used Network Watcher test-ip-flow from the application NIC and confirmed an outbound NSG deny between the API subnet and a private endpoint subnet. Instead of adding a broad warehouse allow rule, they added one application-tier rule with the API subnet as source, the private endpoint address group as destination, TCP 443, and a priority placed above the default deny. Inbound rules on the database tier stayed closed. The team exported the before-and-after NSG rules with Azure CLI and added the test-ip-flow command to the facility deployment runbook so future warehouses could validate access before opening for shipments.

Potential outcomes

Scanner API timeouts were resolved in 22 minutes without widening database exposure.
Direct database access attempts from warehouse networks remained denied.
The rollout checklist caught two similar rule omissions before later site launches.
Network escalation volume during facility cutovers dropped by 45 percent.

What to learn

Precise NSG testing helps teams fix blocked dependencies without turning a tier boundary into a broad exception.

Scenario 03 Temporary merger rules stop becoming permanent risk Scenario, objectives, solution, measured impact, and takeaway.

Scenario

An insurance broker acquired a regional agency and created many temporary NSG rules to connect legacy claim systems during a rushed migration.

Goals

Find rules created for the merger cutover.
Remove stale access without breaking remaining integrations.
Give security reviewers ownership and expiration data.
Standardize future temporary rule approvals.

Approach using Network Security Group

The infrastructure team used Azure CLI to export every NSG rule with priority, source, destination, port, owner tag, and last modified timestamp. Rules linked to the migration were grouped by application dependency, then tested with application owners using effective security rules and synthetic connection checks. Active dependencies were narrowed to exact ports and source ranges, while obsolete Any-to-Any rules were deleted. A policy initiative required owner, ticket, and expiration tags on future temporary rules. Weekly reports showed exceptions nearing expiration, and Network Watcher output was attached to change records so reviewers could see the exact traffic decision before approval. The cleanup board also tracked retired partner networks so reviewers could close related risks together.

Potential outcomes

Stale merger rules fell from 126 to 19 approved exceptions.
No customer claim-processing outage occurred during cleanup.
Security review findings for network exceptions dropped by 70 percent.
Temporary rule approval time improved because evidence was consistent and searchable.

What to learn

NSGs need lifecycle management; otherwise temporary access quietly becomes permanent attack surface.

Azure CLI

I use Azure CLI for Network Security Groups because rule order and scope are easier to review as data than as portal clicks. With ten years of Azure operations behind me, I want to list every rule, sort by priority, compare subnet and NIC associations, and run test-ip-flow before changing production access. CLI makes it simple to export evidence for audits, detect shadowed rules, find Any-to-Any allowances, and validate a firewall change request against actual configuration. It also supports safer automation: generate before-and-after snapshots, update one rule deliberately, and keep the change tied to a ticket. That discipline prevents emergency edits from becoming invisible design drift.

Useful for

List NSGs and their subnet or NIC associations to find which rule set protects a workload.
Export inbound and outbound security rules sorted by priority for audit review or change approval.
Run Network Watcher test-ip-flow to prove whether a specific source, destination, port, and direction is blocked.
Create, update, or remove one rule with explicit priority and scope during a controlled access change.

Before you run a command

Confirm subscription, resource group, NSG name, associated subnet or NIC, and whether the command changes live traffic.
Check current rule priorities first because lower numbers win and duplicate priority-direction pairs are not allowed.
Validate source ranges, service tags, application security groups, and ports with the application owner before approving access.
Take a before-state export so rollback is possible if new connections fail after a rule update.

What the output tells you

Rule output shows direction, priority, access, protocol, port ranges, and source or destination selectors that determine the first matching decision.
Association output reveals whether the NSG protects a subnet, a network interface, or both, which affects troubleshooting scope.
Network Watcher output tells you which rule allowed or denied the test flow and whether the failure is really an NSG issue.

Mapped commands

Network Security Group discovery

discovery

az network nsg list --resource-group <rg> --output table

az network nsgdiscoverNetworking

az network nsg show --resource-group <rg> --name <nsg-name>

az network nsgdiscoverNetworking

az network nsg rule list --resource-group <rg> --nsg-name <nsg-name> --output table

az network nsg rulediscoverNetworking

Network Security Group validation

diagnostic

az network watcher test-ip-flow --vm <vm-id> --direction Outbound --protocol TCP --local <local-ip>:<port> --remote <remote-ip>:<port>

az network watcherdiscoverNetworking

az network nsg rule create --resource-group <rg> --nsg-name <nsg-name> --name <rule-name> --priority <priority> --direction Inbound --access Allow --protocol Tcp --destination-port-ranges <port>

az network nsg rulesecureNetworking

Architecture context

Architecturally, I place Network Security Groups at every subnet boundary where they express intent clearly: web tier accepts only expected ingress, app tier accepts only trusted callers, data tier rejects direct user traffic, and management access is limited to controlled sources. I avoid turning NSGs into giant firewall policy engines because complex inspection belongs elsewhere. Good NSG design uses service tags, application security groups, naming standards, and priority spacing so teams can evolve rules without collisions. The best designs combine NSGs with private endpoints, route tables, Azure Firewall, identity, and logging. NSGs should be boring, explicit, and easy to prove.

Security: Security is the direct purpose of a Network Security Group. Rules define which network flows are allowed, so least privilege matters. Avoid broad inbound rules from Internet, Any source, or wide corporate ranges unless the risk is documented. Protect management ports with jump hosts, Bastion, just-in-time access, or private administration paths. Use service tags carefully because they represent large platform address groups, not business intent. Restrict who can modify NSGs and monitor rule changes in the activity log. A malicious or mistaken NSG update can expose a workload faster than many application teams can detect. Review temporary access weekly and remove it before it normalizes.
Cost: Network Security Groups do not usually drive a direct per-rule bill, but they create cost through operations effort and downstream architecture choices. Too many unclear rules slow every incident, audit, migration, and onboarding request. Overly permissive rules can create breach cost, while overly restrictive rules can cause outage cost and delayed releases. NSG flow logging, Traffic Analytics, and long telemetry retention may add monitoring cost. FinOps conversations should include the operational cost of rule sprawl, duplicate exception processes, and manual reviews. Clean NSG design often saves money by reducing firewall exceptions, rework, and emergency support time. Flow-log retention should match investigation needs, not unlimited curiosity.
Reliability: Reliability impact is indirect but serious. NSGs do not run application code, yet they can break health probes, database connections, private endpoints, replication, patching, DNS, or monitoring agents when rules are too narrow or associated at the wrong scope. Stateful behavior means existing connections may survive a rule removal while new connections fail, which can confuse testing. Operators need staged changes, test-ip-flow checks, dependency maps, and rollback commands. Use priority gaps so emergency fixes do not require renumbering every rule. For critical systems, validate both inbound and outbound paths after every subnet, NIC, or rule change. Document expected probe traffic so platform health checks keep working.
Performance: Performance impact is usually indirect. NSGs are platform-enforced and should not be used as an excuse for application latency, but misconfiguration can force retries, failed connection pools, slow failover, and noisy health checks. Large, confusing rule sets hurt human diagnostic speed even when packet processing remains efficient. Bad outbound rules can block dependency calls and make applications wait for TCP timeouts. Operators should test the exact source, destination, port, protocol, and direction for critical paths. Performance investigations should rule out NSG denies before tuning application code, database queries, or compute scale. Capture failed connection timing so timeout patterns are not misread.
Operations: Operations teams use NSGs for inventory, troubleshooting, approvals, and audit evidence. Daily tasks include listing rules, finding subnet and NIC associations, checking effective security rules, reviewing activity-log changes, and testing flows with Network Watcher. Runbooks should capture who owns each rule, why it exists, the expiration date for temporary access, and the application dependency it protects. Good operators remove stale rules, enforce naming standards, and compare production rules with lower environments. During incidents, NSG evidence helps separate a network block from DNS, routing, identity, firewall, or application failure. Expire temporary changes automatically when the ticket or migration closes. Review owners quarterly.

Common mistakes

Adding a lower-priority allow rule that never runs because a higher-priority deny rule already matches the traffic.
Assuming an NSG is a full firewall and forgetting that it does not inspect URLs, identities, malware, or application payloads.
Opening temporary Any source access for migration work and leaving it in production after the cutover is complete.
Testing only one direction of traffic even though outbound denies can break agents, APIs, updates, and dependency calls.