Azure Bastion
Does ZopNight manage Azure Bastion?
Azure Bastion bills hourly per deployment for availability, not for sessions: a host nobody has connected to in 3 weeks costs exactly what a busy one does. ZopNight discovers each Bastion with SKU detail through Resource Graph and attributes its always-on spend, flagging hosts in low-activity environments for review.
Rules that fire on Azure Bastion
No active rule family targets Azure Bastion today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only. |
Azure Bastion provides browser-based RDP/SSH access to VMs without public IPs, billed hourly per deployment. A Bastion host in a dev VNet bills its full hourly rate even when nobody connects for weeks.
Paying for the door, not the walk-through
Bastion’s meter charges for every hour the host is deployed, scaled by SKU and instance count, with outbound data as a secondary charge. Sessions are not the unit of billing; availability is. The service exists to be ready whenever an engineer needs an RDP or SSH path to a private VM, and that readiness is what the hourly rate buys. The consequence: usage and cost are fully decoupled. A Bastion used daily by an operations team and one last opened during an incident in the previous quarter appear identical on the invoice, differing only in whether the spend bought anything.
Low-activity hosts under ZopNight’s lens
Discovered via Azure Resource Graph with SKU detail. Cost Management billing attributes its always-on spend, flagging Bastion hosts in low-activity environments. Bastion offers no stop or deallocate action, so scheduling it off overnight is not an option ZopNight has, or anyone else; the decision is binary, keep or delete. ZopNight’s contribution is keeping the always-on charge visible per host and per environment, so a deployment whose environment itself is quiet gets questioned rather than grandfathered.
Jump hosts multiplied by template
Waste concentrates in three habits. Per-VNet Bastion sprawl: deploying a host into every VNet instead of using one centrally peered deployment, multiplying an availability charge that one host could cover. Dev-environment permanence: a Bastion stood up for a debugging session that became a fixture, billing hourly for months of zero connections. SKU overshoot: Standard-tier features such as larger instance counts and native client support, enabled where the Basic capability set would serve, raising the hourly rate for capacity no one exercises.
Surveying Bastion deployments in the portal
Azure portal → Bastions lists every host with its SKU, VNet, and provisioning state. Correlate each against the VNet’s actual use. For candidates, the sessions metric answers whether the availability being paid for is ever consumed.