Azure Bastion, Service & Private Endpoints
How do you securely connect to VMs without exposing RDP to the internet? How do you lock down PaaS services like Storage and SQL so they're only reachable from your VNet? Bastion, service endpoints, and private endpoints solve these problems.
What is Azure Bastion?
Azure Bastion is like a secure reception desk in your office building lobby. Instead of giving every employee a street-facing door (public IP), everyone enters through the reception desk and gets escorted to their office.
Without Bastion, connecting to a VM via RDP or SSH typically means giving the VM a public IP and opening port 3389 or 22 to the internet — which is a massive security risk. Bastion lets you connect through the Azure portal’s browser, using TLS over port 443. No public IPs on VMs needed, no ports exposed.
Azure Bastion requirements
| Requirement | Detail |
|---|---|
| Dedicated subnet | Must be named exactly “AzureBastionSubnet” |
| Minimum subnet size | /26 (64 addresses) or larger |
| Public IP | Bastion itself needs a Standard SKU static public IP |
| SKU tiers | Basic (limited features) and Standard (native client, shareable links, IP-based connections) |
What Bastion eliminates:
- No public IPs on VMs
- No NSG rules for RDP (3389) or SSH (22) from the internet
- No VPN or ExpressRoute needed just for management access
- No jump box VMs to maintain
Exam tip: Bastion subnet requirements
The subnet MUST be named exactly AzureBastionSubnet — any other name will fail. It must be at least /26 (64 addresses). Bastion deploys instances into this subnet that scale based on concurrent sessions. A smaller subnet limits how many concurrent sessions you can support.
Real-world: TechCorp removes public IPs
TechCorp Solutions had public IPs on 30 VMs for RDP access, with NSG rules limiting source IPs to the office. After a security audit flagged the risk, Alex deployed Azure Bastion. He removed all 30 public IPs, deleted the RDP NSG rules, and now the team connects via the Azure portal browser. The security auditor was happy, and Alex no longer has to maintain a jump box VM.
Service Endpoints vs Private Endpoints
Both secure access to Azure PaaS services (Storage, SQL Database, Key Vault), but they work very differently.
| Feature | Service Endpoint | Private Endpoint |
|---|---|---|
| How it works | Extends VNet identity to the PaaS service over Azure backbone | Gives the PaaS service a private IP inside your VNet |
| Traffic path | Azure backbone (not public internet) but uses the public IP of the service | Entirely within your VNet via a private IP |
| Public endpoint | Still exists — you add VNet rules to restrict access | Can be disabled entirely |
| DNS resolution | Resolves to public IP (traffic routed via backbone) | Resolves to private IP in your VNet |
| On-prem access | On-prem cannot use the service endpoint path | On-prem can reach via VPN/ExpressRoute (private IP) |
| Cost | Free | Per-hour charge plus data processing fee |
| Configuration | Enable on subnet + add VNet rule to PaaS service | Create endpoint + NIC in subnet + private DNS zone |
Service endpoints in detail
Service endpoints optimise routing by sending traffic to Azure PaaS services over the Azure backbone instead of the public internet.
How to set up:
- Enable the service endpoint on the subnet (e.g., Microsoft.Storage, Microsoft.Sql)
- Add a VNet rule on the PaaS service’s firewall to allow traffic from that subnet
- Optionally deny all other public access
Key limitation: The PaaS service still has a public endpoint. Service endpoints just add a VNet-based access rule. On-prem devices accessing via VPN/ExpressRoute cannot leverage the service endpoint path.
Private endpoints in detail
Private endpoints bring the PaaS service INTO your VNet by assigning it a private IP address.
How to set up:
- Create a private endpoint targeting the PaaS resource (e.g., a storage account)
- Azure creates a network interface in your subnet with a private IP
- Configure a private DNS zone so the service name resolves to the private IP
- Optionally disable the PaaS service’s public endpoint entirely
Key advantage: Traffic never leaves your VNet. On-prem devices can reach the service via VPN/ExpressRoute because it’s just a private IP. You can fully disable public access.
Exam tip: Service endpoints don't remove public access
Service endpoints do NOT remove the public endpoint. They add a VNet-based firewall rule so traffic from your subnet is allowed. Someone with the storage account key could still access it from the internet unless you also deny public access.
Private endpoints, on the other hand, assign a private IP. You can then disable the public endpoint entirely — making the service accessible ONLY from within your VNet or via VPN/ExpressRoute.
Real-world: Meridian Financial locks down storage
Meridian Financial’s compliance team mandates that no storage account data can traverse the public internet. Alex implements private endpoints for all storage accounts:
- Creates private endpoints in the database subnet — each storage account gets a private IP
- Configures private DNS zones (privatelink.blob.core.windows.net) so apps resolve the storage account name to the private IP
- Disables public endpoint access on all storage accounts
- On-prem servers connect via ExpressRoute and resolve the same private IPs through DNS forwarding
Result: zero public exposure, full compliance.
Knowledge check
TechCorp Solutions wants to connect to VMs via RDP without exposing any public IPs. Which solution should Alex implement?
CloudFirst Labs configures a service endpoint for Microsoft.Storage on their app subnet and adds a VNet rule to their storage account. A developer accesses the storage account from their home laptop using the storage account key. Does it work?
Meridian Financial needs their on-premises servers (connected via ExpressRoute) to access an Azure SQL Database without any traffic traversing the public internet. Which should they use?
🎬 Video coming soon