Azure Network Security for AZ-104: NSGs, Bastion and Private Link

Introduction

Azure network security for AZ-104 combines NSG filtering, managed VM access and private connectivity to PaaS services. This lesson belongs to the AZ-104 skills area Implement and manage virtual networking (15–20% of the exam). The study guide objective is configure secure access to virtual networks: create and configure network security groups (NSGs) and application security groups (ASGs), evaluate effective security rules in NSGs, implement Azure Bastion, configure service endpoints for Azure platform as a service (PaaS), and configure private endpoints for Azure PaaS.

Build on Azure VNet addressing, peering and routes to understand the path that NSGs filter. Now you decide who may talk to what. Exam questions in this area describe a symptom (a VM that cannot be reached, a storage account that is reachable from the internet when it should not be, an RDP port that security wants closed) and ask which control fixes it with the least effort. You need to know which layer each control works at, how rules are evaluated, and the difference between a service endpoint and a private endpoint.

After this lesson you will be able to write NSG rules that follow the evaluation order, simplify them with application security groups, explain a denied flow by reading effective security rules, remove public management ports with Azure Bastion, and keep PaaS traffic off the public internet with service endpoints or private endpoints.

Learning objectives

• Create NSGs, write inbound and outbound rules, and associate them with subnets or network interfaces.
• Predict the outcome of a flow using rule priority, default rules and the subnet-plus-NIC evaluation order.
• Use application security groups to write rules by role instead of by IP address.
• Read effective security rules and use IP flow verify to find the rule that decides a flow.
• Deploy Azure Bastion and choose between its SKUs.
• Configure service endpoints and service endpoint policies, and know what they do not do.
• Create private endpoints, link private DNS zones, and decide between service endpoints and private endpoints.

Network security groups

What an NSG is

An NSG is a stateful list of allow and deny rules that filters traffic at layers 3 and 4 (source, destination, port, protocol). It contains no application awareness: it does not read HTTP paths or inspect payloads. That is the job of Azure Firewall or Application Gateway with WAF.

Key properties:

• An NSG is a regional resource. You associate it with a subnet, a network interface (NIC), or both. A subnet association filters supported traffic for that subnet; a NIC association filters that interface. Some managed services and private endpoints have additional network-policy requirements, so do not assume every subnet resource is filtered identically.
• Stateful means that if an inbound flow is allowed, the reply traffic is allowed automatically, and the other way round. You do not write a rule for return traffic. Rule changes affect new connections; an established SSH or application session can remain open after its allow rule is removed. Test a new connection when verifying a deny.
• The same NSG can be associated with many subnets and NICs in the same region and subscription. A subnet or NIC has at most one NSG.

Rule anatomy

Each rule has these fields.

Within one NSG and direction, two rules cannot share the same priority.

Default rules

Every NSG is created with default rules that you can override but not delete. They have priorities 65000 and above so any rule you write takes precedence.

The consequence worth remembering: with a brand-new NSG, inbound from the internet is denied and outbound to the internet is allowed by the NSG. This does not create a route or SNAT method; a private subnet still needs explicit outbound connectivity when public destinations are required. Because VirtualNetwork includes peered networks, a default NSG allows all traffic between peered VNets. If you want to isolate a peered spoke, you must add an explicit deny with a lower priority number than 65000.

Evaluation across subnet and NIC

If both the subnet and the NIC have an NSG, traffic is evaluated by both:

• Inbound: the subnet NSG is evaluated first, then the NIC NSG. Both must allow the flow.
• Outbound: the NIC NSG is evaluated first, then the subnet NSG. Both must allow the flow.

A frequent exam trap is a VM that cannot be reached even though the NIC NSG has an allow rule: the subnet NSG denies it. A rule in either NSG is enough to block, so an allow in one never overrides a deny in the other.

Creating an NSG and a rule

These Bash examples assume the named resource groups, VNets, subnets and NICs already exist and that the caller can update their networking.

az network nsg create -g rg-net -n nsg-web -l westeurope

az network nsg rule create -g rg-net --nsg-name nsg-web -n allow-https \
  --priority 100 --direction Inbound --access Allow --protocol Tcp \
  --source-address-prefixes Internet --destination-port-ranges 443

az network vnet subnet update -g rg-net --vnet-name vnet-hub \
  -n snet-web --network-security-group nsg-web

Worked example 1: the database that web servers cannot reach

Scenario. Fabrikam has two subnets in one VNet: snet-web (10.0.1.0/24) and snet-data (10.0.2.0/24). An NSG on snet-data has these inbound rules:

