What Is Network Security Group in Networking?

Imagine you are organizing a big party at a rented hall. The hall has several rooms, and each room can be entered through a door. You want to control who goes where so that only the right guests get into the right rooms.

A Network Security Group is like a bouncer standing at the door of each room. The bouncer has a list of rules written on a clipboard. One rule might say that anyone from your family is allowed into the main room, but strangers are stopped at the door.

Another rule might say that guests can leave through the back door only if they have a special exit pass. In the cloud world, your hall is your Azure environment. Each room is a virtual machine or a subnet (a group of machines).

The bouncer (the NSG) checks every single piece of traffic that tries to enter or leave that room. The traffic could be a web request coming from the internet to your website, or a file copy going from one server to another. The bouncer does not check the actual data inside the traffic – it only looks at the envelope: who sent it (the source IP address), where it is going (the destination IP address and port), what type of transport it uses (TCP or UDP), and the direction (inbound or outbound).

If the traffic matches an allow rule, it is let through. If it matches a deny rule, it is blocked. If there is no matching rule at all, the bouncer uses a default rule that blocks inbound traffic and allows outbound traffic.

This default behavior prevents accidental exposure of your resources to the internet. You can think of the clipboard as having two pages: one for inbound rules and one for outbound rules. Each rule has a priority number.

The smaller the number, the higher the priority. The bouncer checks rules in order from top to bottom, and the first rule that matches decides the action. If no rule matches, the default rule kicks in.

This system gives you fine-grained control over network traffic without needing to manage physical hardware firewalls.

A Network Security Group (NSG) is a fundamental Azure networking component that acts as a distributed stateful firewall. It filters traffic at the network layer (Layer 3 and Layer 4 of the OSI model) by inspecting source and destination IP addresses, port numbers, and protocol types (TCP, UDP, or ICMP). NSGs are applied either to a virtual network subnet or to a network interface card (NIC) of a virtual machine. When applied to a subnet, the NSG rules affect all resources within that subnet. When applied to a NIC, the rules affect only that specific virtual machine.

Every Azure NSG contains two sets of rules: inbound security rules and outbound security rules. Each rule includes the following properties: name, priority (a number between 100 and 4096, lower is higher priority), source or destination IP address range (expressed as an IP prefix, CIDR block, service tag, or application security group), protocol (TCP, UDP, or Any), direction (Inbound or Outbound), action (Allow or Deny), and an optional description. Traffic is evaluated against rules in priority order. Once a rule match is found, evaluation stops and the specified action is applied. If no rule matches, the default rule for that direction is used. The default inbound rule denies all traffic, and the default outbound rule allows all traffic. These defaults can be overridden by creating custom rules with appropriate priority.

NSGs are stateful. This means that if you allow inbound traffic on a port, the NSG automatically allows the return outbound traffic for that connection, even if no explicit outbound rule exists. Conversely, if you allow outbound traffic, the return inbound traffic is allowed. Statefulness is tracked per flow; once the connection is terminated, the flow is removed. This simplifies rule management because you do not need to create symmetric rules for response traffic.

In addition to IP-based rules, NSGs support service tags. A service tag is a predefined group of IP address prefixes from a specific Azure service, such as AzureLoadBalancer, Internet, or VirtualNetwork. Using service tags makes rules easier to maintain and reduces the risk of misconfiguration. For example, you can create an outbound rule that allows traffic to the Azure SQL Database service without needing to track the constantly changing IP ranges of Azure SQL.

Another advanced feature is Application Security Groups (ASGs). With ASGs, you can group virtual machines by application function (e.g., WebServers, DatabaseServers) and then create NSG rules based on these logical groups. This allows you to define security policies that follow the application architecture, not just the network topology. For instance, you can create a rule that only allows traffic from the WebServers ASG to the DatabaseServers ASG on port 1433 (SQL) without having to maintain individual IP addresses.

NSGs do not inspect the contents of the packet (Layer 7). They only look at the packet header. For deeper inspection (such as malware scanning, intrusion detection, or URL filtering), you would need additional services like Azure Firewall or a third-party network virtual appliance. NSGs are also free of charge, but they are subject to Azure limits (e.g., up to 1000 rules per NSG, up to 200 NSGs per subscription).

