Azure Bastion is a PaaS service that provides secure and reliable RDP and SSH access to virtual machines, directly through the Azure portal. The provisioning of Azure Bastion service is carried out within a Virtual Network of Azure and it supports access to all the virtual machines on it attested, without having to assign public IP addresses directly to systems. This article describes how to activate the service and what things to consider.
Azure Bastion deployment is per virtual network and not per subscription or per single virtual machine. Therefore, after the configuration is complete, you will be able to access directly from the Azure portal all the virtual machines attested on the Host Bastion virtual network.
Activating the Azure Bastion service requires:
- One subnet at least /27, which should be called AzureBastionSubnet and on which the Bastion host will be attested. On this subnet is not currently supported the configuration of User Defined Routes.
- A Static Public IP address that will be assigned to the Bastion resource. The public IP must be standard SKU and must be in the same Azure region on which you want to activate the service.
On the subnet AzureBastionSubnet you can apply a specific Network Security Group (NSG). NSGs are the primary tool for controlling network traffic in Azure and allow you to filter communications with deny and permit rules.
To do this, you should review the network traffic required for Azure Bastion:
The Network Security Group (NSG) on the subnet AzureBastionSubnet must include the following rules.
Inbound security rules
- Inbound traffic from Internet: Azure Bastion Public IP address must be accessed on TCP port 443. The ports 3389/22 *are non required.
- Inbound traffic from the Azure Bastion control plane. You need to enable the port 443 inbound using the service tag GatewayManager. This allows the control plane, (Gateway Manager), to be able to communicate with Azure Bastion.
Outbound security rules
- Outbound traffic to target VMs: Azure Bastion will reach the destination VMs via private IP address. NSGs must allow outbound traffic to other destination subnets for ports 3389 and 22.
- Outbound traffic to other public endpoints in Azure. Azure Bastion must be able to connect to various public endpoints within Azure (For example,, to store diagnostic logs and metering logs). That's why, Azure Bastion must be allowed to exit with the port 443 towards the service tag AzureCloud.
For the subnet on which the machine that needs to be accessed by Azure Bastion is attested, the following rules must be provided.
Inbound security rules
- Inbound traffic from Azure Bastion: Azure Bastion will reach the destination VM via private IP on ports RDP / SSH (ports respectively 3389 and 22). Therefore, as best practice, you can only add the Azure Bastion subnet as the source in this rule.
The creation of the Azure Bastion host can be done directly from the Azure portal by completing the following steps:
Figure 6 – Parameters required when creating the Azure Bastion service
After configuring the Azure Bastion service, you can use it as follows.
To allow access to the service, you must assign the following roles:
- Reader role on the virtual machines that you want to allow access to
- Reader role on NICes with virtual machine private IP address
- Reader role on Azure Bastion resource
Azure Bastion is a paid service, to get cost details you can access the pageAzure Bastion pricing.
Azure Bastion guarantees simple and secure remote access to systems in the Azure environment. There are several features that will be released soon for this service and that will make it even more complete and flexible. These include support for Virtual Network in peering and multi-factor authentication.