A web server at 10.0.1.5 cannot connect to SQL at 10.0.2.10 on 1433. A second NSG on the NIC of the SQL VM allows VirtualNetwork on 1433.

Reasoning.

1. Inbound flow: subnet NSG first. Rule 100 matches source 10.0.1.5, destination port 1433, so it allows the flow and processing stops. The subnet NSG is not the problem.
2. The NIC NSG is evaluated next. It allows VirtualNetwork on 1433, so that also passes.
3. The NSG layer therefore allows the flow. The cause is elsewhere: the SQL service, the guest firewall, or a route. Use IP flow verify to confirm the NSG decision and Connection troubleshoot to test the port end to end.

Why the tempting answers are weaker. Deleting rule 200 changes nothing because rule 100 already matches first, and moving the NSG to the NIC does not change the result.

Application security groups

The problem ASGs solve

Writing NSG rules with IP addresses is fragile: servers are added, removed and re-addressed. An application security group is a label you attach to NICs, so a rule can refer to "all web servers" or "all database servers".

How they work:

• An ASG is a named object in a region. You add a NIC (and therefore its VM) to one or more ASGs.
• In an NSG rule you use an ASG as source or destination in place of an IP address.
• All NICs in an ASG must be in the same virtual network. In exam terms: ASGs work inside one VNet, not across peered VNets.
• ASGs can be used together with service tags in the other side of the rule.

az network asg create -g rg-net -n asg-web -l westeurope
az network asg create -g rg-net -n asg-sql -l westeurope

az network nic ip-config update -g rg-net --nic-name nic-web1 -n ipconfig1 \
  --application-security-groups asg-web

az network nic ip-config update -g rg-net --nic-name nic-sql1 -n ipconfig1 \
  --application-security-groups asg-sql

az network nsg create -g rg-net -n nsg-data -l westeurope

az network nsg rule create -g rg-net --nsg-name nsg-data -n allow-web-to-sql \
  --priority 100 --direction Inbound --access Allow --protocol Tcp \
  --source-asgs asg-web --destination-asgs asg-sql --destination-port-ranges 1433

az network vnet subnet update -g rg-net --vnet-name vnet-hub \
  -n snet-data --network-security-group nsg-data

Evaluating effective security rules

Use Azure Monitor and Network Watcher diagnostics to connect a denied-flow test with longer-term investigation.

When several NSGs, default rules and ASGs interact, reading each NSG is error prone. Azure shows the effective security rules of a NIC: the combined result of the subnet NSG and the NIC NSG. In the portal, open the VM's network interface and choose Effective security rules. In the CLI:

az network nic list-effective-nsg -g rg-net -n nic-web1

For a specific flow, use Network Watcher IP flow verify. You supply the VM, direction, protocol, local and remote IP and port, and it returns Access allowed or Access denied and the name of the rule that made the decision. Use NSG diagnostics in Network Watcher to see all NSGs that apply to a flow in one view. Effective rules describe configuration, while virtual network flow logs record supported flows to Azure Storage; optional Traffic Analytics aggregates them into a Log Analytics workspace. New NSG flow logs cannot be created after June 30, 2025, and existing NSG flow logs retire on September 30, 2027. NSG diagnostic event/counter logs are a separate source and do not replace flow logging.

Azure Bastion

Why Bastion

Opening RDP or SSH to the internet exposes the VMs to brute-force attacks and to any vulnerability in the management service. Azure Bastion is a managed PaaS service. Dedicated deployments run in your VNet; the Developer SKU uses shared infrastructure. Administrators connect to VMs through the Azure portal (or the native client in supported SKUs) over TLS on port 443, and Bastion connects to the VM using its private IP on RDP or SSH. The VM needs no public IP and no inbound RDP/SSH rule from the internet.

Requirements and facts:

• Dedicated Basic, Standard and Premium deployments need AzureBastionSubnet, /26 or larger. The shared Developer SKU does not require this dedicated subnet.
• Normal dedicated deployments use a Standard SKU static public IP on Bastion. Premium private-only deployment has no public IP and requires a private client network path; Developer also differs. Target VMs do not need public IPs.
• Bastion in a VNet can reach VMs in that VNet and, with peering and the right SKU, VMs in peered VNets.
• The NSG on the VM subnet must allow inbound RDP (3389) or SSH (22) from the AzureBastionSubnet range. For a normal public dedicated deployment, an NSG on AzureBastionSubnet needs the full documented rules: inbound TCP 443 from permitted clients, GatewayManager and AzureLoadBalancer; inbound/outbound 8080 and 5701 between VirtualNetwork addresses; outbound management ports to target VMs, TCP 443 to AzureCloud and port 80 to Internet for validation. Follow the SKU-specific rules for private-only deployments and custom management ports.

