AWS Fargate was launched in late 2017. It lets users build and deploy containerized applications without having to manage the underlying infrastructure themselves. Cluster management (tasks like managing EC2 instances, autoscaling policies amongst others) can be operationally challenging and adds a lot of friction for developers who want to be able to deploy their applications as quickly as possible without having to worry about the operational overhead.

How does AWS Fargate work?

Fargate makes deploying and running containerized applications simpler. To be able to run your application on Fargate, you need to:

  • Package your application in containers
  • Specify CPU and memory requirements
  • Define any IAM / networking policies as necessary

Fargate makes it easy to scale applications. Amazon handles scaling underlying resources to ensure that the application continues running in a highly available manner. Amazon does not provide a lot of detail about how Fargate works under the hood. Amazon most likely spins up EC2 instances using ECS as the orchestration service and runs any applications scheduled via Fargate on this multi-tenant cluster.

AWS supports the following configurations for Fargate:


AWS Fargate Pricing

AWS Fargate pricing is based on the amount of resources you use. Resources available for a particular task are vCPU and memory. Pricing is as follows:


Amazon announced at the beginning of 2019 that they had dropped the pricing for AWS Fargate by up to 50%.

Getting started with AWS Fargate

There are a few tutorials available on the internet which help to get started with writing applications for AWS Fargate. Some of these tutorials are:

We also have a tutorial on this blog which walks through a Python web app on Fargate.

When to use AWS Fargate

Fargate is a great tool when you start building a new application and you don’t want any operational overhead. Using Fargate, you only pay for the resources you use and you can iterate much faster.

Some examples of different uses of Fargate:

Comparing Fargate to other AWS services

AWS has a lot of different services available to developers who wish to run their application and it can be confusing to understand which AWS service to use. We will try to compare Fargate to other AWS services to get a better understanding of how these services differ from each other.


AWS Fargate vs AWS Lambda

Fargate and Lambda are both serverless technologies from AWS. You don’t need to provision any infrastructure to run applications on either of these services. Both of these services significantly reduce the operational overhead associated with running applications on AWS. You only pay for the resources used and there are no upfront payments.

There are some key differences between Fargate and Lambda. They are:

  • Lambda has certain limitations in terms of CPU and RAM available to use. A Lambda function can use at most 3 GB of memory. AWS does not provide an option to select CPU for Lambda functions as it allocates the CPU based on how much RAM is selected. As we saw above, Fargate gives users more flexibility when it comes to CPU and RAM. The maximum RAM available for any application is 30 GB and 4 vCPUs.

  • Lambda has a maximum run time of 15 minutes per invocation whereas Fargate has no such limits.

  • Lambda functions don’t need to be packaged into containers making it easier to get started with Lambda.

Fargate vs ECS

Amazon Elastic Container Service or ECS is Amazon’s container orchestration service that makes it easy to manage containers (running, stop, starting containers, etc) on a cluster of EC2 instances.

ECS has two launch types which determine the type of underlying infrastructure and operations required:

  • Fargate Launch Type: This is the mode we chose when we use Fargate. This lets us run the cluster on serverless mode i.e. Amazon manages the underlying cluster. Low operational overhead as well as lower flexibility in terms of resources available compared to the EC2 launch type.

  • EC2 Launch Type: In this mode, we get to choose the EC2 instances on which the cluster runs on. We need to manage the underlying cluster ourselves. You get to choose what kind of scaling policies should be applied, what kind of instances to run on etc. Comes with higher operational overhead since you need to manage the cluster.


We ran load tests to test the performance of a simple Python web app on both Fargate and Lambda. The tests were inspired by this post.

The test setup:

  • 1000 requests to each service to ensure the services are warmed up.

  • 2000 requests to each service after the services had been warmed up.

  • ~30 requests / second

  • Architecture: Fargate + ALB / Lambda + API Gateway

  • Lambda specs: 512 MB of memory

  • Fargate specs: 512 MB of memory, 0.25 vCPU


Initial Warmup Results lambda-warmup

Post Warmup Results lambda-after-warmup


Initial Warmup Results fargate-warmup

Post Warmup Results fargate-after-warmup


The results we saw from the test were pretty similar to the results mentioned in the earlier post:

  • AWS Fargate was consistently slightly faster than AWS Lambda.

  • I noticed a high request failure rate with AWS Fargate when I increased the requests per second. This might be due to Fargate taking longer to scale up. Fargate startup time can be slow.

Initial Warmup Results


Post Warmup Results



It is hard to compare the cost of using AWS Fargate, Lambda and EC2 instances since each of these services use a different pricing model and the comparison is not straightforward.

Pricing for Fargate


Pricing for Lambda

AWS Lambda pricing is split into Compute and Request Charges.

From the pricing page on AWS:

Lambda counts a request each time it starts executing in response to an event notification or invoke call, including test invokes from the console. You are charged $0.0000002 per request for the total number of requests across all your functions.

Duration is calculated from the time your code begins executing until it returns or otherwise terminates, rounded up to the nearest 100ms. The price depends on the amount of memory you allocate to your function. In the AWS Lambda resource model, you choose the amount of memory you want for your function, and are allocated proportional CPU power and other resources. An increase in memory size triggers an equivalent increase in CPU available to your function.



AWS Fargate vs AWS Lambda

AWS Lambda charges you per invocation and duration of each invocation whereas AWS Fargate charges you for the vCPU and memory resources of your containerized applications use per second. Without knowing the particular use-case, it won’t be a fair comparison between Fargate and Lambda.

AWS Fargate/AWS Lambda vs AWS EC2

The following blog posts are extensive and provide a good framework for comparing the cost of these services:

Final Thoughts

Fargate makes it easy to run applications on AWS. AWS takes away the complexity associated with running and scaling the underlying infrastructure. Since you only pay for the resources you use, it might be more cost-efficient when first starting with a new service.

The comparison between Lambda and Fargate is interesting and it can be confusing to decide which service to use. This is how I think about it:

  • If your application is short-lived and requires less than 3GB of memory, use Lambda.

  • If your application is a long compute job and/or requires more than 3GB of memory, use Fargate.

  • If you need higher performance, Fargate is probably the better option.