17-02-2025 / Cost Optimization Strategies / 9 mins.
Scaling Kubernetes clusters can be a complex process, involving multiple components such as networking, storage, worker nodes, and control planes. Maintaining high performance, low latency, and optimal throughput when scaling Kubernetes clusters requires efficient network configurations, load balancing, and proper resource allocation.
More importantly, inefficient scaling can lead to suboptimal resource utilization and unnecessary operational costs.
This is where Amazon Elastic Kubernetes Services (EKS) comes in — a managed AWS service that allows you to scale Kubernetes clusters without the need to manage them directly.
Let's dive deeper to better understand what EKS is and how it works.
What is Amazon EKS?
Amazon Elastic Kubernetes Services (EKS) is a managed service that allows users to run Kubernetes clusters on AWS without needing to install or maintain their own Kubernetes nodes or control planes. With EKS, AWS fully manages the scaling, deployment, and operations of your Kubernetes clusters, letting you focus on more important tasks, such as running your applications.
In essence, you get all the benefits of AWS infrastructure — such as scalability, reliability, and performance — with less operational overhead. It can also be integrated with AWS networking and security services, such as Application Load Balancers (ALB) and AWS Identity and Access Management (IAM).
EKS is designed to be highly secure, scalable, and available. It allows you to run Kubernetes applications on both AWS EC2 and AWS Fargate.
It is also worth noting that applications running on Amazon EKS are compatible with those running in standard Kubernetes environments. You can even migrate standard Kubernetes applications to Amazon EKS without any code changes.
How does EKS work?
EKS is considered AWS's solution for Kubernetes as a service, simplifying the management of Kubernetes clusters on AWS.
There are two main components in EKS:
- Master Nodes / Control PlaneThe control plane includes three Kubernetes master nodes running across different availability zones. All incoming traffic passes through a network load balancer to the control plane. It is important to note that AWS manages the control plane and it cannot be administered by your organization.
- Worker Nodes / Data PlaneWorker nodes are controlled and managed by your organization and run on AWS EC2 instances within the virtual private cloud (VPC).
While the control plane is responsible for managing and monitoring where and when containers are started, worker nodes run your organization's containers and are responsible for running the applications.
With Amazon EKS, you can:
- Automate the scaling of Kubernetes control plane instances based on load.
- Automatically detect and replace unhealthy control plane instances.
- Seamlessly run and scale the Kubernetes control plane across different availability zones.
- Use AWS architecture to ensure high availability.
- Integrate with AWS networking and security services such as ALBs, IAM, and Amazon VPC (which restricts traffic between control plane components within a single cluster, making EKS highly reliable).
- Run updated versions of Kubernetes to access the latest tools and add-ons.
What are the features of Amazon EKS?
Here are the key features of Amazon EKS:
- Fully managed Kubernetes: EKS is Kubernetes as a service. AWS manages the operations, deployment, and scaling of Kubernetes clusters on your behalf, saving time and reducing operational burden.
- High scalability and availability: EKS runs control plane instances across multiple availability zones, improving availability and reducing the risk of downtime. It also allows you to scale applications vertically or horizontally.
- High security: It offers security features such as integration with AWS Key Management, VPC isolation, and IAM roles for Kubernetes service accounts.
- Easy to use: Even if you are new to Kubernetes, EKS provides a straightforward interface for managing and deploying Kubernetes applications.
Understanding EKS Pricing and the Factors That Influence It
For every EKS cluster created, you pay $0.10 per hour. You can use a single EKS cluster to run multiple Kubernetes applications by leveraging IAM security policies and namespaces.
With Amazon EKS, you have the flexibility to run and scale Kubernetes applications both on-premises and in the cloud.
Costs depend on how you run Amazon EKS:
- Amazon EC2: You pay for the AWS resources used, such as EC2 instances and EBS volumes. There are no upfront commitments or minimum fees.
- AWS Fargate: Pricing is calculated based on the vCPU and memory resources used from the time the container image is pulled until the EKS instances are terminated.
- AWS Outposts: You pay $0.10 per hour per cluster, for both local and extended deployments. The EKS fee is charged in addition to the Outposts price.
Main Causes of Inefficient Spending in EKS
Underutilized or Over-Provisioned Resources
One of the most common cost issues in EKS is the underutilization and/or over-provisioning of resources allocated to EKS nodes.
When creating a non-Fargate cluster, we define the instance type that will be used to host the pods containing our application images, known as containers.
For those without experience, it might seem like a good idea to give nodes a "safety margin" by using an instance type with more resources than needed. However, this will inevitably generate unnecessary spending with no real benefit: if your application only requires a certain amount of resources, any surplus will incur unnecessary costs.
While opting for smaller instance types might seem like the solution, the savings gained could be offset by the impact on cluster performance. The key to running cost-optimized containerized workloads is finding the right balance.
To avoid this problem, there are several measures you can take:
- Cluster Autoscaler or Karpenter: these are excellent tools for controlling resource provisioning. Both work by scaling EKS nodes up or down based on available resources in a cluster. If the kube-scheduler is unable to start a pod, both tools detect this situation and add resources to the cluster to relieve the load. This makes it more viable to build clusters with smaller instance types, as these tools automate the creation of additional resources when cluster limits are reached.
- Limits and Requests:Limits and requests are also an important factor in cost optimization. By setting a request within a pod's spec, you tell the Kubernetes scheduler how many specific resources (CPU or memory) the pod is guaranteed to have. The scheduler uses this information to determine which node the pod should be placed on. A limit, on the other hand, is the total amount of resources a pod can consume. If a pod exceeds this limit, it may be evicted, terminated, or prevented from being scheduled. Limits and requests are an excellent way to ensure a predictable budget, improve cluster autoscaling, and optimize workload performance.
- Monitoring tools: Tools like CloudWatch are useful for gaining insight into the health of your cluster. You can use Container Insights to collect metrics and display them in the CloudWatch console, where you can then configure utilization-based alarms to ensure you are notified when certain thresholds are exceeded.
Data Transfer and Egress Costs
Egress and data transfer costs are widely misunderstood topics that significantly impact operational costs. These costs are associated with the movement of data into and out of EKS clusters, to other AWS services, the internet, or between AWS regions and availability zones.
- Be aware of the factors that affect these costs: Additional components such as NAT Gateways, AWS PrivateLink, and AWS Transit Gateway can generate additional charges depending on the type of data transferred.
- Understanding the implications of serving traffic externally is also crucial: A pod is exposed to the outside world using a service of type LoadBalancer, ClusterIP, or NodePort. Misconfigurations — such as using the wrong service type or causing traffic to communicate across availability zones — can be a costly mistake. Make sure you understand how your application is configured and the traffic patterns it will follow.
- Co-locate in the same pod whenever possible: As mentioned above, communication across availability zones incurs costs. Therefore, if you know that two containers need to communicate, assess whether it is feasible to host them in the same pod, as this ensures communication remains within the same availability zone.
Persistent Storage Costs
Persistent storage is typically achieved using Elastic Block Store (EBS). Within an EKS cluster, these volumes can be provisioned and attached to EKS EC2 nodes to ensure data persists beyond pod termination.
While EBS offers durability, scalability, and ease of use, it can also be a significant cost driver if not managed effectively.
Steps to Control These Costs
Understand how much space you need and the latest generations of volume types
Just like over-provisioning instances, EBS volumes can also be over-provisioned with too much space or unnecessary features.
Make sure you have a solid understanding of how much space you need, what newer generations of volume types are available (for example, gp2 vs. gp3), and whether you actually need to define IOPs.
Kubernetes uses objects called Storage Classes and Persistent Volumes to define how additional volumes are created. Familiarize yourself with the available options and annotations to optimize the creation and management of your storage.
- Implement an audit procedure: When resources that use EBS volumes are terminated, the associated volumes are sometimes not deleted — especially if the data is configured to persist. Make sure you have an audit procedure to identify when this occurs and a plan to delete these orphaned volumes.
- Use automation: If you use snapshots for your EBS volumes, use a tool like Amazon Data Lifecycle Manager (DLM) to automate the creation and deletion of EBS snapshots. Define policies that retain only the most recent snapshots and delete anything beyond a certain date.
How Frust Can Help You Reduce Your EKS Costs
Frust constantly analyzes the scaling of your EKS workloads to ensure the best price and stability. This allows you to obtain optimizations for your reserved instances, spot instances, and savings plans. We analyze your organization's usage and market pricing to ensure you are always using the best available options to save on AWS.
