Step-by-Step Guide to Creating and Managing Azure Network Security Groups

Azure Network Security Groups (NSGs) are one of the first controls you should get right when building cloud security in Microsoft Azure. If your Azure NSG setup is weak, every other network control becomes harder to trust. If it is well designed, you can control inbound and outbound traffic with precision, reduce attack surface, and keep application tiers separated without adding unnecessary complexity.

This step-by-step tutorial focuses on the work that matters in real environments: creating NSGs, writing rules that do what you expect, attaching them in the right place, and validating that traffic is actually filtered the way you intended. You will also see how NSGs fit into broader network security and cloud security practices, including least privilege, logging, governance, and change control. For IT teams using Azure at scale, NSGs are not just a checkbox. They are a foundational layer for protecting virtual networks, subnets, and network interfaces.

According to Microsoft Learn, NSGs filter traffic to and from Azure resources using allow and deny rules based on source, destination, port, and protocol. That simple model is powerful, but only if you plan the rules carefully. The sections below show how to do that without guessing. If you are looking for a practical Azure NSG setup guide that busy administrators can apply immediately, this is the right place to start.

Understanding Azure Network Security Groups

A Network Security Group is a virtual firewall control in Azure that filters network traffic using security rules. It does not inspect payloads like a full next-generation firewall, but it is excellent for enforcing segmentation and reducing exposure. In practice, an NSG decides whether traffic is allowed or denied based on attributes such as source IP, destination IP, ports, protocol, and direction.

Azure evaluates inbound rules and outbound rules separately. Inbound rules protect resources from unsolicited traffic entering a subnet or NIC. Outbound rules control traffic leaving your workload, which matters more than many teams realize. Malware, data exfiltration, and accidental calls to public endpoints often move outbound, not inbound.

Rule priority is critical. Azure processes rules in order from the lowest priority number to the highest. That means a rule with priority 100 overrides a similar rule with priority 200. If an allow rule comes before a deny rule, the deny rule may never matter. This is why careful ordering is part of the Azure NSG setup, not an afterthought.

NSGs can be applied to a subnet or a network interface card (NIC). Subnet-level NSGs are best when you want consistent protection for a whole tier, such as all web servers. NIC-level NSGs are useful for unique exceptions on one VM, such as a jump host or a sensitive app server. Azure also applies default rules automatically, including basic allow and deny behavior for virtual network traffic and Azure load balancer traffic, so your custom design must account for those built-ins.

• Use NSGs to isolate workloads.
• Use NSGs to restrict management ports like RDP and SSH.
• Use NSGs to segment dev, test, and production environments.
• Use NSGs to enforce network security at the subnet or NIC layer.

Note: Microsoft documents the default NSG rule set in Azure NSG documentation. Review those defaults before building custom rules so you do not accidentally duplicate or conflict with them.

Planning Your NSG Strategy for Cloud Security

Good cloud security starts with a traffic map, not a portal click. Before creating an NSG, identify every application, service, management path, and integration point that needs network access. That includes user traffic, backend calls, update services, monitoring agents, administrative access, and any third-party dependencies. If you skip this step, you usually end up with broad “temporary” rules that stay forever.

Design around least privilege. The goal is not to “make it work” by allowing entire address ranges or all ports. The goal is to allow only the traffic that a workload truly needs. For example, a web server may need inbound 443 from the internet, but it does not need inbound SQL Server ports from random source IPs. A database server may need inbound 1433 only from an application subnet, not from the full virtual network.

A practical planning method is to build a matrix with source, destination, port, protocol, and direction. That matrix makes rule creation much easier and avoids confusion later. It also helps when teams review the design for compliance or audit purposes.

Field	Example
Source	10.10.1.0/24 or an application security group
Destination	Web subnet or specific VM NIC
Port	443, 1433, 22, or 3389
Protocol	TCP, UDP, or Any
Direction	Inbound or outbound

Tiering also keeps NSGs manageable. Separate web, app, and database layers. That structure makes troubleshooting easier and prevents one oversized rule set from trying to protect everything. Naming conventions matter too. Use names that describe purpose, not just sequence numbers, and tag rules or resource groups consistently for ownership and environment. For broader governance, Microsoft’s guidance on Azure Policy and tagging aligns well with the kind of standardization that security teams need.

