Manu Shukla

Posted on Aug 22 Originally published at ecorpit.com

EKS control plane tuning shipped 12 August 2026 with four parameters and a $1.65/hr paywall

#aws #eks #kubernetes #finops

EKS control plane tuning shipped 12 August 2026 with four parameters and a $1.65/hr paywall

Summary. Amazon EKS opened Kubernetes control plane configuration on 12 August 2026. Four parameters, three components, Kubernetes 1.31 or later. Three of the four are free and work on a Standard control plane. The fourth, horizontalPodAutoscalerSyncPeriod, is the one the announcement leads with, and it requires Provisioned Control Plane, whose cheapest tier is $1.65 per hour on top of the $0.10 per hour cluster charge. That is a 17.5x jump in control plane cost to move a value from 15 seconds to 10. Setting it also locks the cluster out of Standard mode until you set it back. The announcement mentions none of this. And EKS does not validate the value against your HorizontalPodAutoscaler count, which the docs say degrades autoscaling "silently".

What shipped, exactly

The What's New post, dated 12 August 2026: "Amazon Elastic Kubernetes Service (Amazon EKS) now supports configuring parameters for Kubernetes control plane components including the scheduler, controller manager, and API server. You can tune pod placement strategies to improve resource utilization, adjust how quickly horizontal pod autoscaling responds to changes in demand, set resource lifecycle parameters such as event retention duration, and more."

"And more" is doing work. The user guide's master table lists four parameters and nothing else.

Component	Parameter	Supported values	Default	Provisioned Control Plane required
kube-scheduler	nodeResourcesFit.scoringStrategy	LeastAllocated, MostAllocated	LeastAllocated, cpu: 1, memory: 1	No
kube-controller-manager	horizontalPodAutoscalerSyncPeriod	10s to 15s	15s	Yes
kube-apiserver	eventTtl	10m to 60m	60m	No
kube-apiserver	serviceNodePortRange	minPort and maxPort between 10260 and 32767	30000 to 32767	No

Scoring weights run from 1 to 100 across cpu, memory, nvidia.com/gpu, aws.amazon.com/neuron and aws.amazon.com/neuroncore. The upstream RequestedToCapacityRatio strategy is not supported.

The version floor and the price both live in the user guide, not the announcement: "Advanced Kubernetes control plane configuration is supported on new and existing clusters running Kubernetes version 1.31 or later" and "There is no additional charge for configuring control plane parameters. Using horizontalPodAutoscalerSyncPeriod requires Provisioned Control Plane, which is billed at the hourly rate for your scaling tier."

The paywall on the headline feature

The announcement says you can "adjust how quickly horizontal pod autoscaling responds to changes in demand" and that the feature works "in any AWS Region where Amazon EKS is available". It does not say what that costs.

The user guide does: "The horizontalPodAutoscalerSyncPeriod parameter is only available on clusters using Amazon EKS Provisioned Control Plane... Setting this parameter on a cluster in Standard control plane mode fails."

Pulled from the AWS Price List API AmazonEKS offer file, publication date 4 August 2026, us-east-1:

Line item	Hourly rate	Monthly at 730 hours
EKS cluster, standard support	$0.10	$73
EKS cluster, extended support	$0.50	$365
Provisioned Control Plane, XL tier	$1.65	$1,204.50
Provisioned Control Plane, 2XL tier	$3.40	$2,482
Provisioned Control Plane, 4XL tier	$6.90	$5,037
Provisioned Control Plane, 8XL tier	$13.90	$10,147

The Provisioned Control Plane page confirms the tiers stack rather than replace: "You will be billed at the hourly rate for the Provisioned Control Plane scaling tier your cluster is on. This is in addition to the standard or extended support hourly charges."

So the cheapest legal way to run horizontalPodAutoscalerSyncPeriod at anything other than 15s is $1.75 per hour, against $0.10 for a Standard cluster. About $1,277 a month, or roughly Rs 1.1 lakh, per cluster, to change one duration by five seconds.

For most teams that is the wrong trade. If HPA reaction time is the bottleneck, the cheaper levers are the HPA object's own behavior.scaleUp stabilisation window and metric selection, which cost nothing. Provisioned Control Plane earns its price when you need the seat counts and pod-launch rates it buys, not when you need five seconds off a sync loop. The Kubernetes autoscaling patterns for AI inference apply here unchanged.

The lock-in nobody announced

From the control plane configuration page: "Exit restriction for HPA sync period — If horizontalPodAutoscalerSyncPeriod is set to a value other than the default, you can't move your cluster's control plane from Provisioned mode back to Standard mode. To return to Standard mode, first set this parameter back to the default of 15s, then change the control plane scaling tier to standard."

The Provisioned Control Plane page, which is where a FinOps engineer looking to downgrade would actually read, lists only one exit restriction: the 8 GB etcd size limit. It also states "There are no restrictions on how frequently you can switch between tiers." Someone reading that page alone will not learn a second exit lock now exists.

