Introducing “default” instance categories for AWS Batch

Today, we are launching a new set of instance family categories for AWS Batch, "default_x86_64" and "default_arm64". These new categories represent both a clarification and an improvement upon the existing “optimal” instance type category. This blog post gives some background on the new feature and how you can configure your Batch environments to take advantage of the improvements.

Choosing instance types for AWS Batch compute environments to launch

You can specify the set of Amazon EC2 instance types that a compute environment can launch to run the jobs in your job queues. For example, if you know your jobs have the best price/performance on a g6.16xlarge, you can set the computeResources.instanceTypes parameter of your compute environment to ["g6.16xlarge"], and it will only launch that specific instance type and size for the jobs in the associated job queue(s).

To get the most out of Batch’s scheduling and scaling capabilities, you want to define a diverse set of instances and let Batch decide which to launch based on the CPU, memory, and GPU resource requirements of the jobs. Although you can specify a list of instance types (["c5.24xlarge", "m6.48xlarge"]), you can also define a set of instance families (["c5","c7a","c7i","m7i"]) that Batch can launch on your behalf. Historically, you also had the option to use the [“optimal”] category, which Batch translates to ["c4","m4","r4"] when these instances are available in the AWS Region. If a Region does not contain those instance types, Batch translates optimal to the lowest-cost generation in the Region, most often ["c5","m5","r5"].

Although optimal was a convenient shorthand setting, we found that it did not match our customer expectations. Batch did not select instances for your job’s best performance or best price for your application. The optimal category was a simple mapping and nothing more. Newer instance generations potentially have better price/performance for most workloads. In all cases that I’ve looked at 4th generation instances are both slower and more expensive than 5th generation instances, so optimal is not actually optimal!

Finally, optimal did not include instances with AWS Graviton processors, which were specifically designed to deliver great price/performance for a variety of workloads.

Improving on optimal

Today, we launched a new set of instance type categories to improve your experience with Batch’s instance selection. You can now choose default_x86_64 for a set of instance families with x86 CPUs and default_arm64 for a set of instances with AWS Graviton CPUs. The list of instance types will not be static and will change over time as we introduce new instance families. You can find the mapping of each category to the set of instance families in the Region in our Instance type compute table documentation page, but as an example, the mapping of default_arm64 will be the following at feature launch:

Table 1. The mapping of the default_arm64 instance type category to specific instance families in Regions supporting AWS Batch.

The default mappings do not include accelerated instances by design. We strongly recommend setting specific instances if your workload benefit from accelerated instances. In addition, we recommend defining a separate job queue and compute environment from non-accelerated instance pools. With separated resources, Batch can make better scaling decisions for your workloads and prevent scheduling non-accelerated jobs on accelerated instances, which potentially incurs additional costs.

As previously with optimal, you can still define additional instance types alongside the default_* categories. Batch considers your fully defined list when selecting the instance types for your jobs.

Transitioning from optimal

We recommend updating your Batch environments to adopt the new categories. However, you are not required to update. Existing AWS Batch compute environments that use optimal remain valid. The CreateComputeEnvironment and UpdateComputeEnvironment API actions continue to accept optimal as a valid value. The behavior of optimal will stay the same until early November 2025. After that, optimal will behave the same as the default_x86_64 instance category.

Again, after early November 2025 , optimal will no longer be a static mapping to 4^th generation instances (where available) and will change over time as AWS introduces new instance families.  If you want to remain on the current set of instances for optimal, you should update your compute environment(s) to specifically choose those instance types.

We recommend that any new compute environments you create use the new default_* categories. Personally, I also recommend that you check out whether your applications can benefit from Graviton by creating containers for Arm and defining a default_arm64 compute environment and job queue. You may get a pleasant result!

Conclusion

We are excited for you to try out the new default_* instance type categories. We feel that adopting newer instance generations over time will keep your workloads running efficiently and cost-effectively. To start using the new categories, log into the AWS Batch management console, or refer to the tutorial on creating a managed EC2 compute environment in our User Guide.