This chapter covers the differences between Azure Bastion's two SKUs—Developer and Standard—focusing on their features, limitations, and appropriate use cases. Understanding when to choose each SKU is critical for the AZ-104 exam, particularly for objectives related to secure remote access and network connectivity. Approximately 5-10% of exam questions touch on Azure Bastion, often testing SKU selection and feature awareness.
Jump to a section
Imagine two security checkpoints for a corporate campus. The Developer SKU is like a simple guard shack at the entrance: one guard, a phone, and a logbook. It handles one visitor at a time, and if two people arrive simultaneously, one must wait. The guard can only check IDs and make calls; there's no waiting room, no video surveillance, and no backup power. This works fine for a small office with occasional visitors. The Standard SKU is a full security booth: multiple guards, a waiting area, CCTV, biometric scanners, and a backup generator. It can process several visitors concurrently, record every interaction, and operate even during a power outage. The booth also has a separate entrance for deliveries and a secure holding area. In Azure terms, the Developer SKU provides basic RDP/SSH connectivity over TLS on a single instance with no SLA, while the Standard SKU offers concurrent sessions, session recording, logging, and a 99.95% SLA. Just as you wouldn't put a guard shack at a busy airport, you shouldn't use the Developer SKU for production workloads requiring high availability or audit trails.
What is Azure Bastion and Why Two SKUs?
Azure Bastion is a fully managed PaaS service that provides secure and seamless RDP and SSH connectivity to virtual machines directly in the Azure portal over TLS. It eliminates the need for public IP addresses on VMs, bastion hosts, or jump boxes, reducing exposure to the internet. The service is deployed inside a virtual network and uses a dedicated subnet named AzureBastionSubnet.
Microsoft introduced two SKUs in 2024 to address different customer needs: Developer SKU and Standard SKU. The Developer SKU is a cost-effective, single-instance option for development and testing, while the Standard SKU is a fully featured, highly available option for production workloads. The exam expects you to know the key differences and when to use each.
How Azure Bastion Works Internally
Azure Bastion operates by establishing a secure WebSocket tunnel between the user's browser and the target VM. When a user clicks "Connect" in the Azure portal, the following happens:
The portal initiates a request to the Bastion resource in the same region.
Bastion authenticates the user via Azure AD and RBAC (role-based access control).
Bastion creates a TLS-encrypted WebSocket connection to the user's browser.
Bastion then establishes an RDP (port 3389) or SSH (port 22) connection to the target VM over the private network.
The user interacts with the VM through the browser, with all traffic encrypted and proxied through Bastion.
Bastion does not require any agent installed on the VM. It uses the VM's private IP address and the credentials provided by the user. The service is region-specific and must be deployed in the same region as the VMs it connects to.
Key Components and Differences
#### Developer SKU - Instance Type: Single instance, no high availability. - SLA: No SLA (99.9% for Standard). - Concurrent Sessions: Limited – typically 1-2 concurrent RDP/SSH sessions. - Features: Basic RDP/SSH connectivity over TLS. No session recording, no logging, no custom ports. - Scaling: Cannot scale; fixed to a single instance. - Pricing: Lower cost, billed per hour. - Use Case: Development and test environments where availability and advanced features are not critical.
#### Standard SKU - Instance Type: Multiple instances (scale up to 50 instances) for high availability. - SLA: 99.95% SLA. - Concurrent Sessions: Scalable – supports hundreds of concurrent sessions. - Features: Session recording, logging with Azure Monitor, custom ports, IP-based connections, Kerberos, and more. - Scaling: Can scale out by increasing instance count. - Pricing: Higher cost, billed per hour per instance. - Use Case: Production environments requiring high availability, audit trails, and advanced security.
Configuration and Verification
To deploy Azure Bastion, you need:
A virtual network with a subnet named AzureBastionSubnet (minimum /27 subnet mask).
The subnet must not have any network security groups (NSGs) associated (or if they are, specific inbound/outbound rules must allow Bastion traffic).
The Bastion resource is created in the same region as the VNet.
Deploy via Azure CLI:
az network bastion create --name MyBastion --resource-group MyRG --vnet-name MyVNet --public-ip-address MyPublicIP --sku StandardCheck SKU:
az network bastion show --name MyBastion --resource-group MyRG --query skuScale Standard SKU:
az network bastion update --name MyBastion --resource-group MyRG --scale-units 10Interaction with Related Technologies
Azure Bastion integrates with: - Azure AD: For authentication and RBAC. - Azure Monitor: For logging and session recording (Standard only). - Azure Private Link: To access Bastion over private endpoints. - Network Security Groups: While NSGs on AzureBastionSubnet are not recommended, they can be used with caution to restrict traffic. - Azure Firewall: Bastion can be used in a hub-and-spoke topology with Azure Firewall.
Exam-Relevant Details
The Developer SKU was introduced in preview in late 2024 and is now generally available.
You cannot upgrade from Developer to Standard without recreating the resource.
The AzureBastionSubnet must be at least /27; smaller subnets cause deployment failure.
Bastion does not support connecting to VMs using public IP addresses; it always uses private IPs.
Bastion supports RDP (3389) and SSH (22) by default; custom ports are supported only in Standard SKU.
Session recording is available only in Standard SKU and must be enabled with Azure Monitor diagnostic settings.
The Developer SKU is not eligible for any SLA.
Bastion supports connecting to VMs in peered VNets (within the same region or global peering).
Choose the Right SKU
First, determine whether the workload is production or non-production. If it's a production environment requiring high availability, audit logging, and concurrent user access, select Standard SKU. For dev/test or single-user scenarios, Developer SKU suffices. The exam often presents scenarios where you must choose based on requirements like 'needs SLA' or 'supports session recording'—Standard is the answer.
Create AzureBastionSubnet
Within the target virtual network, create a subnet named exactly 'AzureBastionSubnet'. The subnet mask must be at least /27 (32 IPs) for Standard SKU; Developer SKU can use a /26 or larger. Do not associate any NSG initially, as misconfigured NSGs can block Bastion's control plane traffic. If NSGs are required, ensure inbound rules allow TCP 443 from AzureCloud and outbound rules allow TCP 443 to AzureCloud and TCP 3389/22 to target VMs.
Create Public IP Address
Bastion requires a public IP address to receive RDP/SSH connections from the internet. The public IP must be in the same region as the Bastion and have a Standard SKU (not Basic). Create the public IP with static allocation. This IP is the entry point for the browser-based connection. Note: The public IP is used only for the Bastion service; target VMs remain private.
Deploy Bastion Resource
In the Azure portal, navigate to 'Bastions' and click 'Create'. Select the subscription, resource group, region, virtual network, and AzureBastionSubnet. Choose the SKU: Developer or Standard. Provide a name and select the public IP created earlier. For Standard SKU, you can also set the initial scale units (default 2, max 50). Click 'Review + create' to deploy.
Configure Advanced Features (Standard)
For Standard SKU, enable diagnostic settings to send logs to a Log Analytics workspace for session recording. Configure RBAC roles: 'Reader' on the VM for users to see it, and 'Contributor' on the Bastion resource for administrators. Optionally, set up custom ports or IP-based connections. For session recording, enable 'Session Recording' in the Bastion resource under 'Configuration' and create a diagnostic setting capturing 'BastionAuditLogs'.
Connect to a VM
In the Azure portal, go to the target VM, click 'Connect', and select 'Bastion'. Choose the Bastion resource (if multiple). Provide username and password (or SSH key) for the VM. For Standard SKU, you can also use Azure AD authentication. The browser establishes a WebSocket connection to the Bastion's public IP on port 443. Bastion then connects to the VM's private IP on RDP (3389) or SSH (22). The session is encrypted end-to-end.
Enterprise Scenario 1: Production Web Farm with Compliance Requirements
A financial services company deploys a multi-tier web application across 50 VMs in a production virtual network. They need secure remote access for administrators to troubleshoot issues, but auditors require session recording and logging for all RDP/SSH sessions. The team chooses Azure Bastion Standard SKU with 10 scale units to handle up to 100 concurrent sessions. They enable session recording and stream logs to Azure Monitor for retention. The Bastion is deployed in a hub VNet with global VNet peering to spoke VNets. The public IP is locked down with DDoS Protection Standard. Misconfiguration risk: forgetting to enable diagnostic settings for session recording—auditors will flag the gap. Also, if the scale units are too low, users experience connection failures during peak incidents.
Enterprise Scenario 2: Dev/Test Environment for a Startup
A startup uses a single VM for a development server and occasional testing. The team of three developers needs to access the VM from home. Budget is tight, and high availability is not critical. They deploy Azure Bastion Developer SKU for $0.10/hour instead of $0.20/hour for Standard. The single instance handles one session at a time, which is acceptable since developers coordinate. The VM has no public IP, reducing attack surface. If two developers try to connect simultaneously, the second gets a 'resource busy' error. The startup accepts this limitation. A common mistake: assuming Developer SKU supports session recording—it does not, so if compliance becomes a requirement later, they must recreate with Standard SKU.
Enterprise Scenario 3: Multi-Region Disaster Recovery
An e-commerce company runs active-passive DR across two regions. The primary region uses Standard SKU with 20 scale units. The DR region also has a Bastion Standard SKU but with only 2 scale units to save costs. During a failover test, support staff in the DR region experience slow connections because 2 scale units cannot handle 30 concurrent sessions. They learn that scale units must match expected load. The fix is to pre-scale the DR Bastion to at least 10 units before failover. Additionally, they use Azure Front Door to route Bastion traffic to the active region, but Bastion does not support Front Door directly—they must use Traffic Manager or a custom DNS solution.
What AZ-104 Tests on Azure Bastion SKUs (Objective 4.5: Configure and manage virtual networking)
The exam focuses on: - SKU selection based on requirements (SLA, session recording, concurrent users). - Subnet requirements (AzureBastionSubnet /27 minimum). - Feature differences (e.g., custom ports, logging). - Limitations (no upgrade path, no NSGs on subnet).
Common Wrong Answers and Why Candidates Choose Them
Choosing Developer SKU for production because it's cheaper. Many candidates see 'Developer' and assume it's sufficient for production, missing the lack of SLA and high availability. The correct answer is Standard SKU when SLA is required.
Selecting Standard SKU for a single VM dev test because it's 'better'. Overprovisioning is not penalized, but the exam may ask for the most cost-effective solution. If the scenario says 'no SLA needed', Developer SKU is correct.
Assuming you can upgrade SKU in place. The exam loves to test that you must recreate the Bastion resource to change SKU. Candidates often think you can update via portal.
Thinking Bastion requires a public IP on the VM. Bastion uses private IPs; the public IP is only for the Bastion service itself. Wrong answers often state 'assign a public IP to the VM'.
Specific Numbers and Terms on the Exam
Subnet name: AzureBastionSubnet (case-sensitive).
Minimum subnet size: /27 for Standard; /26 for Developer (though /27 works for both).
SKU names: 'Developer' and 'Standard' (not 'Basic' or 'Premium').
SLA: Standard 99.95%; Developer no SLA.
Default ports: RDP 3389, SSH 22.
Scale units: 2 to 50 for Standard.
Edge Cases and Exceptions
AzureBastionSubnet with NSG: While not recommended, you can associate an NSG if you allow specific inbound/outbound rules. The exam may present a scenario where an NSG is blocking connections, and you must identify the missing rule.
Global VNet Peering: Bastion supports connecting to VMs in peered VNets, but the Bastion and VM must be in the same region? No—global peering works, but latency may be high. The exam might test that Bastion can connect across peered VNets.
Azure AD Authentication: Only supported with Standard SKU and requires Azure AD integration on the VM.
How to Eliminate Wrong Answers
When you see a scenario question:
Identify the key requirement: Is SLA needed? Is session recording needed? Are concurrent sessions > 2? If yes to any, eliminate Developer SKU.
Look for the subnet name: If it's not exactly 'AzureBastionSubnet', the answer is invalid.
Check for upgrade path: If the question asks to change SKU, the correct answer involves recreating the resource, not updating.
Remember public IP: Bastion needs a public IP on the service, not on VMs. Any answer that assigns a public IP to a VM is wrong.
By applying these elimination rules, you can confidently choose the correct SKU and configuration.
Azure Bastion requires a dedicated subnet named AzureBastionSubnet with a minimum /27 prefix.
The Developer SKU has no SLA; the Standard SKU offers a 99.95% SLA.
Session recording and custom ports are only available with the Standard SKU.
You cannot change the SKU after creation; you must recreate the Bastion resource.
Bastion connects to VMs using private IPs; no public IPs are needed on VMs.
The Developer SKU is designed for non-production environments with low concurrency.
Standard SKU supports scaling from 2 to 50 scale units.
These come up on the exam all the time. Here's how to tell them apart.
Developer SKU
Single instance, no high availability
No SLA
Limited concurrent sessions (1-2)
No session recording or logging
Lower cost, suitable for dev/test
Standard SKU
Multiple instances, high availability
99.95% SLA
Scalable concurrent sessions (up to hundreds)
Session recording and logging with Azure Monitor
Higher cost, suitable for production
Mistake
Azure Bastion Developer SKU can be upgraded to Standard SKU without downtime.
Correct
No, you cannot upgrade the SKU. You must delete the existing Bastion resource and create a new one with the desired SKU. This causes downtime during recreation.
Mistake
Azure Bastion requires a public IP address on each VM to connect.
Correct
Bastion connects to VMs using their private IP addresses only. The public IP is assigned to the Bastion service itself, not to the VMs. VMs remain fully private.
Mistake
Both Developer and Standard SKUs support session recording.
Correct
Session recording is only available with the Standard SKU. The Developer SKU does not support logging or recording of sessions.
Mistake
Azure Bastion can be deployed in any subnet as long as it has internet access.
Correct
Bastion requires a dedicated subnet named exactly 'AzureBastionSubnet' with a minimum /27 prefix. It cannot share a subnet with other resources.
Mistake
The Developer SKU provides a 99.9% SLA.
Correct
The Developer SKU has no SLA. Only the Standard SKU provides a 99.95% SLA. The exam tests this distinction.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Technically yes, but it is not recommended because the Developer SKU has no SLA and supports very few concurrent sessions. For production workloads requiring high availability and reliability, use the Standard SKU. The exam will consider Developer SKU inappropriate for production scenarios.
You cannot change the SKU directly. You must delete the existing Azure Bastion resource and create a new one with the Standard SKU. This will cause a brief outage. Plan accordingly.
Yes, Azure Bastion supports connections to VMs in peered VNets, including global VNet peering. The Bastion resource must be in the same region as the VNet it is deployed in, but it can reach VMs in peered VNets in other regions.
The Developer SKU is approximately half the cost of the Standard SKU per hour. However, exact pricing varies by region. The Standard SKU also charges per scale unit, so costs increase with higher scale. Check the Azure pricing calculator for current rates.
No, Azure Bastion requires a public IP address to accept incoming RDP/SSH connections from the internet. The public IP is attached to the Bastion resource, not to the VMs. The VMs remain private.
Yes, Azure Bastion supports both password and SSH key authentication for Linux VMs. For Windows VMs, it supports password and Azure AD authentication. SSH keys can be uploaded during connection.
The Standard SKU supports a maximum of 50 scale units. Each scale unit increases the number of concurrent sessions and throughput. The default is 2 scale units.
You've just covered Azure Bastion Standard vs Developer SKU — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?