Securing remote access to virtual machines is one of the most important responsibilities in any cloud engineering architecture. Directly exposing VMs to the public internet increases risk and expands the attack surface. That’s where secure access patterns like jumpboxes, bastion hosts, and Azure Bastion come into play.
Each of these solutions provides a different level of control, visibility, and security. In this article, we’ll walk through what each method offers, with a deeper focus on how Azure Bastion simplifies secure access without requiring public IP addresses on your virtual machines.
What Is a Jumpbox or Bastion Host?
A jumpbox (sometimes called a jump server) is a virtual machine placed in a public subnet that acts as a gateway into your private environment. It is commonly used in development and test environments where teams want fast and lightweight access without setting up complex network rules.
A bastion host is a hardened version of a jumpbox used in production environments. It often has additional security measures in place, including patch management, limited user accounts, and network segmentation.
Key characteristics:
-
Deployed in a public subnet with a public IP
-
Used to initiate RDP (for Windows) or SSH (for Linux) into private resources
-
Acts as a single point of entry, limiting exposure for internal systems
While effective, both models require ongoing VM maintenance, patching, monitoring, and careful configuration of firewall rules and access policies. Organizations that need to meet strict security and compliance requirements often find these traditional approaches difficult to scale.
Azure Bastion: A Cloud-Native Approach
Azure Bastion is a fully managed service that provides secure, seamless RDP and SSH connectivity to Azure virtual machines without requiring those machines to have a public IP. Instead, users initiate sessions directly from the Azure portal over port 443 using Transport Layer Security (TLS), eliminating the need to open common RDP or SSH ports like 3389 or 22.
This approach reduces operational overhead, enhances security, and aligns with zero trust principles.
Benefits of Azure Bastion
Improved Security
-
Private IP access only: Your VMs remain private, with no public exposure
-
No inbound rules: NSGs do not need to allow inbound RDP or SSH traffic
-
TLS tunneling: Sessions use encrypted connections over port 443
-
Supports microsegmentation: Centralized access improves network defensibility
Browser-Based Access
-
No client required: SSH and RDP sessions launch directly from the Azure portal
-
Works across platforms: Compatible with Windows, macOS, and Linux, supporting modern workplace solutions
-
Identity-driven: Enforces Azure role-based access and optional Conditional Access policies
Minimal Operational Overhead
-
No VM management: Azure Bastion requires no OS patching or host monitoring
-
High availability included: Built-in redundancy and zone resilience in the Standard tier
-
No manual scaling or updates required
Role-Based Access and Policy Control
-
Granular permissions: Assign who can access which machines using RBAC
-
Policy enforcement: Use Conditional Access for MFA, device compliance, and geo-based restrictions
-
Audit logging: Monitor all access through the Azure control plane
Monitoring and Observability
-
Native logging: Send diagnostics to Log Analytics, Event Hubs, or Storage
-
Audit sessions: Track login attempts, durations, and IPs
-
Security integration: Use Azure Sentinel to detect anomalies or threats using KQL queries
Advanced Features with Azure Bastion Standard Tier
-
VNet peering support: Connect to VMs in peered networks, ideal for hub and spoke models
-
IP-based access: Option to connect to VMs directly via IP address
-
Session recording (preview): Record sessions for compliance or training, supporting frameworks such as the NIST Cybersecurity Framework
Bastion Setup and Networking Best Practices
To deploy Azure Bastion:
-
Create a dedicated subnet named AzureBastionSubnet with at least a /26 address space
-
Apply NSG outbound rules that allow internet access for the Bastion service itself (inbound rules are not required)
-
Ensure no outbound User Defined Routes (UDRs) from the Bastion subnet interfere with internet-bound traffic over port 443
-
Avoid routing Bastion through firewalls or appliances that perform NAT or SSL inspection
When using VNet peering, make sure route tables in spoke networks allow Bastion to VM communication. For broader guidance, refer to Azure security best practices and patterns from Microsoft.
Cost Comparison: Jumpbox vs Bastion Host vs Azure Bastion
One of the most common questions when choosing a remote access strategy is cost. The table below compares the ongoing expenses associated with each approach for a typical small-to-mid-size deployment.
| Cost Factor | Self-Managed Jumpbox | Hardened Bastion Host | Azure Bastion (Basic) | Azure Bastion (Standard) |
|---|---|---|---|---|
| Compute Cost | VM cost (e.g., B2s ~$30/mo) | VM cost (e.g., D2s_v5 ~$70/mo) | Included in service | Included in service |
| Service Fee | None | None | ~$140/mo (per host) | ~$330/mo (per host, scalable) |
| Public IP Cost | ~$4/mo per IP | ~$4/mo per IP | Included | Included |
| OS Licensing | Windows Server license or Linux | Windows Server license or Linux | None (PaaS) | None (PaaS) |
| Patching / Maintenance | Manual (IT staff hours) | Manual with stricter cadence | None (fully managed) | None (fully managed) |
| Monitoring Setup | Manual (install agents, configure alerts) | Manual | Built-in diagnostics | Built-in diagnostics |
| Scaling Cost | New VM per region/VNet | New VM per region/VNet | Per scale unit (~$330/mo each) | Per scale unit (~$330/mo each) |
| Total Estimated Monthly | ~$35-100 + staff time | ~$75-200 + staff time | ~$140 | ~$330+ (scales with demand) |
Note: Azure Bastion costs are based on hourly billing. The Developer tier is free but uses shared infrastructure and is limited to dev/test scenarios. For production workloads with multiple administrators, the Standard tier’s per-scale-unit pricing becomes more cost-effective than managing multiple jumpbox VMs across regions. Reducing operational overhead is also a key part of broader cloud cost optimization strategies.
While the service fee for Azure Bastion appears higher than a simple VM, organizations should account for the hidden costs of self-managed jumpboxes: IT staff time for patching, monitoring, incident response if the jumpbox is compromised, and the security risk of maintaining a public-facing VM with RDP or SSH exposed.
Security Best Practices for Remote Access
Regardless of which remote access model you choose, the following security practices should be part of your architecture.
Eliminate Public IPs Where Possible
Every public IP address on a VM is a potential attack vector. Threat actors continuously scan public IP ranges for open RDP (port 3389) and SSH (port 22) ports. Azure Bastion eliminates this risk entirely since target VMs never need a public IP. If you must use a jumpbox, restrict inbound access to specific IP ranges using NSGs and consider enabling just-in-time (JIT) VM access through Microsoft Defender for Cloud to open ports only when needed and only for a limited time.
Enforce Multi-Factor Authentication
Whether access flows through a jumpbox or Azure Bastion, require MFA for all administrative sessions. For Azure Bastion, this is enforced through Conditional Access policies in Microsoft Entra ID. For self-managed jumpboxes, consider deploying Azure AD Application Proxy or a third-party MFA solution at the RDP/SSH gateway level. Organizations managing Azure SSO configurations should ensure that MFA policies apply consistently across both portal access and remote management sessions.
Implement Session Logging and Recording
For compliance frameworks like SOC 2 and HIPAA, audit trails of administrative access to production systems are often required. Azure Bastion Premium tier supports session recording, which captures the full RDP or SSH session for later review. For self-managed bastion hosts, consider deploying a Privileged Access Management (PAM) solution that records sessions and manages credentials centrally.
Segment Administrative Access from User Traffic
Place your jumpbox or Azure Bastion in a dedicated management subnet that is isolated from application workloads and end-user traffic. In a hub-and-spoke network topology, the management subnet typically resides in the hub VNet, with peering connections to spoke VNets where workloads run. This ensures that a compromise of the management plane does not directly expose application data.
Rotate Credentials and Use Managed Identities
Avoid storing static passwords or SSH keys on jumpbox VMs. Instead, use Azure AD authentication for SSH (available on Linux VMs) or leverage Azure Key Vault to store and rotate credentials. For automated access scenarios, use managed identities to authenticate without embedding secrets in code or configuration files.
Step-by-Step: Deploying Azure Bastion with Azure CLI
The following walkthrough deploys Azure Bastion in Standard tier using Azure CLI. This is suitable for production environments that need native client support and VNet peering.
# Step 1: Create the resource group
az group create --name rg-bastion-prod --location eastus
# Step 2: Create the virtual network with an AzureBastionSubnet
az network vnet create \
--resource-group rg-bastion-prod \
--name vnet-hub \
--address-prefix 10.0.0.0/16 \
--subnet-name AzureBastionSubnet \
--subnet-prefix 10.0.1.0/26
# Step 3: Create a public IP for Azure Bastion
az network public-ip create \
--resource-group rg-bastion-prod \
--name pip-bastion \
--sku Standard \
--allocation-method Static
# Step 4: Deploy Azure Bastion (Standard tier)
az network bastion create \
--resource-group rg-bastion-prod \
--name bastion-hub \
--public-ip-address pip-bastion \
--vnet-name vnet-hub \
--sku Standard \
--enable-tunneling true
# Step 5: Connect to a VM using the native client (Standard tier)
az network bastion ssh \
--name bastion-hub \
--resource-group rg-bastion-prod \
--target-resource-id /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vm-name} \
--auth-type ssh-key \
--username azureuser \
--ssh-key ~/.ssh/id_rsaAfter deployment, verify connectivity by navigating to the target VM in the Azure portal and clicking Connect > Bastion. For environments using Azure Virtual Desktop, Azure Bastion can also provide administrative access to AVD session hosts without exposing them publicly.
Which Remote Access Model Is Right for You?
Choosing the right solution depends on your environment:
| Criteria | Self-Managed Jumpbox | Hardened Bastion Host | Azure Bastion |
|---|---|---|---|
| Best For | Dev/test, temporary access | Production with strict controls | Production at any scale |
| Security Level | Low to moderate | High (if properly maintained) | High (managed by Microsoft) |
| Operational Overhead | High (patching, monitoring, scaling) | High (hardening, auditing, patching) | Low (fully managed PaaS) |
| Public IP Required on Target VMs | No (only on jumpbox) | No (only on bastion host) | No (not on any VM) |
| MFA Support | Requires additional configuration | Requires additional configuration | Native via Conditional Access |
| Session Recording | Requires third-party tools | Requires third-party tools | Built-in (Premium tier) |
| Multi-VNet Support | Separate jumpbox per VNet | Separate host per VNet | Single deployment via VNet peering |
| Compliance Suitability | Limited | Good with proper hardening | Strong (SOC 2, HIPAA, NIST) |
Frequently Asked Questions
What is Azure Bastion?
Azure Bastion is a fully managed platform-as-a-service (PaaS) from Microsoft that provides secure RDP and SSH access to your Azure virtual machines. It connects directly through the Azure portal over TLS on port 443, so your VMs never need a public IP address or an exposed management port.
What is the difference between a jumpbox and a bastion host?
A jumpbox is a general-purpose virtual machine placed in a public subnet to serve as an access point into a private network. A bastion host is a hardened version of a jumpbox, typically configured with stricter security controls such as limited user accounts, patch management, and network segmentation. Both require ongoing maintenance, whereas Azure Bastion eliminates the need to manage a host VM entirely.
Does Azure Bastion replace the need for a VPN?
Azure Bastion is designed specifically for secure RDP and SSH access to Azure VMs, not as a full network-level VPN replacement. However, for teams that only need to manage virtual machines remotely, Azure Bastion can eliminate the need for a site-to-site or point-to-site VPN by providing browser-based access without exposing public IPs.
What SKU tiers does Azure Bastion offer?
Azure Bastion is available in four tiers: Developer (free, shared infrastructure for dev/test), Basic (dedicated deployment with fixed capacity), Standard (adds native client support, shareable links, IP-based connections, and host scaling), and Premium (adds session recording and private-only deployment for enhanced compliance).
How much does Azure Bastion cost compared to a jumpbox?
A self-managed jumpbox typically costs $35-100 per month in compute and IP charges, but does not include the IT staff time required for patching, monitoring, and incident response. Azure Bastion Basic costs approximately $140 per month with no maintenance overhead. For organizations managing multiple VNets, Azure Bastion Standard with VNet peering is often more cost-effective than deploying and maintaining separate jumpbox VMs in each network.
Can Azure Bastion connect to VMs in peered virtual networks?
Yes. Azure Bastion Standard and Premium tiers support VNet peering, allowing a single Bastion deployment in a hub VNet to provide access to VMs in peered spoke VNets. This is ideal for hub-and-spoke network architectures and eliminates the need to deploy separate Bastion or jumpbox resources in each spoke network.
Final Thoughts
Azure Bastion is the modern evolution of the jumpbox. It removes the burden of managing host machines, reduces risk by keeping VMs private, and integrates tightly with Azure identity, networking, and security services.
At Exodata, our managed IT services team helps organizations design secure remote access patterns using Azure native services. Whether you’re setting up your first landing zone or enhancing an existing one, we can help align your architecture with Microsoft’s Well Architected Framework and Cloud Adoption Framework.
From infrastructure as code with Bicep to secure by default networking, our solutions prioritize long term scalability, compliance, and ease of use.
Ready to secure remote access to your Azure environment? Exodata can help you design and deploy Azure Bastion, configure zero trust networking, and build a secure cloud architecture aligned with Microsoft best practices. Contact us today to get started.