When it comes to running containerized, long-duration workloads in the cloud, AWS Fargate Tasks and GCP Cloud Run Jobs are two options worth considering. AWS Fargate Tasks have been around for quite some time in cloud years (since 2018 ), while GCP Cloud Run Jobs were released in preview in May of 2022. Both options will get the job done, but in terms of simplicity and resulting “Total Cost of Ownership”, Cloud Run Jobs are the clear winner.

AWS Fargate Tasks

AWS Fargate is a fully managed service that allows users to run containers without the need to manage servers. With Fargate, users only pay for the resources that their containers use, making it a cost-effective option. Fargate supports both Amazon Elastic Container Service (ECS) and Kubernetes as a backing compute service.

In Fargate, tasks represent the basic unit of work that runs on a container. A task definition specifies how the container should run and what resources it should use. Users can specify the amount of CPU and memory that each task requires, and Fargate will automatically provision the necessary resources to run that container from the clusters that the task references.

Users must specify and define the ECS or EKS cluster that will provide compute for the Fargate task. And because Fargate is an abstraction around these clusters, you will need to configure the VPC within which these clusters sit depending on which other resources the Fargate task needs to access. Even accessing a public container in Fargate requires manually creating the AWS networking components that allow egress to the internet. Despite being a serverless offering, this becomes suprisingly cumbersome to set up.

GCP Cloud Run Jobs

GCP Cloud Run Jobs allow users to run long duration containers one at a time or in batch calls. It is a sister service of the more mature and well-known Cloud Run Services. Unlike Cloud Run Services, and like AWS Fargate Tasks, Cloud Run Jobs are not triggerable by https requests (although this post describes a solution).

With Cloud Run Jobs, one simply specifies how many GB of ram and vCPUs to allocate to the executing task, and GCP abstracts how that compute is delivered to the container. A VPC connection is certainly possible, but not a default requirement for a Job’s configuration, and accessing a database securely can be done by simply adding a Cloud SQL connection.

Comparision

Both AWS Fargate Tasks and GCP Cloud Run Jobs offer similar functionality for running containers in a serverless manner. Because they run containers, you can test the container execution locally on your machine with exact parity to how it will be run on the cloud, and bring whichever programming lanaguage you want to the service. Both would make great tools for your specific application’s long-running workloads, but one offering comes out on top.

Let’s check the tail of the tape:

Pricing

Both services offer pay-as-you-go pricing models, and for start underlying chips and vCPUs, pricing is a wash between the two services. Winner: Tie.

User Interface Definitions

The complexity of Fargate tasks sitting on top of an ECS or EKS cluster, and as a result requiring VPC configuration, can lead to a much slower deployment/development process than a Cloud Run Job. Fundamentally, the definition of the task itself is similar to the definition of the Cloud Run Job itself, but because GCP abstracts the source of the underlying compute necessary to get to such task definition, Cloud Run Jobs are the clear winner here. Winner: Cloud Run Jobs.

Defining with Terraform

We have defined both Cloud Run Jobs and ECS Fargate Tasks with Terraform, and found that the complexity differences present in setting up each service through their respective cloud console’s carries over to their IaC configuration in a big way. Winner: Cloud Run Jobs.

Job Execution Latency

Google Cloud Run Jobs begin executing within seconds of invocation, whereas Fargate tasks are much slower to start due to a lag in AWS provisioning the underlying compute. While not a deal breaker for long-running tasks that are often times run overnight or without a strict latency requirement, it is worth noting, and can make Fargate more frustrating when testing and debugging tasks in the cloud. Winner: Cloud Run Jobs.

Chip Availability

AWS is the clear winner here, offering access to unique, in-house Graviton chips for Fargate Tasks. Whether having access to Graviton tasks is essential will be up to the individual user. Winner: Fargate Tasks.

Naming

This is a tiny one, but Cloud Run Jobs is a much more intuitive name for the underlying functionality than a Fargate Task. Winner: Cloud Run Jobs.

Conclusion

In conclusion, AWS Fargate Tasks and GCP Cloud Run Jobs both offer a serverless experience for running containers, making it easier for users to focus on their applications rather than infrastructure management. While Fargate Tasks have some strengths, its architecture makes it more difficult and slow to set up than Cloud Run Jobs, greatly increasing its “Total Cost of Ownership” and making the offering from GCP our recommedation.

That being said, if your organization is already using one of these major cloud providers, it is still probably best to select the offering from your existing provider (further highlighting the durable value of moving first).

–

dragondrop.cloud’s mission is to automate developer best practices while working with Infrastructure as Code. Our flagship product regularly scans and identifies resource changes that have occurred outside of a Terraform workflow (e.g. drift) so that dev teams can have a Cloud environment that is fully represented as code. All of our tools are self-hosted by our customers, with no data ever leaving their servers. To learn more, schedule a demo or get started today!