Creating a Network Security Group in Azure

Creating an NSG in the Azure portal is straightforward, but the decisions you make during creation affect maintainability later. Start by selecting the correct subscription, resource group, region, and resource name. The region should match the resources you plan to protect, and the resource group should reflect a clean ownership model. If your resource groups are already messy, fix that before adding more security objects.

In the portal, search for Network security groups, choose Create, and complete the basics. Once the NSG exists, it becomes available for rule configuration and for association to a subnet or NIC. You can then add inbound and outbound rules, or attach it first and return to rules later. The sequence is flexible, but the design should not be.

You are not limited to the portal. Azure CLI, PowerShell, ARM templates, and Bicep are better choices when you need repeatable deployments. Infrastructure as code is the safer path for production because it reduces manual drift and gives you a reviewable change history. For example, teams using Bicep can store NSGs in source control, standardize naming, and deploy the same baseline across multiple environments.

Common setup mistakes are easy to make. Teams create the NSG in the wrong region, use inconsistent names like “nsg1” and “prod-nsg-final,” or place the resource in a group that has no logical relationship to the workload. Those mistakes are not just cosmetic. They slow down troubleshooting and increase the chance of attaching the wrong control to the wrong subnet.

• Verify the subscription before you click create.
• Match the region to the protected workload.
• Use naming that reveals purpose and environment.
• Prefer automation for repeatable Azure NSG setup tasks.

Microsoft documents programmatic deployment options in Azure Resource Manager and Bicep. Those tools are ideal when your network security standards must stay consistent across many subscriptions or business units.

Configuring Inbound and Outbound Security Rules

Every NSG rule is built from the same core fields: priority, source, source port ranges, destination, destination port ranges, protocol, and action. Priority determines which rule is evaluated first. Lower numbers win. That means a tightly scoped deny rule at priority 100 can override a broader allow rule at priority 200, but not the other way around.

For inbound rules, start with specific use cases. A web server may need inbound HTTP and HTTPS from the internet, but only if it is meant to be public. Administrative access such as RDP or SSH should usually be restricted to trusted source IPs, a jump box subnet, or a VPN range. Exposing 3389 or 22 to “Any” is one of the fastest ways to weaken your Azure NSG setup.

Outbound rules deserve equal attention. Many teams leave outbound wide open because it is easier. That works until you need to restrict access to the internet, block unauthorized software updates, or force traffic through a proxy or inspection layer. Outbound restrictions can also reduce the blast radius if a workload is compromised.

Azure provides service tags, application security groups, and IP ranges to simplify rule management. Service tags let you reference broad Azure services without tracking every IP. Application security groups let you group VMs by function, which is helpful when multiple servers share the same role. IP ranges remain useful when you need precision, but they are harder to maintain at scale.

Well-designed NSG rules are specific enough to be safe and simple enough to maintain.

Examples of common inbound rules include:

• Allow TCP 443 from Internet to web tier.
• Allow TCP 3389 only from admin VPN IPs.
• Allow TCP 22 only from a bastion host subnet.
• Deny all other inbound traffic by default.

Examples of common outbound rules include:

• Allow traffic to Azure Monitor and required platform services.
• Allow database connections only to approved internal IPs.
• Deny direct internet access for server subnets that should not browse externally.

Warning: Avoid “allow all from anywhere” rules unless there is a documented, time-limited business reason. Broad rules are hard to audit, hard to justify, and easy to forget.

According to Microsoft Learn, rules are evaluated against flow direction and priority, so a misplaced rule can create unexpected exposure. Treat every rule as a security control, not a convenience setting.

Associating NSGs with Subnets and Network Interfaces

Applying an NSG at the subnet level gives you consistent protection across a group of resources. This is usually the best option for shared tiers such as web servers, app servers, or private utility subnets. If you need the same baseline for multiple machines, subnet-level association reduces duplication and keeps your rule set easier to audit.

