Skip to main content
GenioCT

Which Azure Bastion SKU Do You Actually Need in 2026?

By Jeremy Genicot | | 14 min read
Azure Security Networking Enterprise

In this article

Four brass keys of increasing size laid out on a dark mat in front of a closed steel door with a lit glass panel.

In short: Azure Bastion ships in four SKUs, and Microsoft’s cost guidance tells you to start at Basic while its SKU guidance recommends Premium for production. Both are current, and they answer different questions. What should drive your choice is a short list of hard triggers: virtual network peering pushes you off Developer, the native client and file transfer push you off Basic, and session recording or a private-only deployment pushes you to Premium. Everything else is preference. Choose carefully, because a downgrade means deleting and recreating the host.

We wrote about Azure Bastion when it went GA in 2019. At the time the pitch was simple: stop putting public IPs on your VMs, stop maintaining jump boxes, stop shipping VPN clients to contractors. You deployed one Bastion host, and there was no SKU decision to make because there was only one product.

That pitch still holds. What has grown is the price list. Bastion now sells as Developer, Basic, Standard, and Premium, with a spread from free to roughly 329 dollars per month before anyone connects to anything. The advice we gave in 2019, deploy it and forget about it, has quietly become a budget line and an architecture decision that is awkward to walk back.

Four SKUs, and What Separates Them

Developer is free. It runs on shared Microsoft infrastructure rather than in your virtual network, so it needs no AzureBastionSubnet and no public IP address. In exchange it connects to one VM at a time, does not support concurrent connections, and cannot reach VMs across virtual network peering. Microsoft is direct about it being unsuitable for production. It is available in a subset of regions that covers most of Europe, including West Europe, North Europe, France Central, Germany West Central, Switzerland North, Sweden Central and UK South. Belgium Central is not on that list, so a Belgian team that wants everything in-country cannot use the free tier for local dev subscriptions.

Basic is the first dedicated deployment. You get a bastion host in your own virtual network with two fixed instances, which works out to 40 concurrent RDP sessions and 80 concurrent SSH sessions. Peering works, Kerberos works, concurrent connections work. Access is through the Azure portal only.

Standard adds the features most platform teams end up wanting and makes the host scalable from 2 to 50 instances. Each instance handles 20 concurrent RDP and 40 concurrent SSH sessions, so a fully scaled Standard host reaches 1,000 RDP or 2,000 SSH sessions.

Premium adds exactly two things on top of Standard: session recording, and private-only deployment with no public IP address on the bastion host itself.

DeveloperBasicStandardPremium
DeploymentSharedDedicatedDedicatedDedicated
AzureBastionSubnetNot needed/26 or larger/26 or larger/26 or larger
Public IPNot neededRequiredRequiredOptional
Peered virtual networksNoYesYesYes
InstancesShared2 fixed2 to 502 to 50
Max concurrent RDP1401,0001,000
Max concurrent SSH1802,0002,000
Native client (Azure CLI)NoNoYesYes
File transferNoNoYesYes
Shareable linksNoNoYesYes
IP-based connectionNoNoYesYes
Custom inbound portNoNoYesYes
Linux over RDP, Windows over SSHNoNoYesYes
Disable copy and pasteNoNoYesYes
Session recordingNoNoNoYes
Private-only deploymentNoNoNoYes
KerberosYesYesYesYes

Two rows in that table catch people out. Kerberos authentication is available on every SKU including the free one, so it is not a reason to buy up. File transfer is a Standard feature, but it works through the native client only: you cannot upload or download files through the Azure portal session or through PowerShell. Any workflow that assumed browser-based file copy needs az network bastion rdp or an az network bastion tunnel with scp behind it.

Microsoft’s Guidance Points Two Ways

Read Microsoft’s cost optimization principles for Bastion and you are told to “start with Basic SKU for production environments unless advanced features are required” and to upgrade only when you identify a specific feature gap. Read the SKU comparison page and you are told that “the cost difference between Standard and Premium is marginal” and that “Premium SKU is the recommended choice for production deployments.”

Both pages are current. They are not really in conflict, because they answer different questions: one is optimising your Azure bill, the other is optimising for capability and audit readiness. But a platform team reading both in the same afternoon gets no usable default, so here is ours.

Buy the SKU that your hard requirements force, and treat everything above that as a deliberate purchase. The hard requirements are a short list, and each one is binary.

