Azure Batch is a managed service for running large amounts of parallel or high-performance computing work on a pool of cloud machines, without you building a job scheduler yourself.

The problem it solves

Some work is simply too big for one computer. A studio must draw thousands of frames of an animated film. A bank must test a portfolio against millions of imagined market scenarios. A lab must compare thousands of gene samples. A single machine would take days or weeks. But the work can usually be cut into many independent pieces that do not need to talk to each other. When pieces are independent, a hundred machines finish roughly a hundred times faster than one.

Doing this yourself is harder than it sounds. You must find machines, install software on each one, decide which machine gets which piece, notice when a machine fails, retry the lost piece somewhere else, gather the results, and finally shut everything down so you stop paying. That is a lot of plumbing that has nothing to do with your actual science, finance or art. Azure Batch does the plumbing.

What Azure Batch actually is

Azure Batch is a platform service that creates and manages pools of virtual machines, called compute nodes, installs the programs you need, and schedules your work onto those nodes. You describe work as tasks grouped into jobs. Batch finds free capacity on your nodes, runs the tasks, retries them if something goes wrong, and reports progress. The Batch service itself adds no extra charge. You pay for the machines, storage and networking that your pools use.

Who looks after what

Batch is a managed service, but responsibility is shared. Understanding the line keeps surprises small.

Where Batch fits among Azure choices

Batch has a small vocabulary. Once these words feel natural, everything else in this guide becomes easy to follow.

The big picture in one story

You create a Batch account, which is your home inside the service. Inside it you create one or more pools, which are groups of machines. You then create a job, which is a container for related work, and attach it to a pool. Inside the job you add tasks, each of which is a command to run. Batch matches waiting tasks with free nodes, runs them, and records the results. When you are done, you delete the job and shrink or delete the pool.

The vocabulary

Ephemeral by design

The most important mindset shift is that nodes are temporary. A node can be removed during a scale-down, replaced after a fault, or reclaimed if it is a discounted machine. Anything saved only on a node’s local disk can vanish. That is why durable inputs and outputs live in storage, and why every task should be written so that running it again is harmless.

Parallel work comes in two flavors

Batch is made of a managed service layer that schedules work and a set of compute nodes that perform it.

The two halves

At the top is the Batch service. It accepts your requests, remembers the state of every pool, job and task, decides which task runs where, and instructs Azure to create or remove machines. At the bottom are the compute nodes. Each node runs a small program called the Batch node agent that talks to the service, receives tasks, runs them, and reports back. Around these two halves sit supporting services such as storage for files, virtual networks for connectivity and identity for access.

flowchart TD
  C["Your application, pipeline or portal"] --> S["Azure Batch service"]
  subgraph SVC["Managed by Azure"]
    S --> SCH["Task scheduler"]
    S --> ST["Pool, job and task state"]
    S --> AS["Autoscale evaluator"]
  end
  SCH --> P["Pool of compute nodes"]
  AS --> P
  subgraph NODES["Compute nodes"]
    N1["Node 1 with node agent"]
    N2["Node 2 with node agent"]
    N3["Node 3 with node agent"]
  end
  P --> N1
  P --> N2
  P --> N3
  N1 --> STG["Azure Storage for inputs and outputs"]
  N2 --> STG
  N3 --> STG
  C --> STG
        

What the service does

The Batch service is the brain. It stores which tasks are waiting, running or finished. It watches for nodes that become free and assigns the next waiting task. It enforces retry rules and time limits. It also runs the autoscale evaluation that grows or shrinks pools and applies the quotas that cap how many cores your account may use. You never log into the service. You talk to it through its programming interfaces, command-line tools or the Azure portal.

What a node does

Each node is an ordinary virtual machine, Linux or Windows, with the node agent installed. When it joins a pool, the agent registers with the service and runs the start task if one is defined. Then it waits for work. When a task arrives, the agent downloads the task’s input files, starts the command, watches its progress, and uploads outputs if asked. When the task ends, the agent reports the exit code and the node becomes free for the next task.

