Azure NSGs, Bastion, Service Endpoints & Private Endpoints

A network security group (NSG) is a stateful set of security rules that allows or denies network traffic to and from Azure resources in a virtual network. Each custom rule has a priority between 100 and 4096, and a lower number means higher priority: Azure evaluates rules from the lowest number upward and stops at the first rule that matches. There is no "deny overrides allow" inside one NSG — if a rule at priority 200 allows a flow that a rule at priority 300 would deny, the allow wins because it matches first. Priorities must be unique per direction within one NSG (two inbound rules cannot share 300), but an inbound and an outbound rule may use the same number, and leaving gaps (100, 110, 120…) makes it easy to insert rules later.

Every rule matches on a 5-tuple — source, source port, destination, destination port and protocol (TCP, UDP, ICMP or Any) — plus a direction (inbound or outbound) and an action (Allow or Deny). Source and destination can be an IP address or CIDR range, a service tag such as Internet or VirtualNetwork, or an application security group.

NSGs are stateful

An NSG tracks flows, so you write a rule only for the direction in which a connection starts. If an inbound rule allows TCP 443 to a web server, the server's replies are allowed back out automatically — no matching outbound rule is needed — and an outbound allow likewise lets responses back in. Statefulness also means that removing an allow rule may not cut connections that are already established: existing flows can continue, while every new flow is evaluated against the updated rules.

The default rules

Every NSG contains default rules that you cannot delete but can override with any custom rule, because every custom priority (100–4096) is evaluated before them.

Two consequences follow. First, internet traffic is allowed only outbound by default; any inbound service from the internet (HTTPS, SSH, RDP) needs an explicit allow rule. Second, traffic inside the virtual network is open by default, which matters whenever you want to restrict it (see the service-tag section below).

A service tag is a Microsoft-managed name for a group of IP prefixes that you use as a rule's source or destination instead of typing addresses. Microsoft maintains the prefixes and updates them automatically; you cannot create your own service tags (to group your own VMs, use an application security group). What matters is knowing exactly what each common tag matches:

Because client traffic through a public load balancer keeps the client's source IP, allowing AzureLoadBalancer lets health probes through but not users; the users need a rule for their real source (for example Internet on port 443).

An allow is not a restriction

Adding a narrow allow rule does not block anything else, because the default rules beneath it still allow all VirtualNetwork inbound and all Internet outbound traffic. To limit a database tier to the web tier only, you need the allow (web tier → port 1433) and a lower-priority deny (for example VirtualNetwork → port 1433, or Any) above the 65000 defaults. Likewise, to let VMs reach only Storage in their region, allow Storage.EastUS outbound and then deny Internet outbound — regional PaaS tags are a subset of the Internet space, so the deny must come after the allow. Be careful with a broad custom "deny Any" rule: it sits above the defaults too, so it also removes the VNet and load-balancer allows, and health probes start failing unless you re-allow AzureLoadBalancer.

You can associate an NSG with a subnet, with a network interface (NIC), or with both. An NSG on a subnet applies to every resource in that subnet, which makes it the efficient place for broad rules such as blocking inbound RDP from the internet across a tier. An NSG on a NIC applies only to that interface, which is useful when one machine needs an exception the rest of the subnet does not. One NSG can be associated with many subnets and NICs.

When both are present, traffic must pass both NSGs. For inbound traffic Azure evaluates the subnet NSG first and then the NIC NSG; for outbound traffic it evaluates the NIC NSG first and then the subnet NSG. Each NSG reaches its own first-match verdict independently — priorities do not compare across the two NSGs, so a priority-100 allow on the NIC does not beat a priority-4000 deny on the subnet. If either NSG denies the flow, it is dropped. A common mistake is adding an allow rule to the NIC NSG while the subnet NSG still denies the same traffic — the packet never arrives.

NSG rules also apply to traffic between two VMs in the same subnet: those VMs can normally talk only because the default AllowVNetInBound rule permits it, so a higher-priority deny blocks it.

An application security group (ASG) is a named group of network interfaces that you reference as the source or destination of an NSG rule instead of IP addresses. Maintaining rules by IP becomes fragile as machines scale in and out or change addresses; an ASG lets you write the rule by role and keep it unchanged as membership changes.

You create ASGs such as WebServers and DbServers, then add each VM's network interface to the right group — ASGs are assigned to NICs, not to subnets (and not to the NSG itself). In the NSG you write a rule like "allow TCP 1433 from WebServers to DbServers". When you add a web server, you attach its NIC to WebServers and it inherits every rule that references the group — no rule edits, no IP bookkeeping. ASGs work cleanly with virtual machine scale sets, whose NIC configuration can carry the ASG.

Constraints to remember:

• A NIC can belong to several ASGs at once (for example WebServers and MonitoredHosts).
• All NICs in an ASG must be in the same virtual network as the first NIC added to it.
• When a rule uses ASGs as both source and destination, the NICs in both groups must be in the same VNet. Traffic arriving from a peered VNet therefore cannot be matched by an ASG; reference it by its IP prefix (or a tag) instead.

An ASG only says which machines; the NSG still decides what traffic is allowed, and the default rules still apply beneath your ASG rules.

Effective security rules show, for one network interface, the merged set of rules actually in force: the NSG on that NIC plus the NSG on its subnet, with default rules included, service tags expanded to their IP prefixes and rules that reference ASGs included. It is the way to read the real outcome when rules stack at two levels.

To use it, open the VM's networking page or the network interface and choose Effective security rules. Points that matter in practice:

• The view is per network interface. A VM with two NICs can have different effective rules on each, so check the NIC that actually carries the traffic.
• The VM must be running for effective rules to be shown.
• The portal lists the first 50 rules; download the CSV to see the complete list.
• Read it with the processing logic in mind: first match by priority inside each NSG, and a deny in either NSG wins across the pair.

