CH03-03: Network Security Groups and Segmentation

Goal

The previous section explained virtual networks and subnets as private placement areas. This section explains how Azure filters traffic at those areas using network security groups.

The goal is to understand segmentation as an architecture decision. Segmentation is not only a security team's preference. It affects blast radius, troubleshooting, production safety, application design, and how much confidence a team has when something fails.

The Short Version

A network security group, usually called an NSG, is a set of traffic filtering rules.

An NSG can be associated with a subnet or with a network interface. Its rules can allow or deny traffic based on information such as:

• Direction: inbound or outbound.

• Source: where traffic comes from.

• Destination: where traffic goes.

• Protocol: such as TCP or UDP.

• Port: such as 443 for HTTPS.

• Priority: which rule wins when multiple rules could match.

• Action: allow or deny.

The practical mental model is:

Network security groups help define which network conversations are allowed inside and around a workload.

A private network without segmentation is still too open for many real systems. NSGs help turn private placement into controlled communication.

Why Segmentation Matters

Segmentation answers:

• Which tier can talk to which tier?

• Which management paths are allowed?

• Which workloads should stay isolated from each other?

• Which environments should never talk directly?

• Which traffic should be blocked even though it is technically inside a private network?

Imagine a simple application with a web tier, an API tier, and a data tier.

A weak network design says:

Everything is private, so everything inside the VNet can talk to everything else.

A stronger design asks:

• Should users reach the web tier only through an approved entry point?

• Should the web tier call only the API tier?

• Should the API tier be the only tier that reaches the data dependency?

• Should the data tier reject direct traffic from the web tier?

• Should administrative access come only from approved management paths?

The stronger design does not block communication randomly. It allows the paths the application needs and blocks paths that have no clear purpose.

A Simple Three-Tier Model

A common starting pattern looks like this:

Approved entry point
        |
        v
Subnet: Web
  Allows HTTPS from approved entry path
        |
        v
Subnet: App
  Allows API traffic from Web subnet
        |
        v
Subnet: Data or private access path
  Allows data traffic from App subnet

This diagram is intentionally simple. Real applications may use managed services, private endpoints, API gateways, load balancers, firewalls, or service-specific access controls. The point is still useful: traffic should follow the application design, not the easiest network opening.

NSG Scope: Subnet and Network Interface

NSGs can be associated with subnets and network interfaces.

A subnet-level NSG is often easier to reason about when resources in the subnet share a role. For example, if the app subnet should accept traffic only from the web subnet on specific ports, a subnet-level NSG expresses that intent clearly.

A network-interface-level NSG can be useful for more specific control on individual virtual machines or network interfaces. But too many highly specific rules can become hard to operate. The more exceptions a design has, the more important documentation and troubleshooting become.

A practical rule of thumb is:

Put common traffic rules where the shared responsibility lives, and use narrow exceptions only when there is a real reason.

What an NSG Rule Describes

An NSG rule describes a traffic decision.

For example, a rule might mean:

Allow inbound TCP 443
From: Web subnet
To: App subnet
Purpose: Web tier calls API tier

Another rule might mean:

Deny inbound database traffic
From: Web subnet
To: Data subnet
Purpose: Prevent direct web-to-data access

When writing or reviewing NSG rules, do not look only at the port number. Ask what application path the rule represents.

A good rule has a reason. A rule like "allow any from any" may make testing easier, but it erases the architecture intent.

Inbound and Outbound Traffic

Many teams focus on inbound traffic because it feels more obviously risky. Inbound rules matter, especially for internet-facing or user-facing paths.

Outbound rules matter too.

Outbound control helps answer:

• Can a compromised workload reach unrelated internal systems?

• Can a workload send traffic directly to the internet?

• Should outbound traffic go through a firewall or inspection path?

• Which dependencies does the application actually need?

Outbound control is often where architecture and operations meet. If outbound restrictions are too broad, risk increases. If they are too tight and poorly documented, deployments and runtime dependencies can fail in confusing ways.

NSGs Are One Layer, Not the Whole Security Model

NSGs are important, but they are not a complete security design.

They do not replace:

• Authentication and authorization.

• Managed identity and role-based access.

• Encryption.

• Application security controls.

• Secrets management.

• Patching and vulnerability management.

• Azure Firewall or deeper traffic inspection where needed.

• Monitoring and alerting.

• Service-specific configuration.

For example, an NSG may allow an API subnet to reach a database service. That does not mean every caller should be trusted. The database still needs identity, authorization, encryption, auditing, backup, and proper configuration.

The useful mental model is layered control. NSGs reduce unnecessary network paths. Other controls protect the workload at identity, application, data, and operations layers.

Example: Improving a Customer API Network

Imagine a customer API deployed into three subnets:

VNet: customer-api-prod
  |
  +-- Subnet: web
  +-- Subnet: app
  +-- Subnet: endpoints

An early test configuration allows broad internal traffic:

Allow traffic from VNet to VNet
Allow outbound traffic to internet

The application works, but the design is too broad. If something in the web tier is compromised, it may have unnecessary network paths to deeper parts of the system.

A more intentional design might say:

This design does not make the application secure by itself, but it reduces unnecessary paths. It also gives operators a clearer map when they troubleshoot.

Common Early Mistakes

• Allowing broad inbound traffic to make testing easier. Temporary wide-open rules often survive into production.

• Treating NSGs as a complete security model. NSGs filter traffic, but identity, application security, encryption, service configuration, and monitoring still matter.

• Forgetting outbound rules. Outbound paths can expose data, bypass inspection, or create hidden dependencies.

• Reusing one permissive NSG across unrelated subnets. Shared rules should match shared responsibility, not convenience.

• Creating too many exceptions. A rule set that no one understands becomes risky even if each rule once had a reason.

• Troubleshooting without checking rule direction and priority. A rule may exist but not apply the way the team expects.

If Someone Asks You

If someone asks, "What is a network security group used for in Azure?" a clear answer is:

A network security group is used to filter network traffic at subnet or network interface scope. It contains rules that allow or deny traffic based on direction, source, destination, protocol, port, priority, and action. Architecturally, NSGs help segment workloads so only required network conversations are allowed. They are one layer of security and do not replace identity, application controls, encryption, firewall inspection, or monitoring.

This answer explains both the control and its limits.

What You Should Remember

NSGs help turn private networks into controlled communication spaces.

The most important idea is this:

Segmentation is strongest when each allowed path has a clear purpose.

A good Azure network design does not only ask whether resources are private. It asks which private paths should exist.

Questions to Check Your Understanding

1. What does an NSG rule evaluate?

2. Why is segmentation useful even inside a private network?

3. When might subnet-level NSG rules be easier to operate than interface-level rules?

4. Why do NSGs not replace application security or identity controls?

5. What common troubleshooting issue can rule priority create?