Peering is the first. If your VMs live in spoke virtual networks and your bastion sits in a hub, Developer is out immediately, because it cannot cross a peering. That single line eliminates the free tier for almost every organisation running a hub-and-spoke topology, which is to say almost every organisation with a landing zone.

Native client access and file transfer are the second. Terminal-first teams will not accept a browser as the only way in, and troubleshooting workflows that involve pulling logs off a VM or pushing a script onto it need the native client path. Both require Standard.

Session recording and private-only deployment are the third. If your auditors want replayable evidence of what happened during a maintenance window, or your security architecture forbids a public IP on the access path, Premium is the only tier that does it and no amount of scaling Standard gets you there.

Host scaling is the quiet fourth. Basic’s ceiling of 40 concurrent RDP sessions sounds generous until a migration weekend puts thirty engineers on the platform at once. If you can foresee that, Standard’s scaling is worth having before you need it, because adding it later means an upgrade rather than a setting. Scaling is also not a thing to do casually mid-morning: Microsoft warns that any change to scale units disrupts active Bastion connections, and says to plan it into a maintenance window.

What It Costs

List prices for West Europe in US dollars, checked against the Azure retail prices API on 18 September 2026. Treat them as illustrative: EA, MCA and CSP agreements and exchange rates all move the real number. Bastion bills from the moment it is deployed, whether or not anyone connects.

SKUPer hourPer month at 730 hoursExtra instance per hour
DeveloperFreeFreen/a
Basic0.19138.70n/a, fixed at 2
Standard0.29211.700.14
Premium0.45328.500.22

Outbound data transfer is charged separately, with the first 5 GB per month free across all your Bastion resources and rates falling from roughly 0.087 dollars per GB into the volume tiers. For interactive sessions this line stays small, and consolidating deployments helps you stay inside the free allowance.

The base price for Standard and Premium includes two instances. Additional instances cost less per hour than the base host, so a four-instance Standard host runs about 416 dollars per month rather than double the base price.

About that “marginal” difference between Standard and Premium: it is 117 dollars per month per bastion host, or 55 percent more than Standard. Whether that is marginal depends entirely on what sits behind it. Against a hub serving forty production VMs it genuinely disappears into the noise, and Microsoft’s advice is sound. Against a single small spoke it is a real number that shows up in the subscription review, and if you cannot name the audit requirement that justifies session recording, you are paying 55 percent for a feature nobody has asked for.

Session recording itself stores to a blob container in your own storage account, so the recordings are your storage cost and your retention decision. Budget for that separately, and set a lifecycle policy on the container before you record the first session rather than after the first storage invoice. Note that Microsoft requires the container to have no immutable storage policy and no blob versioning, which rules out exactly the WORM configuration a strict auditor tends to ask for. Authenticating to that storage with a managed identity is the recommended way and is still in preview, so a SAS URL with an expiry you have to track is the GA path.

Before treating recording as a compliance control, read what it covers. Microsoft records the graphical session, and the docs are explicit that “Session recording isn’t available via native client at this time” and that Entra ID sign-in for portal RDP cannot be used at the same time as graphical recording. Once enabled it is all or nothing: it captures every session through that host. Put those together with the reason most teams buy Standard in the first place, which is native client access, and the awkward shape appears. The engineers who work through az network bastion ssh are the ones whose sessions produce no recording. The same tension shows up inside Premium, because the private-only guidance recommends the native client for end-to-end private connectivity, and that is the path recording does not cover.

The Choice Is Harder to Reverse Than It Looks

Upgrading a Bastion SKU works in place, takes around ten minutes, and lets you add features during the upgrade. Downgrading is not supported at all. Moving from Premium back to Standard means deleting the bastion host and creating a new one, which is a change window, a new public IP if the old one was not reserved, and a gap in access while it happens.

One Premium feature is stickier than the SKU itself. Private-only is set at deployment, and Microsoft states plainly that “You can’t change from a regular Bastion deployment to a private-only deployment.” Going private-only later means removing the bastion host and deploying it again in that mode, though the AzureBastionSubnet survives. So the upgrade path that works for session recording does not work here. If a no-public-endpoint requirement is even plausible within the life of the platform, decide it on day one rather than filing it under features you can switch on later.

This asymmetry should shape the decision more than it usually does. Over-buying is not a mistake you fix next quarter when someone notices it in the cost review. It is a recurring monthly charge with a maintenance window attached to its removal. Under-buying is the cheaper error, because the fix is a ten-minute in-place upgrade.

