These core components form the foundation of how Azure Network Security Groups (NSGs) protect resources within a virtual network:

• Network Security Group (NSG): Acts as a virtual firewall at the subnet or network interface level, controlling inbound and outbound network traffic based on security rules.
• Security Rule: Specifies whether to allow or deny traffic based on parameters such as source/destination IP, port, and protocol. Each rule is prioritized and processed in order, with the first match being enforced.
• Priority: Each rule is assigned a numeric value (100–4096). Lower numbers denote higher priority, and rules are evaluated in ascending order.
• Default Rules: System-defined rules that provide basic network connectivity and security. These can be overridden by custom rules but ensure baseline protection.
• Direction: Indicates whether a rule applies to inbound (incoming) or outbound (outgoing) network traffic.
• NSG Association: NSGs can be linked to a subnet (affecting all resources within) or to individual network interfaces for granular control. Both levels can be used simultaneously—if so, both sets of rules are evaluated.
• Service Tags: Simplifies rule targeting using predefined groups (e.g., “Internet”, “VirtualNetwork”) to represent service-related IP ranges.
• Application Security Groups (ASGs): Allows grouping of virtual machine NICs for dynamic and simplified rule management that adapts to scaling and changes.

Azure Network Security Groups (NSGs) are flexible security tools used in a variety of real-world scenarios, including:

• Restricting Internet Access: Only allow specific IP addresses or ranges to access your resources by blocking unauthorized inbound or outbound internet traffic.
• Subnet Segmentation: Control communication between subnets in a virtual network to isolate sensitive workloads or limit lateral movement in case of a breach.
• Protecting Application Tiers: Ensure that only necessary traffic flows between web, application, and database tiers, enforcing least-privilege access at every layer.
• Enforcing Compliance and Security Policies: Implement organizational security requirements, such as blocking prohibited ports or restricting outbound connections to specific services.
• Temporary Access for Maintenance: Grant time-bound access to specific resources (e.g., for troubleshooting or updates) and then remove the rule when maintenance is complete.
• Controlling Outbound Egress: Limit which external endpoints or services your Azure resources can connect to, reducing the risk of data exfiltration.

Azure Network Security Groups (NSGs) protect network resources by filtering traffic with inbound and outbound security rules. Each rule determines whether specific network traffic is allowed or denied based on criteria like source, destination, port, and protocol.

• Inbound Rules: Control the traffic entering your Azure resources. For example, you can allow HTTP traffic (port 80) from the internet or block all other unsolicited inbound connections. Inbound rules usually protect applications by only permitting traffic from trusted sources.
• Outbound Rules: Manage the traffic leaving your resources to the rest of the internet, other subnets, or on-premises environments. For example, you might restrict virtual machines from reaching external services unless explicitly allowed.

Each rule includes these core fields:

Default NSG Rules Example

Azure NSGs come with default rules to ensure fundamental network behavior and security. For example:

• Inbound Default Rules:
  • Allow traffic within the same Virtual Network (AllowVNetInBound)
  • Allow traffic from Azure Load Balancer (AllowAzureLoadBalancerInBound)
  • Deny all other inbound traffic (DenyAllInbound)
• Outbound Default Rules:
  • Allow outbound traffic within the same Virtual Network (AllowVNetOutBound)
  • Allow outbound traffic to the Internet (AllowInternetOutBound)
  • Deny all other outbound traffic (DenyAllOutBound)

How Rule Processing Works

• Inbound rules on a subnet are processed first, then any rules on the network interface.
• Outbound rules are processed first at the network interface, then at the subnet level.
• Once a rule matches, evaluation stops and that action (allow or deny) is enforced.
• Default deny rules ensure security by blocking all traffic not explicitly allowed.

Customize rules by adding new rules with a lower priority (higher up in processing order) than the defaults, tailoring traffic flow to your needs. Default rules can't be deleted but can always be overridden by custom rules.

Each Network Security Group (NSG) rule in Azure is defined by a set of fields that determine how traffic is filtered. Here’s a concise structure showing the key properties of an NSG rule:

Sample: To allow HTTP traffic (port 80) from anywhere on the Internet to a specific VM:

Name:                Allow-HTTP-Inbound
Priority:            200
Source:              Internet
Source Port Range:   *
Destination:         10.0.1.4
Destination Port:    80
Protocol:            TCP
Direction:           Inbound
Action:              Allow
Description:         Permit HTTP traffic from Internet

