Introduction

One of the main perks of Amazon EKS is that AWS manages the Kubernetes control plane for you.

You do not have to operate components like the API server, scheduler, or controller manager yourself.

The trade-off has traditionally been less control over some Kubernetes settings that you can modify in a self-managed cluster.

That is now changing.

With advanced Kubernetes control plane configuration, EKS allows you to customize selected parameters for the scheduler, controller manager, and API server, while AWS continues to manage the underlying control plane.

Let's look at what this means in practice.

More control over pod placement

The Kubernetes scheduler decides which node should run each pod.
By default, the NodeResourcesFit plugin uses the LeastAllocated strategy. It favors nodes with more available resources, which generally spreads workloads across the cluster.

This is a good default when you want to keep capacity distributed across your nodes. But what if you want to make better use of the nodes you already have?

This is where MostAllocated becomes interesting.

In place of spreading workloads, MostAllocated favors nodes that are already more heavily used.
This pushes Kubernetes to pack workloads onto fewer nodes when possible.

For example:

LeastAllocated:

Node 1: 40%
Node 2: 35%
Node 3: 30%

MostAllocated:

Node 1: 85%
Node 2: 80%
Node 3: 10%`

The second approach can improve resource consumption and leave some nodes with little or no workload.
This can be particularly useful with node provisioning and consolidation tools like Karpenter or EKS Auto Mode.

There is an important distinction, though: MostAllocated only affects pod placement. It does not provision or delete nodes. Node provisioning and consolidation are separate processes.

Configuring MostAllocated in EKS

In a self-managed Kubernetes cluster, you would configure the scheduler yourself using a KubeSchedulerConfiguration configuration file:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
 - pluginConfig:
 - name: NodeResourcesFit
 args:
 scoringStrategy:
 type: MostAllocated

With EKS, you do not need to operate the scheduler or manage this configuration file. You can configure the supported parameter via the EKS API.

For example, using the AWS CLI:

aws eks update-cluster-config \
 --name production-cluster \
 --kube-scheduler-config \
 '{"nodeResourcesFit":{"scoringStrategy":{"type":"MostAllocated"}}}'

This is a nice example of the flexibility this feature adds. You can influence Kubernetes behavior while keeping the main benefit of EKS: AWS still manages the control plane for you.

Other settings you can modify

MostAllocated is only one example. EKS also exposes few other settings for other control plane components.

For example, you can configure Kubernetes event retention via the API server:

aws eks update-cluster-config \
 --name production-cluster \
 --kube-api-server-config \
 '{"eventTtl":"30m"}'

You can also alter the Horizontal Pod Autoscaler synchronization period:

aws eks update-cluster-config \
 --name production-cluster \
 --kube-controller-manager-config \
 '{"horizontalPodAutoscalerControllerConfig":{"horizontalPodAutoscalerSyncPeriod":"10s"}}'

Other supported options include the NodePort range and additional scheduler settings.

The exact parameters available depend on the EKS configuration and Kubernetes version.
Some settings also have additional requirements, like EKS Provisioned Control Plane.

What should you consider?

These settings impact cluster-wide behavior, so it makes sense testing them before applying them to production.

For example, MostAllocated can improve node utilization, but workloads that need spare capacity for sudden traffic increases may benefit more from the default LeastAllocated strategy.

It is also important to remember that scheduler behavior and node autoscaling are separate.

Changing where pods are placed does not automatically reduce infrastructure costs. The actual result depends on your workloads, resource requests, and how your node provisioning or consolidation system responds.

The best approach is simple: start with a real problem, change one setting, and measure the result.

Conclusion

What makes this feature amazing is not simply that EKS exposes more Kubernetes parameters. It is that you can now tweak selected control plane behaviors without taking on the responsibility of managing the control plane yourself.

The Kubernetes defaults are still a good starting point for most clusters and use cases. But when those defaults do not really fit your needs, having this extra level of control can make a real difference.

Happy shipping!

Thank You 🖤

Until next time, keep innovating and securing your cloud journey!

💡 Thank you for reading!

Until next time, つづく 🎉

🙌🏻😁📃 see you in the next blog.🤘

🚀 Thank you for sticking up till the end. If you have any questions/feedback regarding this blog feel free to connect with me:

♻️ LinkedIn: https://www.linkedin.com/in/rajhi-saif/

♻️ X: https://x.com/rajhisaifeddine

The end ✌🏻

🔰 Keep Learning !! Keep Sharing !! 🔰

📅 Stay updated

Subscribe to our newsletter for more insights on AWS cloud computing and containers.