Submit feedback on
Idle or Underutilized Azure Bastion Deployment
We've received your feedback.
Thanks for reaching out!
Oops! Something went wrong while submitting the form.
Close
Idle or Underutilized Azure Bastion Deployment
Aaran Bhambra
CER:

CER-0312

Service Category
Networking
Cloud Provider
Azure
Service Name
Azure Bastion
Inefficiency Type
Underutilized Resource
Explanation

Azure Bastion incurs continuous hourly charges from the moment it is deployed until the resource is deleted — regardless of whether any connections are actively being made. This means a Bastion host sitting idle in a development or test environment generates the same cost as one actively serving remote sessions. Because there is no ability to pause or stop a Bastion deployment, the only way to eliminate charges is to delete the resource entirely.

This inefficiency is especially common in non-production environments where Bastion may have been provisioned for occasional troubleshooting or administrative access but then left running indefinitely. Teams often deploy Bastion during initial environment setup and forget about it, or assume it only costs money when sessions are active. Over time, these idle deployments quietly accumulate significant charges — particularly when deployed at the Basic, Standard, or Premium SKU tiers, which use dedicated infrastructure and carry meaningful hourly rates.

The cost impact compounds across an organization with multiple subscriptions or environments. A single idle Bastion host may seem modest in isolation, but dozens of forgotten deployments across dev, test, staging, and sandbox environments can represent a substantial and entirely avoidable expense.

Relevant Billing Model

Azure Bastion uses a dual-component pricing model:

  • Hourly SKU charges — Billed continuously from deployment until deletion, regardless of active sessions or connection volume. Basic, Standard, and Premium SKUs all incur dedicated hourly charges. Standard and Premium SKUs include a base deployment of 2 instances, with additional scale units charged at incremental hourly rates. Pricing varies by Azure region.
  • Outbound data transfer — Data transferred from Bastion to clients is charged in tiers, with a small free monthly allowance. Inbound data transfer is not charged.

The Developer SKU is free but uses shared infrastructure and is limited to a single concurrent connection with no virtual network peering support. For idle deployments at paid SKU tiers, the hourly charge is the primary cost driver since no data transfer occurs when no sessions are active.

Detection
  • Identify all Azure Bastion deployments across subscriptions, noting their SKU tier and the environment they serve (production, development, test, sandbox)
  • Review session activity for each Bastion deployment over a representative period to determine whether connections are being made regularly
  • Assess whether Bastion hosts in non-production environments have had any active sessions in recent weeks or months
  • Evaluate whether the deployed SKU tier is appropriate for actual usage patterns — for example, whether a Standard or Premium SKU is deployed where a Developer SKU or on-demand recreation would suffice
  • Confirm with application and infrastructure teams whether each Bastion deployment is still required for ongoing operations or planned activities
  • Examine whether multiple Bastion hosts exist in peered virtual networks where a single deployment could serve the same set of virtual machines
Remediation
  • Delete Azure Bastion deployments that have had no active sessions over an extended period and are not expected to be needed in the near term. Document the configuration details (subnet, public IP, SKU settings) to enable recreation when needed — note that redeployment typically takes approximately 10–15 minutes.
  • For environments requiring only occasional access, consider adopting a deploy-on-demand pattern where Bastion is created when needed and deleted after use. Scheduled automation can streamline this process.
  • Evaluate whether the free Developer SKU is sufficient for low-usage scenarios such as individual developer access in non-production environments, keeping in mind its limitations around concurrent connections and virtual network peering.
  • Consolidate Bastion deployments where possible by leveraging virtual network peering, allowing a single Bastion host to serve multiple networks rather than maintaining separate deployments per environment.
  • Establish a recurring review cadence — at least quarterly — to identify and clean up idle Bastion resources before costs accumulate.
  • Implement automated alerting on session activity so that Bastion hosts with sustained zero usage are flagged for review.
Submit Feedback