AWS Batch adds GPU quota shares that teams can lend and borrow

AWS has added quota management to AWS Batch for Amazon SageMaker Training jobs. In a post dated 29 October 2026, three AWS authors (Michelle Goodstein, David Lindskog and Tom Burggraf) say administrators can now split shared GPU capacity into quota shares for individual teams, projects or workloads, and let idle capacity move between them automatically. The post presents it as a response to customers who run multi-team training environments and want to avoid separate queues and manual limit changes.

How the shares work

According to AWS, each quota share carries a capacity limit and a resource-sharing strategy for idle compute. A share can hold idle capacity in reserve until its own jobs arrive, lend it to other shares that have work, or do both: lend when idle and borrow when it has work that could use more. A share is a virtual queue nested inside a job queue, and Batch gives priority to shares that are still under their limit.

If a job arrives in a share that has lent its capacity out, AWS says Batch performs cross-share preemption: it reclaims the resources for the lender. If a job arrives in a share that is already at its limit, Batch checks whether another share has spare capacity to borrow. AWS also describes an optional in-share preemption, which stops lower-priority jobs in the SCHEDULED, STARTING or RUNNING state so a higher-priority job at the front of the queue can start.

The three-team example

The worked example configures three shares, each limited to one instance, to show three policies:

• Background jobs: borrow as much spare capacity as is available, with in-share preemption on. AWS says this suits work where nothing is urgent and jobs use checkpointing, so being preempted is acceptable.
• Medium-priority work: lend and borrow, but the team would rather wait for capacity than be preempted repeatedly. AWS says this fits shorter jobs or jobs of similar priority.
• Latency-sensitive work: reserve capacity, neither lend nor borrow, and turn in-share preemption off, so Batch does not preempt these jobs while the capacity limit is unchanged.

In the walkthrough, a job submitted to the medium-priority share triggers a preemption that takes capacity back from the background share, which had been borrowing it. A scientist can also raise the priority of an already submitted job through a new UpdateServiceJob API, which AWS says starts an in-share preemption if no capacity is free to borrow.

What the post does not say

The post is a how-to, not a case study. It gives no utilisation numbers, no cost comparison, and no customer using the feature in production. It does not say how much work a preempted job loses, beyond noting that the background share's jobs use checkpointing, so a team whose jobs cannot resume from a checkpoint should expect preemption to cost them progress. It also covers SageMaker Training jobs only, and the example uses a hello-world trainer, so how it behaves under real data loading is untested here.

For a team that shares a fixed GPU pool, the question the post raises is a policy one rather than a technical one: which workloads may be preempted, which must never be, and who owns the idle capacity. The configuration forces that decision to be written down per share.