This chapter covers Azure Bastion, a fully managed PaaS service that provides secure and seamless RDP and SSH access to virtual machines directly from the Azure portal, without exposing public IP addresses. For the AZ-900 exam, this falls under Objective 2.3: Describe core Azure architecture services, specifically secure remote access solutions. This objective area typically accounts for about 15-20% of the exam. Understanding Azure Bastion is crucial because it demonstrates how Azure addresses the security challenge of remote administration, a common scenario in enterprise environments.
Jump to a section
Imagine you own a medieval castle with a treasure room (your Azure virtual machines). To access the treasure, you need to enter the castle, but you don't want to open a direct door in the wall for every visitor—that would be like exposing your VMs to the public internet with a public IP address. Instead, you build a fortified gatehouse (Azure Bastion) outside the main wall. Visitors (admins) approach the gatehouse, prove their identity (Azure AD authentication), and then the gatehouse opens a private, guarded passage directly into the treasure room. The outside world never sees the treasure room's door; all traffic goes through the gatehouse. If an attacker tries to break in, they must first breach the gatehouse, which is hardened and monitored. This mirrors Azure Bastion: it sits in your virtual network, uses TLS to secure the connection, and forwards RDP/SSH traffic to your VMs without exposing them to the internet. The mechanism is that Bastion acts as a jump server but without the complexity of managing a separate VM—it's a PaaS service that scales automatically.
What is Azure Bastion and the Business Problem It Solves
Azure Bastion is a fully managed platform-as-a-service (PaaS) that provides secure and seamless Remote Desktop Protocol (RDP) and Secure Shell (SSH) access to virtual machines (VMs) directly from the Azure portal, over TLS. The primary business problem it solves is the security risk associated with exposing VMs to the public internet via public IP addresses. Traditionally, to administer a VM remotely, you would assign it a public IP and open RDP (port 3389) or SSH (port 22) in the network security group (NSG). This creates a significant attack surface—bots scan the internet for open RDP/SSH ports and attempt brute-force attacks. Azure Bastion eliminates this need by allowing you to connect to VMs without any public IP address, using a secure gateway that sits within your virtual network.
How It Works – Step-by-Step Mechanism
Azure Bastion is deployed within a virtual network (VNet) and provides connectivity to VMs in that VNet and peered VNets. Here’s the detailed mechanism:
Deployment: You create an Azure Bastion host in your VNet. This host is a PaaS resource that Microsoft manages—you don’t need to patch or maintain it. The Bastion host must be deployed in a dedicated subnet named AzureBastionSubnet with a minimum size of /27 (or larger, e.g., /26 for higher scale).
Connection Initiation: An administrator logs into the Azure portal and navigates to the VM they want to connect to. They select the "Connect" dropdown and choose "Bastion." The portal then requests authentication: Azure AD credentials (or local VM credentials if configured).
Session Establishment: The Azure portal sends a request to the Bastion host over HTTPS (port 443). The Bastion host then opens a secure RDP or SSH session to the target VM over the private network (no public internet exposure). The RDP/SSH traffic is encapsulated within TLS and forwarded from the Bastion host to the VM.
User Experience: The RDP or SSH session is rendered in the browser using HTML5. No client software is required—just a modern browser. The session is interactive and supports copy/paste and file upload/download (if enabled).
Termination: When the user disconnects, the Bastion host closes the session. The VM remains secure with no public endpoint.
Key Components, Tiers, and Pricing Models
Azure Bastion has two SKUs: Basic and Standard. The Basic SKU is included with a free trial for the first 30 days, then billed per hour. The Standard SKU adds features like: - Host scaling: Scale the Bastion host to handle more concurrent sessions (up to 50 sessions per scale unit). - IP-based connection: Connect to VMs using private IP addresses directly (instead of browsing the portal). - Custom port and protocol: Support for non-standard RDP/SSH ports. - Kerberos authentication: For domain-joined VMs.
Pricing: Basic is approximately $0.07/hour (varies by region), Standard is about $0.14/hour. You also pay for data transfer out (egress) at standard rates. There is no upfront cost.
Key components: - AzureBastionSubnet: Dedicated subnet within the VNet. Must not contain any other resources. - Bastion host: The PaaS resource that manages connections. - Target VM: The VM you want to connect to. It must have a private IP and be reachable from the Bastion subnet. - Network Security Groups (NSGs): The VM’s NSG must allow inbound RDP/SSH from the Bastion subnet (or from the AzureBastionSubnet’s IP range).
Comparison to On-Premises Equivalent
On-premises, remote administration often uses a jump server (bastion host) that sits in a DMZ. You RDP/SSH into the jump server, then from there connect to internal servers. This requires managing the jump server’s OS, patching, and securing it. Azure Bastion is a managed version of this concept: no OS to patch, no public IP on the jump server (the Bastion host itself has a public IP, but it only accepts connections from the Azure portal over TLS), and automatic scaling. The on-premises equivalent would be a hardened jump server with a public IP, but that still exposes a management interface. Azure Bastion’s advantage is that the public endpoint is Microsoft-managed and only allows connections authenticated via Azure AD.
Azure Portal and CLI Touchpoints
In the Azure portal, you create Bastion by searching for "Bastion" and clicking "Create." You specify the name, region, VNet, and subnet (must be AzureBastionSubnet). After deployment, you can connect to any VM in the VNet by selecting the VM, clicking "Connect," then "Bastion." You can also use the Azure CLI:
# Create a Bastion host
az network bastion create --name MyBastion --resource-group MyRG --vnet-name MyVNet --public-ip-address MyPublicIP
# Connect to a VM via Bastion (opens browser)
az network bastion ssh --name MyBastion --resource-group MyRG --target-resource-id $(az vm show -n MyVM -g MyRG --query id -o tsv) --auth-type password --username azureuserNote: The CLI az network bastion ssh and az network bastion rdp commands are available in newer versions and require the bastion extension.
Concrete Business Scenarios
Scenario 1: Financial Services Compliance A bank needs to manage VMs hosting sensitive customer data. Compliance requires that no VM has a public IP. Without Bastion, the IT team would need to set up a VPN or ExpressRoute, which adds complexity and cost. With Bastion, they can securely manage VMs from the Azure portal without any public exposure. The team deploys Bastion in a hub VNet and connects spoke VNets via peering. They use Azure AD authentication and conditional access policies to restrict which users can connect.
Scenario 2: DevOps Development Environment A development team has multiple VMs for testing. They often need to SSH into Linux VMs to debug. Previously, they assigned public IPs to each VM, leading to security alerts. With Bastion, they remove all public IPs. Developers connect via the portal using their Azure AD accounts. The team enables file upload/download for transferring build artifacts. The Bastion host is scaled to Standard SKU to handle up to 50 concurrent sessions during peak testing.
What Goes Wrong When Set Up Incorrectly
Common mistakes:
Creating AzureBastionSubnet with a size smaller than /27. This causes deployment failure.
Forgetting to update NSG rules on the target VM. The VM’s NSG must allow inbound RDP/SSH from the Bastion subnet (or from the AzureBastionSubnet’s IP prefix).
Using a public IP on the target VM. Bastion works without public IPs; if a VM has a public IP, it’s still accessible directly, defeating the purpose.
Not enabling Azure AD authentication if desired. By default, Bastion uses local VM credentials. To use Azure AD, you must enable Azure AD login for Windows VMs (requires extension).
Exam Focus
Objective 2.3: Describe core Azure architecture services. Specifically, Azure Bastion is listed under "Secure remote access solutions." The exam expects you to know:
Azure Bastion provides secure RDP/SSH connectivity to VMs directly from the Azure portal.
It eliminates the need for public IP addresses on VMs.
It uses TLS over port 443.
It is a PaaS service (fully managed).
It requires a dedicated subnet named AzureBastionSubnet with a minimum size of /27.
It supports both Basic and Standard SKUs.
It can connect to VMs in the same VNet or peered VNets.
Common Wrong Answers and Why Candidates Choose Them: 1. "Azure Bastion is used to connect to on-premises servers." – Wrong. Bastion is for Azure VMs only. Candidates confuse it with VPN or ExpressRoute. 2. "Azure Bastion requires a public IP on the VM." – Wrong. Bastion eliminates the need for public IPs. Candidates think a public endpoint is needed for any remote access. 3. "Azure Bastion is a VM that you manage." – Wrong. It’s a PaaS service. Candidates think it’s a jump server they must patch. 4. "Azure Bastion can only connect to Windows VMs." – Wrong. It supports both RDP (Windows) and SSH (Linux). Candidates may assume SSH is not supported.
Specific Terms and Values:
- Subnet name: AzureBastionSubnet (exact spelling, case-sensitive).
- Minimum subnet size: /27.
- Ports: 443 (TLS) from client to Bastion; RDP (3389) and SSH (22) from Bastion to VM.
- SKUs: Basic (default) and Standard.
Edge Cases: - Bastion does not support connecting to VMs in a different region than the Bastion host. The Bastion host and VM must be in the same region (or peered VNets in the same region). - Bastion does not support connecting to VMs using private endpoints. The VM must have a private IP in the VNet. - For Azure AD authentication, the VM must have the AADLoginForWindows extension installed and be joined to Azure AD.
Memory Trick: Think "Bastion = Beachhead" – a secure entry point that protects the interior. The subnet name AzureBastionSubnet is like a specific landing zone. Remember: /27 = 32 IPs (minimum).
Decision Tree for Eliminating Wrong Answers: - Question: "Which service provides secure RDP/SSH without public IPs?" - If answer mentions VPN, ExpressRoute, or public IP, eliminate. - If answer says "IaaS" or "VM," eliminate. - If answer says "PaaS" and "portal," likely correct.
Create a Virtual Network
Before deploying Azure Bastion, you need a virtual network (VNet) that contains the target VMs. If you don't have one, create it in the Azure portal. The VNet should have at least one subnet for your VMs. Note that the Bastion host will require its own dedicated subnet, but that's created in the next step. For example, you might have a VNet named 'MyVNet' with address space 10.0.0.0/16 and a VM subnet 10.0.1.0/24.
Add AzureBastionSubnet
In the VNet, create a subnet named exactly 'AzureBastionSubnet'. This name is mandatory. The subnet must have a minimum size of /27 (32 IP addresses) to allow for scaling. You can create a larger subnet, e.g., /26, for more concurrent sessions. This subnet will host the Bastion PaaS resource. No other resources can be placed in this subnet. In the portal, go to the VNet, select 'Subnets', then add a new subnet with the correct name and address range.
Deploy Azure Bastion
In the Azure portal, search for 'Bastion' and select 'Create Bastion'. Provide a name (e.g., 'MyBastion'), choose the region (must match the VNet region), select the VNet, and choose the AzureBastionSubnet. You also need to create or select a public IP address for the Bastion host (this IP is used for the portal connection only). Choose the SKU: Basic or Standard. Standard offers scaling and additional features. Review and create. Deployment takes about 5-10 minutes.
Configure Target VM Access
Ensure the target VM has a private IP and no public IP (optional but recommended). The VM's NSG must allow inbound RDP (3389) or SSH (22) from the AzureBastionSubnet address range. You can add a rule like: Allow inbound from source 'VirtualNetwork' or specific subnet. If using Azure AD authentication, install the AADLoginForWindows extension on Windows VMs. For Linux, SSH key or password authentication works.
Connect to VM via Bastion
In the Azure portal, navigate to the target VM. Click 'Connect' and select 'Bastion'. You'll be prompted to authenticate: enter your Azure AD credentials (if enabled) or local VM credentials (username/password or SSH key). The session opens in a new browser tab over HTTPS. You can now manage the VM using RDP or SSH. To disconnect, simply close the browser tab.
Scenario 1: Healthcare Provider Securing Patient Data A hospital manages Azure VMs hosting electronic health records (EHR). Compliance with HIPAA requires that no VM is directly accessible from the internet. The IT team deploys Azure Bastion in a hub VNet connected to spoke VNets via VNet peering. Each spoke contains VMs for different departments. Administrators use Bastion to RDP into Windows VMs and SSH into Linux VMs for maintenance. They enable Azure AD authentication and conditional access policies to require multi-factor authentication (MFA). The Bastion host is scaled to Standard SKU to support up to 20 concurrent sessions. Cost is approximately $100/month for the Bastion host plus data transfer. Without Bastion, they would need a VPN gateway or ExpressRoute, which would cost more and require additional management.
Scenario 2: E-commerce Company DevOps An e-commerce company has a development environment with dozens of Linux VMs for microservices. Developers frequently need SSH access to debug issues. Previously, each VM had a public IP, leading to security alerts from automated scans. They remove all public IPs and deploy Bastion. Developers connect via the Azure portal using their Azure AD accounts. The Bastion host is Basic SKU, costing about $50/month. They enable file upload/download for transferring log files. One issue they encounter: the VM's NSG initially blocked traffic from the Bastion subnet, causing connection failures. After updating the NSG to allow inbound SSH from the AzureBastionSubnet, connections work. The team also learns that Bastion does not support custom ports by default (Standard SKU needed). They adjust their SSH configuration to use port 22.
Scenario 3: Global Enterprise with Peered VNets A multinational corporation has VNets in multiple Azure regions. They want a single Bastion deployment for all VMs in a region. They deploy Bastion in a central VNet and peer other VNets to it. However, they discover that Bastion only supports VNet peering within the same region. For cross-region connectivity, they must deploy Bastion in each region. They also learn that Bastion does not support connecting to VMs via private endpoints; the VM must have a private IP in the peered VNet. They set up Bastion in each region with Standard SKU for host scaling. The cost is higher but still less than managing jump servers.
Exactly What AZ-900 Tests on This Objective Objective 2.3: Describe core Azure architecture services. Within that, Azure Bastion is listed under "Secure remote access solutions." The exam tests your ability to identify the purpose and key features of Azure Bastion. You should know:
Azure Bastion provides secure RDP and SSH connectivity to Azure VMs directly from the Azure portal.
It eliminates the need for public IP addresses on VMs.
It is a fully managed PaaS service (Microsoft handles patching and availability).
It requires a dedicated subnet named AzureBastionSubnet with a minimum size of /27.
It uses TLS over port 443 for the client connection.
It supports both Basic and Standard SKUs (Standard adds scaling, IP-based connection, custom ports).
It can connect to VMs in the same VNet or peered VNets (same region only).
Common Wrong Answers and Why Candidates Choose Them 1. "Azure Bastion is used to connect to on-premises servers." – Wrong. Candidates confuse Bastion with VPN Gateway or ExpressRoute. Bastion is only for Azure VMs. 2. "Azure Bastion requires a public IP on each VM." – Wrong. Bastion eliminates the need for public IPs. Candidates think remote access always requires a public endpoint. 3. "Azure Bastion is an IaaS service that you manage." – Wrong. It's PaaS. Candidates think it's a jump server VM they must patch. 4. "Azure Bastion only works with Windows VMs." – Wrong. It supports both RDP (Windows) and SSH (Linux). Candidates may assume SSH is not supported.
Specific Terms and Values
- Subnet name: AzureBastionSubnet (exact spelling).
- Minimum subnet size: /27 (32 IPs).
- Ports: 443 (client to Bastion), 3389/22 (Bastion to VM).
- SKUs: Basic (default), Standard.
- Authentication: Azure AD (with extension) or local credentials.
Edge Cases and Tricky Distinctions - Bastion does not support connecting to VMs in a different region than the Bastion host. If you have VMs in multiple regions, you need Bastion in each region. - Bastion does not support connecting to VMs via private endpoints. The VM must have a private IP in the VNet. - Bastion does not support custom ports on Basic SKU. You need Standard SKU for non-standard RDP/SSH ports. - Bastion can connect to VMs without a public IP, but if a VM has a public IP, it can still be accessed directly (bypassing Bastion). The exam may test that Bastion is a secure alternative, not a replacement for NSGs.
Memory Trick
Remember: "Bastion = Beachhead" – a secure entry point. The subnet name AzureBastionSubnet is like a specific beachhead. Minimum size /27 = 32 IPs (think 32 = 2^5, /27 = 32 addresses). For the exam, associate Bastion with "portal," "no public IP," and "PaaS."
Decision Tree for Eliminating Wrong Answers - If the question asks about secure RDP/SSH without public IPs, eliminate any answer that mentions public IP, VPN, ExpressRoute, or IaaS. - If the answer says "jump server" or "VM," it's likely wrong because Bastion is PaaS. - If the answer includes "Azure portal" and "PaaS," it's likely correct.
Azure Bastion provides secure RDP and SSH connectivity to Azure VMs directly from the Azure portal, without exposing public IP addresses.
It is a fully managed PaaS service – Microsoft handles patching, updates, and availability.
Requires a dedicated subnet named 'AzureBastionSubnet' with a minimum size of /27 (32 IP addresses).
Uses TLS over port 443 for client-to-Bastion connections, and RDP (3389) or SSH (22) for Bastion-to-VM connections.
Two SKUs: Basic (default) and Standard (adds scaling, IP-based connection, custom ports, Kerberos).
Can connect to VMs in the same VNet or peered VNets (same region only).
Supports Azure AD authentication (requires AADLoginForWindows extension on Windows VMs).
Does not replace NSGs – VM NSG must allow inbound RDP/SSH from the Bastion subnet.
Bastion does not support cross-region connectivity or on-premises servers.
Pricing: Basic ~$0.07/hour, Standard ~$0.14/hour, plus data transfer egress.
These come up on the exam all the time. Here's how to tell them apart.
Azure Bastion
Fully managed PaaS service – no OS to patch
Connects via Azure portal over TLS on port 443
No public IP needed on target VMs
Scales automatically (Standard SKU)
Priced per hour, no upfront cost
Jump Server (IaaS VM)
IaaS VM you must manage and patch
Requires RDP/SSH client software
Jump server has a public IP (attack surface)
Manual scaling – need to resize or add VMs
VM cost plus management overhead
Azure Bastion
No client software needed – browser-based
Connects to VMs directly from portal
No public IP on VMs
Single region – VMs must be in same region
Priced per hour (Bastion host)
VPN Gateway (Point-to-Site)
Requires VPN client on admin device
Admin connects to entire VNet, then RDP/SSH to VMs
VMs can have public IPs or private
Supports cross-region and on-premises connectivity
Priced per connection hour + data transfer
Mistake
Azure Bastion requires a public IP on each VM to connect.
Correct
Azure Bastion eliminates the need for public IPs on VMs. The VM only needs a private IP. The Bastion host itself has a public IP, but that is only used for the portal connection over TLS.
Mistake
Azure Bastion is a virtual machine that I need to patch and manage.
Correct
Azure Bastion is a fully managed PaaS service. Microsoft handles all patching, updates, and availability. You do not have access to the underlying OS.
Mistake
Azure Bastion only supports Windows VMs via RDP.
Correct
Azure Bastion supports both RDP (Windows) and SSH (Linux) connections. You can connect to Linux VMs using SSH directly from the Azure portal.
Mistake
Azure Bastion can be deployed in any subnet within a VNet.
Correct
Azure Bastion requires a dedicated subnet named exactly 'AzureBastionSubnet'. No other resources can be placed in this subnet. The subnet must be at least /27 in size.
Mistake
Azure Bastion provides connectivity to on-premises servers.
Correct
Azure Bastion is designed for Azure VMs only. It cannot connect to on-premises servers. For hybrid connectivity, you would use VPN Gateway or ExpressRoute.
No, Azure Bastion only supports VMs in the same region as the Bastion host. If you have VMs in multiple regions, you need to deploy a Bastion host in each region. VNet peering across regions is not supported for Bastion connections.
Yes, Azure Bastion can connect to VMs that have public IPs, but the connection will still go through Bastion. However, if a VM has a public IP, it can also be accessed directly via RDP/SSH, which defeats the security purpose of Bastion. Best practice is to remove public IPs from VMs when using Bastion.
Azure Bastion supports two authentication methods: (1) Azure AD authentication – requires the AADLoginForWindows extension on Windows VMs and the VM must be Azure AD-joined; (2) Local VM authentication – using username/password or SSH keys stored on the VM. For Linux, SSH key or password is supported.
Yes, but only with the Standard SKU. The Basic SKU only supports default ports (3389 for RDP, 22 for SSH). With Standard, you can specify a custom port when initiating the connection.
The Basic SKU supports up to 2 concurrent sessions per Bastion host. The Standard SKU supports up to 50 sessions per scale unit (you can scale to multiple units). The actual limit depends on the subnet size and scaling configuration. Minimum subnet /27 allows up to 2 sessions; larger subnets allow more.
No, Azure Bastion is not free. It is priced per hour for the Bastion host (Basic ~$0.07/hour, Standard ~$0.14/hour) plus standard data transfer egress charges. There is a 30-day free trial for new users.
Yes, if the VNets are peered across subscriptions. The Bastion host must be in the same region as the target VMs. You need appropriate permissions (Contributor or Reader access) on the target VM.
You've just covered Azure Bastion — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?