On this page · 11 sections
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 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.
