AWS Fargate Deep Dive: What it is, when to use it
Introduction
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.
Features
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.
Performance
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
Lambda
Initial Warmup Results 
Post Warmup Results 
Fargate
Initial Warmup Results 
Post Warmup Results 
Results
The results we saw from the test were pretty similar to the results mentioned in the earlier post:
Initial Warmup Results
Post Warmup Results
Pricing
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.
Pricing:
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.
from Hacker News https://ift.tt/34DoJRc