Comparison between EKS-Fargate and EKS-EC2

Elastic Kubernetes Service (EKS): EKS is a container deployment service based
on open-source Kubernetes. You could also call it a Kubernetes distribution or
Kubernetes-as-a-Service.

EKS Fargate and EKS EC2 are two deployment options for running containerized
applications on Amazon Elastic Kubernetes Service (EKS).

Before proceeding the comparison between EKS-Fargate and EKs-EC2 lets look
individually

EKS-Fargate

Fargate is AWS serverless compute engine for running containers. It is supported by
Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service
(EKS).

The primary aim of Fargate is to remove the necessary overhead in managing your
own EC2 worker nodes. Users focus on container images and deployments, while
AWS handles infrastructure provisioning and scaling.
Even though Fargate manages the infrastructure, your application still runs in pods.
You define your application using deployment manifests that describe the desired
state of your pods (container image, resource requests, replicas). Fargate translates
these manifests into pod specs and launches them based on your configuration.

Main benefits of EKS-Fargate

Main benefit is not eliminating the need to provision, patch, scale, and secure EC2
instances architecture you still need VPC architecture. There are further benefits
such as

1. Automatic Scaling – Fargate automatically scales pod resources based on your defined requests and limits. You only pay for the resources your containers use. You have unlimited compute and don’t have to worry about scaling EC2 nodes.
2. Faster deployment – Fargate enable faster deployment, rollouts and eliminates the need to wait for EC2 instance to spin up.
3. Pay-Per-Use – You only pay for the resources your containers use, eliminating the need to manage idle EC2 instances and reducing costs for applications with fluctuating resource needs.
4. Right-Sizing – AWS Fargate matches your workloads requirements with a set of pre-configured CPU & Memory based price points.
5. Secure isolation by design – Individual EKS pods each run in their own dedicated kernel runtime environment and do not share resources with any other pod.
6. Security – AWS manages the security of the underlying infrastructure. Users are responsible for container image security and pod configurations. Offers potential benefits due to reduced user interaction with the underlying infrastructure.

EKS-EC2

EKS EC2 is User-managed approach. Requires managing EC2 instances as worker
nodes in your Kubernetes cluster. You’re responsible for provisioning, patching,
scaling, and securing the EC2 instances.

You need to pay for the underlying EC2 instances used by your Kubernetes cluster.
Costs include instance type, usage hours, and any additional AWS services used.
Requires upfront configuration for instance size and scaling strategies.

Users have complete control over the security of the EC2 instances and Kubernetes
cluster configuration. Requires a deeper understanding of security best practices in
the context of container orchestration and underlying infrastructure.

You need to manually scale the number of EC2 instances in your cluster to meet
your application’s resource needs. This can be time-consuming and requires
additional configuration.

Let’s compare EKS Fargate and EKS EC2 with respect to Node, Pod ad kubectl
command

You can use many of the same kubectl commands in EKS Fargate as you can in
EKS with EC2 for interacting with your Kubernetes cluster and managing your
application deployments.

Unlike EKS with EC2, Fargate doesn’t utilize traditional Kubernetes worker nodes.
Fargate manages the underlying infrastructure itself, so you don’t need to provision
or manage EC2 instances

Even though Fargate manages the infrastructure, your application still runs in pods.
You define your application using deployment manifests that describe the desired
state of your pods (container image, resource requests, replicas). Fargate translates
these manifests into pod specs and launches them based on your configuration.

• Pods are still the fundamental unit of deployment in both EKS Fargate and EKS with EC2.
• The key difference lies in how the infrastructure for running those pods is managed:
  • EC2: You manage the worker nodes (EC2 instances) yourself.
  • Fargate: Fargate takes care of infrastructure provisioning and management, eliminating the need for you to manage worker nodes directly.

Table summarizes the difference

Differences:

• Node Management: Since Fargate manages the underlying infrastructure, commands related to node management (e.g., kubectl get nodes, kubectl drain node <node-name>) won’t be applicable in a Fargate cluster.
• Pod Management: While you can view pod information with kubectl get pods, you have less direct control over individual pods in Fargate compared to EC2. Fargate manages the lifecycle of pods based on your deployment configuration.
• Limited Pod Interaction: Due to Fargate managing the infrastructure, some kubectl commands for directly manipulating pods (e.g., kubectl exec, kubectl delete pod) might not be as effective or necessary.
• Focus on Deployments: In Fargate, the focus for managing application lifecycles shifts towards deployments. You define the desired state of your pods in deployments, and Fargate ensures that state is maintained.
• Management: With EC2, you manage both pods (application deployment) and the underlying worker nodes (EC2 instances). Fargate handles infrastructure management, letting you focus on pods and application configuration.
• Visibility: In EC2, you can interact with worker nodes using kubectl. With Fargate, you primarily interact with pods, and Fargate manages the lifecycle of the underlying infrastructure for those pods.

