Azure Bastion overview
Azure Bastion is a managed Azure service for securely connecting to virtual machines over RDP and SSH. Microsoft’s current documentation describes it as a fully managed PaaS service deployed into your virtual network that supports VM connectivity using private IP addresses, without requiring a public IP on each VM, an agent on the VM, or a separate jump host pattern in many common scenarios. :contentReference[oaicite:1]{index=1}
What is Azure Bastion?
Azure Bastion is a managed remote access service that lets administrators connect to Azure virtual machines using RDP or SSH while keeping those VMs on private IP space and avoiding direct exposure of management ports like 3389 and 22 to the public internet. Microsoft says Bastion is deployed into the virtual network itself and supports VMs in the local or peered virtual networks, depending on architecture. :contentReference[oaicite:2]{index=2}
What it does well
It centralizes VM administration access, reduces direct internet exposure, and simplifies secure RDP and SSH connectivity for teams that need managed Azure-native access patterns.
What it is not
It is not a public application gateway, not a web load balancer, not a WAF, and not a replacement for every network access pattern such as full site-to-site VPN requirements.
Why Azure Bastion is used
Teams use Azure Bastion when they need remote administration of VMs without placing public IP addresses on those VMs or exposing inbound management ports. This is especially useful in enterprise Azure environments where security teams want operational access paths to stay tightly controlled.
Reduce direct VM exposure
Bastion helps avoid exposing SSH and RDP directly to the internet, which is one of the most common hardening goals for VM-based environments.
Simplify secure admin access
Instead of building and maintaining your own jump server layer, teams can use a managed Azure service for common VM administration patterns.
Support private network architecture
Bastion fits well with hub-and-spoke designs, private subnets, and Azure environments where operational access should remain on private network paths.
Azure Bastion explained with the 5 Ws + How
This structure helps beginners, working engineers, and interview learners quickly understand where Azure Bastion fits in real cloud networking design.
What
A managed Azure service for secure RDP and SSH connectivity to virtual machines.
Why
To administer VMs without assigning public IPs to them or opening public inbound management ports.
When
Use it when VMs must remain privately addressed but administrators still need secure operational access.
Where
Deployed into the virtual network, typically in the dedicated AzureBastionSubnet, supporting local and often peered VNet scenarios. :contentReference[oaicite:3]{index=3}
Who
Cloud engineers, DevOps engineers, platform teams, operations teams, and security teams managing Azure VMs.
How
Azure Bastion brokers RDP or SSH access to private VMs through the Bastion service, instead of direct internet-facing management connectivity.
Azure Bastion SKUs
Microsoft’s current documentation says Azure Bastion now has four SKUs: Developer, Basic, Standard, and Premium. Choosing the right SKU matters because features such as host scaling and some advanced capabilities depend on the tier. :contentReference[oaicite:4]{index=4}
Developer
The low-cost or free-oriented entry option for lighter scenarios and learning or selected non-production use cases, depending on region and availability. Microsoft’s quickstart explicitly mentions the free Developer SKU. :contentReference[oaicite:5]{index=5}
Basic
A simpler managed Bastion option for core VM access scenarios where you need Bastion but not the broader feature set of higher SKUs. Basic creates two instances by default according to current configuration guidance. :contentReference[oaicite:6]{index=6}
Standard
The practical production choice for many enterprise environments. Current docs say Standard and higher support host scaling, and Microsoft’s Cloud Adoption Framework recommends Standard or Premium for production workloads. :contentReference[oaicite:7]{index=7}
Premium
The higher-end tier for environments that need the broader feature set and stronger enterprise alignment around Bastion capabilities. :contentReference[oaicite:8]{index=8}
| SKU | Best for | Design note |
|---|---|---|
| Developer | Sandbox, test, selected light usage | Good for learning and smaller scenarios where enterprise scaling is not the goal |
| Basic | Core secure VM access | Useful when you need Bastion but not broader advanced features |
| Standard | Most production use | Strong choice for enterprise VM administration patterns |
| Premium | Advanced production use | Best when the environment needs the richer Bastion feature model |
Core components of Azure Bastion
Azure Bastion becomes easier to design when you understand the moving parts around it: the Bastion host, the AzureBastionSubnet, the target VMs, the virtual network, and the chosen access method.
Bastion host
The managed Azure service resource that administrators connect through for secure VM access.
AzureBastionSubnet
The dedicated subnet required for Bastion deployment in standard architectures. Microsoft documents this as a specific Bastion configuration requirement. :contentReference[oaicite:10]{index=10}
Target virtual machine
The VM that remains on private IP space while Bastion provides the remote administration path.
Private IP path
The VM is reached privately inside Azure networking rather than through a direct public management endpoint.
Access method
Portal-based connection or, where supported by the tier, native RDP or SSH client access from local tools. :contentReference[oaicite:11]{index=11}
Optional advanced settings
Current Bastion docs discuss settings like host scaling and private-only deployment depending on architecture and SKU. :contentReference[oaicite:12]{index=12}
How Azure Bastion works
Azure Bastion sits between the administrator and the private VM administration path. Instead of opening RDP or SSH directly on the VM to the internet, Azure Bastion becomes the secure management entry point.
Step-by-step flow
- An administrator selects a VM connection through Azure Bastion.
- Bastion handles the secure access session from the user into Azure.
- Bastion reaches the target VM through private Azure network connectivity.
- The VM remains privately addressed and does not require its own public IP for this administration path. :contentReference[oaicite:13]{index=13}
Important operational behavior
- Bastion is for administration access, not application serving.
- The target VM can stay private.
- You reduce the need to expose management ports publicly.
- Bastion architecture depends on subnet, tier, and chosen deployment model.
Native client support
One of Bastion’s practical advantages is that current documentation says it can support connectivity not only through the Azure portal but also through native SSH or RDP clients on your local machine in supported scenarios and tiers. :contentReference[oaicite:14]{index=14}
Why native client support matters
Many engineers prefer to use their local terminal, local SSH keys, native RDP tools, and familiar operational workflows rather than staying only inside browser-based management sessions.
Why this improves real operations
It makes Bastion more practical for enterprise support, troubleshooting, scripting, and day-to-day administrative workflows where browser-only access would feel restrictive.
Private-only deployment
Microsoft’s current Bastion configuration guidance includes private-only deployment, which creates a non-internet-routable Bastion deployment that allows only private IP address access to the Bastion host itself. Microsoft contrasts this with regular Bastion deployment, where users connect to the Bastion host via public IP. :contentReference[oaicite:15]{index=15}
Host scaling
Current Microsoft guidance says Basic creates two Bastion instances, while Standard or higher lets you choose the number of instances through host scaling. Microsoft also notes that changing scale units disrupts active Bastion connections, so scaling changes should be planned during maintenance windows. :contentReference[oaicite:16]{index=16}
Why host scaling matters
It lets teams match Bastion capacity to expected concurrent administrative usage rather than relying on a fixed one-size-fits-all deployment.
Why this is a production concern
Secure access paths can become an operational bottleneck if they are not sized appropriately, especially in larger enterprise support environments.
Architecture diagram
This simple design shows Azure Bastion as a managed secure administration layer in front of private virtual machines.
Administrator
|
v
+------------------------------+
| Azure Bastion |
| Managed secure RDP / SSH |
| Deployed in AzureBastionSubnet|
+------------------------------+
|
v
+------------------------------+
| Private Azure VNet |
| Target VM (private IP only) |
+------------------------------+
Hub-and-spoke relevance
Microsoft’s design and architecture guidance says Bastion supports virtual network peering in standard architectures, which is one reason it fits well in hub-and-spoke enterprise Azure designs. :contentReference[oaicite:17]{index=17}
Real-world Azure Bastion use cases
These are the kinds of scenarios where Azure Bastion makes strong practical sense and where it can replace less desirable administration patterns.
Production VM administration
An operations team needs secure RDP and SSH into production VMs but security policy forbids public IPs on those VMs and forbids open management ports to the internet.
Hub-and-spoke enterprise design
A central Bastion deployment supports administration of VMs across local and peered virtual networks, reducing the need for jump servers in each spoke environment. :contentReference[oaicite:18]{index=18}
Replacing jump boxes
A team wants to eliminate self-managed bastion hosts or jump servers that require patching, hardening, monitoring, and lifecycle maintenance.
Azure Bastion vs jump box, VPN, and direct public IP access
Choosing the wrong access pattern is one of the most common architecture mistakes. Bastion is best understood by comparing it to the alternatives teams often use.
| Option | Main role | When to choose it |
|---|---|---|
| Azure Bastion | Managed secure VM administration | Choose when you want secure RDP/SSH access without public IPs on VMs |
| Jump box / jump host | Self-managed admin intermediary | Choose only when you need a custom pattern Bastion does not meet |
| VPN | Broader network connectivity | Choose when users need wider private network access, not only VM admin sessions |
| Public IP on each VM | Direct internet administration path | Usually avoid this for production unless there is a very strong reason |
Bastion vs jump box
Bastion is managed by Azure, while a jump box must be deployed, patched, monitored, secured, and maintained by your team. Bastion usually wins when the required feature set aligns with the Azure service model.
Bastion vs VPN
VPN gives broader network connectivity for users or sites. Bastion is more focused: secure remote administration of Azure VMs. These are not always replacements for each other.
Best practices
These recommendations help Azure Bastion deployments stay secure, practical, and production-ready.
Keep VMs private where possible
Use Bastion to reduce the need for public IPs and direct management port exposure on administrative targets.
Pick the right SKU early
Since Microsoft says downgrading after upgrade requires deletion and reconfiguration, choose the long-term tier carefully. :contentReference[oaicite:19]{index=19}
Use Standard or Premium for production where appropriate
Microsoft’s guidance explicitly recommends Standard or Premium for production workloads in many cases. :contentReference[oaicite:20]{index=20}
Design subnet and VNet placement intentionally
The Bastion subnet and the surrounding virtual network architecture should be treated as security-sensitive design choices, not as afterthoughts.
Evaluate private-only Bastion where security requires it
When the organization wants Bastion itself to avoid public IP reachability, private-only deployment is worth evaluating. :contentReference[oaicite:21]{index=21}
Plan scaling changes carefully
Microsoft notes that host scaling changes disrupt active Bastion connections, so operational timing matters. :contentReference[oaicite:22]{index=22}
Common mistakes
These are the problems engineers most often hit when Azure Bastion is misunderstood or deployed with the wrong assumptions.
Treating Bastion like application ingress
Bastion is for administrative access to VMs, not for publishing applications to end users.
Choosing the wrong SKU too casually
Teams sometimes pick a lower tier without considering long-term native client, scaling, or production needs.
Keeping jump boxes when they are no longer needed
Some environments continue running self-managed jump servers even when Bastion would reduce maintenance overhead.
Ignoring private-only deployment options
Organizations with strict security requirements sometimes overlook that Bastion can be deployed in a more locked-down model. :contentReference[oaicite:23]{index=23}
Not planning access scale
Concurrent administrative usage can matter, especially in larger support environments where host scaling becomes relevant.
Assuming Bastion replaces every connectivity tool
It helps with secure VM administration, but it does not automatically replace all VPN, firewall, or network access patterns.
Frequently asked questions
These questions reflect common real-world search intent around Azure Bastion.
What is Azure Bastion used for?
It is used for secure RDP and SSH access to Azure virtual machines without assigning public IPs to those VMs or exposing management ports directly to the internet. :contentReference[oaicite:24]{index=24}
Does Azure Bastion require a public IP on the virtual machine?
No. Microsoft’s overview says target VMs do not need a public IP address when you connect through Azure Bastion. :contentReference[oaicite:25]{index=25}
What Azure Bastion SKUs are currently available?
Microsoft’s current documentation lists Developer, Basic, Standard, and Premium SKUs. :contentReference[oaicite:26]{index=26}
Can Azure Bastion be private-only?
Yes. Microsoft documents a private-only Bastion deployment model that creates a non-internet-routable deployment. :contentReference[oaicite:27]{index=27}
Can I use my local native SSH or RDP client with Azure Bastion?
In supported scenarios and tiers, yes. Microsoft documents native client connectivity as part of the Bastion capability set. :contentReference[oaicite:28]{index=28}
Does Azure Bastion support scaling?
Yes, on Standard or higher, according to Microsoft’s current host scaling guidance. :contentReference[oaicite:29]{index=29}