SKUs

If a question asks for native client connection, IP-based connection to a resource that is not an Azure VM, or scale units, the answer is at least Standard. Upgrading is allowed; downgrading is not, so you delete and re-create.

az network vnet subnet create -g rg-net --vnet-name vnet-hub \
  -n AzureBastionSubnet --address-prefixes 10.10.250.0/26
az network public-ip create -g rg-net -n pip-bastion -l westeurope --sku Standard --allocation-method Static
az network bastion create -g rg-net -n bastion-hub -l westeurope --vnet-name vnet-hub \
  --public-ip-address pip-bastion --sku Standard

Worked example 2: closing RDP on 20 VMs

Scenario. Northwind runs 20 VMs in vnet-prod. Each has a public IP and an NSG rule allowing 3389 from Internet. A security audit requires that administrators can still use RDP in the portal, no VM has a public IP, and the solution must be managed by Microsoft, not by Northwind.

Reasoning.

1. Create AzureBastionSubnet (/26) in vnet-prod and deploy Bastion with a Standard public IP.
2. Change the NSG rule on the VM subnet: source is the Bastion subnet prefix (10.0.250.0/26) instead of Internet, destination port 3389.
3. Dissociate and delete the public IPs of the VMs.
4. Test by connecting through the portal's Connect → Bastion option.

Why the other choices are weaker. A VPN gateway also removes the public exposure, but it is not "managed RDP in the portal" and requires client configuration. A jump box VM that Northwind patches and secures contradicts the managed requirement. Restricting the NSG to a corporate IP range reduces exposure but still leaves public IPs, which the audit prohibits.

Service endpoints

What they do

A service endpoint extends your VNet's identity to a supported Azure PaaS service over the Azure backbone. After you enable the endpoint for a subnet (for example Microsoft.Storage), traffic from that subnet to the service uses the subnet's private source address (instead of a public NAT address) and stays on the Microsoft network. The service firewall can then restrict its public endpoint to the subnet, provided other network rules and bypass exceptions do not grant additional access. Data authorization is still required.

Important points:

• The PaaS resource keeps its public IP and public endpoint. The service only learns to recognise your subnet. You still need the PaaS firewall to deny other traffic.
• The classic service-endpoint setting is made in two places: on the subnet (enable the service endpoint) and on the PaaS resource (add a virtual network rule for that subnet and set the default action to deny). Forgetting the second part is the classic mistake: the endpoint is enabled but the storage account still accepts the whole internet.
• Classic service endpoints have no additional endpoint charge and need no DNS change; normal service and transfer charges still apply. Microsoft also documents Standard service endpoint as a separate preview capability; do not confuse it with the classic subnet endpoint used here.
• They work for traffic originating in the VNet; they do not extend to on-premises networks over VPN or ExpressRoute (those need the on-premises public IPs added to the resource firewall, or a private endpoint).
• Supported services include Storage, Azure SQL Database, Cosmos DB, Key Vault, Service Bus, Event Hubs and others (Microsoft.Storage, Microsoft.Sql, Microsoft.KeyVault, …).
• Service endpoint policies let you restrict a subnet to specific storage accounts, so a VM in the subnet cannot reach someone else's storage account through the same endpoint.

az network vnet subnet update -g rg-net --vnet-name vnet-hub -n snet-app \
  --service-endpoints Microsoft.Storage

az storage account update -g rg-data -n stcontosodata --default-action Deny
appSubnetId="$(az network vnet subnet show -g rg-net --vnet-name vnet-hub \
  -n snet-app --query id -o tsv)"
az storage account network-rule add -g rg-data --account-name stcontosodata \
  --subnet "$appSubnetId"

Private endpoints

What they do

