7.6 Azure Bastion, Service Endpoints, and Private Endpoints

Azure Bastion for management access

Azure Bastion is a managed service that lets administrators connect to Azure VMs over RDP or SSH using the VM private IP. The VM does not need a public IP address. Bastion is deployed into a VNet in a subnet named AzureBastionSubnet, and administrators connect through the Azure portal or supported native client methods depending on configuration and SKU.

The exam signal is usually explicit: no public IPs on VMs, secure administrative access, browser-based RDP or SSH, or reduce exposure of management ports. Adding an inbound NSG rule from Internet to TCP 3389 or TCP 22 is the wrong direction when the requirement says avoid public exposure.

Basic diagram:

administrator browser
        |
Azure portal / Bastion public endpoint
        |
AzureBastionSubnet in hub or workload VNet
        |
VM private IP 10.41.1.4 on TCP 3389 or 22

Bastion still needs network reachability to the VM private IP and port. If an NSG blocks the Bastion subnet from reaching the VM, the connection fails. If the guest OS firewall blocks RDP or SSH, the connection fails. Bastion removes the need for VM public IPs, but it does not replace OS-level configuration.

Service endpoints

A service endpoint is enabled on a subnet for a supported Azure service such as Storage or Azure SQL in supported patterns. It extends the VNet subnet identity to the service, allowing the service firewall to permit traffic from that subnet. The service is still reached through its public endpoint, but traffic uses optimized Azure backbone routing and can be restricted to selected virtual networks and subnets.

Storage example workflow:

1. Enable the Microsoft.Storage service endpoint on the workload subnet.
2. Go to the storage account networking settings.
3. Allow selected networks.
4. Add the VNet and subnet.
5. Test from a VM in that subnet.

Service endpoints are useful when the requirement is to restrict a service to specific subnets without placing a private IP in the VNet. They are simpler than private endpoints in some scenarios, but they do not make the service resolve to a private IP in your VNet.

Private endpoints

A private endpoint creates a network interface with a private IP address in your VNet for a supported Azure service. The service is reached through that private IP. This is the stronger private access model when the requirement says access a PaaS service privately, disable public network access, or expose the service only through private IPs.

Private endpoint diagram:

VM 10.41.1.4
   |
private DNS: mystorage.blob.core.windows.net -> 10.42.5.7
   |
private endpoint NIC 10.42.5.7 in snet-private-endpoints
   |
Azure Storage blob service

DNS is the central private endpoint troubleshooting topic. The client still uses the service FQDN, such as a storage account blob endpoint or SQL server name. That name must resolve to the private endpoint IP from the client network. Azure commonly uses private DNS zones linked to VNets for this. If DNS still returns a public IP after public network access is disabled, the connection fails even though the private endpoint exists.

Service endpoint versus private endpoint

Do not treat service endpoints and private endpoints as interchangeable. A service endpoint setting on a subnet does not create a private endpoint. A private endpoint does not automatically fix a service firewall or DNS issue if the client cannot resolve or reach the private IP.

Portal and CLI patterns

Portal path for Bastion: Azure portal > Bastions > Create, or from a VM connect blade when deploying Bastion into the VNet. Confirm the subnet name and address size before deployment.

Portal path for service endpoints: Virtual networks > <vnet> > Subnets > <subnet> > Service endpoints, then configure the target service firewall to allow that subnet.

Portal path for private endpoints: Private endpoints > Create, choose the target resource and subresource, choose the VNet and subnet, and integrate with a private DNS zone when offered.

CLI snippets:

az network vnet subnet update \
  --resource-group rg-network \
  --vnet-name vnet-prod-eastus \
  --name snet-app \
  --service-endpoints Microsoft.Storage

az network private-endpoint create \
  --resource-group rg-network \
  --name pe-stor-blob-prod \
  --vnet-name vnet-prod-eastus \
  --subnet snet-private-endpoints \
  --private-connection-resource-id <storage-account-id> \
  --group-id blob \
  --connection-name peconn-stor-blob-prod

Troubleshooting private access

For Bastion failures, check that Bastion is deployed, the VM is running, the VM has a private IP in a reachable VNet, NSGs allow Bastion-to-VM management traffic, and the guest OS accepts RDP or SSH. Do not add a VM public IP as the first fix unless the requirement allows abandoning Bastion.

For service endpoint failures, check both sides: the subnet has the service endpoint enabled, and the service firewall allows that subnet. If only the subnet setting exists, the service may still deny the request. If only the storage firewall rule exists but the subnet has no endpoint, the service may not see the subnet identity as expected.

For private endpoint failures, check DNS first. From the client VM, resolve the service FQDN and confirm it returns the private endpoint IP. Then check effective routes to that IP, NSGs on the source and private endpoint subnet if applicable, service private endpoint connection approval state, and whether public network access was disabled before DNS was ready.

Scenario traps

A private endpoint is not the same as VNet peering. Peering connects networks; private endpoints connect to a service through a private IP. A service endpoint is not the same as private DNS. Bastion is not a generic reverse proxy for web apps. NAT Gateway is not a Bastion replacement because it handles outbound SNAT, not interactive management.

A frequent AZ-104 trap says a storage account was restricted to selected networks, and a VM in a subnet still cannot access it. The missing step may be enabling the service endpoint on the subnet or adding the subnet to the storage firewall. Another says public access was disabled after a private endpoint was created, but clients still fail. The likely answer is private DNS zone configuration or VNet link, not creating a public IP for the client VM.