AWS Batch Construct Library
This module is part of the AWS Cloud Development Kit project.
AWS Batch is a batch processing tool for efficiently running hundreds of thousands computing jobs in AWS. Batch can dynamically provision Amazon EC2 Instances to meet the resource requirements of submitted jobs and simplifies the planning, scheduling, and executions of your batch workloads. Batch achieves this through four different resources:
ComputeEnvironments: Contain the resources used to execute Jobs
JobDefinitions: Define a type of Job that can be submitted
JobQueues: Route waiting Jobs to ComputeEnvironments
SchedulingPolicies: Applied to Queues to control how and when Jobs exit the JobQueue and enter the ComputeEnvironment
ComputeEnvironments can be managed or unmanaged. Batch will automatically provision EC2 Instances in a managed ComputeEnvironment and will
not provision any Instances in an unmanaged ComputeEnvironment. Managed ComputeEnvironments can use ECS, Fargate, or EKS resources to spin up
EC2 Instances in (ensure your EKS Cluster has been configured
to support a Batch ComputeEnvironment before linking it). You can use Launch Templates and Placement Groups to configure exactly how these resources
will be provisioned.
JobDefinitions can use either ECS resources or EKS resources. ECS JobDefinitions can use multiple containers to execute distributed workloads.
EKS JobDefinitions can only execute a single container. Submitted Jobs use JobDefinitions as templates.
JobQueues must link at least one ComputeEnvironment. Jobs exit the Queue in FIFO order unless a SchedulingPolicy is specified.
SchedulingPolicys tell the Scheduler how to choose which Jobs should be executed next by the ComputeEnvironment.
Use Cases & Examples
Cost Optimization
Spot Instances
Spot instances are significantly discounted EC2 instances that can be reclaimed at any time by AWS.
Workloads that are fault-tolerant or stateless can take advantage of spot pricing.
To use spot spot instances, set spot to true on a managed Ec2 or Fargate Compute Environment:
vpc = ec2.Vpc(self, "VPC")
batch.FargateComputeEnvironment(self, "myFargateComputeEnv",
vpc=vpc,
spot=True
)
Batch allows you to specify the percentage of the on-demand instance that the current spot price
must be to provision the instance using the spotBidPercentage.
This defaults to 100%, which is the recommended value.
This value cannot be specified for FargateComputeEnvironments
and only applies to ManagedEc2EcsComputeEnvironments.
The following code configures a Compute Environment to only use spot instances that
are at most 20% the price of the on-demand instance price:
vpc = ec2.Vpc(self, "VPC")
batch.ManagedEc2EcsComputeEnvironment(self, "myEc2ComputeEnv",
vpc=vpc,
spot=True,
spot_bid_percentage=20
)
For stateful or otherwise non-interruption-tolerant workflows, omit spot or set it to false to only provision on-demand instances.
Choosing Your Instance Types
Batch allows you to choose the instance types or classes that will run your workload.
This example configures your ComputeEnvironment to use only the M5AD.large instance:
vpc = ec2.Vpc(self, "VPC")
batch.ManagedEc2EcsComputeEnvironment(self, "myEc2ComputeEnv",
vpc=vpc,
instance_types=[ec2.InstanceType.of(ec2.InstanceClass.M5AD, ec2.InstanceSize.LARGE)]
)
Batch allows you to specify only the instance class and to let it choose the size, which you can do like this:
# compute_env: batch.IManagedEc2EcsComputeEnvironment
vpc = ec2.Vpc(self, "VPC")
compute_env.add_instance_class(ec2.InstanceClass.M5AD)
# Or, specify it on the constructor:
batch.ManagedEc2EcsComputeEnvironment(self, "myEc2ComputeEnv",
vpc=vpc,
instance_classes=[ec2.InstanceClass.R4]
)
Unless you explicitly specify useOptimalInstanceClasses: false, this compute environment will use 'optimal' instances,
which tells Batch to pick an instance from the C4, M4, and R4 instance families.
Note: Batch does not allow specifying instance types or classes with different architectures.
For example, InstanceClass.A1 cannot be specified alongside 'optimal',
because A1 uses ARM and 'optimal' uses x86_64.
You can specify both 'optimal' alongside several different instance types in the same compute environment:
# vpc: ec2.IVpc
compute_env = batch.ManagedEc2EcsComputeEnvironment(self, "myEc2ComputeEnv",
instance_types=[ec2.InstanceType.of(ec2.InstanceClass.M5AD, ec2.InstanceSize.LARGE)],
use_optimal_instance_classes=True, # default
vpc=vpc
)
# Note: this is equivalent to specifying
compute_env.add_instance_type(ec2.InstanceType.of(ec2.InstanceClass.M5AD, ec2.InstanceSize.LARGE))
compute_env.add_instance_class(ec2.InstanceClass.C4)
compute_env.add_instance_class(ec2.InstanceClass.M4)
compute_env.add_instance_class(ec2.InstanceClass.R4)
Allocation Strategies
| Allocation Strategy | Optimized for | Downsides |
|---|---|---|
| BEST_FIT | Cost | May limit throughput |
| BEST_FIT_PROGRESSIVE | Throughput | May increase cost |
| SPOT_CAPACITY_OPTIMIZED | Least interruption | Only useful on Spot instances |
| SPOT_PRICE_CAPACITY_OPTIMIZED | Least interruption + Price | Only useful on Spot instances |
Batch provides different Allocation Strategies to help it choose which instances to provision.
If your workflow tolerates interruptions, you should enable spot on your ComputeEnvironment
and use SPOT_PRICE_CAPACITY_OPTIMIZED (this is the default if spot is enabled).
This will tell Batch to choose the instance types from the ones you’ve specified that have
the most spot capacity available to minimize the chance of interruption and have the lowest price.
To get the most benefit from your spot instances,
you should allow Batch to choose from as many different instance types as possible.
If you only care about minimal interruptions and not want Batch to optimize for cost, use
SPOT_CAPACITY_OPTIMIZED. SPOT_PRICE_CAPACITY_OPTIMIZED is recommended over SPOT_CAPACITY_OPTIMIZED
for most use cases.
If your workflow does not tolerate interruptions and you want to minimize your costs at the expense
of potentially longer waiting times, use AllocationStrategy.BEST_FIT.
This will choose the lowest-cost instance type that fits all the jobs in the queue.
If instances of that type are not available,
the queue will not choose a new type; instead, it will wait for the instance to become available.
This can stall your Queue, with your compute environment only using part of its max capacity
(or none at all) until the BEST_FIT instance becomes available.
If you are running a workflow that does not tolerate interruptions and you want to maximize throughput,
you can use AllocationStrategy.BEST_FIT_PROGRESSIVE.
This is the default Allocation Strategy if spot is false or unspecified.
This strategy will examine the Jobs in the queue and choose whichever instance type meets the requirements
of the jobs in the queue and with the lowest cost per vCPU, just as BEST_FIT.
However, if not all of the capacity can be filled with this instance type,
it will choose a new next-best instance type to run any jobs that couldn’t fit into the BEST_FIT capacity.
To make the most use of this allocation strategy,
it is recommended to use as many instance classes as is feasible for your workload.
This example shows a ComputeEnvironment that uses BEST_FIT_PROGRESSIVE
with 'optimal' and InstanceClass.M5 instance types:
# vpc: ec2.IVpc
compute_env = batch.ManagedEc2EcsComputeEnvironment(self, "myEc2ComputeEnv",
vpc=vpc,
instance_classes=[ec2.InstanceClass.M5]
)
This example shows a ComputeEnvironment that uses BEST_FIT with 'optimal' instances:
# vpc: ec2.IVpc
compute_env = batch.ManagedEc2EcsComputeEnvironment(self, "myEc2ComputeEnv",
vpc=vpc,
allocation_strategy=batch.AllocationStrategy.BEST_FIT
)
Note: allocationStrategy cannot be specified on Fargate Compute Environments.
Controlling vCPU allocation
You can specify the maximum and minimum vCPUs a managed ComputeEnvironment can have at any given time.
Batch will always maintain minvCpus worth of instances in your ComputeEnvironment, even if it is not executing any jobs,
and even if it is disabled. Batch will scale the instances up to maxvCpus worth of instances as
jobs exit the JobQueue and enter the ComputeEnvironment. If you use AllocationStrategy.BEST_FIT_PROGRESSIVE,
AllocationStrategy.SPOT_PRICE_CAPACITY_OPTIMIZED, or AllocationStrategy.SPOT_CAPACITY_OPTIMIZED,
batch may exceed maxvCpus; it will never exceed maxvCpus by more than a single instance type. This example configures a
minvCpus of 10 and a maxvCpus of 100:
# vpc: ec2.IVpc
batch.ManagedEc2EcsComputeEnvironment(self, "myEc2ComputeEnv",
vpc=vpc,
instance_classes=[ec2.InstanceClass.R4],
minv_cpus=10,
maxv_cpus=100
)
Tagging Instances
You can tag any instances launched by your managed EC2 ComputeEnvironments by using the CDK Tags API:
# vpc: ec2.IVpc
tag_cE = batch.ManagedEc2EcsComputeEnvironment(self, "CEThatMakesTaggedInstnaces",
vpc=vpc
)
Tags.of(tag_cE).add("super", "salamander")
Unmanaged ComputeEnvironments do not support maxvCpus or minvCpus because you must provision and manage the instances yourself;
that is, Batch will not scale them up and down as needed.
Configuring Job Retry Policies
Certain workflows may result in Jobs failing due to intermittent issues. Jobs can specify retry policies to respond to different failures with different actions. There are three different ways information about the way a Job exited can be conveyed;
exitCode: the exit code returned from the process executed by the container. Will only match non-zero exit codes.reason: any middleware errors, like your Docker registry being down.statusReason: infrastructure errors, most commonly your spot instance being reclaimed.
For most use cases, only one of these will be associated with a particular action at a time.
To specify common exitCodes, reasons, or statusReasons, use the corresponding value from
the Reason class. This example shows some common failure reasons:
job_defn = batch.EcsJobDefinition(self, "JobDefn",
container=batch.EcsEc2ContainerDefinition(self, "containerDefn",
image=ecs.ContainerImage.from_registry("public.ecr.aws/amazonlinux/amazonlinux:latest"),
memory=cdk.Size.mebibytes(2048),
cpu=256
),
retry_attempts=5,
retry_strategies=[
batch.RetryStrategy.of(batch.Action.EXIT, batch.Reason.CANNOT_PULL_CONTAINER)
]
)
job_defn.add_retry_strategy(
batch.RetryStrategy.of(batch.Action.EXIT, batch.Reason.SPOT_INSTANCE_RECLAIMED))
job_defn.add_retry_strategy(
batch.RetryStrategy.of(batch.Action.EXIT, batch.Reason.CANNOT_PULL_CONTAINER))
job_defn.add_retry_strategy(
batch.RetryStrategy.of(batch.Action.EXIT, batch.Reason.custom(
on_exit_code="40*",
on_reason="some reason"
)))
When specifying a custom reason,
you can specify a glob string to match each of these and react to different failures accordingly.
Up to five different retry strategies can be configured for each Job,
and each strategy can match against some or all of exitCode, reason, and statusReason.
You can optionally configure the number of times a job will be retried,
but you cannot configure different retry counts for different strategies; they all share the same count.
If multiple conditions are specified in a given retry strategy,
they must all match for the action to be taken; the conditions are ANDed together, not ORed.
Running single-container ECS workflows
Batch can run jobs on ECS or EKS. ECS jobs can be defined as single container or multinode.
This example creates a JobDefinition that runs a single container with ECS:
# my_file_system: efs.IFileSystem
# my_job_role: iam.Role
my_file_system.grant_read(my_job_role)
job_defn = batch.EcsJobDefinition(self, "JobDefn",
container=batch.EcsEc2ContainerDefinition(self, "containerDefn",
image=ecs.ContainerImage.from_registry("public.ecr.aws/amazonlinux/amazonlinux:latest"),
memory=cdk.Size.mebibytes(2048),
cpu=256,
volumes=[batch.EcsVolume.efs(
name="myVolume",
file_system=my_file_system,
container_path="/Volumes/myVolume",
use_job_role=True
)],
job_role=my_job_role
)
)
For workflows that need persistent storage, batch supports mounting Volumes to the container.
You can both provision the volume and mount it to the container in a single operation:
# my_file_system: efs.IFileSystem
# job_defn: batch.EcsJobDefinition
job_defn.container.add_volume(batch.EcsVolume.efs(
name="myVolume",
file_system=my_file_system,
container_path="/Volumes/myVolume"
))
Running an ECS workflow with Fargate container
job_defn = batch.EcsJobDefinition(self, "JobDefn",
container=batch.EcsFargateContainerDefinition(self, "myFargateContainer",
image=ecs.ContainerImage.from_registry("public.ecr.aws/amazonlinux/amazonlinux:latest"),
memory=cdk.Size.mebibytes(2048),
cpu=256,
ephemeral_storage_size=cdk.Size.gibibytes(100),
fargate_cpu_architecture=ecs.CpuArchitecture.ARM64,
fargate_operating_system_family=ecs.OperatingSystemFamily.LINUX
)
)
Secrets
You can expose SecretsManager Secret ARNs or SSM Parameters to your container as environment variables.
The following example defines the MY_SECRET_ENV_VAR environment variable that contains the
ARN of the Secret defined by mySecret:
# my_secret: secretsmanager.ISecret
job_defn = batch.EcsJobDefinition(self, "JobDefn",
container=batch.EcsEc2ContainerDefinition(self, "containerDefn",
image=ecs.ContainerImage.from_registry("public.ecr.aws/amazonlinux/amazonlinux:latest"),
memory=cdk.Size.mebibytes(2048),
cpu=256,
secrets={
"MY_SECRET_ENV_VAR": batch.Secret.from_secrets_manager(my_secret)
}
)
)
Running Kubernetes Workflows
Batch also supports running workflows on EKS. The following example creates a JobDefinition that runs on EKS:
job_defn = batch.EksJobDefinition(self, "eksf2",
container=batch.EksContainerDefinition(self, "container",
image=ecs.ContainerImage.from_registry("amazon/amazon-ecs-sample"),
volumes=[batch.EksVolume.empty_dir(
name="myEmptyDirVolume",
mount_path="/mount/path",
medium=batch.EmptyDirMediumType.MEMORY,
readonly=True,
size_limit=cdk.Size.mebibytes(2048)
)]
)
)
You can mount Volumes to these containers in a single operation:
# job_defn: batch.EksJobDefinition
job_defn.container.add_volume(batch.EksVolume.empty_dir(
name="emptyDir",
mount_path="/Volumes/emptyDir"
))
job_defn.container.add_volume(batch.EksVolume.host_path(
name="hostPath",
host_path="/sys",
mount_path="/Volumes/hostPath"
))
job_defn.container.add_volume(batch.EksVolume.secret(
name="secret",
optional=True,
mount_path="/Volumes/secret",
secret_name="mySecret"
))
Running Distributed Workflows
Some workflows benefit from parallellization and are most powerful when run in a distributed environment,
such as certain numerical calculations or simulations. Batch offers MultiNodeJobDefinitions,
which allow a single job to run on multiple instances in parallel, for this purpose.
Message Passing Interface (MPI) is often used with these workflows.
You must configure your containers to use MPI properly,
but Batch allows different nodes running different containers to communicate easily with one another.
You must configure your containers to use certain environment variables that Batch will provide them,
which lets them know which one is the main node, among other information.
For an in-depth example on using MPI to perform numerical computations on Batch,
see this blog post
In particular, the environment variable that tells the containers which one is the main node can be configured on your MultiNodeJobDefinition as follows:
multi_node_job = batch.MultiNodeJobDefinition(self, "JobDefinition",
instance_type=ec2.InstanceType.of(ec2.InstanceClass.R4, ec2.InstanceSize.LARGE), # optional, omit to let Batch choose the type for you
containers=[batch.MultiNodeContainer(
container=batch.EcsEc2ContainerDefinition(self, "mainMPIContainer",
image=ecs.ContainerImage.from_registry("yourregsitry.com/yourMPIImage:latest"),
cpu=256,
memory=cdk.Size.mebibytes(2048)
),
start_node=0,
end_node=5
)]
)
# convenience method
multi_node_job.add_container(
start_node=6,
end_node=10,
container=batch.EcsEc2ContainerDefinition(self, "multiContainer",
image=ecs.ContainerImage.from_registry("amazon/amazon-ecs-sample"),
cpu=256,
memory=cdk.Size.mebibytes(2048)
)
)
If you need to set the control node to an index other than 0, specify it in directly:
multi_node_job = batch.MultiNodeJobDefinition(self, "JobDefinition",
main_node=5,
instance_type=ec2.InstanceType.of(ec2.InstanceClass.R4, ec2.InstanceSize.LARGE)
)
Pass Parameters to a Job
Batch allows you define parameters in your JobDefinition, which can be referenced in the container command. For example:
batch.EcsJobDefinition(self, "JobDefn",
parameters={"echo_param": "foobar"},
container=batch.EcsEc2ContainerDefinition(self, "containerDefn",
image=ecs.ContainerImage.from_registry("public.ecr.aws/amazonlinux/amazonlinux:latest"),
memory=cdk.Size.mebibytes(2048),
cpu=256,
command=["echo", "Ref::echoParam"
]
)
)
Understanding Progressive Allocation Strategies
AWS Batch uses an allocation strategy to determine what compute resource will efficiently handle incoming job requests. By default, BEST_FIT will pick an available compute instance based on vCPU requirements. If none exist, the job will wait until resources become available. However, with this strategy, you may have jobs waiting in the queue unnecessarily despite having more powerful instances available. Below is an example of how that situation might look like:
Compute Environment:
1. m5.xlarge => 4 vCPU
2. m5.2xlarge => 8 vCPU
Job Queue:
---------
| A | B |
---------
Job Requirements:
A => 4 vCPU - ALLOCATED TO m5.xlarge
B => 2 vCPU - WAITING
In this situation, Batch will allocate Job A to compute resource #1 because it is the most cost efficient resource that matches the vCPU requirement. However, with this BEST_FIT strategy, Job B will not be allocated to our other available compute resource even though it is strong enough to handle it. Instead, it will wait until the first job is finished processing or wait a similar m5.xlarge resource to be provisioned.
The alternative would be to use the BEST_FIT_PROGRESSIVE strategy in order for the remaining job to be handled in larger containers regardless of vCPU requirement and costs.
Permissions
You can grant any Principal the batch:submitJob permission on both a job definition and a job queue like this:
# vpc: ec2.IVpc
ecs_job = batch.EcsJobDefinition(self, "JobDefn",
container=batch.EcsEc2ContainerDefinition(self, "containerDefn",
image=ecs.ContainerImage.from_registry("public.ecr.aws/amazonlinux/amazonlinux:latest"),
memory=cdk.Size.mebibytes(2048),
cpu=256
)
)
queue = batch.JobQueue(self, "JobQueue",
compute_environments=[batch.OrderedComputeEnvironment(
compute_environment=batch.ManagedEc2EcsComputeEnvironment(self, "managedEc2CE",
vpc=vpc
),
order=1
)],
priority=10
)
user = iam.User(self, "MyUser")
ecs_job.grant_submit_job(user, queue)