How nodes talk to the service

Nodes use a model called simplified node communication. In this model, nodes start the conversation by connecting outward to the Batch service. This means the service does not need to reach into your network, and baseline operation does not require outbound access to Azure Storage. An older classic model, in which the service connected to nodes and needed more network openings, was scheduled for retirement on March 31, 2026, and future improvements to Batch require the simplified model. New designs should assume simplified communication.

The pool allocation modes

When you create a Batch account you choose where the machines of your pools are created. In the default Batch service mode, the virtual machines are allocated in subscriptions managed by the Batch service. In user subscription mode, the machines are created directly in your own subscription, which requires registering your subscription for Batch and linking the account to an Azure Key Vault. Microsoft guidance says the default mode fits most cases, while user subscription mode serves a smaller set of scenarios.

The pool is the security boundary

Batch treats each pool as an isolation boundary. Pools are isolated from each other by default. If two jobs must not share machines, put them in different pools. Creating separate Batch accounts only for isolation is usually unnecessary unless the wider environment demands it.

A node is more than a machine: it is a machine plus an image, a node agent, a start task and your own software.

Inside one node

Life of a node

A node moves through states. It is created, starts up, may run the start task, and then sits idle until a task arrives. While tasks run it is busy. If it is a discounted machine, it may be preempted. If something breaks, it may become unusable or its start task may fail. Knowing the states helps you read dashboards and understand why a pool did not reach its target size.

Choosing images

Most pools start from a marketplace image for Linux or Windows. If you need many programs preinstalled, you can build a custom image and store it in Azure Compute Gallery, which is preferred over older managed image approaches because it gives faster provisioning, larger scale and better reliability. Container-based pools go a step further: you pull a container image onto each node and run tasks inside it.

Image and machine lifecycles

Images and machine sizes do not live forever. Batch publishes support end dates and verification status for the images and sizes it supports, and these can change over time. An image that was verified last year may be marked unverified later. Plan to check these details regularly, and move to supported images or sizes by creating a new pool rather than trying to change a running one.

Software delivery choices

A pool’s design decides how fast, how reliable and how expensive your workload will be.

Dedicated nodes and Spot nodes

A pool can contain dedicated nodes, Spot nodes, or both. Dedicated nodes are reserved for you while they exist and are only removed if you or the platform remove them. Spot nodes use spare Azure capacity at a much lower price, but Azure can take them back when it needs the capacity. Batch tasks on a preempted node are requeued, so Spot suits work that can be repeated without harm.

A change to know about: low-priority became Spot

Older Batch documentation spoke of low-priority nodes. Microsoft retired low-priority VMs on September 30, 2025 and announced that, starting March 1, 2026, remaining low-priority capacity would be migrated to Spot VMs automatically, with billing at Spot rates from the March 2026 invoice. Existing programming interface properties named for low-priority nodes now allocate Spot capacity, so code often needs no change. If you read older articles, translate “low-priority” to “Spot”.

Choosing a machine size

How big should each node be

There is a trade-off between many small nodes and fewer large ones. Many small nodes give smoother scaling and lower waste when work is uneven. Fewer large nodes reduce the overhead of starting machines and suit programs that use many processors or lots of memory at once. Pick the size around the program’s real needs, then use task slots so that several small tasks can share one big node without fighting for processors.

Ephemeral OS disks and local storage

Virtual machine configuration pools can use ephemeral operating system disks, which keep the node’s operating system on local storage instead of a separate managed disk. This avoids managed disk costs and can speed up node creation. Because the node is temporary anyway, losing the OS disk when the node leaves does not matter.

Billing facts worth memorizing

Batch charges nothing for itself, but you are billed for every compute node in the pool in any state, whether it is running tasks or sitting idle, plus related resources such as storage and networking. An idle pool is an unnecessary expense, and a pool that stays at maximum size overnight is a classic source of surprise bills.

Jobs and tasks are where your design skill shows: how you cut the work decides everything that follows.

Fewer jobs, many tasks

