Four Differences Between EKS Fargate vs Managed Nodes

Confused about whether EKS Fargate or Managed Nodes is the best option for running Kubernetes on AWS? This blog breaks down the differences to help you make an informed decision.

Understanding EKS on AWS

Containers have revolutionized the IT world, becoming essential for both public clouds and on-premises infrastructures. AWS offers two approaches for running Kubernetes on AWS Elastic Kubernetes Service (EKS): Fargate and Managed Nodes. But which one should you choose?

Let’s first explore what EKS is. EKS (AWS Kubernetes/Amazon Elastic Kubernets Service) is a container orchestration platform that manages the lifecycle of containerized applications. It consists of:

• Control Manager: Managed by AWS, it oversees pods (groups of one or more application containers) and worker nodes.
• Worker Nodes: A set of virtual machines that perform the heavy lifting for your applications.

AWS supports two EKS models:

• EKS Fargate – A “serverless for containers” model, also referred to as Container as a Service (CaaS).
• Managed Nodes – An Infrastructure as a Service (IaaS) model allowing more control over worker nodes.

What is EKS Fargate?

This model has been designed to give developers the possibility to concentrate only on their workload, pod 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.

What is EKS Managed Nodes?

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.

The Differences Between EKS Fargate vs Managed Nodes

1. Security

Security is a critical concern in today’s environment of increasing data volumes. Understanding AWS’s shared responsibility model is key:

• AWS Responsibilities: Control Manager, underlying infrastructure, and host security.
• Customer Responsibilities: Securing pods, incident response, network configurations, and compliance adherence.

Both EKS Fargate and Managed Nodes adhere to security standards and offer a 99.99% SLA. However, the level of control differs:

• Fargate: AWS handles all aspects of worker node security.
• Managed Nodes: Customers must secure worker nodes in addition to workloads.

2. Scalability

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 they are 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 (scale-out) scaling.

The scope of both these approaches is to deliver the 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.

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, and/or storage to this node. Not highly recommended as you don’t have redundancy or high availability, as this machine will reside in a single availability zone.

3. Network

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. Both Node Managed and Fargate Control Manager are 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 examples 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.

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

How many available IPs will we have for different subnet CIDR range setups?  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 node 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 example number two above, you will need at least CIDR /21 to fit the requirements.

4. Costs

Cost optimization is an important component in any organization, and it requires a good understanding of costs for the 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 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/(60×60) 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

Conclusion

Leveraging cloud services like AWS EKS provides flexibility to focus on workloads instead of infrastructure. Whether you choose Fargate or Managed Nodes depends on your specific needs for control, scalability, networking, and cost-efficiency.

Need help implementing EKS? Contact our AWS experts to request a consultation.