Applying an NSG at the NIC level gives you granular control over a single VM or workload. That is useful for exceptions, jump hosts, domain controllers, or highly sensitive systems that need stricter controls than the rest of the subnet. NIC-level rules are powerful, but overusing them can create a patchwork of exceptions that nobody wants to troubleshoot.

When both subnet and NIC NSGs exist, Azure evaluates the combined effect. Traffic must be allowed by both layers. If either NSG denies it, the flow is blocked. That behavior is helpful for defense in depth, but it also means a harmless-looking subnet rule may not fix a problem if the NIC-level NSG still blocks the port.

Association	Best Use Case
Subnet-level NSG	Shared service tiers and consistent policy
NIC-level NSG	Special exceptions and machine-specific controls

For production workloads, a common pattern is subnet-level baseline protection with selective NIC-level exceptions. For shared services, subnet-level control is usually enough. For sensitive systems, combine subnet controls with a smaller NIC rule set and document every exception. That approach supports cloud security without making the environment fragile.

Microsoft’s guidance on NSG flow and effective rules in how NSGs work is useful here because it explains how Azure combines rules from different scopes. Understanding that combination prevents a lot of “why is this port still blocked?” confusion.

Testing and Validating NSG Rules

Testing is where many Azure NSG setup projects reveal their mistakes. The Azure portal includes effective security rules, which show the resulting rule set after associations and priorities are applied. Use that view before you touch the workload. It tells you what Azure thinks should happen, which is often the fastest way to spot a conflict.

Then test connectivity from realistic source locations. If you are allowing RDP from a VPN, test from the VPN. If you are allowing web access from a public browser, test from a public network. If you are restricting database traffic to an app subnet, test from that subnet and from somewhere else to confirm both allow and deny behavior. A rule is not valid until it behaves correctly in both directions.

Useful tools include ping, Test-NetConnection, curl, telnet, and simple browser checks. Ping is not always reliable because ICMP may be blocked, so do not assume a failed ping means the port is closed. Test-NetConnection is especially helpful for TCP checks in Windows environments, while curl is practical for web endpoints. Telnet can still help verify whether a port is open, even if the service itself is not responding.

• Use browser checks for HTTP and HTTPS.
• Use Test-NetConnection for Windows TCP validation.
• Use curl to confirm service responses and headers.
• Use telnet only for basic port reachability testing.

Network Watcher adds stronger diagnostics. IP flow verify helps determine whether a specific flow is allowed or denied. Connection troubleshoot can test path issues and identify where the communication breaks. Microsoft documents these tools in Network Watcher, and they are worth using whenever a rule behaves unexpectedly.

Monitoring and Troubleshooting NSGs

Once NSGs are live, monitoring matters as much as configuration. Azure provides NSG flow logs and Traffic Analytics so you can see accepted and denied flows over time. That visibility helps you identify unused rules, unexpected access attempts, and patterns that suggest an overly broad exception. If security or operations teams are blind to traffic, they are guessing during incidents.

Azure Monitor and diagnostic settings are useful when you need to correlate NSG behavior with other events. For example, a failed application deployment may coincide with a new deny rule, or a spike in blocked outbound traffic may reveal a misconfigured service dependency. Logging gives you the timeline you need to connect those dots.

Start troubleshooting with the basics. Check the rule priority. Confirm the NSG is associated with the correct subnet or NIC. Verify the source and destination fields are not reversed. Review service tags, because a tag that seems broad may not cover the endpoint you expected. Also look for overlapping rules in both subnet and NIC scopes.

Common problem areas include default rules, missing return traffic, and asymmetric routing. A flow may leave successfully but fail on the return path if the outbound side is blocked. In more complex environments, traffic may travel through different paths on the way in and out, which makes NSG evaluation harder to reason about.

Maintaining a change log is one of the simplest ways to reduce troubleshooting time. Record who changed the rule, why it changed, when it changed, and what incident or request drove the update. That record helps you distinguish legitimate design changes from accidental drift. It also supports audits and post-incident reviews.

Microsoft explains NSG flow logging and monitoring options in NSG flow logs. Use that data to back up your assumptions with evidence.

Best Practices for Managing NSGs at Scale

