• An AWS account
  • kubectl, aws-cli & eksctl installed
  • Some Kubernetes knowledge


Introduced in late 2017, AWS Fargate is a compute engine for serverless container deployments. The engine allows you to run containers without worrying about your infrastructure.
Node scaling and configuration is done by AWS, which means that you only have to worry about the health of your own resources, not of your Kubernetes infrastructure.

Fargate eliminates the struggle of configuring, scaling and initializing nodes on its own. Because as we know, managing clusters / servers / nodes can be a challenging and expensive task.

Pricing is based on the CPU and RAM that is allocated to your pod. Instead of paying for compute nodes you pay for resources allocated to your pods which could drastically decrease computing costs.


AWS Fargate was initially introduced for ECS in 2017. Later in 2019 they added support for EKS. You can configure your current cluster to integrate Fargate. This requires a Fargate pod execution role (to communicate with different Amazon services), and a Fargate profile to specify which pods should use Fargate. You can also create a new cluster with instant Fargate support. For simplicity, I will initialize a new cluster.

eksctl create cluster --name <cluster-name> --region eu-west-1 --fargate

The initialization process takes a while, so don’t wait around for it and find something else to do in the meantime. It shouldn’t take more than 15 minutes.

Fargate in action

After your cluster has been created, you should see two Fargate nodes already running.

$> kubectl get nodes 
NAME                                                    STATUS    ROLES     AGE       VERSION    Ready     <none>    5m       v1.18.8-eks-7c9bda    Ready     <none>    5m       v1.18.8-eks-7c9bda

This is because of the two CoreDNS pods that get spun up after the setup of the cluster.

$> kubectl get pods -n kube-system
NAME                     READY     STATUS    RESTARTS   AGE
coredns-58c89c64-pmjh4   1/1       Running   0          12m
coredns-58c89c64-rm4dr   1/1       Running   0          12m

Each pod gets its own Fargate node and represents the resources that the pods get in order to successfully function. When you create a new deployment, you will notice that you have a pod in the status pending creation.

$> kubectl create deployment spring-boot-docker --image springio/gs-spring-boot-docker
deployment.apps/spring-boot-docker created

$> kubectl get pods
NAME                                  READY     STATUS    RESTARTS   AGE
spring-boot-docker-6656b9d9fb-h82pk   0/1       Pending   0          5s

This is because Fargate has yet to create a virtual node for the Pod to run in. After a few seconds you can see that a new node has been added to your cluster.

$> kubectl get nodes 
NAME                                                    STATUS    ROLES     AGE       VERSION   Ready     <none>    16s       v1.18.8-eks-7c9bda    Ready     <none>    52m       v1.18.8-eks-7c9bda    Ready     <none>    52m       v1.18.8-eks-7c9bda

Now that your virtual node has been added you can see that your pod is starting up.

$> kubectl get pods
NAME                                  READY     STATUS    RESTARTS   AGE
spring-boot-docker-6656b9d9fb-h82pk   1/1       Running   0          2m26s


So right now we have a fully functioning Kubernetes cluster without having to touch or set up any nodes or configuration. Fargate takes away all the stress of maintaining and scaling worker nodes, so you can concentrate on the actual deployment of your application(s) and not worry about cluster resources. Of course, you would still need additional resources to access your application from outside the cluster, but it’s not covered in this post as this does not fall under the Fargate scope.

Yolan Vloeberghs is a Java and Cloud engineer with a sharpened focus on all things related to cloud, specifically AWS. He loves to play around with various technologies and frameworks and is very passionated and eager to learn about everything related to cloud-native development.