When you create a virtual machine in Azure, you are often prompted to either create a new NSG or select an existing one. The portal creates a default NSG that allows inbound RDP (port 3389) for Windows or SSH (port 22) for Linux, and denies all other inbound traffic. Outbound traffic is allowed by default. This default behavior is suitable for initial development but is too permissive for production. In production, you would harden the rules to allow only specific inbound ports (e.g., 80 and 443 for web servers) and restrict outbound traffic based on business needs.

Operationally, NSG rules are evaluated by the Azure host running the virtual machine, not by a central device. This distributed design ensures no single point of failure and reduces latency. However, it also means that network logs must be enabled separately via Network Security Group flow logs, which can be sent to Azure Monitor for analysis. These logs record allowed and denied flows and are essential for security auditing and troubleshooting.

Network Security Groups are one of the most basic yet powerful security controls in Azure. They provide the first line of defense against unauthorized network access. Without an NSG, any resource in Azure that is assigned a public IP could be directly accessible from the internet on any port, which is a severe security risk. NSGs enable you to implement the principle of least privilege at the network level: you allow only the traffic that is explicitly needed for the application to function, and deny everything else.

In practical IT operations, NSGs are used to isolate environments. For example, you can place your development VMs in a subnet that has an NSG allowing only internal traffic, while your production web servers are in a separate subnet with an NSG that allows inbound HTTP and HTTPS from the internet. NSGs also help with compliance requirements such as PCI DSS, HIPAA, or SOC 2, where you must demonstrate controlled network access.

Another reason NSGs matter is cost. They are free to use, unlike Azure Firewall which incurs hourly costs. For many small to medium workloads, well-configured NSGs provide adequate security. They also integrate with Azure Policy, so you can enforce that every subnet has an NSG attached, ensuring baseline security across your entire subscription.

Finally, NSGs are essential for troubleshooting network connectivity issues. When a virtual machine cannot connect to the internet or is unreachable, the first thing you check is whether the NSG has a rule blocking the traffic. NSG flow logs can show you exactly which rule allowed or denied a packet, saving hours of debugging.

Exam questions about Network Security Groups typically fall into three categories: configuration, scenario, and troubleshooting.

Configuration questions ask you to select the correct properties for a rule. For example: "You need to allow HTTP traffic from the internet to a virtual machine. Which source port, destination port, protocol, and action should you use?" The correct answer would be source port: Any, destination port: 80, protocol: TCP, action: Allow. A common distractor is to set the source port to 80, but that is incorrect because the source port is ephemeral.

Scenario questions describe a business requirement and ask which solution to implement. For example: "Your company has a three-tier application running in Azure. Web servers must be accessible from the internet on port 443. Application servers must only accept traffic from the web servers. Database servers must only accept traffic from the application servers. What is the most efficient way to configure NSGs?" The answer often involves using Application Security Groups: create an ASG for each tier, then create NSG rules referencing those ASGs.

Troubleshooting questions present a connectivity problem. For instance: "Users cannot access the web server at its public IP address. The VM is running, and the web service is started. The subnet has an NSG that allows inbound HTTP from the internet. What is the most likely cause?" The answer could be that the VM's NIC also has an NSG that denies HTTP. You must remember that traffic is evaluated by both the subnet NSG and the NIC NSG, and the most restrictive applies.

Another pattern involves default rules and priority. A question might state: "You create a custom inbound rule with priority 200 that denies all traffic from a specific IP range. You also have a default rule that allows all traffic from the virtual network. Traffic from that specific IP range is allowed. Why?" The answer is that the default rule has a priority of 65000, but the custom rule has a higher priority, so the custom rule should win. Actually, the correct reasoning might be that the custom rule deny is higher priority, so the traffic should be denied. The trap is that learners might think defaults override custom rules, but the opposite is true as long as the custom rule priority is lower (more specific).

You may also see questions about statefulness: "You allow inbound traffic on port 3389 from your office IP. Do you need to create an outbound rule for the response traffic?" The answer is no, because NSGs are stateful.

