Amazon EKS 24 GB etcd: Eligible Tiers, Costs and Downgrade Limits

Check the version, tier and Region together

This capacity increase applies to the 4XL and 8XL Provisioned Control Plane tiers on EKS 1.34 or later. AWS says existing clusters meeting those conditions automatically receive 24 GB instead of 16 GB, with no action required. Using EKS alone does not establish eligibility for 24 GB.

The announcement confirms the larger database in all AWS commercial Regions where Provisioned Control Plane is available. The user guide lists broader support for the overall Provisioned feature, including GovCloud and China Regions and EKS versions starting at 1.28. That broader feature support does not extend the Region or version claims in this particular 24 GB announcement.

What does the extra database capacity hold?

etcd is the Kubernetes control plane’s key-value database for cluster state: it stores information about objects such as Pods, Jobs, events and custom resources. AI/ML training and inference, batch processing and CI/CD pipelines that create or update many objects may need to pay particular attention to this space. AWS says a full database prevents the cluster from adding or changing objects.

Moving from 16 GB to 24 GB provides 50% more database headroom. It does not expand worker disks, persistent volumes or an application database. Nor does it establish a 50% gain in scheduling speed, API throughput or application performance; the user guide also distinguishes tier capacity from actual workload performance.

Choose the next step for your current mode

If the cluster already uses 4XL or 8XL on an eligible version, check the current version, control plane mode and tier in the EKS console, then observe database usage. The automatic capacity increase does not require selecting the tier again. You can also inspect the current tier through the read-only describe-cluster command or the corresponding API. No real cluster operation was performed for this article.

If the cluster uses Standard, AWS will not automatically move it to a higher-priced Provisioned mode. Standard scales control plane capacity with demand and remains AWS’s recommendation for the vast majority of use cases. Evaluate an explicit move to Provisioned only when the workload needs high, predictable control plane capacity.

If the cluster uses a different Provisioned tier, tiers do not scale automatically either. To obtain 24 GB, first verify the EKS version and Region requirements, then have an authorized administrator evaluate a move to 4XL or 8XL. The announcement does not upgrade every tier automatically.

Include the additional hourly charge in the decision

Provisioned Control Plane has an hourly charge for the selected tier, in addition to standard or extended-support EKS hourly charges. This announcement does not make the cluster free or remove the additional budget needed to move from Standard to 4XL or 8XL.

The reviewed announcement and guide do not supply Region-specific numeric rates suitable for a budget. Before switching, check current pricing for the destination Region, tier and actual support status. Do not estimate the bill from the percentage increase in capacity or interpret “no action required” for existing eligible clusters as a waiver of charges for every use case.

Plan the exit before using the extra space

Moving to a smaller Provisioned tier or back to Standard requires the actual etcd database to fit the destination limit. The guide lists up to 8 GB for Standard. On EKS 1.34 and later, XL and 2XL support up to 16 GB, while 4XL and 8XL support up to 24 GB. All Provisioned tiers on earlier versions support up to 16 GB.

AWS gives a concrete example: a 4XL cluster with a 20 GB database must reduce it below 16 GB before moving to XL or 2XL, or below 8 GB before returning to Standard. Once used, the extra headroom affects the exit path. A cheaper destination does not mean the cluster can switch to it immediately.

This article does not recommend directly deleting production objects to meet a downgrade threshold. First identify the objects and retention requirements behind the usage, then plan capacity changes through the existing change process. A documented capacity limit does not establish that a particular cleanup action is safe.

Verify actual usage and the update outcome

From the cluster overview in the EKS console, choose Monitor cluster, then Control plane monitoring, and inspect utilization under Control plane scaling. Compare actual database size with the limit for the cluster’s version and tier, keeping used space distinct from allowed capacity. For automated comparisons of tier attributes across versions, the guide provides the DescribeClusterVersions API as a query interface.

When explicitly changing tiers, inspect the cluster update of type ScalingTierConfigUpdate. Updating means it is in progress, Successful means it completed, and Failed requires checking the error field. The guide says a tier change takes several minutes; submitting a request or clicking a console control does not mean the change has completed.

This article verifies public documentation, not a real cluster’s capacity rollout time, load performance or cost outcome. Use the target cluster’s actual version, Region, tier, database usage and update status for the final check.