AWS Batch

AWS Batch runs containerised batch workloads. You submit jobs to a queue; Batch provisions compute to drain the queue, runs the jobs, and scales the capacity back down when the queue is empty. There is no scheduler to install and no cluster to keep warm.

Batch runs on top of AWS’s container orchestration services — Amazon ECS and Amazon EKS — and can scale capacity on EC2 instances, Fargate resources and Amazon ECS Managed Instances. It also provides queuing for Amazon SageMaker AI Training jobs, so machine learning training can be submitted with priorities to configurable queues rather than coordinated by hand.

Why use it

1. No batch scheduling software to install, license or operate
2. Capacity is provisioned when there is work and released when there is not
3. Job dependencies, array jobs, retries and priorities are handled by the service
4. Spot capacity is a first-class option, which is where most of the cost saving comes from

Components

Jobs

The unit of work: a containerised program, invoked with a command and parameters. Jobs can depend on other jobs, and an array job fans one submission out into thousands of indexed children — the usual shape for per-file or per-record processing.

Job definitions

The blueprint a job is submitted against: the container image, vCPU and memory requirements, the IAM job role, environment variables, mount points, the retry strategy and the timeout. Job definitions are versioned, so a submission pins the revision it ran against.

Job queues

Where submitted jobs wait. A queue has a priority and is mapped to one or more compute environments in preference order — which is how a queue tries Spot capacity first and falls back to On-Demand. Multiple queues of different priorities can share the same compute environments.

Compute environments

The capacity that runs the jobs.

• Managed — AWS provisions and scales the capacity within limits you set: instance types or families, minimum, desired and maximum vCPUs, subnets, and whether to use On-Demand or Spot. The default is the most recent approved Amazon ECS-optimised AMI, and you can supply your own.
• Unmanaged — you provision and manage the compute resources yourself. Your AMI must meet the ECS container instance requirements, and everything from scaling to patching is yours. Reserve this for genuinely unusual requirements.

Capacity can be EC2 instances, Fargate, Amazon ECS Managed Instances, or an Amazon EKS cluster.

How the pieces fit together

A job is submitted to a queue using a job definition. The queue is mapped to one or more compute environments, and Batch places the job on capacity from the first environment that can take it.

flowchart LR JD[Job definition] -->|submitted with| S[Submit job] S --> JQ[Job queue] JQ -->|mapped in priority order| CENV subgraph CENV[Compute environments] EC2[EC2 instances] FG[Fargate] MI[ECS Managed Instances] EKS[EKS cluster] end style JD fill:#bbf,stroke:#333 style S fill:#f9f,stroke:#333 style JQ fill:#bfb,stroke:#333 style CENV fill:#fbb,stroke:#333

Note that jobs do not flow through job definitions. The definition is a template the submission references; the queue is what the job is actually placed on.

An example pipeline

A file-triggered Batch pipeline: S3 upload, Lambda submits the job, Batch pulls the image from ECR and writes results to DynamoDB.

The shape is worth noting because it is the common one. A file lands in Amazon S3. The object event invokes a small Lambda function whose only job is to translate the event into a SubmitJob call with the bucket name and object key as parameters — Lambda is doing coordination, not processing, so its 15-minute limit is irrelevant. Batch pulls the container image from Amazon ECR, runs the container against however much capacity it needs, and the container writes results to DynamoDB.

Fargate or EC2 capacity

Fargate	EC2
The recommended starting point for most jobs	When you need control over instance selection
Fast start times, typically under 30 seconds	Elastic Fabric Adapter for tightly coupled HPC
Up to 32 vCPU	Custom AMIs
No GPUs	GPUs and other accelerators
Up to 244 GiB of memory	High levels of concurrency on one host
No access to Linux kernel parameters	Linux parameters, ulimits, privileged containers

Batch or Lambda

AWS Batch	AWS Lambda
No execution time limit	15 minutes, or 90 minutes on Managed Instances for asynchronous and event-source invocations
Any runtime, because jobs are containers	Managed runtimes, or an OS-only runtime for others
Large local and attached storage	Up to 10 GB of /tmp; EFS requires a VPC configuration, which adds cost and cold-start latency
Starts in tens of seconds	Starts in milliseconds
Capacity is provisioned per job	No capacity to think about

The dividing line is duration and size. Anything that finishes in seconds and is triggered by an event belongs on Lambda. Anything measured in minutes or hours, needing GPUs, large memory or a specific toolchain, belongs on Batch. The two compose well: Lambda receives the event and submits the job.

Practical notes

• Give every job definition a retry strategy and a timeout. Spot interruptions are normal, not exceptional.
• Make jobs idempotent, so a retried job does not double-count.
• Use array jobs for per-item work rather than submitting thousands of individual jobs.
• Set the compute environment’s maximum vCPUs deliberately — it is the only thing standing between a runaway submission and a large bill.
• Size the job definition’s vCPU and memory to what the job actually uses; Batch packs jobs onto instances from those numbers.

For how Batch compares with an application-level batch framework, see Spring Batch vs AWS Batch.