NSG Traffic Flows - Securing App & Data Subnets in Azure

In modern Azure architectures, Network Security Groups (NSGs) play a pivotal role in securing and regulating the flow of network traffic. In this post, we explore two critical flows defined by our NSG configurations:

App Subnet Flow

Our App Subnet hosts Azure VMs that serve web applications. The NSG associated with the App Subnet has the following inbound and outbound rules:

• Inbound Rules:
  • AllowHTTPFromInternet: Permits HTTP traffic (port 80) from the Internet.
  • AllowHTTPSFromInternet: Permits HTTPS traffic (port 443) from the Internet.
  • DenyAllInbound: Denies all other inbound traffic by default.
• Outbound Rules:
  • AllowToDataSubnet: Permits outbound traffic (port 5432) to the Data Subnet.
  • DenyAllOutbound: Denies any other outbound traffic.

This configuration ensures that only necessary web traffic is allowed in and that the application VMs can securely communicate with the database servers in the Data Subnet.

Data Subnet Flow

The Data Subnet is designed to host critical database servers and is secured by its own NSG with these rules:

• Inbound Rules:
  • AllowFromAppSubnet: Allows inbound traffic (port 5432) from the App Subnet, ensuring that only authorized application servers can reach the databases.
  • DenyAllInbound: Denies all other inbound traffic.
• Outbound Rules:
  • DenyAllOutbound: Blocks outbound traffic from the Data Subnet to prevent unauthorized data egress.

How NSG Rules Determine the Flow

Azure NSGs evaluate rules based on priority. Lower priority numbers (e.g., 100) are processed before higher numbers (e.g., 4096). This means:

• Allowed flows (e.g., HTTP, HTTPS, and specific port 5432 for database connectivity) are explicitly permitted by high-priority allow rules.
• Denied flows are caught by lower priority rules that act as a catch-all, ensuring that any request not explicitly allowed is rejected.

By following these principles, the NSG configuration successfully secures the two subnet environments while allowing essential communication between them.

This design not only enforces the principle of least privilege but also minimizes the exposure of your critical cloud infrastructure.

Diagram showing NSG rule evaluation and traffic flow between App and Data subnets.

Visualizing the Traffic Flow

Understanding how traffic flows through your Azure environment is critical for troubleshooting and security audits. Let’s visualize the allowed communication paths:

1. Internet → App Subnet (Ports 80/443): Public web traffic reaches your application servers.
2. App Subnet → Data Subnet (Port 5432): Application servers communicate with database servers using PostgreSQL protocol.
3. All other traffic is denied by the explicit deny rules configured in each NSG.

Visual representation of NSG traffic flows and security layers.

Best Practices for NSG Configuration

When designing NSG rules for multi-tier applications, consider these best practices:

1. Start with Deny All: Begin with a default deny posture and explicitly allow only necessary traffic.
2. Use Service Tags: Leverage Azure Service Tags (like Internet, VirtualNetwork) instead of hard-coding IP ranges.
3. Document Rule Purpose: Include clear naming conventions that explain what each rule does (e.g., AllowHTTPFromInternet).
4. Regular Audits: Periodically review NSG rules to remove obsolete entries and ensure compliance with security policies.
5. Monitor Flow Logs: Enable NSG Flow Logs to track and analyze traffic patterns for security incidents or optimization opportunities.

Always test NSG changes in a non-production environment before applying them to critical workloads.

Conclusion

By implementing layered NSG rules across your App and Data subnets, you create a robust security perimeter that protects your Azure infrastructure while allowing essential business communications. This approach embodies defense-in-depth principles and helps maintain compliance with security frameworks.

For a hands-on guide to automating NSG deployment with PowerShell, check out my post on Automating Azure VNet & NSG Deployment.

“Security in the cloud is not just about tools—it’s about thoughtful architecture and continuous vigilance.”