A job is a container for tasks, and Batch applies quotas to jobs but not to the number of tasks. Because of that, the best practice is to put many tasks into one job instead of creating thousands of tiny jobs. Thousands of simultaneously active jobs make listing and tracking slower and may hit limits. Completed jobs do not count toward the active job limit, but deleting them from time to time keeps queries fast.

How big should a task be

Each task carries scheduling overhead: Batch must assign it, prepare its folder, download files, start the process and record the result. A task that runs for one or two seconds spends most of its time on overhead. Aim for tasks that last at least about ten seconds, and ideally a minute or more. If your natural unit of work is tiny, group many units into one task that loops through them.

Task slots and sharing a node

By default a node runs one task at a time. By raising the number of task slots per node, you let several tasks run together on a single machine. This improves utilization for small, single-threaded programs. Be honest about what each task needs. If you give a node eight slots but each task secretly needs four processors, tasks will compete and slow each other down.

Spread or pack

Batch can fill nodes in two ways. Spreading tasks evenly gives each running task more room and balances load. Packing tasks onto as few nodes as possible leaves other nodes idle, which makes it easy for autoscale to remove them. Choose spreading when speed matters and packing when you want the pool to shrink quickly toward the end of a run.

Ordering work with dependencies

Not all work is independent. A video pipeline might need to split a file, encode the pieces, then stitch them together. Task dependencies let you state that a task can run only after others succeed. Batch will hold the dependent task back until its prerequisites finish. Dependencies turn a simple pile of tasks into a small workflow, without needing an external orchestrator for simple cases.

flowchart LR
  A["Split input into pieces"] --> B1["Process piece 1"]
  A --> B2["Process piece 2"]
  A --> B3["Process piece 3"]
  A --> B4["Process piece 4"]
  B1 --> C["Merge results"]
  B2 --> C
  B3 --> C
  B4 --> C
  C --> D["Upload final output"]
        

Helper tasks inside a job

Retries and idempotency

Tasks fail for many reasons: a program crashes, a node reboots, a spot machine is taken away. Batch can retry a task a number of times after a nonzero exit code, controlled by the maximum retry count you set. Batch also performs its own internal retries, first on the same node and then on a different one. Therefore your tasks must be safe to run more than once.

A safe task is idempotent or goal-seeking. If it is interrupted halfway and started again, it still ends in the correct state. A simple method is to skip any output file that already exists, so a retried task resumes where it stopped instead of duplicating work or corrupting results.

Ending jobs cleanly

A job stays open until it is ended or deleted, even after all its tasks finish, because you might still add more tasks. If you forget, the job lingers and, if it is tied to an auto-scaling rule or schedule, can keep a pool alive. Set the job to finish when all tasks complete, or give it a maximum wall-clock time so it ends itself.

By default pool nodes live in a Batch-managed network, but real projects usually need nodes to reach private data, licenses or on-premises systems.

Why put a pool in your own network

Nodes often need to read from a private database, contact a license server, mount a file share or reach on-premises equipment. To allow this, you can place a pool inside your own Azure virtual network by choosing a subnet. Batch then creates the node network interfaces there. Some supporting network resources are created in the subscription of that virtual network regardless of allocation mode.

flowchart LR
  subgraph VNET["Your virtual network"]
    subgraph SUB["Batch subnet"]
      N1["Node 1"]
      N2["Node 2"]
    end
    NSG["Network security group"]
  end
  SUB --- NSG
  N1 -->|"outbound connection"| BS["Batch service"]
  N1 --> ST["Storage via service or private endpoint"]
  N1 --> DB["Private data source"]
  N1 --> FW["Firewall or gateway to internet and on-premises"]
        

Rules that keep nodes healthy

Pools without public addresses

Many organizations forbid nodes from having public internet addresses. Batch supports pools whose nodes have no public IP addresses, which fits the simplified communication model because nodes only make outbound connections. Such pools need a reliable outbound path to reach Batch, so you must plan private connectivity or a controlled gateway. Check the current requirements in the Batch documentation, since networking options for these pools have been evolving.