Let us dive deeper into how NSGs work in practice. When you create an Azure virtual machine, the platform automatically suggests creating an NSG. This default NSG allows inbound RDP (port 3389) for Windows or SSH (port 22) for Linux from the internet. While convenient for testing, this is a major security hole if left unchanged. A real-world professional would modify these rules immediately.

First, understand the rule evaluation process. Imagine you have a web server that needs to serve HTTPS on port 443. You create a rule: Priority 100, Source: Any, Source Port: Any, Destination: VM IP, Destination Port: 443, Protocol: TCP, Action: Allow. Then you create a second rule: Priority 200, Source: Any, Source Port: Any, Destination: Any, Destination Port: Any, Protocol: Any, Action: Deny. This works: HTTPS traffic matches rule 100 and is allowed. Everything else matches rule 200 and is denied. But what if you also need SSH for administration from a specific office IP (say 203.0.113.50)? You would add a rule with Priority 150 that allows traffic from 203.0.113.50 to port 22. Because 150 is lower than 200, the SSH rule is evaluated before the global deny. Traffic from the office IP matches rule 150 and is allowed. Traffic from other IPs to port 22 fails to match rules 100 or 150, then matches rule 200 and is denied.

Now consider a common advanced scenario: outbound restriction. A database server should not initiate connections to the internet. By default, outbound traffic is allowed. You need to create a custom outbound rule with a low priority that denies all outbound traffic to the internet. However, you must still allow outbound traffic to Azure services like DNS (port 53) or Azure AD. To do this, you can create a high-priority allow rule for the VirtualNetwork service tag and the Azure-specific service tags before the deny rule.

Another practical aspect is that NSG rules support not only individual IPs but also IP ranges and CIDR blocks. For example, you can allow your entire corporate IP range (10.0.0.0/8) on multiple ports. But careful: large ranges can be too permissive. Use the principle of least privilege.

One common mistake in practice is forgetting that NSGs do not filter traffic between resources in the same subnet unless you also apply an NSG to the NIC. The subnet NSG does not filter traffic within the subnet by default. To isolate VMs within a subnet, you must apply NSGs to each NIC.

Finally, keep in mind the Azure resource limits. An NSG can have up to 1000 rules (500 inbound, 500 outbound). If you need more granularity, consider using ASGs to group rules, or split into multiple NSGs across subnets. Also, you cannot change the name of an NSG after creation, but you can update rules at any time without downtime.

In production, use Infrastructure as Code (IaC) tools like Azure Resource Manager templates, Terraform, or Bicep to define NSGs. This ensures consistency and allows version control. For example, a Bicep file can define an NSG with rules, then reference it in the subnet resource. This makes deployments repeatable and auditable.

Network Security Groups in Azure, or NSGs, are a core component of virtual network security and operate based on a specific and critical rule evaluation order. Understanding this order is essential for passing the AZ-104, Azure Fundamentals, and SC-900 exams, and it frequently appears in AWS SAA discussions as a contrast to AWS Security Groups. In Azure, an NSG contains a set of security rules that are evaluated in priority order. Each rule is assigned a numeric priority value, ranging from 100 to 4096, where a lower number indicates higher priority. When Azure processes network traffic entering or leaving a subnet or a network interface, it starts with the rule that has the lowest priority number and continues until it finds a match. Once a match is found, the specified action, either Allow or Deny, is applied immediately, and no further rules are evaluated. This is a key difference from some other cloud platforms where deny rules are evaluated first.

For example, suppose you have a rule with priority 100 that allows all inbound traffic from the internet to port 80, and another rule with priority 200 that denies inbound traffic from a specific IP range to any port. If traffic arrives from that specific IP range destined for port 80, the rule at priority 100 is checked first. Because that rule allows all inbound traffic from the internet, it matches, and the traffic is permitted. The deny rule at priority 200 is never reached. This demonstrates that the default-deny or explicit deny rules cannot override a higher-priority allow rule. This is a common source of misconfiguration and a frequent exam trap. The exam tests this by presenting scenarios where a deny rule seems to be in place but traffic is still flowing because an earlier allow rule with a lower priority number exists.

