Azure NSG: The Ultimate Guide to Network Security Groups (2025)

When you build in the cloud, you are building on a foundation of software-defined networking. This offers incredible flexibility, but it also means that securing your virtual infrastructure is fundamentally your responsibility. The primary tool Microsoft provides for this critical task, the very bedrock of network access control in its cloud, is the Azure NSG (Network Security Group). Think of your Azure Virtual Network as a building with many rooms; an NSG acts as the tireless, rule-based security guard posted at every door and in every hallway, meticulously checking the credentials of every packet of data that tries to enter or leave. Without mastering this tool, your cloud environment is an open door. This guide is designed to be your complete masterclass on the Azure NSG. We will deconstruct it from the ground up, explore its advanced features, uncover best practices forged from real-world experience, and reveal how to pair it with Application Security Groups to build a security posture that is not just robust, but also scalable and manageable.

The Universal Concept of Network Security Groups

Before diving into the specifics of Azure’s implementation, it’s crucial to understand the universal concept of Network Security Groups. In the context of any major cloud platform (be it Azure, AWS, or GCP), a network security group is a foundational service that acts as a virtual, stateful firewall for your virtual machines (VMs) and other resources. Its purpose is to control inbound and outbound network traffic based on a set of defined security rules.

At its core, it’s a packet filter. It inspects the metadata of each data packet—not the content itself—and decides whether to allow or deny it based on the rules you’ve configured.

Stateful vs. Stateless: The Key Difference

One of the most important characteristics of network security groups is that they are stateful. This is a critical distinction from older, more basic firewalls.

• A stateless firewall treats every single data packet as an independent event. If you want to allow a web server to respond to a user’s request, you need two separate rules: one for the user’s inbound request and another for the server’s outbound response.
• A stateful firewall, like an NSG, is smarter. It understands the context of a connection. If you create an inbound rule that allows a user to connect to your web server on port 443, the NSG automatically remembers that connection. It will then dynamically allow the return traffic from the web server back to the user without needing a separate outbound rule.

This stateful nature dramatically simplifies rule management and reduces the potential for misconfiguration.

The 5-Tuple: The Anatomy of a Security Rule

Every rule within a network security group is based on what is known as the “5-tuple.” This is the set of five properties that uniquely identifies a network connection:

1. Source IP Address: Where is the traffic coming from?
2. Source Port: Which port on the source machine is the traffic originating from?
3. Destination IP Address: Where is the traffic going?
4. Destination Port: Which port on the destination machine is the traffic targeting?
5. Protocol: What network protocol is being used (e.g., TCP, UDP, ICMP)?

A security rule essentially says, “If a packet matches these five criteria, then perform this action (Allow or Deny).”

How the Concept Varies Across Clouds

While the core concept is the same, the implementation and terminology differ slightly between the major cloud providers. Understanding these differences provides valuable context.

This foundational understanding of what network security groups are in a general sense allows us to appreciate the specific design choices and powerful features that Microsoft has built into its Azure-specific implementation.

Compare Cloud Security Features Across Top Providers

A Deep Dive into Network Security Groups in Azure

Now, let’s focus exclusively on the Azure ecosystem. Network Security Groups in Azure are the primary tool you will use to enforce and control network traffic flow between Azure resources, resources in your on-premises network, and the internet. They are a free service, though you are billed for the Azure resources they protect. An NSG is essentially a container for security rules that you can create and manage.

The Core Components of an Azure NSG

Every NSG is made up of a collection of security rules, which are divided into two categories:

• Inbound Security Rules: These rules control traffic coming into your resource. For example, allowing traffic from the internet to your web server on port 443 (HTTPS).
• Outbound Security Rules: These rules control traffic going out of your resource. For example, allowing your application server to connect to an Azure SQL database on port 1433, but blocking it from accessing the internet.

Each individual rule has a set of properties that you must define. Let’s break down each one.

Understanding the Unseen: Default NSG Rules

When you create a new NSG, it isn’t empty. Azure automatically populates it with a set of default rules. These rules are designed to ensure basic connectivity and follow a “secure-by-default” principle.

Default Inbound Rules:

• AllowVNetInBound (Priority 65000): Allows traffic originating from any IP address within the same virtual network.
• AllowAzureLoadBalancerInBound (Priority 65001): Allows health probes from Azure’s load balancer.
• DenyAllInBound (Priority 65500): A final “catch-all” rule that denies all other inbound traffic.

Default Outbound Rules:

