Securing Azure Virtual Networks With Network Security Groups and Application Security Groups

Azure virtual networks are not secure just because they use private IP addresses. If you want real control, you need segmentation, and that means using Azure Network Security Groups (NSGs) and Application Security Groups (ASGs) to enforce least-privilege traffic flow without turning every rule change into a maintenance problem.

Primary Use	Azure network troubleshooting and traffic validation
Key Features	IP flow verify, connection troubleshoot, topology, packet capture
Best For	NSG validation, route troubleshooting, connectivity diagnostics
Scope	Virtual networks, subnets, and network interfaces
Cost	Usage-based pricing varies as of July 2026 according to Microsoft Azure Pricing
Documentation	Microsoft Learn
Related Skills	Network security, segmentation, traffic filtering, diagnostics

This matters because Azure security starts with segmentation, not with a long list of private IPs. If your rules are built around individual addresses, they become brittle the moment a workload scales, redeploys, or shifts subnet placement.

That is where Network Security Groups (NSGs) and Application Security Groups (ASGs) come in. NSGs enforce the policy. ASGs make that policy readable, reusable, and easier to keep aligned with changing workloads.

The practical goal is simple: reduce lateral movement, limit blast radius, and keep the rule set understandable enough that operations teams can maintain it without guesswork. This also lines up with the kind of security and identity thinking covered in Microsoft SC-900: Security, Compliance & Identity Fundamentals, where control, visibility, and governance matter as much as technology choice.

What Is Azure Network Watcher?

Azure Network Watcher is Microsoft’s built-in diagnostics service for Azure networking. It helps you see whether traffic is allowed or denied, where packets are going, and why a connection fails after a change.

For teams managing Azure Virtual Networks, the biggest value is not just troubleshooting. It is validation. You can prove that an NSG rule behaves the way you intended, which is critical when you are trying to keep segmentation tight without breaking application traffic.

Why Network Watcher matters for secure design

A network can look correct on paper and still behave incorrectly in production. A route table may point traffic the wrong way, an NSG rule may be shadowed by a higher-priority deny, or a port may be open from the wrong source subnet.

• IP flow verify checks whether a specific source, destination, port, and direction would be allowed or denied.
• Connection troubleshoot tests end-to-end reachability between Azure endpoints or from Azure to external targets.
• Packet capture helps confirm whether traffic is arriving, being dropped, or leaving a host.
• Topology helps visualize relationships between Azure networking components.

That combination is why Azure Network Watcher belongs in the day-to-day workflow of network and security administrators. It turns rule design from theory into evidence.

Security controls are only useful when you can verify that they behave correctly under real traffic conditions.

Microsoft documents the service and its capabilities on Microsoft Learn, which is the best place to check current behavior and feature availability before you rely on an older blog post or a memory from last year.

Understanding Azure Virtual Network Segmentation

Azure Virtual Network is Microsoft Azure’s logical network boundary for private resources. It gives you address space, subnets, routing, and security controls, but it does not automatically create a secure design.

The mistake many teams make is treating a VNet as if it were already segmented just because resources have private IP addresses. A flat network still allows too much trust between systems that should not be talking to each other.

That creates two problems. First, an attacker who reaches one host can often move laterally to others. Second, a simple operational error can expose management ports or application ports more broadly than intended.

Why flat designs fail

A flat network is one where too many systems can communicate with each other by default. It is easier to build at first, but it usually becomes harder to defend and harder to troubleshoot.

• Web tier systems should usually accept internet-facing traffic on limited ports only.
• App tier systems should usually accept traffic only from the web tier or approved management sources.
• Database tier systems should usually accept traffic only from the app tier and restricted admin paths.
• Management tier systems should be isolated from general user and application traffic.

This structure is not just about security. It improves ownership, simplifies audits, and makes dependency mapping easier when something breaks. The more clearly you define trust boundaries, the easier it becomes to justify every allowed flow.

Where segmentation happens in Azure

In practice, Azure segmentation happens at multiple levels. Subnets are the most common organizational boundary, while NSGs can be attached to either a subnet or an individual network interface card, depending on the design goal.

That flexibility is useful. For broad policy, subnet-level control is simpler. For tighter exceptions or special cases, NIC-level control can give you more precision without redesigning the whole network.

Microsoft’s networking guidance on NSG documentation and the Azure Well-Architected Framework’s security guidance both reinforce the same idea: identity, segmentation, and governance should work together, not in separate silos.

How Network Security Groups Work in Azure

Network Security Groups are the core traffic enforcement layer in Azure virtual networking. They use allow and deny rules to control traffic to and from resources based on source, destination, port, protocol, and direction.

NSGs are not firewalls in the traditional appliance sense, but they perform a similar policy function at the subnet or NIC level. If the traffic does not match an allowed rule, it is denied.