A private endpoint is a network interface in your subnet that receives a private IP address from your address space and is connected to one specific instance of a PaaS service (a storage account's blob endpoint, a SQL server, a Key Vault, a web app) through Azure Private Link. Clients address the service through that private IP over the Azure backbone, and you can disable the public endpoint of the service entirely.

Key points:

• One private endpoint targets a single resource and a single sub-resource (the "group ID"). A storage account needs one for blob, another for file, and so on.
• It works for traffic from the VNet, peered VNets, and on-premises networks over VPN or ExpressRoute because it is a private IP in your range.
• It costs money (per hour and per GB), unlike service endpoints.
• A private endpoint connection can be approved automatically when the caller has the required resource permissions, or needs manual approval when the caller lacks those permissions. Verify the connection is Approved. A private endpoint does not automatically disable the service’s public endpoint or grant data-plane access; configure both explicitly.

Private endpoint DNS and hybrid forwarding

Review private DNS zones and hybrid name resolution when the same service must resolve privately from Azure and head office.

The client still connects to the service's normal name, for example stcontosodata.blob.core.windows.net. For the traffic to use the private IP, the name must resolve to the private IP inside your network. The public DNS record is a CNAME to stcontosodata.privatelink.blob.core.windows.net, so you create a private DNS zone named privatelink.blob.core.windows.net, add an A record for the private IP, and link the zone to the VNet. The portal can create the zone, the A record and the link for you when you tick the integration option.

If the zone is not linked to the VNet, clients resolve the public IP, which fails once public access is disabled (or silently uses the public path if it is still enabled). When on-premises users must reach the private endpoint, configure on-premises conditional forwarding for the service’s recommended public DNS suffix, such as blob.core.windows.net, to an Azure DNS Private Resolver inbound endpoint or an Azure-hosted DNS forwarder. That resolver’s VNet must be linked to privatelink.blob.core.windows.net. The public-name CNAME chain is then resolved using the private zone. Do not point an on-premises DNS server directly at 168.63.129.16; that platform address is reachable from Azure VNets.

az network private-endpoint create -g rg-net -n pe-blob \
  --vnet-name vnet-hub --subnet snet-pe \
  --private-connection-resource-id "$(az storage account show -g rg-data -n stcontosodata --query id -o tsv)" \
  --group-id blob --connection-name pe-blob-conn

az network private-dns zone create -g rg-net -n privatelink.blob.core.windows.net
az network private-dns link vnet create -g rg-net -n link-hub \
  -z privatelink.blob.core.windows.net -v vnet-hub -e false
az network private-endpoint dns-zone-group create -g rg-net --endpoint-name pe-blob \
  -n default --private-dns-zone privatelink.blob.core.windows.net --zone-name blob

The private endpoint subnet must support private endpoints and must not be delegated to another service. If NSG or UDR filtering is required for private-endpoint traffic, enable the corresponding private endpoint network policies and verify their effective behavior. DNS resolution, endpoint approval, routing and data permissions are separate checks.

Comparison: service endpoint versus private endpoint

Worked example 3: storage that on-premises users must reach privately

Scenario. Adatum stores reports in stadatumreports. Requirements: the account must not be reachable from the internet; applications in vnet-prod and users in the head office (connected through site-to-site VPN) must reach it; and only that one account may be exposed to the network.

Reasoning.

1. Service endpoint? It allows only VNet subnets, does not serve on-premises traffic over VPN, and leaves the public endpoint in place. Rejected.
2. Private endpoint? It gives a private IP, works from the VNet and over VPN, allows the public network access setting to be disabled, and targets just this account.
3. Create a private endpoint for sub-resource blob (and file if needed) in a subnet of vnet-prod, create the privatelink.blob.core.windows.net zone, link it to vnet-prod, configure on-premises DNS to forward blob.core.windows.net to the Azure resolver, and set Public network access: Disabled.

Why other choices are weaker. A storage firewall allowing the head-office public IPs keeps the endpoint public, and an NSG cannot remove a service's public endpoint.

Pitfalls and exam tips

• Lower priority number wins. Priority 100 beats 200. The default rules at 65000+ are always last.
• Both NSGs must allow. For inbound, subnet NSG then NIC NSG; for outbound the reverse. An allow never overrides a deny in the other NSG.
• NSGs are stateful. Do not add return-traffic rules.
• VirtualNetwork includes peered VNets. A default NSG does not isolate a peered network.
• ASGs work within one VNet and are attached to NICs.
• Dedicated Bastion needs AzureBastionSubnet /26 or larger. Developer uses shared infrastructure; Premium private-only omits the public IP.
• Service endpoint = two steps: enable it on the subnet and add the virtual network rule on the PaaS firewall.
• Service endpoints do not serve on-premises traffic; private endpoints do.
• Private endpoints need correct name resolution. A linked private zone is the common solution; custom DNS must return the same private mapping.
• IP flow verify names the rule; Next hop is for routing, not for NSGs.

Exam tip: When two options both "work", prefer the one that meets every stated constraint with the least administrative effort. "No public IP on the VM" plus "managed service" points to Bastion; "no public endpoint on the PaaS resource" points to a private endpoint.

Mini case study: Tailwind Traders

Tailwind Traders runs a three-tier app in vnet-app (10.4.0.0/16) with subnets snet-web, snet-app and snet-data. Requirements:

1. Only HTTPS from the internet to the web tier.
2. The app tier may be reached only from web servers on port 8080, and SQL (1433) only from app servers, even as servers are added.
3. Administrators must connect to every VM without public IPs.
4. A storage account sttailwindlogs must be reachable only from snet-app, cheaply, and a second account sttailwindarchive must have no public access but be readable from head office over ExpressRoute.
5. A support engineer reports that the app server 10.4.2.7 cannot reach SQL at 10.4.3.5 on 1433.

Solution.

1. Create nsg-web on snet-web with an Internet-to-web TCP 443 allow at priority 100. Add the required Bastion management allow and any required load-balancer probe allow before an explicit lateral-traffic deny. The default AllowVnetInBound otherwise permits internal access beyond HTTPS.
2. Create ASGs asg-web, asg-app and asg-sql, add the NICs to them, and write rules: asg-web to asg-app on 8080 and asg-app to asg-sql on 1433. For each tier, place the permitted app flows, Bastion management ports and required probes before a VirtualNetwork deny at priority 4000, which is still before the default allow at 65000. Use explicit priorities, for example 100/110 for permitted traffic and 4000 for the deny. New servers only need to join the right ASG.
3. Deploy Azure Bastion with an AzureBastionSubnet /26; allow 3389 and 22 from that subnet in each tier's NSG; remove public IPs.
4. For sttailwindlogs: enable the Microsoft.Storage service endpoint on snet-app, set the storage default action to Deny, and add the virtual network rule. For sttailwindarchive: create a private endpoint (sub-resource blob) in a dedicated subnet, link privatelink.blob.core.windows.net to the VNet, forward on-premises DNS, and disable public network access.
5. Run IP flow verify for the app VM’s outbound TCP flow (local app IP and ephemeral source port, remote SQL IP:1433), then for the SQL VM’s inbound flow (local SQL IP:1433 and the same remote app IP/source port). A source-VM test cannot evaluate the destination VM’s inbound NSGs. If denied, inspect the named rule on the VM and direction being tested. If it says allowed, test with Connection troubleshoot and check the SQL service and guest firewall.

Commentary. The design shows each control in its place: NSG and ASG for filtering between tiers, Bastion for management access, a service endpoint for the cheap subnet restriction, a private endpoint when on-premises access and no public endpoint are required.

Key terms

• NSG: stateful layer 3/4 filter with priority-ordered allow and deny rules.
• Service tag: Microsoft-managed group of IP prefixes for a service or the internet.
• ASG: label attached to NICs, used in NSG rules instead of IP addresses (one VNet).
• Effective security rules: the combined NSG result on a NIC.
• IP flow verify: Network Watcher check of a 5-tuple against NSG rules, naming the rule.
• Azure Bastion: managed RDP/SSH access to private-IP VMs, with shared, dedicated and Premium private-only deployment options.
• Service endpoint: subnet-level route to a PaaS service over the backbone, identifying the subnet to the service firewall.
• Private endpoint / Private Link: private IP in your subnet mapped to a single PaaS resource.
• Private DNS zone (privatelink.*): zone that resolves the service name to the private IP.

Summary checklist

• I can write NSG rules and predict the outcome using priority and the default rules.
• I know that inbound evaluates the subnet NSG then the NIC NSG, and that both must allow.
• I can use application security groups and service tags in rules, and I know ASGs are limited to one VNet.
• I can use effective security rules and IP flow verify to explain a denied flow.
• I can deploy Azure Bastion in AzureBastionSubnet (/26) and choose between its SKUs.
• I can configure a service endpoint on a subnet and the matching rule on the PaaS firewall.
• I can create a private endpoint with a linked private DNS zone and explain why DNS matters.
• I can choose between a service endpoint and a private endpoint from the requirements.

Official sources

• AZ-104 study guide: https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/az-104 (opens in a new tab)
• Network security groups: https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview (opens in a new tab)
• Application security groups: https://learn.microsoft.com/en-us/azure/virtual-network/application-security-groups (opens in a new tab)
• Azure Bastion: https://learn.microsoft.com/en-us/azure/bastion/bastion-overview (opens in a new tab)
• Virtual network service endpoints: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview (opens in a new tab)
• Private endpoints: https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview (opens in a new tab)
• Private endpoint DNS configuration: https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/bastion/bastion-nsg (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/bastion/design-architecture (opens in a new tab)
• Microsoft documentation: https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns-integration (opens in a new tab)
• NSG flow-log retirement guidance: https://learn.microsoft.com/en-us/azure/network-watcher/nsg-flow-logs-overview (opens in a new tab)