10.4 Batch Processing Solution Design (Azure Batch, HPC Workloads)

Why Batch Processing Design Matters on AZ-305

The final compute-selection objective is "Recommend a compute solution for batch processing." It covers fewer raw exam bullets than VM, container, or serverless design, but scenario questions on large-scale parallel job scheduling, Spot-node cost optimization, and migrating legacy on-premises high-performance computing (HPC) clusters appear consistently — particularly for financial services, manufacturing, and life-sciences customers, who are heavy Azure HPC adopters. The exam expects you to distinguish embarrassingly parallel batch workloads (independent tasks with no communication between them) from tightly-coupled HPC workloads (nodes that must communicate with each other at very low latency during the computation).

Azure Batch Core Concepts

Azure Batch is a managed service for running large-scale parallel and high-throughput computing workloads without building your own job-scheduling infrastructure. Its building blocks:

• Pools — a collection of compute nodes (VMs) provisioned from an Azure-managed image or a custom image, sized to the workload
• Nodes — individual VMs in a pool; can be dedicated (guaranteed capacity, full price) or Spot (discounted, evictable with short notice)
• Jobs and Tasks — a job is a logical grouping of related tasks; each task runs on one node. Task dependencies, automatic retries, and a "job manager task" (a controlling task that can submit further tasks) are all configurable
• Autoscale formulas — custom scaling expressions that grow or shrink the pool based on the number of pending tasks, rather than a fixed schedule

A critical, exam-current fact: Batch's "low-priority" node tier was retired, with existing low-priority nodes migrated to Spot nodes by March 2026. Any scenario using the term "low-priority nodes" is describing legacy terminology — as of the current blueprint, discounted, evictable Batch capacity is always provisioned as Spot nodes, and Batch-managed allocation-mode pools no longer auto-provision Spot the way they once auto-provisioned low-priority capacity.

HPC-Specific Constructs

Batch is the right tool for embarrassingly parallel work — independent tasks that never need to talk to each other mid-computation. But tightly-coupled HPC workloads (computational fluid dynamics, weather simulation, seismic processing) need nodes that can communicate with extremely low latency during the run, which requires different building blocks entirely:

• HB-series / HC-series VMs — the highest per-VM core counts in Azure, paired with InfiniBand remote direct memory access (RDMA) networking for the low-latency, high-bandwidth interconnect that Message Passing Interface (MPI) workloads require between nodes
• Azure CycleCloud — an orchestration tool purpose-built for standing up and managing HPC clusters that integrate with existing job schedulers such as Slurm, PBS Pro, Grid Engine, and HTCondor. CycleCloud autoscales a mixed pool of Spot and regular-priority VMs and is the natural fit for lifting and shifting an existing on-premises HPC scheduler into Azure without rewriting job scripts into Batch's job/task model
• Azure Managed Lustre — the current recommended parallel file system for I/O-intensive HPC and AI training workloads, delivering throughput in the hundreds of GBps and integrating with Blob Storage for data tiering. It replaces Azure HPC Cache, which was fully retired on September 30, 2025 — recommending HPC Cache in any current-dated scenario is now a wrong answer

Decision Table

Common Exam Traps

• Recommending plain Azure Batch for a tightly-coupled MPI simulation that explicitly needs low-latency inter-node communication — the "tightly coupled" language in the scenario stem is the signal to reach for HB/HC-series VMs (via CycleCloud or a Batch pool explicitly configured for InfiniBand), not a default Batch pool.
• Using the term "low-priority nodes" as if it is still current — the objective as of the April 2026 blueprint reflects Spot-only terminology; low-priority nodes were retired and migrated.
• Recommending Azure HPC Cache for any current scenario — it is retired; Azure Managed Lustre is the current answer for a parallel HPC file system.
• Defaulting to Azure Batch when the scenario describes millions of very small, sub-second tasks rather than large or long-running tasks — at that scale, an event-driven Functions/queue design can have lower per-task overhead than Batch's job-scheduling model; the exam tests whether you notice task size and volume, not just "batch" in the prompt.

Scenario Walkthrough

A genomics research firm needs to process 50,000 independent DNA sequencing files nightly, with no dependency between files and full tolerance for a node being evicted mid-task as long as the task simply retries — the fit is an Azure Batch pool using Spot nodes, with an autoscale formula tied to the count of pending tasks. A separate engineering team is migrating an on-premises 200-node Slurm-scheduled computational fluid dynamics cluster and wants to preserve its existing job scripts while running on HB-series VMs with InfiniBand across Azure regions — the fit is Azure CycleCloud, paired with Azure Managed Lustre for the shared low-latency storage the simulation reads and writes during the run.