1. Azure evaluates the rule set in priority order. Lower numbers have higher priority, so the first matching rule wins.
2. Inbound and outbound traffic are evaluated separately. A system may be reachable from the internet but still unable to return traffic if outbound is blocked.
3. Source and destination matter. Rules can target IP ranges, service tags, subnets, or ASGs.
4. Protocol and port are checked. TCP, UDP, ICMP, and specific ports such as 80, 443, or 1433 can be controlled.
5. Default rules exist. Azure ships with default security rules so core platform traffic is not broken, but custom rules can override those defaults when they are more specific.

That priority model is where many mistakes happen. A broad deny with a higher priority than a specific allow can block an application entirely. The reverse can also happen: a loose allow rule can expose more than the operator intended.

Inbound and outbound rules both matter

Inbound rules control what can reach a resource. Outbound rules control what the resource can reach. In secure Azure environments, both should be designed intentionally.

• Inbound example: Allow HTTPS from the internet to a web tier, but deny everything else.
• Outbound example: Allow the app tier to reach only the database port on the database subnet.
• Administrative example: Allow RDP or SSH only from a hardened jump host subnet, never from broad user networks.

For a current reference, Microsoft Learn’s Network Security Groups overview remains the authoritative source for how Azure applies rules and defaults. If you are validating rule behavior, pair that documentation with Azure Network Watcher’s IP flow verify feature so you are not guessing.

What Application Security Groups Add to the Model

Application Security Groups let you group virtual machines by function instead of by static IP address. That is the main reason they are so useful in Azure.

In a cloud environment, IP addresses can change when systems are rebuilt, scaled, or redeployed. ASGs reduce the maintenance burden because your NSG rules can reference a role-based group instead of a pile of individual NICs or addresses.

How ASGs improve rule readability

Without ASGs, an NSG rule might say that a web server can talk to four specific IPs that happen to belong to app servers right now. That rule works until the app tier changes, which is usually sooner than people expect.

With ASGs, the rule can say that the Web ASG may talk to the App ASG on a specific port. That reads like architecture, not a spreadsheet.

• Web tier ASG: Public-facing or front-door workloads.
• App tier ASG: Internal logic and API services.
• Database tier ASG: Data stores and persistence services.
• Jump host ASG: Administrative entry points with tightly controlled access.

What ASGs are not

An ASG is not an enforcement mechanism by itself. It does not block traffic independently. It is a targeting mechanism that makes NSG rules easier to define and maintain.

That limitation matters. If your NSG design is weak, ASGs will not fix it. But if your NSG policy is sound, ASGs make the implementation cleaner and less error-prone.

Microsoft’s ASG guidance on Azure documentation is worth checking before you standardize a design across subscriptions. It confirms how ASGs work and where they fit in the rule model.

How Does Azure Network Watcher Help Verify NSG and ASG Rules?

Azure Network Watcher helps verify NSG and ASG behavior by showing whether traffic is allowed, denied, or blocked by another network condition. The most useful validation feature for this topic is IP flow verify.

IP flow verify answers a very practical question: “Would this traffic be allowed from this source to this destination on this port?” That makes it ideal when you are checking whether a rule tied to an ASG is actually working the way you expected.

1. Pick the source VM or NIC.
2. Enter the source IP, destination IP, protocol, and port.
3. Run IP flow verify.
4. Review whether the result is allowed or denied and which rule caused the decision.
5. Adjust the NSG or ASG placement if the result does not match the intended architecture.

Connection troubleshoot is the next step when the problem is broader than an NSG rule. If routing, DNS, or a remote endpoint is involved, you need more than a simple allow/deny check.

The official Microsoft Learn pages for IP flow verify and connection troubleshoot are the best references for current behavior, output, and limitations.

Designing a Practical Segmentation Strategy

A practical segmentation strategy starts with trust boundaries, not with rules. Before you write a single NSG entry, decide which systems should be public, internal, restricted, or administrative-only.

Network segmentation works best when it reflects the actual application design. A web server should not need database access to everything in the environment. A database should not accept management traffic from a broad user subnet. That sounds obvious, but many production networks still drift into that pattern over time.

Map the application first

Document the application flow in plain language. Identify the entry point, the service tier, the data tier, and the administrative path.

1. List the workloads in each tier.
2. Define the required ports and protocols.
3. Mark any trusted management sources.
4. Identify which flows must never exist.
5. Turn those decisions into NSG rules and ASG groupings.

Separate environments when it matters

Production, development, and testing should not share the same trust model unless there is a clear, documented reason. In many organizations, production belongs in separate VNets or at least separate subnets with stricter control and more restrictive inbound paths.

That separation is more than a security habit. It reduces accidental cross-environment access and keeps nonproduction experiments from becoming a path into live data.

For governance alignment, this is the same kind of control discipline emphasized in the Microsoft SC-900 learning path on Microsoft Learn: understand the control, place it correctly, and review it regularly.