The reset problem compounds it: "Amazon EKS doesn't provide a dedicated reset operation, and omitting a field from an update leaves its current value in place rather than clearing it." You have to explicitly set 15s back. Dropping the field from your Terraform or CDK does nothing.

Silent failure is documented, and it is the real risk

The sharpest warning on the page is about the same parameter:

"Exceeding the supported count degrades autoscaling silently. If the controller can't work through every object within the period, some objects aren't reconciled on schedule. EKS doesn't emit an alarm or a Kubernetes event for this condition, and the symptom is autoscaling that responds more slowly than expected — the opposite of the intended effect. If you observe delayed scaling after shortening the sync period, return the parameter to the default of 15s."

And there is no guardrail: "EKS doesn't validate the sync period against your HPA object count. The configuration change succeeds even if your cluster already has more HorizontalPodAutoscaler objects than the shorter period supports. Verify the count yourself before making the change." The docs quantify the cost: "Reducing the period from 15s to 10s lowers the supported object count by roughly one third."

Concurrency by tier, from the Provisioned Control Plane page: XL supports 50 concurrent HPA syncs, 2XL 100, 4XL and 8XL 200 each. The upstream Kubernetes default is 5. Count your HPA objects before you touch this. If shortening the period pushes you past what the tier sustains, you pay $1.65 an hour to make autoscaling slower, with no signal that it happened.

Every change is a rolling control plane update

"A configuration change isn't in effect when UpdateClusterConfig returns. Amazon EKS applies the new configuration through a rolling update of your control plane, so expect several minutes before the change takes full effect. The cluster returns to ACTIVE status when the update completes."

Two of the four parameters carry one-way behaviour on top of that.

eventTtl deletes data you cannot get back: "Deleted events can't be recovered. After Kubernetes removes an event, it's gone permanently." Changes are not retroactive either — "Events that already exist keep the retention period that was in effect at their creation" — and expiry is approximate, because "an event's expiry can be extended past the value you configured because of etcd lease renewal that might happen during control plane leader election."

serviceNodePortRange breaks on redeploy rather than on change: "Recreating a service reallocates its port. If a service holding an out-of-range port is deleted and recreated, that port can no longer be assigned." And statically pinned ports are validated too: "A static port request outside the range is rejected, even if the same port was valid under a wider range you configured previously." A narrowed range therefore survives until your next blue-green deploy, then fails.

The bounds have reasons: 10260 "keeps NodePort allocation clear of ports that Kubernetes system components on your nodes already use, including the kubelet health port (10248) and the kube-proxy health check port (10256)", and 32767 "keeps the range clear of the Linux ephemeral port range, which typically begins at 32768."

Nothing here can be scoped: "Advanced control plane parameters apply to the entire cluster and to all workloads running on it. You can't scope them to individual namespaces or workloads."

Where the docs disagree with themselves

eksctl support. The user guide says "available through the AWS Management Console, eksctl, AWS CLI, Amazon EKS API, AWS CloudFormation, and AWS CDK at launch. Support for AWS Controllers for Kubernetes (ACK), and Terraform is coming soon." The AWS containers blog, published the same day, says "with support for eksctl, AWS Controllers for Kubernetes (ACK), and Terraform planned" and does not mention CDK at all. Two AWS pages, same launch, opposite claims about eksctl.

Value ranges. The API reference for HorizontalPodAutoscalerControllerConfigRequest states: "Valid values are single-unit durations such as 15s or 1m." One minute is four times the user guide's documented maximum of 15s. The API reference publishes no minimum or maximum at all. The same pattern repeats for eventTtl, where the API reference offers "30m or 1h" against a user guide ceiling of 60m.

Prerequisites. The blog requires "An Amazon EKS Auto Mode cluster running Kubernetes version 1.31 or later." The user guide requires only "An Amazon EKS cluster running Kubernetes version 1.31 or later." Auto Mode is not a documented prerequisite anywhere in the user guide.

Hidden per-tier overrides. DescribeClusterVersions nests a controlPlaneComponentConfigOverrides object inside each entry of controlPlaneScalingTiers, carrying its own constraints and defaults per parameter. The string "override" does not appear once in the user guide's control plane configuration pages. Both user guide tables present one flat set of bounds with no hint they can vary by Provisioned tier. AWS's own instruction is to treat the API as authoritative: use DescribeClusterVersions "as the source of truth if you manage clusters across several versions or automate cluster configuration."

A stale figure. The Provisioned Control Plane page's prose says "a 4XL tier configures API Priority and Fairness (APF) with 6,800 concurrent request seats". Its own table for EKS v1.34 and later puts 4XL at 8,000. The 6,800 number is the v1.30 to v1.33 value, quoted without qualification.

There is also a coverage gap. The EKS Best Practices Guide pages that own control plane scaling contain zero occurrences of eventTtl, serviceNodePortRange, MostAllocated, scoringStrategy, horizontalPodAutoscalerSyncPeriod, kubeApiServerConfig or kubeSchedulerConfig. The user guide tells you to tune these for etcd pressure; the scaling guide it links to does not know they exist.

