Apple Podcasts 
Spotify 
Youtube Music 
Spreaker 
Podchaser 
Amazon Music Azure Network Security Groups - Simply Explained
Azure Network Security Groups (NSGs) are one of the most important security features in Microsoft Azure, allowing you to control inbound and outbound network traffic for virtual machines, subnets, and other Azure resources. By defining security rules based on IP addresses, ports, and protocols, NSGs help protect workloads from unauthorized access while ensuring legitimate traffic can flow where it's needed.
In this episode of Microsoft Knowledge Nuggets, Mirko Peters explains Azure Network Security Groups in simple terms and shows why NSGs are a fundamental building block of every secure Azure environment. You'll learn how NSGs work, how traffic is evaluated, and how they help enforce network security without requiring additional infrastructure.
The episode covers key concepts including inbound and outbound rules, priorities, service tags, application security groups (ASGs), default security rules, stateful filtering, and subnet versus network interface associations. It also explains how NSGs integrate with Azure Virtual Networks, Azure Firewall, Load Balancer, VPN Gateway, Bastion, and other Azure networking services to create layered security architectures.
You'll also discover security best practices, common deployment scenarios, and the differences between NSGs and Azure Firewall. Understanding when to use simple network filtering and when to implement more advanced security controls is essential for building secure, scalable, and well-governed Azure environments.
Whether you're an Azure administrator, network engineer, cloud architect, or IT professional, this episode provides a practical introduction to Azure Network Security Groups. By the end, you'll understand how NSGs protect Azure resources, simplify network security management, and form a critical layer in Microsoft's cloud security model.
Quick answer: Azure Network Security Groups is covered in this M365 FM episode with a practical focus on what it is, how it works, and the decisions that matter for architecture, adoption, security, governance, or day-to-day operations.
Azure network security groups help you control traffic flowing in and out of your Azure resources. By using NSGs, you can reduce risks tied to misconfigurations and unauthorized access, which commonly threaten cloud environments. These network security groups allow you to segment traffic within your virtual networks, creating strong boundaries that protect your workloads. Azure’s security framework relies on NSGs to enforce access control and segmentation, which strengthens your overall cloud security posture.
Network security groups provide detailed control over network traffic, making them vital for maintaining a secure cloud environment.
Key Takeaways
- Azure Network Security Groups (NSGs) control traffic to and from Azure resources, enhancing security.
- NSGs allow you to set specific rules for inbound and outbound traffic, ensuring only necessary services are accessible.
- Applying NSGs to subnets or virtual machines creates strong security boundaries within your network.
- Use NSGs to implement a 'deny by default' approach, minimizing exposure to potential threats.
- Service Tags simplify NSG management by automatically updating IP address ranges for Azure services.
- Application Security Groups (ASGs) help organize resources based on roles, reducing the complexity of security rules.
- Enable NSG flow logs to monitor traffic patterns and detect potential security threats effectively.
- Regularly review and update NSG rules to align with your security needs and maintain a strong security posture.
What Are NSGs?
Definition and Purpose
Azure Network Security Groups (NSGs) are essential tools for managing network security within the Azure environment. They enable you to set and enforce rules that control both inbound and outbound network traffic at the level of subnets or individual virtual machines. This capability allows for precise control over network access, ensuring that only necessary services remain accessible. By doing so, NSGs enhance your overall security posture and help protect your resources from unauthorized access.
The primary purpose of NSGs is to filter network traffic between Azure resources in a Virtual Network (VNet). You can apply NSGs to subnets or directly to network interfaces of virtual machines. This flexibility allows you to create a layered security approach, ensuring that your workloads remain secure while still being accessible to legitimate users.
Key Components of NSGs
Understanding the key components of NSGs is crucial for effectively managing your network security. Here are the main elements that make up an Azure Network Security Group:
| Component | Description |
|---|---|
| Network Security Group | Used to filter network traffic between Azure resources in a VNet. |
| Security Rules | Allow or deny inbound and outbound network traffic based on specified criteria. |
| Subnet Application | Recommended to apply an NSG to each subnet, ensuring proper traffic management and security. |
NSGs contain security rules that allow or deny traffic at both the subnet and virtual machine levels within a VNet. This structure facilitates effective segmentation of virtual machines across different subnets. For instance, you can create a virtual network (VNet) to establish a network boundary for resources like VMs. Within this VNet, you can create subnets to further segment the network into smaller sub-networks.
By applying NSGs, you gain granular control over traffic flow between resources in your virtual network. They enable a 'deny by default, permit by exception' approach, which is crucial for isolating high-risk workloads. Additionally, Application Security Groups (ASGs) simplify the management of security rules by grouping virtual machines based on their roles.
Remember, NSGs are not just about blocking traffic; they also allow you to monitor and manage traffic effectively, ensuring that your Azure environment remains secure.
How NSGs Function
Azure Network Security Groups (NSGs) play a crucial role in controlling network traffic. They allow you to define specific rules that govern both inbound and outbound traffic to your Azure resources. Understanding how these rules work helps you maintain a secure environment.
Inbound and Outbound NSG Rules
NSGs consist of two main types of rules: inbound and outbound. Each type serves a distinct purpose in managing network traffic.
AllowVnetInbound Rule
The AllowVnetInbound rule permits traffic from other virtual networks (VNets) within Azure. This rule is essential for scenarios where resources need to communicate with each other securely. For example, if you have multiple virtual machines in different subnets, this rule allows them to exchange data without exposing them to the public internet.
DenyAllInbound Rule
The DenyAllInbound rule blocks all incoming traffic that does not match any other defined rules. This rule acts as a safety net, ensuring that only explicitly allowed traffic can reach your resources. By default, NSGs deny all inbound traffic unless you specify otherwise. This approach helps you minimize exposure to potential threats.
| Rule Type | Description |
|---|---|
| Inbound Rules | Control incoming traffic to Azure resources, allowing traffic from VNets and Azure load balancers while blocking all other incoming traffic. |
| Outbound Rules | Control outgoing traffic from Azure resources, allowing access to other virtual networks and the internet but denying everything else. |
Rule Priority and Evaluation
The priority of NSG rules significantly impacts how Azure evaluates and enforces them. Each rule has a priority number, with lower numbers indicating higher priority. When traffic matches multiple rules, Azure processes them in a top-down manner. The first rule that matches the traffic dictates the action taken. Once a match is found, Azure does not evaluate any further rules.
| Rule Type | Priority Level | Evaluation Order |
|---|---|---|
| Security Admin Rules | Higher | Evaluated first before NSG rules |
| Network Security Groups | Lower | Evaluated after security admin rules |
| Actions on Traffic | N/A | Allow, Always Allow, Deny |
This evaluation process ensures that critical security rules take precedence over others. For instance, if you have a rule that allows traffic from a specific IP address and another rule that denies all inbound traffic, the allow rule will take effect if it has a higher priority.
By understanding how NSGs function, you can effectively filter network traffic and enhance the security of your Azure resources. Properly configured NSGs help you create a robust security posture, ensuring that only legitimate traffic reaches your applications.
Related Concepts: Service Tags and ASGs
Understanding Service Tags
Service tags simplify the management of network security groups (NSGs) in Azure. They represent groups of IP address prefixes managed by Microsoft. By using service tags, you eliminate the need for manual tracking and updating of IP addresses for Azure services. This feature significantly reduces management complexity. Here are some key benefits of service tags:
- They automatically update when Azure service IP ranges change.
- They enable granular control over network traffic to and from Azure services.
- They help you maintain a secure environment without constant manual adjustments.
Common Azure services represented by service tags include:
| Tag | Purpose | Can use inbound or outbound? | Can be regional? | Can use with Azure Firewall? |
|---|---|---|---|---|
| ActionGroup | Action Group. | Inbound | No | Yes |
| ApiManagement | Management traffic for Azure API Management-dedicated deployments. | Inbound | Yes | Yes |
| ApplicationInsightsAvailability | Application Insights Availability. | Inbound | No | Yes |
| AppConfiguration | App Configuration. | Outbound | No | Yes |
| AppService | Azure App Service. Recommended for outbound security rules to web apps. | Outbound | Yes | Yes |
| AppServiceManagement | Management traffic for App Service Environment. | Both | No | Yes |
| AzureActiveDirectory | Microsoft Entra ID Services. | Outbound | No | Yes |
| AzureAdvancedThreatProtection | Microsoft Defender for Identity. | Outbound | No | Yes |
Application Security Groups (ASGs)
Application Security Groups (ASGs) enhance the management of network security by allowing you to group resources based on their application roles. This dynamic grouping simplifies security management and reduces administrative overhead. Here’s how ASGs work with NSGs:
- ASGs facilitate the grouping of virtual machines (VMs) based on workloads.
- They define security boundaries between application tiers.
- ASGs reduce the number of security rules needed and scale automatically.
The benefits of using ASGs in large-scale Azure deployments include:
| Benefit | Description |
|---|---|
| Operational Efficiency | ASGs lower the risk of outages during maintenance by reducing IP-related mistakes. |
| Security Posture | They support tighter segmentation, controlling access between application tiers. |
| Maintainability | ASGs allow for cleaner, more flexible network security rules. |
| Scalability | They help maintain concise security rules as environments grow. |
| Automation | ASGs fit well into automated deployment workflows. |
| Troubleshooting | They simplify troubleshooting by allowing teams to trace traffic by role. |
By leveraging service tags and ASGs, you can enhance your NSG configurations. These tools provide you with the flexibility and control needed to secure your Azure environment effectively.
Importance of NSG Flow Logs
Monitoring Traffic
Azure NSG flow logs play a vital role in monitoring network traffic. They provide you with detailed insights into the flow of data to and from your Azure resources. By enabling NSG flow logs, you can track which traffic is allowed or denied based on your defined security rules. This visibility helps you confirm network isolation and adherence to enterprise access regulations.
Here are some key benefits of using NSG flow logs for monitoring:
- Visibility: Flow logs give you a clear view of actual network traffic. This visibility helps you identify access patterns that may breach organizational policies.
- Compliance: Keeping records of network traffic is essential for meeting regulatory or legal obligations. Flow logs assist in demonstrating compliance with security standards.
- Threat Detection: Thorough monitoring of NSG traffic is crucial for ensuring network security. It helps you detect potential threats and verify the effectiveness of your NSG rules.
| Source | Evidence |
|---|---|
| Flow logging for network security groups | Flow data can be utilized to confirm network isolation and adherence to enterprise access regulations. |
| Understanding Azure Logs from a security perspective | Flow logs provide visibility into actual network traffic, which helps in identifying access patterns that may breach organizational policies. |
| What Are Network Security Groups (NSGs) in Azure? | Keeping records of network traffic is essential for meeting regulatory or legal obligations. |
| Cloud Network Security and Automation | Thorough monitoring of NSG traffic is crucial for ensuring network security, detecting potential threats, and verifying the effectiveness of NSG rules. |
Analyzing Traffic Patterns
Analyzing NSG flow logs allows you to identify unusual traffic patterns or potential security threats. By examining the data, you can spot anomalies that may indicate unauthorized access or other malicious activities. Here are some common types of anomalies to watch for:
| Type of Anomaly | Description |
|---|---|
| Unexpected Traffic | Detection of traffic from unknown IP addresses that may indicate unauthorized access attempts. |
| Sudden Data Transfer Spikes | Identifying unusual increases in data transfer that could signify data exfiltration attempts. |
| Repeated Failed Connection Attempts | Monitoring for multiple failed connection attempts that may suggest a brute-force attack. |
| Port Scanning | Recognizing multiple connection requests across different ports from a single IP address. |
| DDoS Indicators | Large volumes of inbound traffic from various IPs that may indicate a Distributed Denial of Service attack. |
| Unusual Geographic Access | Access attempts from locations where there are no legitimate users, indicating potential threats. |
| Malware C2 Communications | Repeated connections to known malicious IPs that could signify command and control activities. |
To maximize the effectiveness of your analysis, consider these best practices:
- Enable NSG flow logs on critical subnets to ensure auditing and security.
- Enable NSG flow logs on all network security groups attached to a resource to capture all traffic.
- Provision storage according to the expected volume of flow logs.
- Ensure network security group names are within character limits to avoid truncation.
By leveraging tools like Azure Traffic Analytics, you can visualize and interpret NSG flow log data effectively. This enables you to automate threat detection and configure alerts for high volumes of denied access attempts.
To visualize and query NSG flow logs within Microsoft Sentinel, configure diagnostic settings to stream logs into a Log Analytics Workspace connected to Sentinel.
With these insights, you can enhance your security posture and respond proactively to potential threats.
NSGs vs. Azure Firewall
When it comes to securing your Azure environment, both Azure Network Security Groups (NSGs) and Azure Firewall play important roles. However, they serve different purposes and have distinct functionalities. Understanding these differences helps you choose the right tool for your security needs.
Key Differences
| Feature/Functionality | Azure Firewall | Azure Network Security Group (NSG) |
|---|---|---|
| Type of Service | Managed, cloud-based network security service | Logical firewall service |
| Filtering Level | Stateful packet inspection, application-level protection | Network layer (Layer 4) filtering |
| Centralized Management | Yes, provides centralized security for all resources in a virtual network | No, operates on individual resources |
| Granular Application Filtering | Yes, allows for advanced application-level filtering | No, basic rules for inbound and outbound traffic |
| Threat Intelligence | Yes, includes threat intelligence-based filtering | No, does not provide advanced threat protection |
| Use Case | Suitable for larger deployments requiring advanced security features | Suitable for basic traffic filtering between resources |
| Combination Use | Works well with NSGs for multilayer security | Can be used alongside Azure Firewall for enhanced security |
Use Cases for Each
You might prefer NSGs in several scenarios. Here are some reasons to choose NSGs over Azure Firewall:
- NSGs are a cost-effective solution compared to Azure Firewall.
- They provide straightforward management, making them easier to administer for basic network security needs.
- NSGs are ideal for scenarios requiring granular control at the network level, allowing customized security configurations for individual virtual machines or subnets.
- They are a more budget-friendly option, making them suitable for straightforward network security needs.
- NSGs are preferred when the primary goal is to manage traffic allowance or restriction at the network layer.
On the other hand, Azure Firewall is better suited for more complex security requirements. Here are some scenarios where Azure Firewall excels:
- When you need centralized management for multiple resources across a virtual network.
- If your deployment requires advanced application-level filtering and threat intelligence.
- In hybrid architectures where you want to combine NSGs and Azure Firewall for multilayer security. For example, you can set up a hub-and-spoke model. The hub contains shared services like Azure Firewall, while spokes host workloads such as virtual machines. All traffic from spokes routes to the hub for inspection.
By understanding the differences and use cases for NSGs and Azure Firewall, you can make informed decisions about your Azure security strategy.
In summary, Azure Network Security Groups (NSGs) are vital for securing your cloud environment. They provide granular access control, enabling you to manage traffic flow effectively. With features like micro-segmentation and integration with private endpoints, NSGs enhance your security posture.
To maximize their effectiveness, consider these strategies:
- Regularly review NSG rules to align with your security needs.
- Ensure secure configurations of your Virtual Networks (VNets).
- Integrate Azure Firewall with NSGs for layered security.
By implementing these practices, you can strengthen your Azure security strategy and protect your resources from potential threats.
Remember, a proactive approach to managing NSGs can significantly reduce risks and improve your overall cloud security.
FAQ
What is an Azure Network Security Group (NSG)?
An Azure Network Security Group (NSG) is a tool that filters network traffic to and from Azure resources. You can apply NSGs to subnets or individual virtual machines for enhanced security.
How do I create an NSG?
You can create an NSG through the Azure portal, Azure CLI, or Azure PowerShell. Simply navigate to the "Network Security Groups" section and follow the prompts to set up your rules.
Can I apply multiple NSGs to a single resource?
Yes, you can associate multiple NSGs with a single resource. However, the effective rules will depend on the priority of each NSG's rules.
What happens if there are conflicting rules in NSGs?
Azure evaluates NSG rules based on priority. The first matching rule takes precedence. If two rules conflict, the one with the higher priority (lower number) will apply.
How do NSGs enhance security?
NSGs enhance security by allowing you to define specific inbound and outbound traffic rules. This control helps prevent unauthorized access and reduces the risk of attacks on your resources.
Can I monitor NSG traffic?
Yes, you can monitor NSG traffic using flow logs. These logs provide insights into allowed and denied traffic, helping you analyze patterns and detect potential threats.
Are NSGs free to use?
Yes, NSGs are free to use. However, you may incur costs for data transfer and other Azure resources associated with your NSG configurations.
How do NSGs work with Azure Firewall?
NSGs and Azure Firewall complement each other. Use NSGs for basic traffic filtering and Azure Firewall for advanced security features like threat intelligence and centralized management.
🎧 Listen to this episode
Want a practical explanation of Azure Network Security Groups? This episode breaks down the topic in clear language and shows why it matters for Microsoft 365, Azure, Power Platform, security, AI, and modern work.
Listen to this episode if you want to:
- Understand the key concepts behind Azure Network Security Groups
- See how it fits into the wider Microsoft technology ecosystem
- Learn where it can create practical value for your organization
You may also enjoy these related M365 FM episodes:
- Dataverse Security - Simply Explained
- Azure Virtual Network - Simply Explained
- Microsoft Security Copilot - Simply Explained
- Zero Trust AI Security with Microsoft Copilot and Azure – Mourtaza Fazlehoussen [MVP]
- Microsoft Graph Security Automation for Microsoft 365
Discover more practical Microsoft conversations on M365 FM.
Last reviewed: July 2026.
Who Should Listen
This episode is for Microsoft 365 administrators, architects, IT leaders, and practitioners who need a practical understanding of Azure Network Security Groups before planning, implementing, or supporting it.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:04,200
Welcome to another episode of Microsoft Knowledge Nuggets here on M365, FM, I'm Milko
2
00:00:04,200 --> 00:00:05,200
Peters your host.
3
00:00:05,200 --> 00:00:09,100
Today's topic is one almost everyone has heard of, but not everyone fully understands.
4
00:00:09,100 --> 00:00:12,000
As your network security groups, imagine you just moved into a new house.
5
00:00:12,000 --> 00:00:15,400
You have doors, windows and a garage, but you forgot to lock the front door.
6
00:00:15,400 --> 00:00:17,400
That's your Azure VM without an NSG.
7
00:00:17,400 --> 00:00:20,900
By the end of this episode, you'll understand what NSGs are, how their rules work and the
8
00:00:20,900 --> 00:00:23,900
common mistakes that leave your cloudhouse wide open.
9
00:00:23,900 --> 00:00:27,200
We'll walk through the problem first, then the solution, how the rules work, the gotchas
10
00:00:27,200 --> 00:00:29,400
and the best practices, all in plain English.
11
00:00:29,400 --> 00:00:31,000
So why do you even need an NSG?
12
00:00:31,000 --> 00:00:32,800
Let's dive into the problem.
13
00:00:32,800 --> 00:00:33,800
The problem.
14
00:00:33,800 --> 00:00:36,000
Why your Azure VMs need protection?
15
00:00:36,000 --> 00:00:38,800
Here's the thing that catches most beginners off guard.
16
00:00:38,800 --> 00:00:43,400
By default, an Azure VM with a public IP can receive traffic from the internet on any port,
17
00:00:43,400 --> 00:00:47,600
unless you tell it otherwise, which means spinning up a VM with a public IP is like standing
18
00:00:47,600 --> 00:00:51,800
at the curb, waving a sign that says, "Come on in, 20 years ago you'd lock a physical
19
00:00:51,800 --> 00:00:55,900
server behind a hardware firewall, but in Azure you have to lock down ports manually one
20
00:00:55,900 --> 00:01:00,500
by one." And most beginners skip that step, which is exactly how breaches happen.
21
00:01:00,500 --> 00:01:04,600
Microsoft built some default protections into the platform, attach an NSG to a resource
22
00:01:04,600 --> 00:01:06,700
and it comes with a few default rules.
23
00:01:06,700 --> 00:01:11,200
Allow all traffic within the virtual network, allow a zero load balancer health probes and
24
00:01:11,200 --> 00:01:13,700
deny everything else inbound from the internet.
25
00:01:13,700 --> 00:01:14,700
Those defaults are solid.
26
00:01:14,700 --> 00:01:17,860
They block inbound traffic from the outside world by default.
27
00:01:17,860 --> 00:01:19,140
But here's the real problem.
28
00:01:19,140 --> 00:01:22,700
Many people override these defaults or forget to attach an NSG altogether.
29
00:01:22,700 --> 00:01:27,740
They open port 3389 for RDP from any because they want to remote in from a coffee shop or
30
00:01:27,740 --> 00:01:32,340
they leave port 22 open for SSH because they'll lock it down later and later never comes.
31
00:01:32,340 --> 00:01:34,420
This happens more often than you think.
32
00:01:34,420 --> 00:01:38,540
Overly permissive inbound rules are the top cause of Azure security incidents and it's
33
00:01:38,540 --> 00:01:42,100
not a sophisticated zero day exploit or a platform floor.
34
00:01:42,100 --> 00:01:44,380
It's someone leaving the front door unlocked.
35
00:01:44,380 --> 00:01:46,540
That's exactly where network security groups come in.
36
00:01:46,540 --> 00:01:48,940
Think of them as your personal balancer at the door.
37
00:01:48,940 --> 00:01:51,420
What is an Azure network security group?
38
00:01:51,420 --> 00:01:54,900
Come to another episode of Microsoft Knowledge Nuggets here on M365 FM.
39
00:01:54,900 --> 00:01:56,380
I'm your host, Mirko Peters.
40
00:01:56,380 --> 00:02:00,500
Today we're breaking down Azure network security groups or NSGs for short and by the end of
41
00:02:00,500 --> 00:02:03,340
this episode you'll understand what they actually do and why they matter.
42
00:02:03,340 --> 00:02:04,660
So what exactly is an NSG?
43
00:02:04,660 --> 00:02:05,820
Here's the simplest definition.
44
00:02:05,820 --> 00:02:09,260
An NSG is a collection of rules that controls what traffic can flow in and out of your
45
00:02:09,260 --> 00:02:10,260
Azure resources.
46
00:02:10,260 --> 00:02:14,340
It works at layers three and four of the network model, which means it looks at IP addresses,
47
00:02:14,340 --> 00:02:17,620
ports and protocols without digging into the actual content of the traffic.
48
00:02:17,620 --> 00:02:19,980
It only checks the envelope, not what's inside.
49
00:02:19,980 --> 00:02:21,740
Think of it like a bouncer at a club.
50
00:02:21,740 --> 00:02:24,660
You walk up to the door with your IP address as your ID.
51
00:02:24,660 --> 00:02:28,180
The bouncer checks where you're coming from, then asks what you want to do and that's where
52
00:02:28,180 --> 00:02:29,180
the port number comes in.
53
00:02:29,180 --> 00:02:31,580
Are you here to dance on port 80 for web traffic?
54
00:02:31,580 --> 00:02:35,540
Or are you trying to cause trouble on port 3389 for remote desktop?
55
00:02:35,540 --> 00:02:39,260
Based on that check, the bouncer makes the call allow or deny.
56
00:02:39,260 --> 00:02:41,340
Now here's something that surprises most people.
57
00:02:41,340 --> 00:02:42,420
NSGs are stateful.
58
00:02:42,420 --> 00:02:43,420
What does that mean?
59
00:02:43,420 --> 00:02:48,380
If you allow inbound traffic on port 80, the reply traffic goes back out automatically.
60
00:02:48,380 --> 00:02:51,780
You don't need a separate outbound rule for the response because the NSG remembers that
61
00:02:51,780 --> 00:02:54,500
connection and lets the return traffic through.
62
00:02:54,500 --> 00:02:57,780
Compared to traditional firewalls where you'd write rules for both directions, that's
63
00:02:57,780 --> 00:02:58,780
a huge time saver.
64
00:02:58,780 --> 00:03:00,380
Where do NSGs actually live?
65
00:03:00,380 --> 00:03:04,500
You can apply them at two levels, the subnet level or directly to a VM's network interface
66
00:03:04,500 --> 00:03:06,660
card, which is the NIC.
67
00:03:06,660 --> 00:03:08,540
Subnet level is the recommended approach.
68
00:03:08,540 --> 00:03:12,700
One NSG per subnet protects every VM inside it, so it's cleaner and easier to manage without
69
00:03:12,700 --> 00:03:14,580
worrying about individual machines.
70
00:03:14,580 --> 00:03:17,940
You attach the NSG to the subnet and every VM in that subnet inherits those rules
71
00:03:17,940 --> 00:03:18,940
automatically.
72
00:03:18,940 --> 00:03:23,740
NIC level is for special cases where you have two VMs in the same subnet that need different
73
00:03:23,740 --> 00:03:24,740
rules.
74
00:03:24,740 --> 00:03:28,540
Say one is a web server that needs port 80 open and the other is a database server that
75
00:03:28,540 --> 00:03:30,220
should only talk to the web server.
76
00:03:30,220 --> 00:03:35,580
In that case, you'd apply an NSG directly to the database VM's NIC for extra restrictions
77
00:03:35,580 --> 00:03:36,940
on top of the subnet rules.
78
00:03:36,940 --> 00:03:37,940
Here's the best part.
79
00:03:37,940 --> 00:03:39,140
NSGs are completely free.
80
00:03:39,140 --> 00:03:42,100
No extra cost, no per rule fees, no association charges.
81
00:03:42,100 --> 00:03:45,220
That's why they're the first line of defense in Azure and there's really no excuse not
82
00:03:45,220 --> 00:03:46,220
to use them.
83
00:03:46,220 --> 00:03:48,740
Let's open the hood and see how the rules actually work.
84
00:03:48,740 --> 00:03:50,860
How NSG rules work?
85
00:03:50,860 --> 00:03:53,980
Priority allow, deny and defaults.
86
00:03:53,980 --> 00:03:58,740
Every NSG has two sets of rules, inbound and outbound and those rules get processed in
87
00:03:58,740 --> 00:04:00,740
a very specific order.
88
00:04:00,740 --> 00:04:04,860
Priority numbers start low for highest priority and go up, so a rule at priority 100 gets checked
89
00:04:04,860 --> 00:04:06,940
before a rule at priority 200.
90
00:04:06,940 --> 00:04:08,940
The first rule that matches the traffic wins.
91
00:04:08,940 --> 00:04:10,620
If it's an allow, the traffic passes through.
92
00:04:10,620 --> 00:04:14,220
If it's a deny, it gets blocked and no further rules are checked after that.
93
00:04:14,220 --> 00:04:16,340
So the order of your rules matters tremendously.
94
00:04:16,340 --> 00:04:18,780
Now every NSG comes with default rules baked in.
95
00:04:18,780 --> 00:04:20,220
You get three inbound rules.
96
00:04:20,220 --> 00:04:21,420
Allow vnet inbound.
97
00:04:21,420 --> 00:04:24,780
Let's traffic from inside your virtual network, talk to each other.
98
00:04:24,780 --> 00:04:26,660
Allow as your load balancer inbound.
99
00:04:26,660 --> 00:04:30,660
Let's the as your load balancer send health probes to your VMs and deny all inbound blocks
100
00:04:30,660 --> 00:04:32,100
everything else from the outside.
101
00:04:32,100 --> 00:04:36,060
On the outbound side you get allow net outbound, allow internet outbound and deny
102
00:04:36,060 --> 00:04:37,180
all outbound.
103
00:04:37,180 --> 00:04:39,100
These all sit at very high priorities.
104
00:04:39,100 --> 00:04:42,300
65,000, 65,000, 1,6,500.
105
00:04:42,300 --> 00:04:45,860
You cannot delete these default rules because they're baked into the system, but you can
106
00:04:45,860 --> 00:04:50,140
override them with custom rules that have a higher priority meaning a lower number.
107
00:04:50,140 --> 00:04:54,380
So if you want to allow RDP traffic from the internet, you create a custom rule at priority
108
00:04:54,380 --> 00:04:59,300
100 that allows port 3389 and because that rule gets checked before the default deny,
109
00:04:59,300 --> 00:05:00,980
the traffic passes through.
110
00:05:00,980 --> 00:05:05,500
The custom rule priority range goes from 100 to 4296 and here's a practical tip.
111
00:05:05,500 --> 00:05:07,140
Leave gaps between your priorities.
112
00:05:07,140 --> 00:05:11,780
Use 100, 200, 300 instead of 100 and 102.
113
00:05:11,780 --> 00:05:16,420
If you need to insert a new rule later, you can slide it in at 150 without re-numbering
114
00:05:16,420 --> 00:05:17,420
everything.
115
00:05:17,420 --> 00:05:19,940
It's a small habit that saves a lot of headache down the road.
116
00:05:19,940 --> 00:05:23,820
Each rule has several components, source and source port, define where the traffic is coming
117
00:05:23,820 --> 00:05:27,420
from, destination and destination port define where it's going.
118
00:05:27,420 --> 00:05:30,020
Protocol specifies TCP, UDP or any.
119
00:05:30,020 --> 00:05:31,820
Action is allow or deny.
120
00:05:31,820 --> 00:05:34,380
Priority determines where it sits in the evaluation order.
121
00:05:34,380 --> 00:05:36,060
And a name so you can identify what it does.
122
00:05:36,060 --> 00:05:39,740
Now one feature that makes NSG's really powerful is service tags.
123
00:05:39,740 --> 00:05:43,460
These are convenient labels that represent groups of IP addresses.
124
00:05:43,460 --> 00:05:47,900
Instead of trying to remember every IP range Azure uses for service, you just use the tag
125
00:05:47,900 --> 00:05:51,860
like internet, virtual network, Azure load balancer or storage.
126
00:05:51,860 --> 00:05:52,860
West US.
127
00:05:52,860 --> 00:05:56,980
Microsoft manages the IP ranges behind those tags, so you don't have to track changes.
128
00:05:56,980 --> 00:06:00,900
If Azure adds new IP addresses for service, the tag updates automatically.
129
00:06:00,900 --> 00:06:04,460
And then there are application security groups or ASGs for short.
130
00:06:04,460 --> 00:06:08,740
These let your group VMs logically instead of writing rules with individual IP addresses.
131
00:06:08,740 --> 00:06:13,700
You create an ASG called web servers, add those VMs to it and write one rule that says,
132
00:06:13,700 --> 00:06:15,900
allow traffic from web servers.
133
00:06:15,900 --> 00:06:20,220
If you add more web servers later, they just join the ASG and the existing rule already covers
134
00:06:20,220 --> 00:06:21,940
them with no updates needed.
135
00:06:21,940 --> 00:06:23,780
Great for scaling.
136
00:06:23,780 --> 00:06:27,420
That covers the theory, but here's where most people run into problems.
137
00:06:27,420 --> 00:06:29,500
Common misconfigurations and beginner mistakes.
138
00:06:29,500 --> 00:06:31,340
So here's the thing about network security groups.
139
00:06:31,340 --> 00:06:33,460
I see the same six mistakes all the time.
140
00:06:33,460 --> 00:06:35,020
And these aren't just small errors.
141
00:06:35,020 --> 00:06:38,060
The number one cause of Azure breaches isn't some advanced exploit.
142
00:06:38,060 --> 00:06:40,540
Simple misconfigurations.
143
00:06:40,540 --> 00:06:41,940
Let's break down the first one.
144
00:06:41,940 --> 00:06:47,860
Allowing traffic from any or internet to sensitive ports, RDP on port 3389 SSH on 22 SQL
145
00:06:47,860 --> 00:06:49,380
on 1,33.
146
00:06:49,380 --> 00:06:54,540
Someone spins up a virtual machine, once remote access, so they open port 3389 to the whole
147
00:06:54,540 --> 00:06:56,900
world, thinking they'll change it later.
148
00:06:56,900 --> 00:07:00,420
Attackers can find that VM in about 15 minutes instead always restrict source IPs to
149
00:07:00,420 --> 00:07:03,140
trusted ranges like your office IP or your VPN.
150
00:07:03,140 --> 00:07:04,500
Never the entire internet.
151
00:07:04,500 --> 00:07:06,900
Another common mistake is forgetting about outbound rules.
152
00:07:06,900 --> 00:07:09,780
The default outbound rule lets all internet traffic through.
153
00:07:09,780 --> 00:07:14,420
That means if a VM inside your network gets compromised, it can call home, download malware
154
00:07:14,420 --> 00:07:15,780
and X-Filtrate data.
155
00:07:15,780 --> 00:07:19,340
The NSG won't stop it because the default says allow outbound.
156
00:07:19,340 --> 00:07:22,860
For sensitive subnets, add outbound deny rules and only allow traffic to the specific
157
00:07:22,860 --> 00:07:24,980
destinations your application actually needs.
158
00:07:24,980 --> 00:07:29,260
Then there's the issue of applying NSGs at the NEC level when you should use the subnet
159
00:07:29,260 --> 00:07:30,260
level.
160
00:07:30,260 --> 00:07:31,260
This creates a management nightmare.
161
00:07:31,260 --> 00:07:35,020
You end up with 20 different NSGs, each with slightly different rules and nobody remembers
162
00:07:35,020 --> 00:07:38,140
which VM has which NSG stick to one NSG per subnet.
163
00:07:38,140 --> 00:07:40,940
Apply it once and every VM in that subnet is protected.
164
00:07:40,940 --> 00:07:43,780
Use NEC level NSGs sparingly for exceptions.
165
00:07:43,780 --> 00:07:47,420
Another mistake is not using application security groups or service tags.
166
00:07:47,420 --> 00:07:49,540
Hard coding IP addresses makes your rules brittle.
167
00:07:49,540 --> 00:07:53,500
If a VM moves to a different subnet or gets recreated, it's IP changes and your rule
168
00:07:53,500 --> 00:07:54,500
breaks.
169
00:07:54,500 --> 00:07:55,940
ASGs keep it flexible.
170
00:07:55,940 --> 00:08:00,180
Group VMs by function, write one rule against the ASG and you're done.
171
00:08:00,180 --> 00:08:02,860
Service tags do the same for Azure services, use them both.
172
00:08:02,860 --> 00:08:04,980
And don't forget to test with effective rules.
173
00:08:04,980 --> 00:08:08,860
The Azure portal has a feature called effective security rules that shows you the combined
174
00:08:08,860 --> 00:08:11,380
result of subnet and NEC NSGs.
175
00:08:11,380 --> 00:08:14,420
It's the single most useful troubleshooting tool for NSGs.
176
00:08:14,420 --> 00:08:16,460
Always check it before assuming traffic will flow.
177
00:08:16,460 --> 00:08:20,260
You'd be surprised how often that deny rule at the subnet level blocks traffic that
178
00:08:20,260 --> 00:08:21,900
the NIC rule allows.
179
00:08:21,900 --> 00:08:24,540
Finally, opening port ranges to wide.
180
00:08:24,540 --> 00:08:30,140
Instead of allowing port 3389 from any, allow it only from your office IP.
181
00:08:30,140 --> 00:08:35,900
Instead of opening ports 1 through 65535, open only the specific ports your application needs,
182
00:08:35,900 --> 00:08:38,020
the narrower the range, the smaller the attack surface.
183
00:08:38,020 --> 00:08:39,500
So how do you avoid these mistakes?
184
00:08:39,500 --> 00:08:41,500
Let's talk best practices.
185
00:08:41,500 --> 00:08:43,620
Best practices for NSG rule management.
186
00:08:43,620 --> 00:08:45,620
Here's the most important principle.
187
00:08:45,620 --> 00:08:46,620
Least privilege.
188
00:08:46,620 --> 00:08:48,340
Only allow what's needed nothing more.
189
00:08:48,340 --> 00:08:51,980
Start with a deny all posture and open specific ports to specific sources.
190
00:08:51,980 --> 00:08:54,260
Don't open everything and try to lock it down later.
191
00:08:54,260 --> 00:08:55,420
That never works.
192
00:08:55,420 --> 00:08:58,220
Another best practice is to use ASGs and service tags.
193
00:08:58,220 --> 00:08:59,580
Group your VMs by function.
194
00:08:59,580 --> 00:09:04,460
App servers in one ASG, application servers in another, database servers in a third, then
195
00:09:04,460 --> 00:09:06,500
write your NSG rules against those groups.
196
00:09:06,500 --> 00:09:12,140
The web ASG talks to the app ASG on port 443 and the app ASG talks to the database ASG
197
00:09:12,140 --> 00:09:13,740
on port 1433.
198
00:09:13,740 --> 00:09:18,460
When you add more web servers later, they join the web ASG and the rules already cover them.
199
00:09:18,460 --> 00:09:19,980
No need to update anything.
200
00:09:19,980 --> 00:09:21,140
And document your rules.
201
00:09:21,140 --> 00:09:24,100
Each rule should have a meaningful name and description.
202
00:09:24,100 --> 00:09:26,220
Allow RDP from office IP is a good name.
203
00:09:26,220 --> 00:09:27,340
Rule one is not.
204
00:09:27,340 --> 00:09:31,340
One else should be able to look at your NSG and understand why each rule exists.
205
00:09:31,340 --> 00:09:32,980
That someone might be used six months from now.
206
00:09:32,980 --> 00:09:34,620
Apply NSGs at the subnet level.
207
00:09:34,620 --> 00:09:35,620
One NSG per subnet.
208
00:09:35,620 --> 00:09:40,500
If you need per VM exceptions, combine a subnet NSG with a unique NSG, but always test the
209
00:09:40,500 --> 00:09:43,660
effective rules in the portal to see the combined result.
210
00:09:43,660 --> 00:09:45,020
Enable NSG flow logs.
211
00:09:45,020 --> 00:09:46,980
These capture traffic that's allowed or denied.
212
00:09:46,980 --> 00:09:51,420
Send them to a storage account or log analytics for monitoring and troubleshooting.
213
00:09:51,420 --> 00:09:52,420
One important note.
214
00:09:52,420 --> 00:09:55,140
New NSG flow log creation ends June 2025.
215
00:09:55,140 --> 00:09:58,060
After that, use virtual network flow logs instead.
216
00:09:58,060 --> 00:09:59,420
Regularly review your rules.
217
00:09:59,420 --> 00:10:03,260
Ordered for overly permissive or unused rules and removed them.
218
00:10:03,260 --> 00:10:06,220
Attackers love stale rules that someone forgot to clean up.
219
00:10:06,220 --> 00:10:08,860
And one more thing, don't apply NSGs to gateway subnets.
220
00:10:08,860 --> 00:10:13,900
If you have a subnet used for VPN or express route gateways, don't attach an NSG to it.
221
00:10:13,900 --> 00:10:16,100
It's unsupported and breaks connectivity.
222
00:10:16,100 --> 00:10:18,660
But wait, isn't Azure Firewall a thing?
223
00:10:18,660 --> 00:10:19,660
How does NSG compare?
224
00:10:19,660 --> 00:10:21,620
We'll cover that in another episode.
225
00:10:21,620 --> 00:10:24,980
NSG vs Azure Firewall went to use each.
226
00:10:24,980 --> 00:10:28,940
You might be wondering if NSGs are so great, why does Azure Firewall exist?
227
00:10:28,940 --> 00:10:30,420
And when should you pick one over the other?
228
00:10:30,420 --> 00:10:32,860
Imagine this, and NSG is the front door bouncer.
229
00:10:32,860 --> 00:10:36,780
It checks your ID, looks at what you want to do, and decides whether to let you in or keep
230
00:10:36,780 --> 00:10:37,780
you out.
231
00:10:37,780 --> 00:10:42,300
Azure Firewall is the full security team with cameras, metal detectors, and the whole package.
232
00:10:42,300 --> 00:10:43,300
Here's the thing.
233
00:10:43,300 --> 00:10:44,300
NSGs are free.
234
00:10:44,300 --> 00:10:49,220
They work at layers three and four, filtering based on IP addresses, ports, and protocols.
235
00:10:49,220 --> 00:10:52,500
Because they're distributed, you apply them per subnet or per ennick, which makes them
236
00:10:52,500 --> 00:10:54,220
perfect for basic filtering.
237
00:10:54,220 --> 00:10:58,580
If you just need to say, allow web traffic on port 80 from the internet or block RDP from
238
00:10:58,580 --> 00:10:59,580
outside.
239
00:10:59,580 --> 00:11:00,900
And NSG is all you need.
240
00:11:00,900 --> 00:11:06,220
Azure Firewall is a paid service at about 1.25 per hour plus data processing costs.
241
00:11:06,220 --> 00:11:09,060
It's centralized, so you deploy it once and route traffic through it.
242
00:11:09,060 --> 00:11:13,540
It works at layers three through seven, which means it can inspect packets deeply.
243
00:11:13,540 --> 00:11:17,940
Instead of allowing traffic to any IP on port 443, you can allow traffic to pomadeys,
244
00:11:17,940 --> 00:11:21,980
sunmicrosoft.com only because it filters by fully qualified domain names.
245
00:11:21,980 --> 00:11:27,380
It can also do TLS inspection, decrypting traffic to check what's inside, plus intrusion detection
246
00:11:27,380 --> 00:11:28,460
and prevention.
247
00:11:28,460 --> 00:11:32,700
And it uses threat intelligence feeds to block known malicious IPs and domains.
248
00:11:32,700 --> 00:11:34,140
So when do you use each one?
249
00:11:34,140 --> 00:11:37,220
For most beginners and small deployments, NSGs are sufficient.
250
00:11:37,220 --> 00:11:40,820
You have 102 v-nets, a handful of subnets, and you just need to control who can talk to
251
00:11:40,820 --> 00:11:41,820
what?
252
00:11:41,820 --> 00:11:42,820
And NSG handles that perfectly.
253
00:11:42,820 --> 00:11:47,060
As you grow, you add Azure Firewall when you have multiple v-nets that need to talk
254
00:11:47,060 --> 00:11:50,620
to each other, workloads that need controlled internet access.
255
00:11:50,620 --> 00:11:53,020
And you need centralized logging and auditing.
256
00:11:53,020 --> 00:11:54,500
That's when Azure Firewall makes sense.
257
00:11:54,500 --> 00:11:56,700
The real value comes from using both together.
258
00:11:56,700 --> 00:12:00,940
NSG at the subnet level handles basic segmentation, while Azure Firewall at the hub manages
259
00:12:00,940 --> 00:12:03,100
cross-finet and internet traffic inspection.
260
00:12:03,100 --> 00:12:04,100
That's defense in depth.
261
00:12:04,100 --> 00:12:08,460
The NSG handles the simple stuff and the firewall handles the complex stuff.
262
00:12:08,460 --> 00:12:11,300
Let's see all this in action with a quick walkthrough.
263
00:12:11,300 --> 00:12:13,900
Quick walkthrough, creating and applying an NSG.
264
00:12:13,900 --> 00:12:16,340
Let me walk you through creating an NSG in the Azure portal.
265
00:12:16,340 --> 00:12:19,260
It's straight forward and you'll have it done in under five minutes.
266
00:12:19,260 --> 00:12:23,820
Go to the Azure portal, search for network security groups and click Create.
267
00:12:23,820 --> 00:12:27,500
Choose your subscription, resource group, and the region where your v-net lives, then give
268
00:12:27,500 --> 00:12:32,420
it a descriptive name like NSG Web Subnet, not NSG1 or Test.
269
00:12:32,420 --> 00:12:34,820
You'll thank yourself later.
270
00:12:34,820 --> 00:12:39,460
Once it's created, go to Inbound Security Rules and click Add to create your first rule.
271
00:12:39,460 --> 00:12:43,740
For the source, select the internet service tag, which means traffic from anywhere on the
272
00:12:43,740 --> 00:12:44,740
internet.
273
00:12:44,740 --> 00:12:48,380
Leave the destination as any because this NSG applies to the whole subnet.
274
00:12:48,380 --> 00:12:53,860
For the service, select HTTP and HTTPS, which opens ports 80 and 4.43.
275
00:12:53,860 --> 00:13:00,180
Set the priority to 100, name it something like Allow HTTPS internet and click Add.
276
00:13:00,180 --> 00:13:04,740
Now add a second rule for RDP, but notice you're not going to open it to the internet.
277
00:13:04,740 --> 00:13:09,420
For the source, select IP addresses and enter your office IP or your home IP if you're
278
00:13:09,420 --> 00:13:10,420
remote.
279
00:13:10,420 --> 00:13:15,780
For the service, select RDP on port 3389, set the priority to 200, name it Allow RDP Office
280
00:13:15,780 --> 00:13:17,300
IP and click Add.
281
00:13:17,300 --> 00:13:19,300
Just associate this NSG with a subnet.
282
00:13:19,300 --> 00:13:23,540
Go to the Subnet tab, click Associate, select your virtual network and the subnet you want
283
00:13:23,540 --> 00:13:24,540
to protect.
284
00:13:24,540 --> 00:13:26,980
In this case, your web subnet and click OK.
285
00:13:26,980 --> 00:13:27,980
That's it.
286
00:13:27,980 --> 00:13:30,500
Every VM in that subnet is now protected by these rules.
287
00:13:30,500 --> 00:13:33,740
If you want to take it a step further, create an application security group called web
288
00:13:33,740 --> 00:13:38,380
servers, add your web VMs to it, then go back to your NSG rule and change the destination
289
00:13:38,380 --> 00:13:40,500
from any to that ASG.
290
00:13:40,500 --> 00:13:43,780
Now the rule only applies to those specific VMs, not the whole subnet.
291
00:13:43,780 --> 00:13:45,220
It's clean and flexible.
292
00:13:45,220 --> 00:13:48,500
Before you assume everything is working, check the effective security rules.
293
00:13:48,500 --> 00:13:52,100
Go to any VM in the subnet, click on Networking, then Effective Security Rules.
294
00:13:52,100 --> 00:13:56,180
You'll see the combined result of your subnet NSG and any NIC level NSGs.
295
00:13:56,180 --> 00:13:57,580
This is your single source of truth.
296
00:13:57,580 --> 00:14:00,220
If traffic isn't flowing, this is where you'll find out why.
297
00:14:00,220 --> 00:14:01,220
That's it.
298
00:14:01,220 --> 00:14:02,980
Simple, powerful and free.
299
00:14:02,980 --> 00:14:03,980
So there you have it.
300
00:14:03,980 --> 00:14:06,620
NSGs are your first line of defense in Azure.
301
00:14:06,620 --> 00:14:08,780
Think of them as a bouncer for your virtual machines.
302
00:14:08,780 --> 00:14:10,740
They control who gets in and who gets out.
303
00:14:10,740 --> 00:14:12,460
Stick with subnet level NSGs.
304
00:14:12,460 --> 00:14:16,660
Also the principle of least privilege, use ASGs and service tags and avoid those common
305
00:14:16,660 --> 00:14:20,940
mistakes we covered, especially opening sensitive ports to the whole internet.
306
00:14:20,940 --> 00:14:24,740
If this helped, subscribe for more Azure Knowledge Nuggets and share this episode with someone
307
00:14:24,740 --> 00:14:26,140
just starting their cloud journey.
308
00:14:26,140 --> 00:14:27,340
They'll thank you later.
309
00:14:27,340 --> 00:14:29,060
Don't leave your front door unlocked.
310
00:14:29,060 --> 00:14:30,220
Apply an NSG today.
Founder of m365.fm, m365.show and m365con.net
Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.
Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.
With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.