How to Build Effective NSG Rules

Effective NSG rules are specific enough to protect the environment and broad enough to avoid breaking legitimate traffic. That balance is the difference between a secure design and a support nightmare.

The biggest rule-writing mistake is relying on “Any” for source or destination when a tighter scope is available. A rule that allows TCP 443 from the internet to a web tier is reasonable. A rule that allows all traffic from anywhere to anywhere is not.

Rule design habits that work

• Scope sources tightly: Use approved subnets, service tags, or ASGs instead of broad address ranges when possible.
• Scope destinations tightly: Point traffic only at the workloads that need it.
• Use clear names: Names like Allow-Web-To-App-443 are easier to audit than generic labels.
• Avoid duplicated logic: Consolidate common flows instead of creating separate rules for every VM.
• Review rule order: Priority mistakes can shadow the rule you think is active.

Common application traffic examples

A typical web tier might allow inbound TCP 80 and 443 from the internet or an approved front-end service. The app tier might allow inbound from the web tier only, and the database tier might allow inbound on the database port only from the app tier.

Administrative access should be narrower still. RDP or SSH should usually come from a hardened admin subnet or jump host, not from general employee networks or the public internet.

For operational sanity, this is also where official Microsoft documentation and Azure Network Watcher validation work together. Write the rule, test it with IP flow verify, then document the intended outcome so the next person does not have to reverse-engineer your intent.

Good rule	Allow HTTPS from Web ASG to App ASG
Weak rule	Allow TCP 443 from Any to Any

Using ASGs to Simplify Real-World Rule Management

ASGs are most valuable when they reduce the number of things you have to touch during change. If a VM gets redeployed and its IP changes, an ASG-based rule usually stays intact.

That is a major operational win. It means security policy stays tied to function, not to a temporary address that may disappear during the next maintenance window.

How ASGs reduce rule churn

Suppose you have eight app servers behind a load-balanced service. Without ASGs, an NSG rule may need eight separate destination IPs. When one server is rebuilt, that list needs immediate attention.

With ASGs, you assign the servers to the App ASG and target that group from the web tier. The rule remains stable even when the underlying hosts change.

• Better readability: Security reviews can see the business purpose of the rule.
• Less human error: Fewer manual IP updates means fewer misconfigurations.
• Cleaner audits: Roles and traffic paths are easier to explain.
• Lower maintenance: Group membership changes are simpler than rule rewrites.

Where ASGs fit best

ASGs work best when workloads have a consistent role and clear ownership. They are less helpful in highly fragmented environments where every VM has a unique access pattern.

If a workload’s role keeps changing, a static ASG may not solve the complexity. In that case, you need to fix the application design or isolate the special case rather than forcing the group model to do everything.

This is where Azure Network Watcher’s validation tools are useful again. After you change ASG membership, use IP flow verify to confirm the expected path still works and no unintended path opened with it.

Azure Security Architecture Patterns and Examples

A three-tier Azure architecture is the most common practical model for NSGs and ASGs. It usually includes a web tier, an app tier, and a database tier, each with different trust levels.

In that pattern, the web tier may accept internet-facing traffic on 443. The app tier should accept traffic only from the web tier. The database tier should accept traffic only from the app tier and tightly controlled administrative sources.

Example one: public web application

A customer-facing site hosted on Azure might place the web VMs in one subnet, the app VMs in another, and the database systems in a third. The Web ASG can be referenced in an NSG rule that allows inbound HTTPS from the internet, while the App ASG only accepts traffic from the Web ASG on the application port.

The database subnet should be even tighter. Only the App ASG should be permitted to reach the database port, and management access should come from a jump host subnet or privileged admin network.

Example two: management and shared services

Administrative access is often where designs slip. A hardened administrative subnet lets operators manage systems without placing RDP or SSH on a broad internal network.

Shared services such as monitoring, backup, or update systems should also be targeted intentionally. They often need access to many workloads, but that does not mean they should be placed in a general-purpose allow rule.

• Monitoring: Allow agents to reach only the required telemetry destinations.
• Backup: Restrict backup traffic to backup infrastructure and approved ports.
• Patching: Permit update services only from approved repositories or management hosts.

Microsoft’s current Azure guidance on network segmentation and the Azure Well-Architected Framework both support this pattern because it improves blast-radius control and makes accountability much clearer.

Common Mistakes That Weaken Azure Network Security

Most Azure network security failures are not caused by exotic attacks. They come from ordinary design mistakes that make the environment easier to misuse.

Overly permissive rules are the biggest problem. If a rule uses broad source or destination ranges, it defeats the purpose of segmentation. A single “temporary” exception can stay in production for months if nobody owns the cleanup.

Other mistakes to avoid

