Azure Bastion is a service you deploy that lets you connect to virtual machines directly over TLS from the Azure portal, or via the native SSH or RDP client already installed on your local computer. The Azure Bastion service is a fully platform-managed PaaS service that you provision inside your virtual network. It provides secure and seamless RDP/SSH connectivity to your virtual machines directly from the Azure portal over TLS. When you connect via Azure Bastion, your virtual machines do not need a public IP address, agent, or special client software.

In this blog post, we will explore the design and implementation of Azure Bastion, focusing on how to access virtual machines securely. We’ll cover key features, best practices, and steps to ensure safe remote connectivity to your Azure resources.

Azure Bastion allows users to initiate an RDP-like connection over HTTPS to servers within Azure without opening ports, adding a public IP address, or compromising security.

Why do we need Azure Bastion?

Azure Bastion addresses several critical needs for secure and efficient connectivity to virtual machines:

1. Secure Connectivity: Bastion enables users to connect to VMs using RDP or SSH over TLS on port 443, ensuring that the connection is secure and encrypted.
2. Protection from External Threats: By keeping your VMs protected from port scanning and other external threats, Azure Bastion enhances your network’s security posture. Additionally, deploying with availability zones can provide extra resilience against system failures.
3. Scalability and Flexibility: Azure Bastion supports host scaling and allows for shareable links and connections via IP addresses, making it versatile for various use cases and environments.
4. Reduced Management Overhead: You can deploy Azure Bastion once and use virtual network peering to connect multiple networks, significantly simplifying management and reducing administrative effort.
5. Compliance and Audit Requirements: For organisations with strict compliance needs, Azure Bastion offers session recording capabilities (available in the Premium SKU), helping meet audit requirements and ensuring accountability.
6. Platform as a Service: Bastion is a PaaS service that you provision and manage on the Azure platform.

In summary, Azure Bastion is essential for providing secure, flexible, and manageable access to your virtual machines while fortifying them against potential security threats.

Azure Bastion Connection Types?

Azure Bastion provides different methods to connect to the target virtual machines. The types are below:

Browser-Based Connections:

Native Client Connections:

• This method allows users to connect to target VMs with the SSH or RDP client already installed on their local computers.
• Available for Standard and Premium SKUs.
• Supports Microsoft Entra ID authentication and file transfer.

Shareable Links:

• This method helps to create shareable links that allow users to connect to VMs without accessing the Azure portal.
• Available for Standard and Premium SKUs.

Azure Bastion SKU Types?

Azure Bastion offers four SKU tiers, and the table below will help you understand them:

SKU Type	Description	Scale Limit	Features
Basic	Suitable for fixed capacity	No scaling and Dedicated Host.	Fixed capacity of two instances (40 RDP/80 SSH sessions)
Developer	Ideal for development and testing scenarios.	No scaling and Shared resources	Shared instance and allows 1 VM at a time.
Standard	Suitable for production workloads	Scaling from 2-50 instances and Dedicated host.	1. This version allows host scaling (2-50 instances) 2. This version allows high concurrency (up to 1,000 RDP or 2,000 SSH sessions at max scale).
Premium	For enterprise-level applications and workloads.	Scaling from 2-50 instances and a dedicated host.	1. This version allows host scaling (2-50 instances) 2. This version allows high concurrency (up to 1,000 RDP or 2,000 SSH sessions at max scale).

For a complete comparison of features and capacity details, see Choose the right Azure Bastion SKU.

Architecture Options

The Bastion architecture accommodates various models, which we can explore in detail in this section.

• Bastion Dedicated:

The Default architecture model is the standard Azure Bastion architecture for production environments. Azure Bastion is deployed into a dedicated AzureBastionSubnet within your virtual network, allowing administrators to securely connect to virtual machines using RDP or SSH without assigning public IP addresses to the VMs.

The Bastion is hosted on the HUB VNET in a HUB and Spoke topology. It supports secure management across local and peered virtual networks and is suitable for organisations looking for a scalable, enterprise-grade remote access solution. The picture below illustrates that the Bastion is hosted in a Hub VNET, and its spoke VNET resources are accessible from the Bastion.

Deploying Bastion in a hub and spoke network topology, you can centrally manage secure RDP and SSH access to workloads spread across multiple virtual networks (VNets). Instead of deploying a Bastion host in every single VNet, you place one Bastion host in the central Hub VNet and allow it to communicate securely with peered Spoke VNets

The bastion subnet requires a dedicated subnet (AzureBastionSubnet) in the hub VNET; you require a CIDR block of at least /26 or larger. The Bastion holds a public IP address and helps to limit the public exposure of virtual machines’ IPs.It provides access to all VMs within a local or peered virtual network through a single hardened access point. No public IP address is required on your VMs—using an Azure Bastion host lets you open a more secure RDP or SSH protocol connection using a private IP address.

This method of deployment is not supported in Azure Virtual WAN; deploying Bastion directly inside the Microsoft-managed Virtual WAN hub is not supported. Instead, implement the virtual hub extension pattern by creating a dedicated Spoke VNet attached to the vWAN hub, deploying Bastion there, and using IP-based routing to reach others.