Effective rules list everything; they do not give a verdict for one specific connection. Network Watcher provides the complementary tools:

So use IP flow verify when you need a quick allow/deny for a single connection with the responsible rule named, effective security rules when you need to audit the whole rule set on a NIC, and next hop when the packet is being sent somewhere unexpected rather than being blocked.

Azure Bastion is a fully managed PaaS service that gives RDP and SSH access to virtual machines through the Azure portal over TLS on port 443, connecting to each VM on its private IP. The VMs need no public IP, no inbound RDP/SSH from the internet and no agent or extra software installed; administrators need only a browser (or, on higher SKUs, the native client).

A dedicated Bastion host (Basic, Standard or Premium SKU) is deployed into a subnet named exactly AzureBastionSubnet, sized /26 or larger, and uses a Standard SKU public IP (the exception is a Premium private-only deployment, which has no public IP). If you put an NSG on AzureBastionSubnet itself, it must carry the rules Bastion needs (for example inbound 443 from Internet and GatewayManager, and outbound RDP/SSH to the VNet).

Rules on the target VMs

Bastion connects to a VM from inside the virtual network, so the target VM's NSG must allow RDP (3389) or SSH (22) from the AzureBastionSubnet address range — not port 443 (that is the admin-to-Bastion leg) and not the administrators' public IPs (their packets never reach the VM directly). You can then deny all other inbound traffic from the internet.

One host for peered VNets

A Basic or higher Bastion host reaches VMs in its own VNet and in directly peered VNets. Peering is not transitive, so in a hub-and-spoke design you place one Bastion host in the hub and it serves every spoke peered to that hub; a spoke peered only to another spoke is not reachable.

Bastion SKUs

Bastion diagnostic logs record connection metadata (who connected, from where, to which VM and when), not the session contents — recording the sessions themselves needs Premium session recording. Bastion complements NSGs; it does not replace them.

Service endpoints and private endpoints both secure access from a virtual network to Azure PaaS services such as Azure Storage, Azure SQL Database and Key Vault, but they work differently: a service endpoint keeps the service on its public endpoint and lets its firewall trust your subnet, while a private endpoint gives the service a private IP inside your VNet.

Choose a service endpoint when traffic only needs to come from Azure subnets, at no cost and with no DNS work. Choose a private endpoint when the service must be reachable on a private IP, from on-premises or peered networks, or with public access turned off entirely.

Configuring a service endpoint is a two-sided change: enable the endpoint on the subnet, then trust that subnet on the service.

1. On the subnet, enable the service endpoint for the service type, such as Microsoft.Storage or Microsoft.Sql.
2. On the resource's networking/firewall settings, set public network access to Enabled from selected virtual networks and IP addresses and add a virtual network rule for that subnet.

Behaviour to understand:

• The source address changes. Once the endpoint is enabled, the subnet's traffic to that service arrives from its private VNet address instead of its public IP. Any existing firewall IP rule that admitted the subnet by its public IP stops matching, so add the VNet rule first (or together) to avoid an outage.
• IP network rules accept public ranges only. You cannot admit a private (RFC 1918) range through an IP rule; private sources are admitted with VNet rules.
• On-premises is not covered. Traffic from on-premises reaches the service through its public IP (typically its NAT address), so it needs an IP rule for that public address — or a private endpoint.
• It depends on the public endpoint. If public network access is set to Disabled, VNet rules stop applying and only private endpoints work.

A private endpoint is a network interface with a private IP from your subnet that connects through Azure Private Link to one resource and one target sub-resource. A storage account that needs both Blob and Files privately needs two private endpoints (sub-resources blob and file), each with its own private IP and DNS record. Because it is just an IP in your VNet, the endpoint is reachable from the VNet, from peered VNets and from on-premises over VPN or ExpressRoute.

Creating the endpoint does not by itself block the public endpoint. To make the service private-only, set its public network access to Disabled as a separate step.

How name resolution works

Clients keep using the normal hostname, such as contoso.blob.core.windows.net. When a private endpoint exists, the public DNS answer becomes a CNAME to contoso.privatelink.blob.core.windows.net. Inside your network, a private DNS zone named privatelink.blob.core.windows.net holds an A record mapping that name to the endpoint's private IP. Outside your network the same CNAME resolves to the public IP, so no certificate or connection-string changes are needed.

When you create the endpoint in the portal with private DNS integration, Azure creates (or reuses) the privatelink zone for that service — for example privatelink.vaultcore.azure.net for Key Vault or privatelink.database.windows.net for Azure SQL — adds the A record and links the zone to the virtual network.

Forward the public zone, not only the privatelink zone, so the CNAME chain is followed and resolved inside Azure.

Your compliance team sets two rules for a new application tier: administrators must manage the virtual machines without any VM being exposed to the internet, and the application's storage account must not be reachable over its public endpoint at all.

For administrative access, deploy Azure Bastion (Basic or higher) into an AzureBastionSubnet of /26 or larger in the hub VNet that the application VNet is peered to. Remove public IPs from the VMs. In the VMs' NSG, allow RDP or SSH from the AzureBastionSubnet range and rely on DenyAllInBound for internet traffic. Admins connect through the portal over TLS with no exposed management ports.

For the storage account, create a private endpoint for the blob sub-resource in the application subnet (and a second one for file if Azure Files is used), with private DNS integration so privatelink.blob.core.windows.net is linked to the VNet. Then set the account's public network access to Disabled. If on-premises servers also need the account, add a conditional forwarder for blob.core.windows.net to a DNS Private Resolver inbound endpoint. The result: no internet-facing VMs and a storage account reachable only on its private IP.