Let’s compare the pricing of EKS-EC2 and EKS-Fargate

EKS Fargate pricing is primarily based on two factors:

• vCPU (virtual CPU) consumption: This refers to the amount of processing
  power allocated to your containerized applications running on Fargate. The
  more vCPU resources your pods require, the higher the cost will be.
• Memory consumption (GB): This refers to the amount of RAM allocated to
  your pods. Similar to vCPU, the more memory your pods utilize, the higher the cost will be.

Other dimensions that affect the fargate pricing are

1. Operating System
2. CPU Architecture
3. Storage Resources for the Task or Pod

For linux/X86

per vCPU per hour $0.04048
per GB per hour $0.004445
For linux/ARM
per vCPU per hour $0.03238
per GB per hour $0.00356
For window/X86
per vCPU per hour $0.046552
OS license fee – per vCPU per hour $0.046
per GB per hour $0.00511175
So, for example, let’s say we have a pod being deployed to Kubernetes that has the
following configuration:

EKS-Fargate

1 vCPU and 2 GB memory per pod. It runs for 10 hours per day.

• Using Fargate pricing calculator (https://aws.amazon.com/fargate/pricing/), the estimated cost per pod per hour is around $0.024.
• For 10 hours with average resource consumption, the cost per pod would be: $0.024/pod/hour * 10 hours = $0.24/pod
• If you have 5 pods running, the total daily cost for Fargate would be: $0.24/pod * 5 pods = $1.2

EKS with EC2:

The application runs on a t3.medium EC2 instance (2 vCPU, 4 GB memory) with an
average utilization of 50% CPU and 75% memory. It runs for 10 hours per day.

• On-demand pricing for t3.medium instance is around $0.098 per hour
  (https://aws.amazon.com/ec2/pricing/on-demand/).
• Daily cost for the EC2 instance: $0.098/hour * 10 hours = $0.98.
• In this example, even with moderate resource needs and some idle time, EKS Fargate might result in slightly higher costs ($1.2) compared to a continuously running t3.medium EC2 instance ($0.98).
• If you’re taking advantage of EC2 spot (Currently there is no support for AWS EKS Fargate Spot – Only ECS),the EC2 is cheaper compared to Fargate, Since there is no support for EKS Fargate Spot pricing yet , the spot seems to be the primary cost factor when comparing the services.

Both EC2 and Fargate workloads can be made even cheaper by applying AWS
Savings Plans.
Here’s why considering Fargate can still be cost-effective in many scenarios:

• No management overhead: You save time and resources on managing EC2 instances (patching, scaling, etc.).
• Automatic scaling: Fargate automatically scales pods based on needs, ensuring you only pay for used resources. This can be particularly beneficial for applications with fluctuating workloads.
• Reduced idle costs: With Fargate, you don’t pay for EC2 instances when your application is not.
• Choose Fargate for: running.
  • Applications with variable resource needs.
  • Focus on simplicity and reduced management overhead.
  • Willingness to potentially pay a slight premium for automatic scaling and serverless benefits.
• Choose EC2 for:
  • Applications with predictable resource needs.
  • Cost optimization as a top priority and the ability to leverage Spot or Reserved Instances for significant savings.
  • More control over the underlying infrastructure.

Fargate for the win! Are there any drawbacks?

AWS Fargate was initially deployed in November 2017, and whilst there have been
many improvements, there are still some fundamental limitations when it comes to
combining EKS with Fargate.

1. Without EKS Fargate Spot, EC2 is cheaper.
2. Daemonsets are not supported on Fargate. This means you will need to re-
   engineer solutions (such as pre-made HELM charts) to use sidecars in your
   containers instead.
3. Privileged containers are not supported (although this is generally best practice)
4. GPUs are currently not available in Fargate.
5. Only Private Subnets are supported (generally best practice)

AWS Container Insights is currently unsupported on EKS Fargate

By understanding these pricing differences and considering your application’s
resource needs and priorities, you can make an informed decision about the most
cost-effective approach for deploying your applications on EKS.

Choosing the Right Approach:

The best approach depends on your specific needs and priorities. Consider the
following factors:

• Focus: If minimizing management overhead and serverless simplicity are priorities, Fargate might be suitable.
• Cost: If cost optimization is a major concern and your workloads have predictable resource needs, consider EKS with EC2 instances and explore options like Spot or Reserved Instances.
• Control: If you need more granular control over the underlying infrastructure, EKS with EC2 offers greater flexibility.
• Scalability: Both Fargate and EC2 can scale, but Fargate offers automatic scaling based on resource requests/limits.

By understanding these differences, you can make an informed decision about
whether EKS Fargate or EKS with EC2 is the right approach for deploying your
containerized applications on AWS.