That argues for buying the SKU your requirements force today rather than the one you might grow into, with one exception: if a migration or an onboarding wave is already scheduled and will exceed Basic’s concurrency, buy Standard before it rather than during it.

Keeping the Bill Honest

Developer being free changes the economics of non-production access. Every sandbox subscription, personal lab, and dev environment where one engineer connects to one VM at a time can run Developer at zero cost, in most European regions. That alone removes a category of spend that used to be a permanent Basic host per environment.

For everything dedicated, consolidation does the work. One Bastion host in a hub serves VMs across every peered spoke, so the cost question is how many hubs you have rather than how many virtual networks. Teams that deployed Bastion per spoke out of habit are usually paying several hundred dollars a month for duplication.

On-demand deployment still earns its place in environments that need dedicated features but only occasionally. A Terraform module with a boolean flag on the bastion host and its public IP lets a team bring it up for a maintenance window and destroy it afterwards. Terraform makes this cheap to operate, and the ten-minute deployment time is tolerable for planned work. It is a poor fit for anything that needs unplanned access at three in the morning, so keep production hubs always on and apply the pattern to spokes and sandboxes.

One landing-zone habit is worth adopting regardless of which SKU you pick. Reserve the /26 AzureBastionSubnet in every hub virtual network address plan, even where Bastion is not deployed yet. The minimum size has been /26 since November 2021, hosts deployed into older /27 subnets keep working but cannot scale, and finding a spare /26 after the rest of the address space is allocated is a genuinely annoying afternoon. While you are there, decide on availability zones too. Zone deployment is still in preview, covers West Europe, North Europe and UK South among others, and like private-only it cannot be changed after the resource exists.

What Bastion Does Not Give You

Bastion controls the path to the VM and records that a session happened. It does not decide who should have been on that VM in the first place, and it is not a privileged access management product. Session recording gives auditors evidence after the fact. It does not add an approval step before the session starts. If your control requirement is “a second person approves production access”, that is Defender for Cloud just-in-time access, an Entra ID Privileged Identity Management role, or a real PAM tool, layered on top.

Deploying Bastion also does nothing to stop someone attaching a public IP to a VM next week. Enforcing that is an Azure Policy deny on public IP association in spoke subscriptions, which belongs in your landing zone rather than in the Bastion configuration. Without it you have bought a secure front door and left a window open beside it.

The NSG rules on AzureBastionSubnet are the most common deployment failure we see. Microsoft publishes specific inbound and outbound requirements, and a security team applying a standard restrictive NSG template to that subnet will break the service in ways that look like a platform fault. Get those rules into the module that creates the subnet so nobody has to remember them.

Finally, turn on diagnostic settings and send Bastion connection logs to Log Analytics. Every session records who connected, to which VM, when, and for how long, at no additional cost beyond ingestion. For audit evidence that log is often more useful than the session recording, because it answers the question auditors actually ask first, which is who had access rather than what they typed.

The Decision at a Glance

SituationSKUWatch out for
Sandbox or personal dev, one VM at a time, supported regionDeveloperNo peering, no concurrent sessions, not for production
Production access, portal only, no peering-independent features neededBasicFixed at 40 RDP sessions, no native client, no file transfer
Hub serving spokes, terminal-first teams, file transfer, contractor accessStandardSize the instance count ahead of a migration wave rather than during it
Session recording required, or no public IP permitted on the access pathPremiumRecording misses native-client sessions, and private-only cannot be turned on later
Any dedicated SKUMicrosoft now recommends Premium for production, at 55 percent more per host

Bastion in 2026 does the same job it did in 2019 and does it well. What changed is that the SKU line is now where the cost and the compliance posture are decided, and Microsoft’s documentation will not choose for you. Work the four triggers in order, buy the tier they force, and reserve the /26 whether or not you deploy today.

Need help with your Azure security posture?

We help enterprises design and tune Azure security controls: WAF policies, Sentinel ingestion, Defender for Cloud, identity governance, and NIS2/DORA readiness.

Start with a security assessment. Typical engagement: 2-4 weeks.
Discuss your security needs
Share this article

Start with a Governator-powered Azure Health Check

Not sure where to begin? A quick architecture review gives you a clear picture. No obligation.

  • Risk scorecard across identity, network, governance, and security
  • Top 10 issues ranked by impact and effort
  • 30-60-90 day roadmap with quick wins