Demystifying AWS Fargate

Apparently, AWS Fargate is a technology for “running” your containers. You provide an image and tell a few things about how you want it to be run and Fargate will get it done for you. You don’t worry about cluster, nodes, patching nodes, scaling, etc. That’s the 30 seconds overview. But there is more.

BTW, I hear people comparing Fargate against ECS. That is not even an apple to oranges comparison. Fargate is basically a launch type with ECS (and probably with EKS as well in the future, once EKS is available). Launch type just determines the type of infrastructure that hosts the tasks/services. You have something like this.

|                              |
|          ECS/EKS             |
|                    (Docker)  |
|                              |
|                              |
|          EC2/Fargate         |
|                              |
|                    (Compute) |

First, you need a container management service or an orchestrator such as ECS or EKS. Then comes Fargate. For the orchestrator to launch a container, infrastructure or resources are needed and that is what is provided by Fargate. Of course, you can also use EC2 as the underlying resource and this option will provide you more control. Thus, the two options Fargate launch type and EC2 launch type.

Basically, what Fargate does is it abstracts away the cluster and nodes and related problems like high availability, scalability, etc. AWS handles these for you. You will deal only with the orchestrator, which is ECS (or EKS in the future). So, if you use Fargate with ECS, all ECS constructs like tasks, service are all applicable. Of course there are limitations but fundamentally you are working only with ECS.

Now, the Serverless part. AWS Serverless computing page does not have a single mention of Fargate – at least I couldn’t find it. May be it is nothing to do with Serverless? There are similarities with Lambda though. You don’t need to manage infrastructure and AWS automatically scales for you and takes care of high availability. In addition, Fargate tasks can run without any duration limitations that Lambda has. From that perspective, you can think off Fargate being an improvement over Lambda. If you have a batch kind of workload, you can containerize the job and let Fargate run it. Example: building and deploying an app (CI/CD pipeline), image processing, etc. However, when it comes to pricing, there is an important difference although the pricing appears to be similar. Lambda pricing is based on the execution time. “You are charged based on the number of requests for your functions and the duration, the time it takes for your code to execute.” – That’s what Lambda pricing page says, as of today. For Fargate also, you pay for what you use (kind of). Pricing is based of CPU and memory and the time your container runs (to be accurate, the duration of the task – from the time the image is pulled until the ECS task terminates). Pricing for Lambda and Fargate is similar especially for batch scenarios – a task that has a start and an end – a container starts up, does some processing and terminates. You can put API Gateway in front of Lambda and use it as the backend for Web apps and pay only for the execution of requests. This is where Fargate pricing differs. If I were to run an NGINX container, just as an example, this container is not going to terminate. It is going to keep on running and keep listening for requests. If you are not serving any requests, you are not using any resource you might think but as far as Fargate is concerned, it is running a task (NGINX container) and you will pay until the container terminates. Because of this, I do not think Fargate are Lambda are not the same when it comes to $, in case of web apps. If I’m stating anything wrong, please let know through the comments and I’ll edit the post so that it remains useful and accurate for at least a few months (or weeks may be).

So, you have a Docker image. You don’t care about the cluster or the management aspects of the nodes. Also, you don’t want to bother about scalability and availability. That’s the use case for Fargate. But there are other technologies around, which do the same thing (at least more or less the same) – my favorite Google Kubernetes Engine being an example. All you need is a Docker image to run it in GKE but then Fargate vs GKE is not a fair comparison. With GKE, it is a little bit more work. Google does patch the nodes for you, especially if you Container-Optimized OS node image. But you need to be aware of few other things like Horizontal Pod Autoscaler (HPA) and multi-zone and regional clusters. Not just that, you have to know about Kubernetes concepts like Pods, Deployment, Services, NodePort, etc. That’s definitely more work but then in terms of pricing, Fargate is almost two times that of GKE (rough estimates). If you have workloads that are okay with handling someone pulling the plug on them, you can even use preemptible VMs in GCP and decrease you bills even further. You have to be okay to get preempted though and not every app can be okay. BTW, AWS has a history of slashing prices. So, this could change in the future.

If I missed something important, please do leave a reply.

3 thoughts on “Demystifying AWS Fargate

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.