Skip to main content
In this lesson we focus on Azure Bastion — a fully managed PaaS service that provides secure, browser-based RDP and SSH connectivity to virtual machines (VMs) directly through the Azure portal. Azure Bastion allows you to connect to VMs without exposing them via public IP addresses or opening inbound ports, significantly reducing your attack surface while simplifying remote operations. Bastion is deployed inside your virtual network and requires a dedicated subnet named AzureBastionSubnet plus a public IP for the Bastion resource; the VMs you connect to do not require public IP addresses. Learning objectives
  • Understand what Azure Bastion is and when to use it.
  • Learn how Bastion enables RDP/SSH connectivity through the Azure portal.
  • Understand the architecture and how Bastion removes the need for public IP addresses on VMs.
  • Learn the basic steps to connect to a VM using Azure Bastion.
Azure Bastion acts as a managed jump host inside your virtual network. It proxies RDP/SSH sessions over TLS through the Azure portal so you don’t need to open inbound ports or assign public IPs to your VMs. Use Bastion to centralize secure remote access while keeping VM network interfaces private.

​
What is Azure Bastion?

Azure Bastion is a managed platform service that provides secure RDP and SSH connectivity to VMs directly from the Azure portal using TLS. Unlike a traditional jump box (bastion host VM) that you must manage and patch, Azure Bastion is maintained by Microsoft and scales automatically. It sits inside your Virtual Network (VNet) and proxies connections to private IPs of VMs, removing the need to expose VM public IPs or open RDP/SSH inbound ports. Key benefits
  • No public IPs required on VMs.
  • No inbound NSG rules for RDP/SSH needed.
  • Browser-based RDP/SSH from the Azure portal or native clients (depending on configuration).
  • Managed, highly available PaaS offering that removes VM management overhead.

​
How Azure Bastion works (Architecture overview)

  • Azure Bastion is deployed inside a VNet and requires a dedicated subnet named AzureBastionSubnet.
  • A public IP address is assigned to the Bastion resource (not to individual VMs).
  • When you initiate a connection from the Azure portal, the portal establishes a secure TLS session to the Bastion service. Bastion then proxies that session to the target VM using its private IP.
  • All traffic between the portal and Bastion is encrypted; no RDP/SSH inbound rules on the VM are required.
Typical flow:
  1. User clicks “Connect” -> “Bastion” in the Azure portal for a given VM.
  2. Browser establishes TLS to Azure Bastion (public IP of Bastion).
  3. Bastion proxies the connection to the VM’s private IP inside the VNet.

​
Requirements and constraints

  • The subnet name must be exactly: AzureBastionSubnet
  • The AzureBastionSubnet must have a minimum prefix of /26 (to accommodate scale and future features).
  • Bastion requires a Standard SKU Public IP (static recommended).
  • Bastion is deployed into the same VNet as the target VMs (or a peered VNet with appropriate routing/peering).
  • Ensure Network Security Groups (NSGs) allow necessary outbound traffic from the AzureBastionSubnet.
Important: The subnet for Bastion must be named exactly AzureBastionSubnet and be at least /26 in size. Deploying with a smaller prefix or a different name will fail.

​
Quick deployment examples

Below are common Azure CLI snippets to create the required subnet, public IP, and Bastion resource. Replace placeholders (resource group, VNet name, location) with your values. Create the AzureBastionSubnet in your VNet: 
az network vnet subnet create \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --name AzureBastionSubnet \
  --address-prefixes 10.0.255.0/26
Create a Standard SKU public IP for Bastion: 
az network public-ip create \
  --resource-group MyResourceGroup \
  --name MyBastionPIP \
  --sku Standard \
  --allocation-method Static
Create the Bastion host: 
az network bastion create \
  --resource-group MyResourceGroup \
  --name MyBastionHost \
  --public-ip-address MyBastionPIP \
  --vnet-name MyVNet \
  --location eastus
Note: You can also deploy Bastion from the Azure portal via the “Create a resource” workflow — select Bastion and follow the guided steps to choose the VNet, create the AzureBastionSubnet, and assign a public IP.

​
Connecting to a VM using Azure Bastion

  1. In the Azure portal, navigate to the VM you want to access.
  2. Select “Connect” and choose “Bastion”.
  3. If Bastion is already deployed in the VM’s VNet, the Bastion connection pane will appear. Provide credentials (username/password or SSH private key) and click “Connect”.
  4. A browser-based RDP or SSH session will open over TLS and proxy to the VM’s private IP.
If Bastion is not deployed, the portal provides a shortcut to create Bastion directly from the VM’s “Connect” blade.

​
Comparison: Remote access options

Resource TypeExposureManagement OverheadWhen to use
Azure BastionNo public IPs on VMs; Bastion has public IPLow (PaaS managed)Secure, portal-based access without public VM IPs
Public IP on VM + NSG rulesVM public IP exposedMedium (manage NSGs, patching)Quick access but higher attack surface
Jump box (VM)Jump VM has public IPHigh (maintain VM, HA, patching)When advanced agentless workflows or full-control jump hosts are required

​
Security and best practices

  • Use role-based access control (RBAC) to restrict who can create and use Bastion.
  • Audit Bastion usage with Azure Activity Logs and Azure Monitor.
  • Use private link or VNet peering cautiously; ensure routing and NSGs allow Bastion-to-VM connectivity.
  • Keep the AzureBastionSubnet sized to /26 or larger to allow failures-free scaling.
  • Combine Bastion with Just-In-Time (JIT) and conditional access where appropriate to strengthen access controls.
Use these resources to plan deployments, verify requirements, and follow step-by-step tutorials for production-ready Azure Bastion configurations.

Watch Video