there are default Azure rules that are automatically created for every NSG. These include rules like AllowVnetInBound, AllowAzureLoadBalancerInBound, and DenyAllInbound, and similar outbound rules. These default rules have high priority numbers, such as 65000 and 65500, meaning they are evaluated last. They are designed to be overridden by custom rules. For instance, if you have no custom rule allowing SSH traffic, the DenyAllInbound rule will block it. Exam questions often ask about the priority order and how to ensure a specific traffic flow is allowed or denied. You must also remember that NSG rules are stateful. This means that if you allow inbound traffic from a specific source, the return traffic from the destination is automatically allowed, regardless of outbound rules. This stateful behavior is critical for scenarios involving RDP, SSH, or any two-way communication.

In exam contexts, especially for the Security+ and CySA+ exams, you might see questions that combine NSG rule evaluation with network segmentation or zero-trust models. The key takeaway is that priority numbers must be meticulously planned. A common best practice is to use incremental numbers like 100, 200, 300 to allow for future insertion. Avoid leaving large gaps unless you have a clear plan. The exam will test your ability to debug traffic issues by examining the priority order and identifying that a lower-priority rule should be assigned a lower number to be evaluated first. Another nuance is that NSG rules can be associated at the subnet level or the NIC level. When both are applied, the rules are evaluated in order but the subnet-level NSG is evaluated first, then the NIC-level NSG. This layered approach can sometimes cause unexpected denials if rules conflict. Exams, particularly the AZ-104, love to ask about this layered evaluation and how to troubleshoot traffic that is unexpectedly blocked or allowed. Understanding this evaluation order is not just theoretical; it is a practical skill for designing secure networks in Azure and is a recurring theme in certification exams across the board, including the CISSP where network security architecture is a key domain.

Network Security Group flow logs are a powerful feature in Azure that allows administrators and security engineers to capture information about IP traffic flowing through a network security group. This is a critical topic for the AZ-104, SC-900, and especially for the Security+ and CySA+ exams, which emphasize monitoring and logging. NSG flow logs provide insight into which rules are being hit, what traffic is allowed or denied, and the volume of traffic. They are part of Azure Network Watcher and are essential for troubleshooting connectivity issues, auditing network security, and meeting compliance requirements. When a connection fails or behaves unexpectedly, flow logs can show whether the traffic was denied by an NSG rule or if it was allowed but something else blocked it, such as a firewall or application-level issue.

For example, if a user complains they cannot RDP into a virtual machine, you can enable NSG flow logs on the NSG associated with the VM's subnet or NIC. After a few minutes, you can query the logs to see if inbound RDP traffic (port 3389) was allowed or denied. If the logs show that traffic was denied, you know the NSG is the culprit. If the logs show that traffic was allowed, you must look elsewhere, such as the guest OS firewall or the application itself. This diagnostic capability is a frequent exam question topic, where candidates must understand how to enable flow logs, interpret the output, and troubleshoot connectivity problems. The logs include source and destination IP addresses, ports, protocol, and the action taken (Allow or Deny). They also include the rule ID that matched the traffic, enabling you to pinpoint exactly which rule is affecting your traffic.

Enabling NSG flow logs is done through the Azure portal, PowerShell, or CLI. The logs are stored in an Azure Storage Account, sent to Azure Monitor Logs, or streamed to Event Hubs for real-time analysis. For exam purposes, you should know that flow logs have a cost associated with storage and data processing, so they are not enabled by default. The exam might ask you to recommend a solution for auditing traffic, and you should choose NSG flow logs over simpler metrics. Flow logs can be analyzed using Traffic Analytics, a feature within Network Watcher that provides a visual map of traffic flows, identifies top talkers, and detects anomalies. For the Security+ and CySA+ exams, this is related to security monitoring and incident response.

Another diagnostic tool closely related to NSGs is the Network Watcher IP flow verify. This tool allows you to test a specific traffic flow between a source and destination, and it will tell you whether the traffic is allowed or denied by the NSG, along with which rule took the action. This is faster than enabling flow logs and is ideal for ad-hoc troubleshooting. The AZ-104 exam often tests this by asking you to use IP Flow Verify to check if a specific connection is blocked. For instance, you can specify source IP 10.0.0.4, destination IP 10.0.1.5, port 443, protocol TCP, and the tool will simulate the traffic and return the result. This eliminates the guesswork involved in manually tracing rule priorities.