DNS and connection manners

Programs talking to the Batch account address should respect DNS time-to-live and never hardcode an address. If the service returns a server error and asks to close the connection, close it, look up the name again and retry on a fresh connection. Use retry policies that span at least five minutes, because short blips are normal in cloud systems. A timeout does not prove a request failed, so check the resource state before repeating an action that might have already succeeded.

The right number of nodes changes during a run, and paying for the wrong number is the most common waste in Batch.

Fixed size or automatic

You can set a pool to a fixed number of nodes and resize it yourself, or you can attach an autoscale formula that lets Batch adjust the target number of nodes automatically. Fixed sizes are simple and predictable. Autoscale saves money when demand rises and falls, because it grows the pool when tasks wait and shrinks it when the work is done.

How autoscale works

An autoscale formula is a short piece of logic that you write once. Batch reviews its measurements at regular intervals, runs your formula, and sets the target number of nodes. The default interval is every fifteen minutes. You can choose between five minutes and one hundred sixty-eight hours. Autoscale is built for gradual adjustment over the course of a workload, not for reacting within seconds.

flowchart TD
  A["Batch records metric samples every 30 seconds"] --> B["Samples reach the formula after about a minute"]
  B --> C["Evaluation runs at your chosen interval"]
  C --> D["Formula reads task counts and node counts"]
  D --> E["Formula sets target dedicated and Spot nodes"]
  E --> F["Batch adds or removes nodes toward the target"]
  F --> G["Removed nodes follow your deallocation rule"]
  G --> A
        

What a formula can see

Deciding what happens to tasks on removed nodes

Mixing dedicated and Spot nodes in autoscale

A formula can set separate targets for dedicated and Spot nodes. A popular pattern starts with Spot nodes to save money and, whenever Spot nodes are preempted, replaces them with dedicated nodes up to a fixed ceiling. This caps the number of interruptions your workload suffers over the pool’s lifetime while still enjoying most of the discount.

Habits for dependable formulas

Because nodes are temporary, data must be staged in and carried out through durable storage.

The data journey

A typical task needs input data, runs a program, and produces results. Inputs usually start in Azure Storage or another durable store. They are copied to the node, either by Batch through resource files or by your own program. The program writes outputs to the node’s local task folder. Before the task ends, outputs and important logs are uploaded to durable storage. After that the node may disappear without any loss.

Ways to get data to nodes and back

Why durable output matters

Files on a node are deleted when the node leaves the pool. Move outputs and failure logs to durable storage before the task completes, using output file settings or uploading yourself. Set a retention time on tasks so Batch frees disk space after the results are safe, and delete tasks you no longer need. Remember that Batch cleans only the task working directory. Anything your program writes elsewhere on the node stays until the node goes.

Reference data and caching

Many workloads read the same large reference dataset in every task. Copying it again for each task wastes time and bandwidth. Better approaches include copying it once per node in the start task, using a job preparation task, mounting a shared file system, or baking it into a custom image when it changes rarely. Choose according to how big the data is and how often it changes.

Storage account choices

Use general purpose version 2 storage accounts, which support higher limits than the older version 1, and note that version 1 accounts are being retired. If many nodes read from the same account at once, check the account’s request and bandwidth limits, and spread data across several accounts or containers when throughput becomes a bottleneck.

Following one job from submission to final output shows how every part of Batch cooperates.

The story of one job

Suppose you submit a job with five thousand tasks to a pool that currently has no nodes and an autoscale formula attached. Many things happen in a sensible order, and understanding them helps you predict delays and diagnose slow starts.

sequenceDiagram
  participant You as You or pipeline
  participant Svc as Batch service
  participant Az as Azure compute
  participant Node as Compute node
  participant Stg as Storage
  You->>Svc: Create job and add tasks
  Svc->>Svc: Record tasks as active
  Svc->>Az: Autoscale asks for more nodes
  Az->>Node: Create and boot virtual machine
  Node->>Svc: Node agent registers
  Node->>Stg: Start task fetches software
  Node->>Svc: Report node idle and ready
  Svc->>Node: Assign next task
  Node->>Stg: Download task inputs
  Node->>Node: Run task command
  Node->>Stg: Upload outputs
  Node->>Svc: Report exit code
  Svc->>Svc: Mark task complete and assign next
        

