Azure Bastion

Azure Bastion is a fully managed Platform-as-a-Service (PaaS) offering that provides secure, seamless Remote Desktop Protocol (RDP) and Secure Shell (SSH) access to Azure virtual machines (VMs) directly through the Azure portal, over TLS. Its primary purpose is to eliminate the need for public IP addresses on VMs for remote management, thereby reducing the attack surface. Without Bastion, administrators often resort to creating VMs with public IPs and opening RDP (port 3389) or SSH (port 22) to the internet, which is a leading cause of brute-force attacks and compromises. Alternatively, they might use a jump box — a VM with a public IP that acts as a gateway — but that still requires managing, patching, and securing that VM. Azure Bastion replaces the jump box model with a Microsoft-managed, hardened service that is automatically updated and patched.

Azure Bastion is deployed inside a virtual network (VNet) in a dedicated subnet named AzureBastionSubnet (minimum /27). It is not a VM; it is a PaaS resource that scales automatically based on the number of concurrent sessions. Here's the step-by-step mechanism:

- AzureBastionSubnet: Must be named exactly AzureBastionSubnet (case-sensitive). Minimum prefix length /27 (e.g., 10.0.0.0/27 gives 32 addresses, of which 11 are used by Azure). Must be in the same VNet as the VMs you want to connect to. You cannot use a different VNet for Bastion and VMs unless you use VNet peering (supported). - SKU Tiers: - Basic: Supports up to 2 concurrent RDP/SSH connections per scale unit. No premium features. No support for private-only endpoints. Default if not specified. - Standard: Supports up to 50 concurrent connections per scale unit. Includes features like IP-based connections, private-only access (no public IP on Bastion), and session recording (preview). - Scale Units: Each scale unit provides a certain number of concurrent sessions. For Basic: 2 sessions/unit. For Standard: 50 sessions/unit. You can scale up to 50 units (100 sessions Basic, 2500 sessions Standard). - Connection Timeout: Idle timeout for Bastion sessions is 30 minutes. The session is terminated after 30 minutes of inactivity. - Ports: Bastion uses port 443 for HTTPS/WebSocket traffic. The VM must allow outbound HTTPS to the Bastion host's private IP (or to AzureCloud service tag if using public endpoint). No inbound ports need to be open on the VM. - Authentication Methods: Azure AD authentication (password or MFA) for Windows VMs (requires Azure AD login extension), local username/password, SSH keys (for Linux). For Azure AD login, the VM must be domain-joined or have the AADSSHLoginForLinux extension.

To deploy Bastion using Azure CLI:

# Create resource group
az group create --name MyBastionRG --location eastus

# Create VNet and subnet (must be named AzureBastionSubnet)
az network vnet create --name MyVNet --resource-group MyBastionRG --location eastus --address-prefix 10.0.0.0/16
az network vnet subnet create --name AzureBastionSubnet --resource-group MyBastionRG --vnet-name MyVNet --address-prefixes 10.0.1.0/27

# Create public IP (optional, required for Basic SKU)
az network public-ip create --name MyBastionPublicIP --resource-group MyBastionRG --location eastus --sku Standard

# Create Bastion host
az network bastion create --name MyBastion --resource-group MyBastionRG --vnet-name MyVNet --public-ip-address MyBastionPublicIP --location eastus

To verify Bastion status:

az network bastion show --name MyBastion --resource-group MyBastionRG --query "provisioningState"

To connect to a VM via Bastion using CLI (requires Azure CLI bastion extension):

az network bastion ssh --name MyBastion --resource-group MyBastionRG --target-resource-id $(az vm show -g MyVMResourceGroup -n MyVM --query id -o tsv) --auth-type password --username azureuser

A financial services company with strict compliance requirements (PCI-DSS, SOC 2) must allow its IT team to manage hundreds of VMs in Azure. They cannot expose any VM to the internet with a public IP. Previously, they used a jump box VM with a public IP, but that jump box itself became a target and required constant patching. They deployed Azure Bastion (Standard SKU) in a hub VNet with private-only mode, peered with multiple spoke VNets containing the VMs. The Bastion host has no public IP; all traffic stays within the Microsoft backbone. IT staff authenticate using Azure AD with MFA. The VMs have the AADLoginForWindows extension, so they don't need local accounts. The Bastion host is scaled to 5 scale units (250 concurrent sessions) to handle peak maintenance windows. They monitor session activity using Bastion's diagnostics logs sent to Log Analytics. The result: reduced attack surface, simplified compliance, and no jump box to maintain.

A SaaS provider has developers and support engineers across the globe who need occasional RDP/SSH access to customer-facing VMs. They use Azure Bastion Basic SKU with a public IP. The Bastion host is deployed in the same VNet as the VMs. Because the Basic SKU only supports 2 concurrent sessions per scale unit, they set up multiple Bastion hosts in different regions for load distribution. They use RBAC to restrict which users can connect to which VMs. They found that the 30-minute idle timeout is sometimes too short for long debugging sessions; they must train users to keep the session active. They also discovered that if the Bastion host's public IP is blocked by a corporate firewall, users must connect from a network that allows outbound HTTPS to Azure.