Four differences between EKS Fargate and Node Managed

The Cloud
Publication Date
17 January 2022

Four differences between EKS Fargate and Node Managed


Are you in doubt about what would be the right option to run Kubernetes on AWS? In this blog post you will get the answer, I will show you a few differences between EKS Node Managed and EKS Fargate. 

Containers are not a new concept in the IT world: they have been widely used in public cloud or on-premises. Most public cloud providers offer different approaches on how to implement the containers. Let’s talk about EKS on AWS. You may ask yourself what does EKS stand for? 

EKS cluster is a container orchestration platform that consists of a set of virtual machines called worker nodes and is designed to manage the lifecycle of containerized applications. Control Manager of EKS manages the nodes and the pods in the cluster. A “pod” is a group of one or more application containers.  This platform also provides availability, scaling, and reliability of the pods. 

AWS supports 2 EKS models:

  • EKS Fargate: Container as a Service (CaaS) also called "serverless for containers".  
  • EKS Node Managed: Infrastructure as a Service (IaaS)

EKS Fargate. This model has been designed to give developers the possibility to concentrate only on their workload, pods configurations, and application logic, without worrying about the infrastructure management, availability, fault tolerance, scaling, and patching of host machines. Therefore the , control manager and worker nodes are managed by AWS. 

EKS Node Managed. This model gives developers the freedom to manage not only the workload, but also the worker nodes. Worker nodes consist of a group of virtual machines. However, the control manager is always managed by AWS.

The following drawing shows a high-level difference between EKS Fargate and Node Managed.


EKS Node Managed vs Fargate 

Let me show you a few differences between them:


Nowadays, security is a fundamental component. The importance of data protection increases as the amount of data grows, so it is important to have in place a good approach to protect the data and systems from challenging threats. A good way to start is by understanding the shared responsibility model: what are AWS’s and Customer’s responsibilities, and who is responsible to enhance the security of pods, network, incident response, and compliance. Both services are compliant by meeting the security standards, and there is also an SLA 99.99%. 

pasted image 0-1

Shared responsibility EKS model 


Your resources increase or decrease according to the system’s workload demands. To better manage the workload, it’s good to have the right scaling strategy allowing systems to scale without interrupting their operation and to ensure that the activities work as it is expected.

  • In EKS Fargate, AWS is responsible for managing the scaling of the worker nodes in the cluster, so you don’t need to worry about scalability.
  • In Node Managed, the customer is responsible for managing the scalability of the worker nodes. 

There is a tool in AWS that helps you to manage different scaling approaches, this service is called Auto Scaling group(ASG). It provides vertical (scale-up) and horizontal scaling (scale-out). The scope of both these approaches is to deliver performance and capacity that the workloads require. But these models work differently. You may ask: Which one is a better solution? Let me briefly explain how they handle the resource based on the workload. 

pasted image 0 (1)-2

Scale-out vs scale-up 

Scale-out: Add or remove nodes to the cluster, this means a group of virtual machines can be deployed as dependent pieces. 

Scale-up: Add or remove capacity to a single node, you can add more CPU, RAM, Storage to this node. Not highly recommended as you don’t have a redundancy, and high availability, as this machine will reside in a single availability zone. 


Running the EKS cluster on AWS requires a pre-existing networking configuration. So, the first step is to set up the virtual private network (VPC) configuration. Keep in mind what workload you may have before deciding the Inter-domain routing (CIDR) of VPC. As your cluster grows and your applications become more complex you may need other resources running on the same network such as load balancers, databases, etc. It’s important to have a scalable solution that fits your requirements, so you won’t be in a position to recreate the resources and network from scratch because your CIDR block is too small in the first place. For both Node Managed and Fargate Control manager is part of the internal network managed by AWS, so you don’t have to worry about that. In the case of Fargate, AWS also manages the worked node network, so you’ll only need to calculate the pod IPs.

Let me give you two example of how many IP Addresses you need available to run a simple application in EKS. Here are some combinations of subnet size and machine type. 

  1. One cluster with 5 nodes and 40 pods running on each node.
  2. Two clusters with 30 nodes and 40 pods running on each node.

How many available IPs will we have for different Subnet CIDR range setup?  In the illustration below are three different scenarios, and each one of them shows how many available IPs we will have for different SIDR ranges.

Subnet /25 = 126 IPs available

Subnet /24 = 254 IPs available

Subnet /21 = 2046 IPs available

Now let’s imagine we want to use different worker nodes types m5.large and m5.4.xlarge. Can we leverage all available IPs in both scenarios? As you can see in the illustration below there are some limitations on pods availability for different instance types. 

M5 large = max 3 ENI and 9 Secondary IPs per ENI = max 27 pods available

M5.4 xlarge = max 8 ENI and 29 Secondary IPs per ENI = max 232 pods available

5 Node x 40 pods = 200 IPs address 

30 Node x 40 pods x 2 cluster = 2400 IPs address  

/24 can fit your requirement

You need at least /21 = 2046 IPs to setup cluster

In the example # 2 above, you will need at least CIDR /21 to fit the requirements.  


Cost optimization is an important component in any organization, and it requires a good understanding of costs for short and long term. In AWS, you pay for computing capacity per second depending on what cluster you run. Let me show you how much Fargate and Managed Node will cost for one, three and six months. To illustrate this better, I will showcase you two different cases.

Managed Node Case: 15 nodes, using 2vCPU, 16 GB memory each (3 hours a day and 24 hours)

Managed Node EC2 Cost (15 nodes m5.large)

($0.0111/hour x 3 hours x 30 days) x 15 = $14.9/months

($0.0111/hour x 24 hours x 30 days) x 15 = $119.88//months

Fargate Case: 15 pods, using 2vCPU, 16 GB memory each (3 hours a day and 24 hours) 

  • Monthly CPU charges Fargate

Total vCPU charges = # of Pods x # vCPUs x price per CPU-second x CPU duration per day (seconds) x # of days

15 pods x (2vCPU x $0.04048/(60x60) seconds) x 10800 seconds x 30 days = $109.29 /Month

15 pods x (2vCPU x 0.000011244) x 43200 seconds x 30 days = $437.16 /Month

  • Monthly memory charges Fargate

Total memory charges = # of Pods x memory in GB x price per GB x memory duration per day (seconds) x # of days

15 pods x (8GB x $0.000001235) x 10800 seconds x 30 days = $48.0168 /Month

15 pods x (8GB x $0.000001235) x 43200 seconds x 30 days = $192.067 / Month


Short and long term costs


Customers may have complex container architecture in their data centers that may face challenges. However, taking advantage of the cloud gives you the flexibility to focus on what you need, and quickly solves scalability, readability, and security.

More About Our Technology

Let our expertise complement yours

Leave your details below and we'll be in touch soon.