Step by step in words

Why the first task is slow

New pools pay a startup tax: machine creation, boot, node agent registration and start task. This can take several minutes. If your whole job only runs for a minute or two, that startup time dominates. This is why Batch rewards reusing pools for many jobs instead of creating a new pool for each small job, and why very short, one-off runs often suit other services better.

Failure handling inside the loop

There are two separate flows to understand: the control flow that carries instructions and the data flow that carries your files.

Two paths, two jobs

The control path carries commands and status: create pool, add tasks, task started, task finished. It runs between your tools, the Batch service and the node agents. The data path carries your actual files and results between nodes and storage or other data sources. Keeping these two paths apart in your mind clarifies many problems. A slow job may have a healthy control path but a congested data path.

flowchart LR
  subgraph CTRL["Control path"]
    U["Your pipeline"] --> API["Batch service"]
    API --> AG["Node agents"]
  end
  subgraph DATA["Data path"]
    IN["Input storage"] --> NODE["Compute nodes"]
    NODE --> OUT["Output storage"]
    REF["Reference data and databases"] --> NODE
  end
  AG --- NODE
  OUT --> DOWN["Downstream systems and reports"]
        

A typical end-to-end flow

Imagine a nightly video processing run. New files land in an input container. An event triggers a small piece of automation that creates a job and adds one task per file. Batch scales the pool, nodes download files, encode them, and upload results to an output container. A final task or an event notifies downstream systems that the results are ready. Every hop has a different failure mode and a different thing to monitor.

Where time is spent

Event-driven triggers

Batch can emit events when pools resize, jobs complete or tasks finish, and these events can feed automation such as functions, workflows or notifications. This lets you chain stages without constantly polling the service, which keeps solutions cheaper and more responsive.

A pool of rented machines that read your data and run your code deserves layered protection.

Defense in depth

A bank vault is not guarded by one lock. It has a front door, cameras, guards, an inner door and a safe. Batch security works the same way. You protect who can talk to the service, which identity each node uses, which network paths exist, what software runs, and how data is stored. If one layer fails, another still stands.

The layers

Managed identity: no passwords on nodes

In older designs, a connection string with a secret key was copied onto every node so tasks could read storage. Anyone who could read the task or the node could steal it. With managed identities, Azure gives each node a verified identity. When a task asks storage for access, Microsoft Entra ID checks that identity and hands back a short-lived token. Nothing long-lived is stored, and the identity can be limited to exactly the resources it needs.

sequenceDiagram
  participant Task as Task on node
  participant IMDS as Node identity endpoint
  participant Entra as Microsoft Entra ID
  participant Stg as Azure Storage
  Task->>IMDS: Ask for access token
  IMDS->>Entra: Request token for the pool identity
  Entra->>IMDS: Return short-lived token
  IMDS->>Task: Hand over token
  Task->>Stg: Read or write data with token
  Stg->>Task: Allow only what the identity may do
        

Practical hardening checklist

Node agent updates need your action

The node agent is not automatically upgraded on a pool that already has nodes. To pick up a newer agent, resize the pool to zero nodes or recreate it. Download agent logs first if you are troubleshooting, because they disappear with the nodes. Planning a regular pool refresh solves both the agent and the image freshness problems at once.

Cloud services change constantly, and Batch is no exception. Teams stay calm by tracking changes before they become emergencies.

Things that expire

Several parts of a Batch solution have lifetimes. Operating system images have support end dates and a verification status that can change. Virtual machine sizes can be retired, and Microsoft has announced end-of-life for several older machine series in Batch pools, including some high-performance computing and graphics families. The node communication model, the way nodes and the service connect, has moved from a classic style to a simplified style. Custom image approaches based on older formats have also been scheduled for retirement in favor of Azure Compute Gallery.

