When you run a VM in Azure, you can connect to it through public Internet or VNet connectivity to your on-premises environment or another instance running it in Azure. If you are connecting through public internet, VM running in on Azure should have a public IP, and you should enable the relevant network port access. This is only good for testing because it is not secure for a production environment.
Azure Bastion provides a secure and seamless RDP/SSH connectivity to your virtual machines directly from the Azure Portal over SSL. This post discusses what Azure Bastion is and how we can implement it step by step.
Azure Bastion is a fully managed PaaS service where you can deploy from the Azure portal. It provides secure and seamless RDP/SSH connectivity to your virtual machines directly from the Azure portal over TLS. When you deploy Azure Bastion, its provision inside of your virtual network, any VM running in the Virtual network does not need to have a public IP address, agent, or special client software to access through Azure Bastion.
Architecture
Azure Bastion provides the jump host facility to the VM’s reside in the virtual network. When you deploy bastion, it will place a managed VM inside your VNET. This will have a public IP address that can only be accessed through Azure Portal. Then the Bastion host will orchestrate an RDP/SSH session to your VM reside in the same virtual network. The session will be opened through the HTML 5 based browser over TSL on port 443.
By using bastion, you can avoid exposing your VM’s to the internet through Public IP addresses. This will protect against port scanning and other applicable threats. Since it is a fully managed service, we don’t need to apply network security groups and manage its infrastructure. However, bastion requires a separate subnet in the virtual network.
The below diagram represents bastion architecture. Microsoft publishes this.
Before configuring Bastion, there are few things you need to consider.
1. Log in to the Azure portal - Virtual networks, click Subnets. This is the virtual network where your bastion will be placed and connecting VM’s residing.
2. Click +Subnet and create a new subnet. You can select a private IP range. It doesn’t need to be routable.
3. To add bastion service, click + Create a resource and type Bastion.
4. Select the Subscription, Resource group, Name, and select the Virtual network and the subnet you created earlier. Also, select an existing Public IP or create a new one.
5. Click Review + Create to create the bastion host.
After deploying the Bastion host, you can easily connect to it using the Azure portal. In my example, I am connecting to an Azure VM running as a WVD host which doesn’t have a public IP
Click Connect - Bastion and click Use Bastion.
Type the Username and Password of the VM
Bastion is not a free service; there is a cost when you implement it. So, I believe the first step is to understand the real requirement, do you really want it? Is there any other way to securely connect to your VM’s? If you already have a site to site VPN or an Express route to your on-premises environment, you can use it to connect to the VM’s securely from an on-premise environment. Another way to securely connect is through point to site VPN. However, it has some limitations, as well. After considering all of this and still you need to connect to the VM’s from the public internet, the best foremost secure connection is to select Bastion.
At this moment, Bastion only supports virtual network deployment. Also, it does not support VNET peering. If you do not have many VM’s in a VNET, then it is pointless to run a bastion on it. You can decide to have a bastion host on a virtual network with a high number of VM’s. This is a good factor to consider when designing your Azure Network.
Azure Bastion has two parts for its pricing. Hourly charge and charges for Outbound data transfer. The hourly charge is a fixed 0.19$ per hour, and Data transfer is increased with consumption. Refer (here) for exact pricing.
The bastion host does not support deallocation, so there is no way to shut it down to save your hourly charge. However, if you implement it in a separate resource group, you can delete the whole resource group, so your bastion service will be removed. In the same way, you can find the bastion service and delete it from a console click.
When required, you can re-deploy it within few minutes. However, it is just the cost of running a small VM.
Hope this post is useful
Cheers