• AllowVnetOutBound (Priority 65000): Allows traffic destined for any IP address within the same virtual network.
• AllowInternetOutBound (Priority 65001): Allows outbound traffic to the internet.
• DenyAllOutBound (Priority 65500): A final “catch-all” rule that denies all other outbound traffic.

Crucially, you cannot delete these default rules, but you can override them by creating new rules with a lower priority number. For example, to block all outbound internet access, you would create a new outbound rule with a priority of 4095 (or anything lower than 65001) that denies traffic to the Internet service tag.

Where to Apply NSGs: Subnet vs. NIC Association

An NSG on its own does nothing. It must be associated with an Azure resource to take effect. You have two options for association:

1. Subnet: You can associate an NSG with an entire subnet within your virtual network. When you do this, the rules in the NSG are applied to all resources (like VMs) within that subnet. This is ideal for creating broad, baseline security policies (e.g., a “Web Tier” subnet).
2. Network Interface (NIC): You can also associate an NSG directly with the network interface of a specific virtual machine. This allows you to create more granular, machine-specific rules.

You can even use both at the same time for a defense-in-depth strategy. A VM can be in a subnet that has an NSG, and its own NIC can also have a different NSG. We will explore how Azure processes rules in this complex scenario in the next section.

Mastering Azure Network Security Groups: Advanced Techniques

Understanding the basics is one thing; mastering Azure Network Security Groups requires a deeper understanding of their behavior, diagnostic tools, and the best practices that separate a secure, manageable environment from a chaotic one. This section is dedicated to those advanced techniques.

The Definitive Rule Processing Logic

This is one of the most important and often misunderstood aspects of NSGs. When a VM has both a Subnet NSG and a NIC NSG, how does Azure decide which rules to apply?

For Inbound Traffic:

1. Azure first evaluates the rules in the Subnet NSG. It checks the rules in priority order (lowest number first).
2. If it finds a matching rule with a Deny action, the packet is dropped, and processing stops immediately. The NIC NSG is never even checked.
3. If it finds a matching rule with an Allow action (or if no rule matches and it falls through to the default rules), the traffic is provisionally allowed, and processing continues.
4. Azure then evaluates the rules in the NIC NSG. It checks the rules in priority order.
5. If a matching rule with a Deny action is found, the packet is dropped.
6. Only if the traffic is allowed by both the Subnet NSG and the NIC NSG will it finally reach the virtual machine.

For Outbound Traffic:

The process is reversed.

1. Azure first evaluates the rules in the NIC NSG.
2. If a Deny rule matches, the traffic is dropped.
3. If allowed, Azure then evaluates the rules in the Subnet NSG.
4. If a Deny rule matches, the traffic is dropped.
5. Traffic must be allowed by both the NIC NSG and the Subnet NSG to leave the VM.

This creates a powerful layered security model but requires careful planning to avoid unintentional rule conflicts.

Leveraging Service Tags for Dynamic Rules

Manually managing lists of IP addresses for Azure services is a fragile and error-prone process. Microsoft solves this with Service Tags. A Service Tag is a label that represents a group of IP address prefixes for a specific Azure service. Microsoft manages the IP addresses within the tag, so your rules stay current automatically.

Practical Use Cases for Service Tags:

• Storage.WestUS2: Create an outbound rule to allow a VM to connect to any Azure Storage account in the West US 2 region, without needing to know the specific IP addresses.
• AzureKeyVault: Allow your application servers to securely access secrets and keys from Azure Key Vault.
• Internet: A convenient tag to represent all IP addresses outside of your virtual network.
• VirtualNetwork: A tag that represents all IP address space within your virtual network.

Using service tags makes your rules more readable, resilient, and significantly easier to manage.

NSG Best Practices for a Secure and Scalable Environment