For Virtual WAN, use the last method of deployment discussed in this article (Bastion with Dedicated Virtual Network).

• Bastion Developer:

Bastion Developer is a lightweight, cost-effective deployment option intended for development and testing scenarios. Unlike the dedicated models, Microsoft hosts the Bastion infrastructure, so no dedicated Bastion resource or subnet is required in your virtual network.

When connecting with Bastion Developer, the deployment requirements differ from those associated with deploying other SKUs. Typically, a bastion host is deployed to the AzureBastionSubnet within the virtual network. The Bastion host is designated for individual use, while Bastion Developer is not dedicated. Because the Bastion Developer resource is shared, its features are limited. Users can upgrade to a specific SKU if additional features are required.

The picture below illustrates that the Bastion Developer:

This deployment model is suitable for PoC workloads and isolated workloads in the cloud. It provides secure browser-based access to virtual machines while offering a simplified feature set, making it suitable for individual developers, labs, and proof-of-concept environments rather than production workloads.

• Bastion Private IP only:

The Private-only Deployment model is designed for organisations with strict security and compliance requirements. Available with the Premium SKU, this deployment removes the public IP address from the Bastion host, ensuring all management traffic stays on private networks via VPN or ExpressRoute. This architecture minimises internet exposure and is ideal for regulated industries or highly secure enterprise environments.

In this setup, Bastion is deployed within a virtual network. A user connected to Azure via ExpressRoute private peering can securely access Bastion using its private IP address. From there, Bastion can establish a connection to a virtual machine that resides either in the same virtual network as the Bastion host or in a peered virtual network. Importantly, in a private-only Bastion deployment, outbound access to resources outside of the virtual network is not permitted.

The diagram below illustrates the architecture for a dedicated, private-only deployment of Azure Bastion (Premium SKU Tier):

Bastion with Dedicated Virtual Network.

In a typical design, the Bastion resides in the hub VNET, and any user accessing a spoke VM via the Bastion host must be granted at least the Reader role on the Bastion resource and the hub VNET. This can violate the principle of least privilege in strict compliance environments, as application teams must be given permissions to the central hub.

Additionally, Virtual WAN setup cannot place Bastion in the managed HUB VNET.

Why not deploy Bastion in the Hub VNet?

Hosting Azure Bastion in the hub has the following disadvantages:

• The Hub VNet typically contains many peerings and shared infrastructure.
• Users with read access to the Bastion deployment may gain unnecessary visibility into routing and connected VNets.
• It violates the principle of least privilege by exposing more of the network than required.
• Bastion traffic is harder to force through a central firewall in a traditional hub-and-spoke design because the Azure Bastion subnet doesn’t support User Defined Routes (UDRs).

Why use a dedicated Bastion VNet?

To address the above two concerns, Bastion can be placed in a dedicated subscription and a spoke virtual network. Azure Bastion does not support User-Defined Routes (UDRs) AzureBastionSubnet. Bastion relies strictly on native VNet routing, so do not point the subnet’s 0.0.0.0/0 traffic toward an Azure Firewall or NVA.

This configuration allows a single Azure Bastion instance to provide access to multiple virtual networks. By using VNet peering, businesses can connect to numerous VNets securely while maintaining central management of the Bastion service. This is ideal for scenarios where workloads are distributed across different VNets but need to be accessed securely and seamlessly.

A separate VNet for Bastion provides several advantages:

• Isolation – Bastion has no shared workloads.
• Reduced network visibility – administrators using Bastion don’t learn about every connected VNet.
• Independent security controls – NSGs and routing are specific to Bastion.
• No impact on production workloads if Bastion networking changes.

This design method required a dedicated virtual network for hosting Bastion. I use a dedicated VNet for Azure Bastion to avoid affecting other workloads by sharing the VNet. The networking routing design should follow the principles below:

• The Azure Bastion network connects to the Internet through 0.0.0.0/0 for control plane traffic.
• It accesses private IP ranges through the Firewall (Placed in the Hub), allowing precise traffic management.
• Target spokes with VMs for RDP or SSH need a return route to the Azure Bastion network via the Firewall private IP.
• Allow RDP (TCP/UDP/3389) and SSH (TCP/22) on the Firewall and NSGs from the Bastion subnet to VM subnets or IPs in other VWAN spokes.
• Configure the Azure Bastion NSG specifically for its role.

Conclusion

In conclusion, Azure Bastion serves as a pivotal tool for enhancing the security and accessibility of your virtual machines in the cloud. With its seamless integration into the Azure ecosystem, it eliminates the need for public IP addresses while providing a secure gateway to your VMs through the Azure portal. The diverse SKU options cater to various business needs, allowing you to scale efficiently based on your requirements. Its deployment model is straightforward, ensuring a hassle-free setup that can be quickly customised to fit your organisational needs. Overall, Azure Bastion not only simplifies remote access but also significantly strengthens the security posture of your cloud infrastructure, making it an indispensable solution for any enterprise looking to leverage the full potential of Azure while maintaining robust security standards.