• Relying only on IP addresses: Dynamic cloud workloads change too often for fragile IP-based policy.
• Putting everything in one giant NSG: Large rule sets become hard to understand and easy to break.
• Ignoring shadowed rules: A higher-priority rule can silently override the one you intended to use.
• Mixing admin and app traffic: Management access should be separate and more tightly controlled.
• Poor naming and documentation: If no one knows why a rule exists, no one can safely maintain it.

These mistakes matter because they compound over time. The network that starts “simple” can become fragile, opaque, and overexposed after only a few release cycles.

NIST SP 800-53 Rev. 5 is a useful reference for control thinking here, especially around least privilege, access enforcement, and continuous review. It does not tell you how to write an Azure NSG rule, but it does reinforce why the rule should exist in the first place.

Operational Best Practices for Ongoing Management

Ongoing management is where Azure NSG and ASG designs succeed or fail. The initial design may be good, but if nobody reviews it, the environment will drift.

Security teams should review rule assignments, ASG membership, and exception paths on a regular schedule. That review should be part of change control, not a one-time cleanup project.

Controls that keep the design healthy

1. Use naming standards: Make it clear what each NSG, ASG, and rule protects.
2. Add ownership metadata: Tag resources with team, environment, and application name.
3. Test in nonproduction first: Validate changes before applying them broadly.
4. Keep change control strict: Treat security rule changes like production code changes.
5. Monitor logs: Review denies, unusual bursts, and unexpected allowed flows.
6. Clean up stale entries: Remove old rules, unused ASGs, and obsolete exceptions.

That operational discipline aligns well with Microsoft’s current security guidance and with broader governance practices used in regulated environments. If you need to justify a control during an audit, a documented rule change with evidence from Azure Network Watcher is much stronger than verbal memory.

For teams measuring workforce readiness, this is the kind of control model that fits with the general security and compliance foundation taught in Microsoft SC-900. The value is not just knowing the terms. It is knowing how to operationalize them.

Monitoring, Troubleshooting, and Validation

Validation is the difference between “the rule looks right” and “the traffic actually behaves correctly.” Azure Network Watcher is built for that gap.

After deployment, use IP flow verify to check critical flows such as web-to-app, app-to-database, and admin-to-jump-host access. If something fails, move to connection troubleshoot to determine whether the issue is NSG-related, routing-related, or something outside the network policy layer.

A simple validation checklist

• Can the web tier receive only the intended inbound ports?
• Can the app tier reach only approved downstream systems?
• Can the database tier reject all unapproved sources?
• Can administrators reach systems only from the hardened admin subnet?
• Do denied flows match the documented design?

Denied connections are not always bad. Sometimes they are exactly what you want, because they show the control is working. But a spike in denied traffic can also indicate misconfiguration, scanning, or an application team deploying code that assumes a path that no longer exists.

Microsoft’s IP flow verify documentation and the broader Azure Network Watcher documentation should be part of your standard troubleshooting workflow. They give you a consistent way to answer the question every operator hears sooner or later: “What changed?”

Current Azure Networking Considerations to Keep in Mind

Current Azure networking practice is less about static rules and more about repeatable governance. Teams want readable policy, automation-friendly design, and evidence that controls work the same way across environments.

That is why NSGs and ASGs remain relevant. They are simple enough to standardize, but flexible enough to support modern application deployments. Their value increases when they are managed consistently across subscriptions, environments, and business units.

What to keep in view now

• Automation matters: Manual rule edits do not scale well.
• Governance matters: Standard policy patterns make reviews easier.
• Documentation matters: If the intent is not documented, the design is fragile.
• Validation matters: Use Azure Network Watcher instead of assuming control behavior.
• Maintenance matters: Security degrades when old rules linger too long.

Microsoft updates Azure networking guidance regularly, so the safest approach is to anchor your design in the current documentation rather than a static screenshot or a remembered rule example. That is especially important when you are supporting compliance, identity, and security controls together.

If your team is building a modern Azure security baseline, this topic belongs alongside identity controls, governance controls, and secure administrative access. Network controls are only one layer, but they are the layer that often stops lateral movement before it spreads.

Conclusion

Azure network security works best when you treat segmentation as a design requirement, not an afterthought. NSGs enforce the traffic policy, and ASGs make that policy manageable as workloads change.

Azure Network Watcher closes the loop by showing whether the policy actually behaves the way you intended. That is how you catch hidden gaps, shadowed rules, and broken dependencies before they turn into incidents.

The practical takeaway is straightforward: build for least privilege, keep the rule set readable, and validate it regularly. Good Azure network security is simple in concept, disciplined in execution, and reviewed often enough to stay current.

For teams building a foundation in security, compliance, and identity, this is exactly the kind of operational thinking reinforced in Microsoft SC-900 and in the Azure documentation that should guide day-to-day implementation.

Microsoft® and Azure® are trademarks of Microsoft Corporation.