1. Always Start with a Plan: Don’t create NSGs on the fly. Design your network topology, define your application tiers (e.g., web, business, data), and plan the required traffic flows before creating a single rule.
2. Embrace a Deny-by-Default (Zero Trust) Stance: While NSGs have a default deny, you should create your own explicit “Deny All” rules with a high priority number (e.g., 4090). Then, only add specific Allow rules with lower priorities for traffic you absolutely need.
3. Avoid Overly Permissive Rules: A rule that allows Any Source to Any Destination on Any Port is a massive security hole. Be as specific as possible.
4. Use Application Security Groups (ASGs): For any environment with more than a handful of VMs, stop managing rules by IP address. Use ASGs to group servers by role. This is so important, we’ve dedicated the next entire section to it.
5. Standardize Naming Conventions: Develop a clear and consistent naming standard for your NSGs (NSG-WebApp-Prod-01) and your rules (Allow-RDP-From-AdminNet).
6. Regularly Audit Your Rules: Use Azure Security Center and the “Effective security rules” view to periodically review what rules are actually being applied to your VMs. Remove any rules that are no longer needed.
7. Enable NSG Flow Logs: This is the most critical tool for diagnostics and monitoring. NSG Flow Logs record every single connection that is allowed or denied by your NSG. These logs can be sent to an Azure Storage Account and visualized with Azure Traffic Analytics, which can turn raw log data into a beautiful map of your network traffic. You could even use a silly marker like a “Gemini banana image” on the map to flag unexpected traffic from a specific country.

NSG vs. Azure Firewall: Choosing the Right Tool

NSGs are not the only network security tool in Azure. It’s important to know when to use an NSG and when to step up to a more powerful service like Azure Firewall.

The bottom line: Use NSGs for east-west traffic control (between VMs in your VNet) and basic north-south filtering. Use Azure Firewall when you need centralized, intelligent perimeter security for all your VNets. The two tools are designed to be used together.

Get a Free Azure Network Security Assessment

The Power of the Application Security Group in Azure

If you’ve ever managed NSG rules for a large environment using only IP addresses, you know the pain. Every time you add, remove, or replace a VM, you have to update a long list of IP addresses in your NSG rules. This is not just tedious; it’s a recipe for human error and security gaps. The Application Security Group Azure (ASG) is Microsoft’s elegant solution to this exact problem.

An ASG is not a security boundary itself. It’s best to think of it as a tag or a label. You create an ASG to represent a logical grouping of VMs that perform a similar function, like “web servers” or “domain controllers.” You then apply this tag to the network interfaces of the relevant VMs.

How ASGs Revolutionize NSG Rule Management: An Example

Let’s walk through a common three-tier application scenario to see the power of the Application Security Group Azure.

The Old Way (IP Addresses):

1. Deploy 10 web servers, each with a private IP.
2. Deploy 5 application servers, each with a private IP.
3. Deploy 2 database servers, each with a private IP.
4. In your NSG, you create a rule to allow traffic from the 10 web server IPs to the 5 application server IPs on port 8080.
5. You create another rule to allow traffic from the 5 application server IPs to the 2 database server IPs on port 1433.
6. Tomorrow, you add one more web server. You must now find and update the source IP list in your NSG rule.

The New Way (ASGs):

1. Create three ASGs: asg-web-tier, asg-app-tier, and asg-data-tier.
2. As you deploy your VMs, you associate the NIC of each web server with asg-web-tier, each app server with asg-app-tier, and each database server with asg-data-tier.
3. In your NSG, you create two simple, beautiful rules:
   • Rule 1: Source asg-web-tier -> Destination asg-app-tier -> Port 8080 -> Action Allow.
   • Rule 2: Source asg-app-tier -> Destination asg-data-tier -> Port 1433 -> Action Allow.
4. Tomorrow, you add one more web server. You simply associate its NIC with the asg-web-tier ASG. You do not touch the NSG at all. The rule applies automatically.

IP Address Management vs. Application Security Groups

This table clearly illustrates the operational benefits of adopting ASGs.

By decoupling the network policy (the NSG rule) from the network configuration (the IPs), ASGs make your security posture more agile, readable, and fundamentally more secure.

Learn More About Automating Azure Security with Policies

From Foundation to Fortress with Azure NSG

We have journeyed through the entire landscape of network traffic control in Azure, starting with the foundational concept of the Azure NSG. It is the essential, non-negotiable building block for securing any workload you run in Microsoft’s cloud. We’ve dissected its rules, decoded its processing logic, and laid out the critical best practices that distinguish a secure environment from a vulnerable one. More importantly, we’ve seen how to evolve beyond basic IP-based rules by leveraging the power of the Application Security Group Azure to create policies that are scalable, readable, and resilient to change. Mastering these tools is not merely an IT administration task; it is a core business competency. It enables you to build a secure, segmented, and Zero Trust-aligned network foundation upon which you can confidently build, innovate, and grow your business in the cloud.

Please leave this field empty

Join a community of forward-thinkers.

Your essential weekly briefing, backed by expert research.

We value your privacy. You can unsubscribe at any time! Take a look at our Privacy Policy for more info.

Thank you for subscribing! Check your inbox for your first briefing.