Traffic Filtering and Boundary Defense in Azure Virtual Networks
Securing workloads across cloud architectures requires strict control over how data enters and leaves virtual networks. An Azure Network Security Group (NSG) serves as a stateful, layer 4 virtual firewall that filters traffic to and from resources inside an Azure Virtual Network (VNet). Site Reliability Engineers (SREs) rely on NSGs to enforce micro-segmentation, protect sensitive backend systems, and prevent unauthorized east-west or north-south traffic traversal.
Core Architectural Mechanics and Rule Evaluation
NSGs evaluate traffic using deterministic parameters to ensure that only expected connections reach target endpoints:
- 5-Tuple Rule Structure: Every rule filters traffic based on five criteria: source IP/CIDR, source port, destination IP/CIDR, destination port, and protocol (TCP, UDP, or ICMP).
- Priority-Based Processing: Rules execute sequentially based on assigned priority numbers from 100 to 4096. Lower numbers hold higher priority; once traffic matches a rule, evaluation stops immediately.
- Stateful Filtering: NSG rules track connection states. If an inbound packet is permitted, the return outbound traffic is automatically allowed regardless of outbound security rules (and vice versa).
- Association Granularity: NSGs can bind directly to an entire subnet (applying rules to all contained resources) or attach directly to an individual Virtual Machine’s Network Interface Card (NIC) for granular endpoint protection.
Management Simplification via Service Tags and ASGs
Managing individual IP addresses across expanding cloud deployments quickly becomes unsustainable. Azure provides two native abstractions to simplify NSG rule sets:
- Service Tags: Predefined labels representing categories of IP addresses managed directly by Microsoft (such as
AzureLoadBalancer, Storage, or Internet). Using service tags prevents rule sprawl and eliminates the need to manually update rule IPs when cloud service ranges shift.
- Application Security Groups (ASGs): Allows engineers to group virtual machines based on their application roles (e.g.,
ASG-Web or ASG-Database). SREs write declarative security rules targeting the ASG rather than tracking dynamic VM IP addresses, making auto-scaling operations seamless.
Operational Considerations for Reliability Engineers
Misconfigured network security controls represent a leading source of unexpected outages and dropped connections. Reliability teams adopt specific operational practices to maintain stability:
- Dual-Layer Evaluation Awareness: When an NSG is attached to both a subnet and a NIC, inbound traffic must pass the subnet NSG first, followed by the NIC NSG. For outbound traffic, the NIC NSG evaluates first, followed by the subnet NSG. A deny rule at either level immediately drops the packet.
- Overriding Default Rules: NSGs deploy with immutable default rules (such as allowing all internal VNet traffic and denying all inbound internet access). Custom rules must use explicit priorities (between 100 and 4095) to override these platform defaults safely.
- NSG Flow Logging & Telemetry: Enabling virtual network flow logs captures raw IP traffic data, which can be piped to tools like Azure Network Watcher or SIEM platforms to audit denied connections, diagnose latency drops, and monitor security posture in real time.