A Network Security Group (NSG) is Azure's built-in packet filter: a list of allow and deny rules, evaluated by priority, attached to a subnet or a network interface. Once you route Claude traffic through an Azure Private Link private endpoint on your Foundry resource, the NSG question follows immediately: what rules does that traffic need? First, an honesty note this site owes you: Microsoft's Claude-on-Foundry documentation does not publish an NSG rule table — the networking guidance is generic to Foundry resources. What follows applies standard Azure NSG practice to the documented traffic pattern; verify against current Azure documentation before locking down production.
Know what the traffic looks like
The traffic you are filtering is simple and uniform. Your application calls https://<resource-name>.services.ai.azure.com/anthropic/v1/messages — HTTPS, standard port 443. With the private endpoint and its private DNS zone in place, that hostname resolves to the endpoint's private IP inside your VNet. So the flow an NSG sees is: TCP 443 from your application's subnet to one private IP (or the endpoint subnet's range). There are no exotic ports, no inbound callbacks to your app, and streaming responses ride the same connection the client opened.
The rules you need
| Where | Rule | Purpose |
|---|---|---|
| App subnet (outbound) | Allow TCP 443 to the private endpoint's IP or subnet range | Lets your workloads call the Claude Messages endpoint |
| App subnet (outbound) | Allow DNS to your resolvers (if you restrict outbound broadly) | The services.ai.azure.com name must resolve to the private IP |
| Endpoint subnet (inbound) | Allow TCP 443 from your application subnets | Only needed if you filter inbound traffic to the endpoint subnet at all |
In many environments the default NSG rules already permit intra-VNet traffic, so a deny-by-default posture is what creates work: you add the explicit 443 allows above and you are done. Scope the rules as tightly as your operations tolerate — a specific endpoint IP is tighter than a subnet range, but costs a rule edit if the endpoint is ever recreated.
The rules you don't need
No inbound rules on the application subnet for Claude. The model never initiates connections to your app; responses, including streamed ones, return over the app's own outbound connection.
No public-internet allowances for model traffic. With public network access disabled on the resource and the private endpoint carrying the traffic, outbound rules permitting general internet HTTPS are not required for Claude calls. If Claude was the last reason an app subnet had open internet egress, this is your chance to close it.
No custom port openings. Everything — Messages, streaming, token counting — is HTTPS on 443 to the same resource endpoint.
Two subtleties worth knowing
First, NSGs and private endpoints have historically had special interactions in Azure — support for applying NSG rules to private-endpoint network interfaces has its own settings and evolution. If you intend to filter traffic at the endpoint's subnet rather than at the source, check the current Azure Private Link documentation for how NSG enforcement on private endpoints behaves, rather than assuming parity with ordinary NICs.
Second, NSGs are packet filters, not authentication. A permitted path to the endpoint still requires a valid API key or Microsoft Entra ID token, and a blocked packet produces a connection timeout in your application — not a 401 or 403. That distinction is your fastest triage signal: timeouts point at NSGs, routing, or DNS; explicit HTTP errors mean the network path is fine and the problem is roles or credentials. When testing, remember NSG flow logs exist precisely to show which rule matched a denied flow.
Where to go next
Set up the endpoint itself in private endpoints for Foundry, place it well with VNet topology options, and keep the go-live checklist handy.