This chapter covers Azure Bastion, a fully managed Platform as a Service (PaaS) that provides secure and seamless RDP and SSH access to virtual machines directly through the Azure portal, without exposing public IP addresses. For the AZ-500 exam, understanding Azure Bastion is critical for the Network Security domain (Objective 3.3), as it represents a key security control for remote access. Approximately 5-10% of exam questions touch on Azure Bastion, either directly or as part of broader scenarios involving secure connectivity, just-in-time access, and network segmentation. Mastering this topic ensures you can design and implement secure remote access solutions that align with Azure security best practices.
Jump to a section
Think of Azure Bastion like a secure, guarded gateway into a high-security corporate campus. In a traditional office, visitors cannot walk directly into a building; they must first check in at a guardhouse, where their identity is verified, they are logged, and they are given a temporary badge that allows access only to specific areas. The guardhouse itself is hardened and isolated from the internal offices. Similarly, Azure Bastion acts as a hardened, fully managed jump box inside your virtual network. Instead of exposing your virtual machines to the public internet via a public IP address, all Remote Desktop Protocol (RDP) and Secure Shell (SSH) traffic is routed through the Bastion service. The Bastion service authenticates the user via Azure Active Directory and Azure role-based access control, then creates a secure, one-time session that is proxied to the target VM. The VM itself never has a public IP and never initiates the outbound connection—the Bastion service does. This mirrors the guardhouse: the visitor (user) never directly enters the building (VM) without going through the secure checkpoint (Bastion). The guardhouse logs every visit, and the visitor’s access is limited to what their badge allows. In Azure, Bastion logs all sessions via Azure Monitor and enforces RBAC to control which VMs a user can reach. The key mechanistic detail is that the Bastion service uses a separate subnet (AzureBastionSubnet) and leverages TLS 1.2+ to encrypt the session, ensuring that even if the network is compromised, the session traffic is protected.
What is Azure Bastion?
Azure Bastion is a fully managed PaaS service that provides secure and seamless RDP and SSH access to virtual machines (VMs) directly through the Azure portal, using TLS encryption. It eliminates the need to expose VMs to the public internet via public IP addresses, reducing the attack surface. Bastion is deployed inside a virtual network (VNet) and requires a dedicated subnet named 'AzureBastionSubnet' with a minimum /26 prefix (64 IP addresses). It supports both RDP (port 3389) and SSH (port 22) protocols and integrates with Azure Active Directory (Azure AD) for authentication and authorization.
Why Azure Bastion Exists
Traditionally, administrators connect to Azure VMs by assigning a public IP address and configuring network security group (NSG) rules to allow RDP/SSH traffic from specific source IPs. This approach has several security drawbacks: VMs are exposed to the internet, public IPs increase attack surface, and managing NSG rules for dynamic IPs is cumbersome. Azure Bastion addresses these issues by acting as a jump box that is fully managed, scalable, and integrated with Azure AD and RBAC. It also supports features like just-in-time (JIT) access (when combined with Microsoft Defender for Cloud) and session recording (via Azure Monitor).
How Azure Bastion Works Internally
When a user connects to a VM via Bastion, the following steps occur at a high level:
Authentication and Authorization: The user authenticates to the Azure portal using Azure AD credentials. Once authenticated, the portal checks RBAC permissions to ensure the user has the 'Reader' role on the VM and the 'Contributor' or higher role on the Bastion resource (or specific RBAC actions like 'Microsoft.Network/bastionHosts/read'). Bastion itself does not authenticate to the VM using Azure AD; instead, it requires the user to provide credentials for the VM (local username/password or SSH key) during the session initiation.
Session Initiation: The user selects the VM in the Azure portal and clicks 'Connect' -> 'Bastion'. The portal sends a request to the Bastion resource, which then establishes a secure TLS tunnel to the user's browser. The Bastion service opens a WebSocket connection over HTTPS (port 443) to the browser.
Connection to VM: Bastion uses the credentials provided by the user to authenticate to the VM via RDP or SSH. Importantly, Bastion does not need a public IP on the VM; it connects to the VM's private IP address within the VNet. The VM must have the appropriate NSG rules to allow inbound traffic from the Bastion subnet (AzureBastionSubnet) on ports 3389 (RDP) or 22 (SSH). Bastion also supports connecting to VMs via private IPs in peered VNets, as long as the Bastion host and the VM are in the same VNet or a directly peered VNet (not over VPN or ExpressRoute gateways).
Session Streaming: Once the connection is established, the RDP or SSH session is streamed through the Bastion service to the user's browser. The Bastion service acts as a proxy, forwarding keystrokes, mouse movements, and screen updates. All traffic is encrypted end-to-end using TLS 1.2+.
Key Components, Values, Defaults, and Timers
Subnet Requirements: AzureBastionSubnet must be a dedicated subnet with a minimum /26 prefix (64 IPs). It cannot contain any other resources. The subnet must be in the same VNet as the Bastion host.
SKU Tiers: Azure Bastion offers two SKUs: Basic and Standard. Basic supports up to 2 concurrent RDP/SSH sessions per scale unit, while Standard supports up to 50 concurrent sessions per scale unit and includes features like IP-based connection, session recording, and custom port configuration.
Scale Units: Bastion automatically scales out based on load. Each scale unit can handle a certain number of concurrent sessions (2 for Basic, 50 for Standard). The service can scale up to 50 scale units (100 concurrent sessions for Basic, 2500 for Standard).
Ports: RDP uses port 3389, SSH uses port 22. Bastion itself listens on port 443 for HTTPS connections from the browser.
Protocols: Only RDP and SSH are supported. No other protocols (e.g., HTTP, FTP) can be tunneled through Bastion.
Authentication: Bastion supports Azure AD authentication for the Azure portal login, but VM credentials must be provided separately. It does not support Azure AD-joined VMs for direct authentication (i.e., you cannot use Azure AD credentials to log into a VM through Bastion without additional configuration like Azure AD Domain Services).
Session Timeout: The default session timeout for an idle RDP/SSH session is 20 minutes. This can be configured in the Bastion resource settings.
Logging and Monitoring: Bastion integrates with Azure Monitor for session logs, including connection attempts, successful logins, and session duration. Diagnostic settings can be configured to send logs to Log Analytics workspaces, storage accounts, or Event Hubs.
Configuration and Verification Commands
To deploy Azure Bastion using Azure CLI:
az network bastion create \
--name MyBastion \
--resource-group MyResourceGroup \
--vnet-name MyVNet \
--public-ip-address MyBastionPublicIP \
--location eastus \
--sku StandardTo verify the Bastion host:
az network bastion list --resource-group MyResourceGroup -o table
az network bastion show --name MyBastion --resource-group MyResourceGroupTo connect to a VM via Bastion using CLI (requires az network bastion ssh command in preview):
az network bastion ssh \
--name MyBastion \
--resource-group MyResourceGroup \
--target-resource-id /subscriptions/.../virtualMachines/MyVM \
--auth-type password \
--username azureuserInteraction with Related Technologies
Network Security Groups (NSGs): For Bastion to connect to VMs, the NSG on the VM's subnet must allow inbound traffic from the AzureBastionSubnet on ports 3389 and 22. The NSG on the AzureBastionSubnet must allow inbound traffic from the internet on port 443 (for the browser to Bastion) and outbound traffic to the VM subnet on ports 3389/22. Also, the Bastion subnet NSG must allow inbound traffic from the AzureGatewayManager service tag on port 443 and outbound to AzureCloud on port 443 for management purposes.
Azure Firewall: Bastion can be placed behind Azure Firewall for additional inspection, but it's not required. The Bastion service itself does not integrate directly with Azure Firewall.
Just-In-Time (JIT) Access: Bastion can be used with JIT VM access in Microsoft Defender for Cloud. When JIT is enabled, Bastion can only connect to VMs if the JIT policy allows the connection. The user must have appropriate RBAC permissions to request JIT access.
Azure AD and RBAC: Bastion uses Azure AD for portal authentication and RBAC to control which users can access the Bastion resource and which VMs they can connect to. The minimum RBAC role required to use Bastion is 'Reader' on the VM and 'Contributor' on the Bastion host (or a custom role with 'Microsoft.Network/bastionHosts/read' and 'Microsoft.Network/bastionHosts/connect' actions).
Common Misconfigurations and Troubleshooting
Incorrect Subnet Size: If the AzureBastionSubnet is smaller than /26, deployment fails.
NSG Rules Missing: If the VM subnet NSG blocks inbound from AzureBastionSubnet on ports 3389/22, Bastion cannot connect.
Peering Limitations: Bastion can only connect to VMs in the same VNet or directly peered VNets. It cannot connect to VMs over VPN or ExpressRoute gateways (i.e., VNets that are not directly peered).
Bastion Public IP: Bastion requires a standard SKU public IP address with static assignment. Basic SKU public IPs are not supported.
Deploy Azure Bastion
Create a dedicated subnet named AzureBastionSubnet with a minimum /26 prefix in the target VNet. Deploy the Bastion resource using the Azure portal, CLI, or PowerShell, specifying the VNet, subnet, and a standard SKU public IP address. During deployment, choose the SKU (Basic or Standard) based on concurrency and feature requirements. The deployment typically takes 5-10 minutes. Once deployed, the Bastion host is assigned a public IP and is ready to accept connections from the Azure portal.
Configure NSG Rules
Ensure the NSG on the AzureBastionSubnet allows inbound HTTPS (port 443) from the internet (or specific source IPs) and outbound to the VM subnet on ports 3389/22. Also allow inbound from AzureGatewayManager service tag on port 443 and outbound to AzureCloud on port 443 for management. On the VM subnet NSG, allow inbound from AzureBastionSubnet on ports 3389/22. Without these rules, Bastion cannot establish the connection. Misconfigured NSGs are the most common cause of connectivity failures.
Authenticate to Azure Portal
The user signs in to the Azure portal with Azure AD credentials. The portal verifies RBAC permissions: the user must have at least Reader access on the target VM and Contributor (or custom role with connect action) on the Bastion host. If the user lacks permissions, the 'Connect' option is grayed out or fails. This step ensures only authorized users can initiate Bastion sessions.
Initiate Bastion Session
In the Azure portal, navigate to the VM, click 'Connect' -> 'Bastion'. Provide the VM's local credentials (username/password or SSH key). The browser establishes a WebSocket connection over HTTPS to the Bastion host's public IP on port 443. Bastion then connects to the VM's private IP using the provided credentials. The session is proxied through Bastion; the browser never directly contacts the VM. The user can now interact with the VM's desktop or shell.
Monitor and Audit Sessions
Bastion logs all session activity to Azure Monitor. To configure, enable diagnostic settings on the Bastion resource and send logs to a Log Analytics workspace, storage account, or Event Hubs. Logs include connection attempts, success/failure, session duration, and source IP. For Standard SKU, you can also enable session recording to capture keystrokes and screen activity for compliance. Use Azure Monitor alerts to detect anomalous behavior, such as multiple failed login attempts.
In a large enterprise with hundreds of VMs across multiple regions, Azure Bastion is deployed to eliminate public IP addresses on VMs, reducing the attack surface and simplifying network security group management. For example, a financial services company uses Bastion to allow its system administrators to manage VMs hosting sensitive customer data. The Bastion host is deployed in a central hub VNet with Azure Firewall for egress inspection. Administrators connect via the Azure portal, which enforces Azure AD Multi-Factor Authentication (MFA) and RBAC. The company uses the Standard SKU to support up to 50 concurrent sessions per scale unit and enables session recording for compliance with PCI DSS. They have configured diagnostic settings to send all Bastion logs to a central Log Analytics workspace, where they run queries to detect unauthorized access attempts.
Another scenario: a startup with a single VNet and a few VMs uses Bastion Basic to provide secure SSH access to their Linux VMs. They avoid the cost and complexity of a VPN gateway or jump box VM. The startup's developers connect via the Azure portal, using SSH keys for authentication. They have set up NSG rules to only allow Bastion subnet traffic to the VMs, ensuring no other inbound traffic is permitted.
A common production issue is when Bastion fails to connect due to missing NSG rules. For instance, an engineer deploys Bastion but forgets to add the inbound rule from AzureBastionSubnet to the VM subnet on port 3389. The connection attempt times out after 20 seconds. The engineer checks the Bastion logs and sees 'Connection failed: VM unreachable'. After adding the rule, the connection succeeds. Another issue is scale: during a critical incident, many administrators try to connect simultaneously, exhausting the concurrent session limit. With Basic SKU (2 sessions per scale unit), only two can connect at once. The company upgrades to Standard SKU to handle the load.
Performance considerations: Bastion adds latency because traffic is proxied through the service. For latency-sensitive tasks, some organizations prefer a VPN connection with a jump box. However, for most administrative tasks, the added latency (typically 50-100ms) is acceptable. Bastion automatically scales out to handle increased load, but scaling can take a few minutes during sudden spikes.
The AZ-500 exam tests Azure Bastion primarily under Objective 3.3: Implement secure access to virtual networks, specifically 'Implement Azure Bastion'. Questions focus on understanding Bastion's purpose, deployment requirements, and security benefits. Common exam scenarios include:
Identifying when to use Bastion vs. other solutions: The exam presents a scenario where you need to provide secure RDP/SSH access to VMs without public IPs. The correct answer is Azure Bastion. Wrong answers include VPN Gateway, ExpressRoute, or just-in-time VM access (JIT alone doesn't provide the proxy).
Deployment prerequisites: Questions often ask about the required subnet size (/26) and the need for a standard SKU public IP. A common trap is choosing a /28 subnet or a basic SKU public IP. Remember: Bastion requires a dedicated subnet named 'AzureBastionSubnet' with a /26 or larger.
NSG rules: The exam may ask which NSG rules are necessary for Bastion to function. Wrong answers include allowing inbound from internet to VM subnet on port 3389 (that defeats Bastion's purpose). The correct rule is allowing inbound from AzureBastionSubnet to VM subnet on ports 3389/22.
Authentication: Bastion does not authenticate users to VMs using Azure AD; it requires local VM credentials. A common wrong answer is 'Bastion uses Azure AD to authenticate to the VM'. The reality is that Azure AD is used only for the portal login; VM credentials are separate.
Peering limitations: Bastion can only connect to VMs in the same VNet or directly peered VNets. It cannot connect over VPN or ExpressRoute. The exam may present a scenario with VMs in a spoke VNet connected via VPN to the hub where Bastion is deployed. The correct answer is that Bastion cannot connect to those VMs unless they are directly peered.
SKU features: The exam tests differences between Basic and Standard SKUs. Standard supports IP-based connections, session recording, and higher concurrency. A question might ask which SKU supports custom port configuration; the answer is Standard.
Cost considerations: While not heavily tested, the exam may mention that Bastion is billed per hour plus data transfer. Basic is cheaper but limited.
To eliminate wrong answers, focus on the mechanism: Bastion is a proxy that sits in the VNet and connects to VMs via private IP. It does not expose VMs to the internet. Any answer that suggests exposing the VM to the internet or using public IPs is incorrect. Also, remember that Bastion is PaaS, so no maintenance of jump box VMs is needed.
Azure Bastion is a PaaS service that provides secure RDP/SSH access to VMs without public IPs.
Bastion requires a dedicated subnet named AzureBastionSubnet with a minimum /26 prefix.
Bastion uses a standard SKU public IP address; basic SKU is not supported.
NSG rules must allow inbound from AzureBastionSubnet to VM subnet on ports 3389/22.
Bastion authenticates users via Azure AD for the portal, but VM credentials are separate.
Bastion can only connect to VMs in the same VNet or directly peered VNets (not over VPN/ExpressRoute).
Standard SKU supports up to 50 concurrent sessions per scale unit, IP-based connections, and session recording.
Bastion logs are integrated with Azure Monitor for auditing and diagnostics.
Bastion does not support protocols other than RDP and SSH.
Bastion eliminates the need for jump box VMs, reducing management overhead.
These come up on the exam all the time. Here's how to tell them apart.
Azure Bastion
Provides a fully managed jump box proxy for RDP/SSH sessions.
Eliminates the need for public IPs on VMs.
Requires a dedicated subnet and public IP for the Bastion host.
Supports session recording and custom ports (Standard SKU).
Billed per hour plus data transfer.
Just-In-Time (JIT) VM Access
Controls inbound RDP/SSH access by opening ports temporarily via NSG rules.
Does not remove public IPs; it limits exposure by time-bound rules.
No additional infrastructure; works with existing NSGs.
Integrates with Microsoft Defender for Cloud for policy enforcement.
No additional cost beyond Defender for Cloud pricing.
Mistake
Azure Bastion eliminates the need for NSGs on VM subnets.
Correct
Bastion still requires NSG rules on the VM subnet to allow inbound traffic from AzureBastionSubnet on ports 3389/22. NSGs are essential for defense in depth.
Mistake
Bastion can connect to any VM in any VNet, including those connected via VPN or ExpressRoute.
Correct
Bastion can only connect to VMs in the same VNet or directly peered VNets. It does not support transitive connectivity over VPN or ExpressRoute gateways.
Mistake
Bastion authenticates users to VMs using Azure AD credentials.
Correct
Bastion uses Azure AD only for portal authentication. VM credentials (local username/password or SSH key) must be provided separately during session initiation.
Mistake
Bastion requires a public IP on the target VM.
Correct
Bastion connects to VMs using their private IP addresses. The VM does not need a public IP, which is a key security benefit.
Mistake
Bastion supports any protocol, not just RDP and SSH.
Correct
Bastion only supports RDP and SSH. It cannot be used to tunnel other protocols like HTTP or FTP.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The minimum subnet size is /26 (64 IP addresses). The subnet must be named 'AzureBastionSubnet' and cannot contain any other resources. A smaller subnet like /28 will cause deployment failure.
Yes, but only if the VNets are directly peered. Bastion does not support transitive connectivity over VPN or ExpressRoute gateways. The Bastion host and the VM must be in the same VNet or in VNets that are directly peered.
No. Bastion uses Azure AD only for portal authentication. To log into the VM, you must provide local credentials (username/password or SSH key). Azure AD authentication for VM login requires additional configuration like Azure AD Domain Services or Azure AD-joined VMs with proper extensions.
Basic SKU supports up to 2 concurrent sessions per scale unit and does not support IP-based connections, session recording, or custom ports. Standard SKU supports up to 50 concurrent sessions per scale unit, IP-based connections, session recording (preview), and custom port configuration (e.g., RDP on port 3390).
No. Azure Bastion requires a standard SKU public IP address to accept connections from the Azure portal. The public IP is assigned to the Bastion host, not to the VMs.
Enable diagnostic settings on the Bastion resource and send logs to a Log Analytics workspace, storage account, or Event Hubs. Logs include connection attempts, success/failure, session duration, and source IP. For Standard SKU, you can also enable session recording.
If the NSG on the VM subnet does not allow inbound from AzureBastionSubnet on ports 3389/22, Bastion will fail to connect. Similarly, if the Bastion subnet NSG blocks inbound HTTPS from the internet, users cannot initiate sessions. Always verify NSG rules during troubleshooting.
You've just covered Azure Bastion for Secure Access — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?