A common troubleshooting scenario involves traffic that is intermittently blocked. Flow logs can reveal if certain packets are being dropped due to asymmetric routing or if a rule is incorrectly configured to deny traffic from a specific subnet. For the CISSP and AWS SAA exams, you might compare this to VPC Flow Logs in AWS, but the underlying concept remains the same: centralized logging of network traffic for security analysis. Always remember that flow logs must be enabled per NSG, not per virtual machine, and that there is a limit on the number of flow logs you can have per region. The exam will also test your knowledge of log retention: by default, flow logs are stored for a configurable period, and if you don't set a retention policy, they are stored indefinitely, incurring costs. Mastering NSG flow logs and IP Flow Verify is crucial for passing network troubleshooting questions on Azure-related certifications and for demonstrating practical diagnostic skills in any cloud security role.

Azure Network Security Groups come with a set of default rules that are automatically created when you create an NSG. These rules are designed to provide baseline security while still allowing necessary internal traffic. Understanding these default rules, along with service tags, is a frequent and high-weight topic in exams such as AZ-104, Azure Fundamentals, SC-900, and even the AWS SAA when comparing cloud network security models. The default inbound rules include: AllowVnetInBound, which allows all traffic from within the virtual network; AllowAzureLoadBalancerInBound, which allows traffic from the Azure load balancer health probe; and DenyAllInbound, which blocks all other inbound traffic. The default outbound rules are similar: AllowVnetOutBound, AllowInternetOutBound, and DenyAllOutbound. These rules have priority values of 65000, 65001, and 65500, respectively. Because they have high priority numbers, they are evaluated last, meaning custom rules with lower priority numbers will take precedence.

Exam questions often test your ability to modify or supplement these rules. For example, if you want to allow SSH from the internet, you would create a custom inbound rule with priority 100 that allows TCP 22 from the Internet service tag. This custom rule will be evaluated before the DenyAllInbound rule, allowing SSH. Without that custom rule, SSH would be blocked by the default DenyAllInbound rule. The exam also tests the behavior of the AllowVnetInBound rule: it permits all traffic between virtual networks that are peered or connected via VPN, as long as the traffic originates from within the Azure backbone. This is crucial for multi-tier application architectures where a web tier needs to communicate with a database tier.

Service tags are another critical concept related to NSGs. A service tag represents a group of IP address prefixes from a specific Azure service, such as AzureLoadBalancer, VirtualNetwork, Internet, Sql, Storage, etc. When you create an NSG rule, you can use a service tag as the source or destination instead of specifying individual IP ranges. This simplifies rule creation and management, and ensures that when Azure adds or removes IP addresses for that service, the rule automatically updates. For example, to allow a virtual machine to access Azure SQL Database, you would create an outbound rule with destination service tag Sql. The exam loves to test service tags in scenario-based questions. For instance, they might ask: 'You need to ensure that only traffic from Azure Load Balancer can reach your virtual machines. Which source service tag should you use?' The answer is AzureLoadBalancer, not Internet. This is a trick because many candidates think the load balancer uses the Internet, but it uses its own service tag.

Another common exam scenario involves allowing traffic from a specific Azure service while blocking all other inbound traffic. You would create a deny-all custom rule with a low priority, then create an allow rule with an even lower priority for the specific service tag. But because of the rule evaluation order, you must be careful: if you create a custom deny rule with priority 200, and then an allow rule for the service tag with priority 100, the allow rule wins. If you reverse the priorities, the deny rule would block the service. Exams test this nuance heavily.

For the Security+ and CySA+ exams, understanding default rules is part of network security hardening. The default rules are not inherently secure if you allow all outbound internet traffic by default via the AllowInternetOutBound rule. Many security policies require you to modify this rule to deny outbound traffic by default and only allow specific destinations. This is a common exam question: 'How would you restrict outbound traffic from a subnet to only the internet? You would either change the default outbound rule or add a custom deny rule with a lower priority that blocks all outbound traffic except for a specific service tag or IP range.'

