The AWS Batch team recently launched support for Graviton and Windows containers running on AWS Fargate resources. Combine that announcement with other recent additions such as larger task sizes and configurable local storage and Fargate becomes an even better serverless solution for your batch and asynchronous workloads.
Let’s take a look at the features that make Fargate a great choice for your small to medium scale AWS Batch environments, starting with the most recent announcements.
Previously, Batch on Fargate only supported running containers that leverage an x86 CPU architecture, even though Fargate itself was able to run tasks using Linux containers built for the Graviton2 Arm architecture. We closed that gap with this release and you can now leverage Graviton2 which delivers 2-3.5 times better CPU performance per watt than any other processors of the same generation for your Batch jobs, making them a sustainable choice. They also have very capable price/performance characteristics and so are idea for analyzing data, logs, or other batch processing. Fargate does not yet support Graviton3.
The best way to find out whether x86 or aarch64 resources give you better price/performance is to try them out on your own application. You can leverage AWS CodePipeline to build multi-architecture container images and store them in Amazon Elastic Container Registry (Amazon ECR). If you need some guidance for building multi-architecture container images, this AWS samples GitHub repository is a good place to start.
To leverage Fargate Graviton resources, you set the job definition’s runtimePlatform.cpuArchitecture parameter to ARM64. Then submit a job to a job queue that is configured to use Fargate resources. Graviton with Fargate is available in most AWS Regions, but there are some limitations for you should consider such as being limited to Linux containers. The full set of considerations are outlined in the documentation in Working with 64-bit ARM workloads on Amazon ECS.
Since its release, AWS Batch has only supported running containers on top of the Linux operating system. Customers could build against the .NET Core for Linux, but not native Windows containers. Those containers are required to run Windows-only applications. Windows Batch jobs can also automate tasks that would benefit from a Windows environment, for example when you want to integrate with Microsoft Active Directory…