Managing one NSG by hand is easy. Managing dozens across teams, subscriptions, and environments is not. The first best practice is to use infrastructure as code for deployment and updates. Bicep, ARM templates, or scripted PowerShell and CLI workflows help you standardize rule creation, reduce drift, and review changes before they reach production. Automation also makes rollback much easier.

Standardize rule naming and documentation. A rule named “Allow-HTTPS-Web-Tier” tells a future admin much more than “rule-12.” Include a short purpose statement and tag the NSG or resource group with environment, owner, and support contact information. That structure saves hours during incident response and security reviews.

Review rules on a schedule. Remove stale entries, duplicate rules, temporary exceptions, and broad allow statements that no longer have a business need. The longer a rule lives, the more likely it is to outlive the reason it was created. Periodic review is a core part of cloud security hygiene.

Governance tools help keep standards intact. Azure Policy can enforce baseline requirements, such as requiring tags, restricting public IP exposure, or flagging noncompliant configurations. Role-based access control is equally important. Not everyone should be able to modify NSGs in production, and not every engineer needs the same level of access.

• Deploy NSGs through code, not ad hoc portal clicks.
• Apply naming standards that describe intent.
• Review rules quarterly or after major changes.
• Use Azure Policy to reduce drift and enforce standards.
• Separate duties with role-based access control.

For governance and controls, Microsoft’s Azure Policy documentation and resource tagging guidance are worth following closely. Good NSG management is not just a technical task. It is an operational discipline.

Common Mistakes to Avoid in Azure NSG Setup

The most common mistake is using broad allow rules that expose sensitive ports to the internet. An open 22 or 3389 rule may look harmless during a test, but it becomes a standing risk if nobody closes it. If remote administration is required, restrict it to fixed trusted IPs, a VPN, or a bastion pattern.

Another frequent issue is confusing source and destination. In an inbound rule, the source is where traffic comes from and the destination is your protected workload. Mixing those up creates rules that look right in the portal but do nothing useful. This mistake is easy to make under time pressure.

Rule sprawl is another problem. When teams create one-off exceptions without ownership or expiration dates, NSGs become cluttered and fragile. You lose the ability to tell which rules are essential and which are leftovers from a past outage. At scale, that is a security and operations problem.

Outbound traffic is often ignored until it causes a failure. Applications need return-path traffic, update endpoints, package repositories, DNS, time synchronization, and monitoring destinations. If you block outbound traffic without mapping dependencies, the workload may break in non-obvious ways. That is why outbound testing should be part of every deployment.

Documentation is the last common miss. Every exception should have an owner and a reason. Future teams need to know whether a rule protects a business-critical service, supports a temporary migration, or exists only because of a historical workaround. Without that context, people are forced to guess, and guesswork is bad security.

Warning: If you cannot explain a rule during an audit or outage review, you probably should not keep it.

For additional guidance on common vulnerabilities and network filtering discipline, the CIS Benchmarks are a useful reference point for hardening and control design, even when you are not applying them directly to NSGs.

Conclusion

Azure NSGs give you a practical way to secure cloud workloads through controlled traffic filtering. They are not complicated on the surface, but they demand discipline in design, rule priority, scope, testing, and monitoring. A strong Azure NSG setup supports cloud security by limiting exposure, segmenting workloads, and making access rules understandable to the people who have to support them later.

The main lesson is simple: plan before you build, use least privilege, validate behavior from real source networks, and keep logs and governance in place after deployment. Subnet-level and NIC-level NSGs each have a place, but they work best when used intentionally. If you automate deployment, standardize naming, and review rules regularly, your network security posture becomes easier to defend and easier to operate.

Take a fresh look at your current Azure rules this week. Identify one overly broad allow rule, one missing outbound restriction, and one NSG that needs better documentation. Then tighten them with a small, controlled change and verify the result. For teams that want deeper, hands-on guidance, ITU Online IT Training can help you build the skills to design, test, and manage Azure security controls with confidence.

If your organization is expanding its Azure footprint, now is the time to turn NSG management into a repeatable practice instead of a series of one-off fixes. The payoff is lower risk, cleaner operations, and fewer surprises when traffic does not behave the way someone assumed it would.