Finally, the CISSP exam might ask about the principle of least privilege as it applies to NSG rules. Default rules like AllowVnetInBound violate least privilege if you want to restrict internal east-west traffic. In such a case, you would need to create a custom deny rule that blocks traffic between subnets, allowing only specific flows. This requires careful priority management. Mastering default rules and service tags is non-negotiable for Azure certification exams and serves as a solid foundation for understanding cross-platform network security concepts.

While Network Security Groups are a free resource in Azure in the sense that there is no additional charge for the NSG itself, there are associated costs and performance considerations that are critical for exam success, especially for AZ-104, Azure Fundamentals, and SC-900. The primary cost indirectly related to NSGs is the cost of NSG flow logs. Enabling flow logs incurs charges for data storage in Azure Storage Accounts and for data processing when using Traffic Analytics. For the exam, you need to know that while NSGs themselves are free, the diagnostic and monitoring features are not. A common exam question might ask you to recommend a cost-optimized solution for auditing network traffic. You would need to balance between enabling flow logs for all NSGs (which can become expensive) and selectively enabling them for critical subnets only.

Performance considerations are equally important. NSGs are a software-defined network layer that apply rules to traffic flow. In general, NSGs do not introduce significant latency because they are implemented at the Azure hypervisor level using hardware acceleration. However, there are limits. Each NSG can support up to 1000 rules (combined inbound and outbound). For the exam, you should know that having too many rules, especially complex rules with many IP ranges, can impact performance, though it is often negligible. A more critical performance impact comes from the number of flows. Each NSG can handle a certain number of flows per second. If you exceed these limits, packets may be dropped. The exam might present a scenario where a high-traffic application experiences packet loss, and you must determine if the NSG is the bottleneck. In practice, NSGs scale well, but for extremely high-throughput workloads, you might consider using Azure Firewall or a third-party NVA for more advanced filtering.

Best practices for NSG configuration are a major theme in all Azure-related certifications and are also relevant for the Security+ and CISSP for general network security principles. First, always use the principle of least privilege. This means you should only allow traffic that is explicitly required, and deny all other traffic. A common mistake is to create overly permissive rules like 'Allow all inbound from any source to any port'. This defeats the purpose of an NSG. Second, use service tags whenever possible instead of IP ranges. Service tags are automatically managed by Azure, reducing administrative overhead and the risk of misconfiguration. For example, use the 'Sql' service tag instead of a list of IP addresses for Azure SQL. Third, plan your rule priority numbers carefully. Use gaps such as 100, 200, 300 to allow inserting new rules later without renumbering. Many exam questions test this by giving you a set of rules with priorities 100, 110, 120 and asking what happens when you add a new rule at priority 105.

Fourth, always consider layered security. An NSG at the subnet level provides a common security boundary for all resources in that subnet, while an NSG at the NIC level provides more granular control for individual VMs. Both can be applied simultaneously, and the subnet NSG is evaluated first, then the NIC NSG. This is a frequent exam scenario: a VM is not reachable even though the subnet NSG allows traffic, because the NIC NSG denies it. Troubleshooting this requires checking both layers. Fifth, document your rules and audit them regularly. Use Azure Policy to enforce compliant NSG configurations, such as ensuring no rules allow all inbound traffic from the internet. For the SC-900 exam, this aligns with governance and compliance concepts.

Another best practice is to use application security groups, or ASGs, to simplify rule management. ASGs allow you to group virtual machines logically (e.g., 'WebServers', 'DatabaseServers') and then create NSG rules based on those groups instead of individual IP addresses. This is highly exam relevant for AZ-104 and SC-900. For example, you can create a rule that says 'Allow inbound traffic from WebServers to DatabaseServers on port 1433'. This simplifies security management and scales well as you add more VMs. The exam tests your understanding of when to use ASGs versus IP-based rules. Always remember that NSGs are stateful. You do not need to create return flow rules; the return traffic is automatically allowed. This is a common trick in exam questions where they present a scenario requiring you to create both inbound and outbound rules, but the outbound rule is unnecessary because of statefulness. Understanding these best practices will not only help you pass exams but also design secure, efficient, and cost-effective network architectures in Azure.