Azure Bastion Overview: Secure VM Access Without Public SSH

What problem Bastion solves

The traditional way to SSH into an Azure VM is to give it a public IP and open port 22 in the Network Security Group. That works, but creates two problems:

• Attack surface. Any public IP with port 22 open immediately attracts brute-force attempts, credential stuffing, and exploit probing. Even with key-based auth blocking password guessing, you are still exposing the SSH daemon and any vulnerabilities in it.
• Operational complexity. Maintaining allowlists of IP ranges for developers, updating them when IPs change, and auditing who connected when is ongoing manual work.

Bastion removes both problems. The VM has no public IP. Port 22 and 3389 are not open in the NSG. Your developers connect through the Azure portal using their Entra ID credentials — the same credentials that control access to every other Azure resource. Access is revoked by removing the RBAC role assignment, not by editing NSG rules or SSH key files.

How Bastion works

Azure Bastion deploys into a dedicated subnet called AzureBastionSubnet (the name is required — Azure will not recognise a differently-named subnet). The Bastion service gets a public IP and exposes an HTTPS endpoint. When you connect through the portal:

1. Your browser opens an HTTPS connection to the Bastion service’s public IP.
2. Bastion authenticates you with your Entra ID session.
3. Bastion opens an SSH or RDP connection to your VM using the VM’s private IP inside the VNet.
4. The terminal or remote desktop session runs in your browser over WebSocket.

The VM sees an SSH connection originating from the AzureBastionSubnet range, not from the internet. The NSG on the VM needs to allow SSH from that subnet only.

Deploying Azure Bastion

Bastion requires a dedicated subnet in the VNet where your VMs live. The subnet must be named exactly AzureBastionSubnet and must be at least /26 (64 addresses).

# Add the AzureBastionSubnet to your existing VNet
az network vnet subnet create \
  --resource-group my-rg \
  --vnet-name my-vnet \
  --name AzureBastionSubnet \
  --address-prefix 10.0.255.0/26

# Create a public IP for Bastion (Standard SKU required)
az network public-ip create \
  --resource-group my-rg \
  --name my-bastion-pip \
  --sku Standard \
  --location eastus

# Create the Bastion host (Basic SKU)
az network bastion create \
  --resource-group my-rg \
  --name my-bastion \
  --vnet-name my-vnet \
  --public-ip-address my-bastion-pip \
  --location eastus \
  --sku Basic

Bastion provisioning takes 5–10 minutes. Once deployed, navigate to any VM in the portal, click Connect, and choose Bastion. You authenticate with your Entra ID account (and the VM’s admin username and SSH key or password), and a browser-based terminal opens.

Native client support (Standard SKU)

The Standard SKU adds the ability to use your local SSH or RDP client rather than the browser. This is useful when you need SSH features that the browser terminal does not support — such as SCP file transfers, port forwarding, or terminal multiplexers.

# Connect to a VM using the Azure CLI and your local SSH client
az network bastion ssh \
  --resource-group my-rg \
  --name my-bastion \
  --target-resource-id /subscriptions/.../virtualMachines/my-vm \
  --auth-type ssh-key \
  --username azureuser \
  --ssh-key ~/.ssh/azure-vm-key

With native client support, Bastion tunnels the SSH session through HTTPS. Your local SSH client connects to a localhost port that Bastion maps to the VM’s private SSH port. The session looks and behaves like a normal SSH connection, but traffic never leaves Azure’s network unencrypted and no public IP is needed on the VM.

SKU comparison

When Bastion is not the right tool

Bastion is a good fit for most teams, but not all:

• If you need SCP or SFTP file transfers, the basic browser terminal does not support them. The Standard SKU with native client solves this, but adds cost.
• If you run dozens of VMs and need bulk SSH automation, tools like Ansible, Azure Run Command, or SSH via a VPN are more practical than connecting through Bastion for each VM.
• If cost is a hard constraint, a jump host (a small VM in the same VNet with a public IP) can serve the same isolation purpose at lower cost — though with more operational overhead.