Azure Batch
Azure Batch is managed batch computing: you submit a job made of many tasks, and Batch provisions a pool of VMs to run those tasks in parallel, then scales the pool back down when the work drains. It is built for throughput-bound, embarrassingly parallel workloads — rendering, financial simulation, genomics, large-scale data processing.
Batch is not a service host and not a general orchestrator. It is the tool when you have thousands of independent tasks to run across a fleet that should appear for the work and vanish afterward. For a steady service, or a handful of containers, Container Apps or AKS is the right tool; Batch earns its place on bursty, parallel, compute-heavy jobs.
Pools, Jobs, and Tasks
The model has three levels. A pool is the set of VMs that run work, with a chosen size and node count. A job is a collection of tasks submitted to a pool. A task is a single command — process this frame, run this simulation seed — scheduled onto a node. One job fans out across the pool as hundreds or thousands of tasks.
Pool nodes are dedicated or Spot. Dedicated nodes are stable and full price; Spot nodes use spare capacity at a deep discount and can be reclaimed mid-task. For idempotent, retry-safe tasks, a mostly-Spot pool cuts cost dramatically with little downside. (Spot replaced the older low-priority nodes, which Azure Batch retired in 2025; Spot pools require a user-subscription Batch account.)
Autoscale Formulas
A pool resizes by an autoscale formula — an expression over metrics like the number of pending tasks and current node count, evaluated on an interval. A good formula grows the pool toward the pending-task count and shrinks it to zero when the queue empties, so you never pay for idle nodes between jobs. A pool with no formula and a fixed node count burns money whenever it sits idle.
Application Packages and Containers
Tasks need their binaries on the node. Application packages distribute and version executables to pool nodes automatically. Alternatively, pool nodes can run container workloads, so a task is a container invocation — useful when the work is already containerized and you want Batch's scheduling without repackaging it.
Scheduling
Batch handles the scheduling concerns that make large jobs reliable: task dependencies so one task waits on another, automatic retries so a transient failure does not kill the task, and job preparation and release tasks that run once per node to set up and tear down shared state. These turn a pile of commands into a dependable pipeline.
Azure Batch — Purpose-built for large-scale parallel batch — thousands of tasks, Spot pools, autoscale formulas, task dependencies. Choose it for HPC-style throughput work.
Container Apps jobs — Serverless run-to-completion jobs for containerized work at modest scale. Choose it when the batch is containerized and the scale is moderate.
AKS — General orchestration you operate yourself. Choose it only when batch shares a cluster with services and you want one control plane.
- Running all-dedicated pools for retry-safe work when a mostly-Spot pool would cut the bill by most of its value.
- Leaving a pool at a fixed node count with no autoscale formula, so idle nodes bill around the clock between jobs.
- Disabling or ignoring task retries, so a single transient failure kills a task and stalls the whole job.
- Sizing nodes by vCPU alone for memory-bound tasks, which then thrash or fail on undersized memory.
- Using Batch for a long-running service instead of bursty jobs — it is built to appear for work and scale to zero, not to serve traffic.
- Forgetting job preparation and release tasks, so per-node setup is repeated per task or shared state is never cleaned up.
- Use Spot nodes for idempotent, retry-safe tasks and reserve dedicated nodes for the portion that must not be reclaimed.
- Drive pool size with an autoscale formula tied to pending tasks so the pool scales to zero between jobs.
- Enable task retries and model dependencies so transient failures recover and ordered work runs correctly.
- Size nodes for the task's real bottleneck — memory for memory-bound work, not vCPU by reflex.
- Distribute binaries with application packages, or run container tasks when the work is already containerized.
- Reserve Batch for bursty parallel jobs; use Container Apps jobs or AKS when the work is a containerized job at modest scale.
Knowledge Check
What is the relationship between pools, jobs, and tasks in Azure Batch?
- A pool is the VM fleet; a job is a set of tasks submitted to it; a task is a single command on a node
- A pool is a single VM; a job is a container image running on it; a task is one in-process thread of execution
- Jobs contain pools, which contain tasks
- They are three names for the same scheduling unit
Why use Spot nodes for a rendering job?
- They use spare capacity at a deep discount, and rendering tasks are idempotent and safe to retry after reclamation
- They are faster than dedicated nodes for GPU work
- They are the only Batch node type that supports running containerized tasks, which most rendering pipelines depend on
- They cannot be reclaimed by Azure once a task has started running on the node
What does an autoscale formula control in a Batch pool?
- The node count, typically growing with pending tasks and shrinking to zero when the queue empties
- The maximum retry count applied to each task that fails on a node
- The VM family and size used by every node in the pool
- The scheduling priority assigned to each job submitted to the pool, relative to all other queued jobs
You got correct