Recent changes worth knowing

Replace pools, do not patch them forever

The cleanest way to move to a new image, size or setting is to create a new pool, point jobs at it, and delete the old pool afterward. Avoid deleting and recreating pools every day out of habit, because node creation time then eats into run time. Instead, create the new pool first, repoint jobs, and delete the old pool only when the switch is proven.

Naming and tidiness

Give every new resource a unique name, such as one that includes a creation timestamp or random suffix, and use display names to keep things readable. Reusing the same name for a deleted-then-recreated pool can collide with leftovers. Delete old tasks and jobs periodically because listing becomes slow when thousands of them accumulate.

Batch work often runs overnight while nobody watches, so good visibility decides whether problems are found at midnight or at breakfast.

What to observe

The Azure toolbox

Azure Monitor collects Batch account metrics and can send diagnostic logs to a Log Analytics workspace, where you can query and alert on them. Batch also publishes events that can trigger automation. For hands-on exploration, Batch Explorer is a desktop tool for browsing pools, nodes, jobs and tasks and for looking at files on nodes, and additional insight tooling can show node-level performance. In user subscription mode you can run Azure Monitor Agent on nodes, but collect only the counters you truly need to control cost.

flowchart LR
  B["Batch account"] --> M["Azure Monitor metrics"]
  B --> D["Diagnostic and service logs"]
  B --> EV["Batch events"]
  N["Compute nodes"] --> NL["Node and task logs"]
  M --> AL["Alert rules"]
  D --> LA["Log Analytics workspace"]
  NL --> ST["Durable storage for logs"]
  LA --> AL
  EV --> AUTO["Automation and notifications"]
  AL --> ON["On-call people and runbooks"]
        

Questions your dashboard should answer

Always keep logs somewhere durable

Because nodes vanish, so do their local logs. Upload task output, failure logs and agent logs to durable storage before the node is removed. The Batch service logs upload feature can collect agent logs from a node before you deallocate a problem node. Without this habit, the most interesting failures leave no evidence behind.

Alerting people can live with

Alert on outcomes, not on every blip. Useful alerts include “no task completed in a long while”, “failed task percentage above a threshold”, “pool did not reach its target within an expected time” and “job running past its expected deadline”. Each alert should link to a short runbook that explains what it means and what to check first.

In Batch, reliability means finishing the work correctly even when nodes, networks and regions misbehave.

Expect things to fail

With hundreds of machines, something is always failing: a node reboots, a spot machine is reclaimed, a download times out. Batch tries to recover failed nodes and may reschedule the tasks that were running on them. The reliable approach is not to prevent failure but to design for it, so that failure only causes a retry rather than a wrong answer.

Building blocks of dependable batch work

Quota is not capacity

Core quota only says how many cores you may ask for. It does not guarantee that Azure has that many machines of your chosen size free right now. Allocation can fail because of regional capacity or problems in dependent services. For work with a hard deadline, scale the primary pool well before the start time, check that it actually reached its target, and fall back to a second region if it did not.

flowchart TD
  S["Scheduler or pipeline"] --> P["Primary region Batch account"]
  S --> B["Backup region Batch account"]
  P --> PP["Primary pool scaled before start time"]
  B --> BP["Backup pool kept small or at zero"]
  PP --> OK{"Pool reached target in time"}
  OK -->|"Yes"| RUN["Run jobs on primary pool"]
  OK -->|"No"| FAIL["Scale backup pool and run there"]
  RUN --> OUT["Durable output storage"]
  FAIL --> OUT
        

Single region or several

Failure modes and responses

Batch can turn a huge compute bill into a small one, or the reverse, depending on a handful of habits.

Where the money goes

The largest cost is almost always the compute nodes, billed for every minute they exist in any state. After that come storage, data transfer out of Azure, networking resources such as public addresses and gateways, and monitoring data. Batch itself adds no fee. This means the cheapest node is the one that does not exist, and idle nodes are pure waste.

The levers

Tail waste: the last few tasks

