Azure Batch accounts with no jobs, and why the cost sits in their pools
What does ZopNight detect here?
An Azure Batch account itself costs nothing; Microsoft states there is no extra charge to use Batch and you pay only for the VMs, storage and networking behind it. ZopNight therefore raises no finding on an idle Batch account. The spend to check is pool nodes left running, visible through `RunningNodeCount` and `az batch pool list`.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1375 |
| Category | idle |
| Severity | low |
| Metric | RunningNodeCount, TaskCompleteEvent, JobStartEvent |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | Microsoft.Batch/batchAccounts/read · Microsoft.Batch/batchAccounts/pools/read · Microsoft.Insights/Metrics/Read |
Where it applies
Where Batch money is actually spent
The Batch overview is explicit: there is no extra charge to use Batch, and you pay only for the underlying resources, such as virtual machines, storage and networking. The account is a free container for pools, jobs and tasks. The pools are where the bill comes from, because each compute node is a VM billed while it exists, whether or not a task is running on it.
An account with no jobs is therefore harmless on its own. An account with no jobs and a pool still holding dedicated nodes is not.
Finding pools that hold nodes with nothing to do
az batch pool list --account-name mybatch \ --account-endpoint https://mybatch.eastus.batch.azure.com \ --query "[].{id:id, vmSize:vmSize, dedicated:currentDedicatedNodes, spot:currentLowPriorityNodes, autoscale:enableAutoScale}" \ -o table
az monitor metrics list --resource <batch-account-resource-id> \ --metric RunningNodeCount JobStartEvent TaskCompleteEvent --offset 30d --interval PT24H --aggregation TotalNodes present every day while JobStartEvent and TaskCompleteEvent stay at zero is the
pattern to act on.
What ZopNight evaluates for a Batch account
ZopNight collects the account’s node, job start and task completion metrics over 30 days, but it does not turn them into a finding on the account. An account has no price of its own to recover, so any saving figure attached to it would be invented. Earlier logic that equated an idle account with its full cost was removed for exactly that reason.
Why this page never shows a finding
The honest answer to “what would deleting this idle account save?” is nothing. The saving, when there is one, belongs to the VMs in the pools. Those are evaluated by the VM-level checks such as Idle Azure VM and Idle Azure VM Scale Set, which price the compute that is actually billed.
No saving on the account itself
There is no dollar figure here. What you can save is the cost of the idle pool nodes, which the commands above let you see directly.
Stopping idle pools from billing
- Resize a fixed pool to zero between batches:
az batch pool resize --pool-id mypool --target-dedicated-nodes 0 --target-low-priority-nodes 0. - Better, enable autoscale on the pool with a formula based on pending tasks, so nodes appear
only when there is work (
az batch pool autoscale enable). - Use Spot nodes for interruptible tasks to cut the rate on the nodes you do run.
- Delete pools and, if nothing uses it, the account once the workload has moved elsewhere.