Azure Bastion provides managed RDP and SSH connectivity to Azure virtual machines through the Azure portal or supported native clients. It is deployed in a virtual network and lets you connect to VMs using private IP addresses, so the VMs do not need public IP addresses for Bastion access.
Understand what Azure Bastion changes
Bastion carries remote access over TLS on port 443 and protects VMs from direct internet exposure and port scanning. It does not remove the need for identity, VM permissions, network controls, or careful administration. [1]
Azure Bastion has Developer, Basic, Standard, and Premium SKUs. Developer is intended for development and testing in supported regions. Basic, Standard, and Premium use a dedicated AzureBastionSubnet; Premium also supports private-only deployment without a public IP. [1]
1. Check the prerequisites
- An Azure subscription.
- A virtual machine inside an Azure virtual network.
- Permission to read the VM and its network interface.
- For a Windows VM, inbound port 3389 available to the required access path.
- For a Linux VM, inbound port 22 available to the required access path.
The quickstart also requires Reader access on the VM and its network adapter. Confirm the virtual network before starting because Bastion uses the VM’s network configuration. [2]
2. Open the VM’s Bastion page
- Sign in to the Azure portal.
- Open the virtual machine you want to access.
- In the left menu, select Bastion.
- If necessary, expand the dedicated deployment options.
3. Deploy Bastion with the portal defaults
- Select Deploy Bastion.
- Wait for the deployment to finish.
- Review the generated Bastion resource and its network settings.
Microsoft’s portal quickstart deploys Bastion with the Standard SKU and creates the dedicated subnet and public IP configuration from the virtual network. The deployment can take around ten minutes. [2]
4. Connect to the VM
- After deployment completes, use the Connect pane.
- Choose SSH or RDP as appropriate.
- Enter the VM authentication details.
- Select Connect.
The portal opens the connection through an HTML5 client over port 443. The VM can be reached using its private IP address and does not need a public IP for this Bastion connection. [2]
5. Remove an unnecessary VM public IP
After testing Bastion, review whether the VM’s public IP is still required for another service. If it is not needed, dissociate it from the network interface and delete the unused public IP resource. Do this only after confirming that administrators and applications do not depend on it. [2]
6. Choose a suitable SKU
Use Developer for supported development or testing scenarios. Choose Basic for a fixed-capacity production deployment. Standard adds features such as scaling, native client connections, shareable links, IP-based connections, custom ports, and file transfer. Premium adds capabilities such as session recording and private-only deployment. Review current pricing and feature availability before selecting a production SKU. [1]
7. Clean up test resources
Bastion incurs hourly charges from the moment it is deployed, even when it is not actively being used. Delete the Bastion resource and related test resources when a temporary lab is complete. [2]
Common mistakes
- Leaving a public IP on the VM without a current business reason.
- Choosing a SKU without checking its regional and feature requirements.
- Forgetting that Bastion itself incurs ongoing charges.
- Opening management ports broadly rather than limiting the access path.
- Assuming Bastion replaces VM authentication and least-privilege administration.