Often ninety-five percent of tasks finish quickly while a few slow ones run for a long time. During this tail, most of the pool is idle but still billed. Reduce it by using packing so idle nodes empty out and autoscale can remove them, by splitting long tasks into smaller ones, and by setting time limits on tasks that hang. A formula that shrinks the pool as the number of waiting tasks falls prevents paying for an empty room.

Make cost visible

Tag Batch accounts, pools and storage with team, project and environment. Review monthly spending by tag and share it with the teams who cause it. People waste less when they can see what their runs cost.

Teams that run Batch well keep reusing a small set of proven shapes.

Workload patterns

Pool strategy patterns

Triggering patterns

Packaging patterns

These habits feel harmless in a small test and turn expensive or unreliable at scale.

A compact checklist in plain words, grouped by the topics you have just learned.

Best practices by area

Common mistakes

These are typical patterns of use. They are illustrative scenarios, not descriptions of particular companies.

What the examples have in common

In every case the work splits into pieces, the pool exists only while needed, data lives in durable storage, and tasks tolerate being rerun. The industries differ, but the habits that make them succeed are strikingly alike. Those habits, not the specific software, are what you should copy.

Plain answers to questions that newcomers and experienced engineers often ask when they first use Azure Batch.

Virtual machines are individual computers you manage yourself. Azure Batch uses virtual machines underneath, but adds scheduling, pooling, retries and automatic scaling, so you manage work instead of individual machines.

The Batch service itself adds no charge. You pay for the compute nodes in your pools, in any state, plus related resources such as storage, networking and monitoring data.

A task is one unit of work, usually a single command. A job is a collection of tasks that run on a pool and share settings such as priority and end rules.

If the pool had no ready nodes, Azure must create virtual machines, boot them and run the start task before any task can run. This usually takes minutes. Keeping a small warm pool or reusing pools reduces the wait.

Low-priority VMs were retired, and remaining capacity was migrated to Spot VMs starting in March 2026, with Spot billing. Existing settings named for low-priority nodes now allocate Spot capacity, so you should think in terms of Spot going forward.

The task is requeued and runs again on another node. That is why tasks must be safe to repeat and why long tasks should save progress as they go.

By default every fifteen minutes, and you can choose an interval between five minutes and one hundred sixty-eight hours. Autoscale is built for gradual changes, so for urgent work scale the pool up ahead of time.

In durable storage such as Azure Storage, uploaded before the task ends. Files on nodes are deleted when the node leaves the pool, so never treat local disks as permanent.

Yes. Pools can use Windows or Linux images, and you can also run tasks inside containers when you want portable, reproducible environments.

Yes, through multi-instance tasks that run one coordinated program across several nodes, commonly with message-passing software. These need suitable machine sizes and careful networking.

Use separate pools, since the pool is Batch’s isolation boundary, separate managed identities with narrow roles, and separate storage access. Use separate accounts only if your wider environment requires it.

Use the default Batch service mode for most cases. Choose user subscription mode only when you need the machines created in your own subscription, and be ready to register the subscription and link a Key Vault.

No. For tiny jobs that finish in seconds, simple event-driven services are better. For always-on web services, container platforms fit better. Batch shines for large, bursty, repeatable compute where nodes can come and go.

Follow Azure announcements and the Batch documentation, check the supported image and machine size lists regularly, and watch service health notifications. Treat any article, including this one, as a guide to concepts rather than a replacement for current official pages.

Azure Batch lets you rent as much computing power as a job needs, for exactly as long as it needs it, without writing your own scheduler. You split work into tasks, group them into jobs, and let Batch run them on pools of temporary nodes, retrying what fails and scaling the pool to match demand. Success depends on a small number of habits: tasks that are safe to repeat, durable storage for inputs and outputs, identity instead of stored secrets, autoscale with sensible caps, honest slot and machine sizing, thoughtful networking and steady attention to retirements and costs. Teams that follow these habits finish enormous workloads quickly and cheaply. Teams that ignore them pay for idle machines, lose results and debug mysterious failures.