How to set them

Each component takes its own flag with inline JSON:

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

The flags are --kube-scheduler-config, --kube-controller-manager-config and --kube-api-server-config; UpdateClusterConfig accepts the matching kubeSchedulerConfig, kubeControllerManagerConfig and kubeApiServerConfig fields. The returned update object carries "type": "ControlPlaneComponentConfigUpdate".

One caution on verification. The user guide claims describe-cluster "returns the complete configuration running on your control plane, including parameters you haven't customized and their default values". The worked example in the getting-started guide returns {"nodeResourcesFit": {"scoringStrategy": {"type": "LeastAllocated"}}} with no resources array, even though the documented default includes cpu: 1 and memory: 1. Do not treat an absent field in describe-cluster as proof a default is unset.

What to do

Take the three free parameters first. MostAllocated scoring is the one with a real bin-packing payoff on GPU and Neuron fleets, it costs nothing, and it works on a Standard control plane. Shorten eventTtl only if etcd pressure is measured, and remember the change is irreversible for events already deleted. Narrow serviceNodePortRange before you have services pinned inside the old range, not after.

Leave horizontalPodAutoscalerSyncPeriod alone unless you are already on Provisioned Control Plane for capacity reasons. Count your HPA objects against your tier's concurrency first. Read DescribeClusterVersions rather than the user guide table if you run more than one cluster version, because the per-tier overrides are real and undocumented. And if you are still on a version below 1.31, none of this is available to you — our note on the EKS 1.33 standard support end date and upgrade cost sets out that path.

FAQ

How many control plane parameters can I configure in EKS?

Four, across three components. The scheduler's nodeResourcesFit scoring strategy, the controller manager's horizontal pod autoscaler sync period, and the API server's event TTL and service NodePort range. The AWS blog describes this as the initial set chosen from customer requests, so more may follow.

Does control plane configuration cost anything?

Three of the four parameters are free on a Standard control plane. The horizontal pod autoscaler sync period requires Provisioned Control Plane, whose cheapest XL tier is $1.65 per hour in N. Virginia on top of the $0.10 per hour cluster charge, taking a cluster from roughly $73 to about $1,277 per month.

What happens if I shorten the HPA sync period past what my cluster supports?

Autoscaling degrades without any signal. AWS states that EKS emits no alarm and no Kubernetes event, and the symptom is slower scaling than before the change. EKS does not validate the value against your HorizontalPodAutoscaler count, and moving from 15s to 10s cuts the supported object count by roughly one third.

Can I move back to Standard control plane mode afterwards?

Only after resetting the parameter. If horizontalPodAutoscalerSyncPeriod holds any non-default value, the cluster cannot leave Provisioned mode. Set it back to 15s first, then change the scaling tier. There is no reset operation, so omitting the field from an update leaves the current value in place.

Is shortening eventTtl reversible?

The setting is, the data is not. AWS states that once Kubernetes removes an event it is gone permanently. A change applies only to events created afterwards, because expiry is fixed at creation time, and existing events keep the retention period in force when they were written.

Which Kubernetes versions support this?

Version 1.31 and later, on both new and existing clusters. The version floor appears in the EKS User Guide but not in the 12 August 2026 announcement, which says only that the feature works in any Region where Amazon EKS is available.

Can I apply these settings to one namespace only?

No. The user guide states the parameters apply to the entire cluster and every workload on it, and cannot be scoped to individual namespaces or workloads. That restriction is repeated separately for the sync period, the event TTL and the NodePort range.

Does eksctl support this at launch?

The two AWS sources disagree. The EKS User Guide lists eksctl among the tools supported at launch alongside the console, CLI, API, CloudFormation and CDK. The AWS containers blog published the same day lists eksctl as planned rather than shipped. Verify against your installed eksctl version before relying on it.

How eCorpIT can help

Our senior engineering teams run EKS platform reviews covering control plane sizing, autoscaling behaviour and the cost trade-offs described above, including whether a Provisioned Control Plane tier is justified by workload rather than by one parameter. That work sits alongside our managed Kubernetes AI platform service and our analysis of EKS cluster CA rotation. eCorpIT is CMMI Level 5, MSME Certified and ISO 27001:2022 certified. Talk to us via /contact-us/.

References

Last updated: 22 August 2026.

DEV Community

EKS control plane tuning shipped 12 August 2026 with four parameters and a $1.65/hr paywall

EKS control plane tuning shipped 12 August 2026 with four parameters and a $1.65/hr paywall

What shipped, exactly

The paywall on the headline feature

The lock-in nobody announced

Silent failure is documented, and it is the real risk

Every change is a rolling control plane update

Where the docs disagree with themselves

How to set them

What to do

FAQ

How eCorpIT can help

References

Top comments (0)