• Intro
• What the portal now shows
• Why this matters for design
• Recommended approach
• Final remark

Intro

When Software Defined Networking (Arc-enabled) is configured on an Azure Local cluster, Network Security Groups are available directly in the Azure portal for Azure Local resources. That gives us a familiar control surface for segmentation, but there is one design detail that is easy to miss:

you can attach an NSG to the logical network and you can also attach NSGs to VM network interfaces.

Both models are valid. The important part is to plan which one you want as your primary enforcement scope before workloads are deployed.

What the portal now shows

In my environment, the logical network vlan0 now exposes a dedicated NSG section and clearly shows the currently associated NSG:

From the logical network itself, I can directly associate or dissociate an NSG:

On the NSG resource overview, Azure Local also shows where it is linked:

In this example, the NSG is associated with 1 Logical network and 0 VM network interface, and the logical network tab confirms the current link:

For completeness, the logical network details (DNS, connected devices, and settings) remain managed on the same Azure Local logical network resource:

Why this matters for design

This dual association capability is powerful, but it can also create an unintended rule model if it is not planned.

If an NSG strategy is mixed across scopes (some controls at logical network level and additional controls at VM NIC level), administrators may get behavior that is technically correct but operationally confusing:

• troubleshooting becomes harder because filtering can happen at more than one scope
• ownership boundaries get unclear (platform network team vs workload team)
• exceptions can be implemented in inconsistent places

The result is often not a platform issue. It is a design issue.

Recommended approach

Pick the primary enforcement model per environment and document it:

1. Logical network-centric model Use NSGs primarily on Azure Local logical networks when you want consistent controls for all workloads connected to that network segment.
2. VM NIC-centric model Use NSGs primarily on VM NICs when you need workload-specific segmentation and tighter per-application control.
3. Mixed model (only when intentional) If both scopes are used, define it as an explicit architecture decision with clear ownership, rule precedence guidance, and operational runbooks.

The key is not whether both are possible. The key is whether your team intentionally chose the model.

Final remark

With SDN (Arc-enabled) on Azure Local, NSGs can now be associated to both logical networks and VM network interfaces. That flexibility is useful, but only when the target scope is chosen deliberately.

Before onboarding workloads, decide your NSG pattern, ownership model, and exception process. Otherwise, you risk ending with an NSG design that works technically but was never intended operationally.