Rules are enforced in ascending order of priority. Once a matching rule is found for the traffic, that action (allow or deny) is taken, and evaluation stops. Custom rules with lower priority values take precedence over the built-in default rules. Always ensure there are no overlapping rules with the same priority and direction in a single NSG[1][6].

Adhering to best practices in configuring Azure Network Security Groups (NSGs) maximizes your cloud security and network efficiency. Here are actionable recommendations:

• Adopt a Least Privilege Model: Only allow the traffic that is absolutely necessary. Deny all other inbound and outbound connections by default, and grant access as needed for specific ports, IP ranges, or protocols[8][5].
• Segment Networks Logically: Use NSGs at both the subnet and NIC level to isolate workloads and control internal traffic. Segregate critical workloads from less sensitive infrastructure for additional security layers[5][1].
• Avoid Broad Rules: Do not use overly permissive rules (such as large IP ranges or *Any*). Make your rules as specific as possible to limit exposure[8][5].
• Use Service Tags and Application Security Groups (ASGs): Simplify rule management by leveraging service tags (like VirtualNetwork, Internet) and group similar servers or application tiers with ASGs. This reduces management overhead and increases agility[7][8].
• Maintain Clear Naming Conventions: Use descriptive names for NSGs and rules (e.g., NSG-WebTier, Allow-HTTP-Inbound) to aid with ongoing management and auditing[8][7].
• Space Rule Priorities Wisely: Leave gaps between rule priorities (e.g., 100, 110, 120) so you can insert new rules later without a major overhaul[8][7].
• Regularly Review and Clean Up Rules: Periodically audit NSGs to retire obsolete rules, minimize configuration drift, and enforce updated security needs[2][1].
• Monitor with NSG Flow Logs and Alerts: Enable NSG flow logs and set up alerts for suspicious activities. Active monitoring helps detect anomalies and unauthorized access attempts[3][7].
• Automate Deployment and Governance: Use automation tools and infrastructure-as-code templates to manage NSGs at scale, ensuring standardized application of security controls across environments[7][1].
• Combine with Other Azure Security Tools: Use NSGs alongside Azure Firewall, Azure Bastion, and Azure Policy for comprehensive defense-in-depth and to ensure policy compliance across the cloud environment[1][4].

While Azure Network Security Groups (NSGs) are useful for controlling network traffic, they come with several limitations and are not suitable for every scenario:

• Layer 3 & 4 Filtering Only: NSGs operate only at the network (Layer 3) and transport (Layer 4) layers, so they cannot filter based on application content or perform deep packet inspection (Layer 7). For advanced threat protection, features like web filtering or application-layer controls, you’ll need to use Azure Firewall or a third-party security solution[1][8].
• Rule Capacity Limits: Each NSG can have a maximum of 1,000 rules, and a subscription can contain up to 5,000 NSGs. Rules cannot share the same priority and direction within the same NSG. There are additional limits for IP addresses, ports, and application security groups per rule[1][4][11].
• No Support for Domain Names: NSGs cannot specify Fully Qualified Domain Names (FQDNs) in security rules. Filtering can only be based on IP addresses, service tags, or application security groups[1][8].
• No Network Address Translation (NAT): NSGs do not provide source or destination NAT capabilities (SNAT/DNAT). NAT must be handled by other Azure resources like Azure Firewall or load balancers[1][8].
• No Threat Intelligence: NSGs do not offer built-in threat intelligence or automated blocking based on threat feeds; this requires Azure Firewall or other security tools[1][8].
• Basic Logging & Monitoring: While NSGs integrate with Azure Monitor, flow logs and traffic analysis are not enabled by default, and logging does not provide as much detail or correlation as advanced security solutions[1].
• No Payload Inspection: Rules are enforced only on IP, port, and protocol metadata. NSGs cannot examine the content of packets to enforce policies based on data patterns or applications[1][8].
• Augmented Rules Limitations: While augmented rules help reduce rule count, there are still limits on the combined number of addresses, ranges, and ports allowed per rule[5].
• Default Rules Cannot Be Deleted: Built-in default rules are always present and can only be overridden—not removed or modified directly[5].
• Stateful But Not Connection-Aware Beyond Five-Tuple: NSGs are stateful for new flows, but cannot enforce security policies based on application context or session behavior[1][8].