EKS raised the OIDC provider cap to 10 on 24 August 2026, but only above Kubernetes 1.32

Summary. On 24 August 2026 AWS announced that Amazon EKS supports up to 10 external OpenID Connect identity providers per cluster, at no additional cost, in every Region where EKS runs. The Amazon EKS User Guide adds two limits the announcement leaves out: the cap of 10 applies only to clusters on Kubernetes 1.32 or later, and the combined size of all OIDC provider configurations on a cluster must stay under 12 KB. Clusters below 1.32 still get exactly one provider. Kubernetes 1.32 left EKS standard support on 23 March 2026, so the oldest cluster version that can hold 10 providers is already billing at the extended-support rate of $0.60 per cluster hour instead of $0.10. That is a difference of $365 per cluster per month on a 730-hour month.

What AWS actually announced

The AWS What's New post, dated 24 August 2026, is short. It says you "can associate up to 10 OIDC identity providers with a single cluster," names employees, contractors and CI/CD systems as the populations this is meant to separate, and states that existing IAM authentication keeps working alongside every configured provider. Providers are added through the console or the AssociateIdentityProviderConfig API. The post closes with the availability line: "available at no additional cost in all AWS Regions where Amazon EKS is available."

Nothing in that post is wrong. It is just incomplete in the two places that decide whether you can use the feature this quarter.

The version floor the announcement omits

The Amazon EKS User Guide page for external OIDC providers states the constraint plainly: "The number of OIDC identity providers you can associate with a cluster depends on the cluster's Kubernetes version. On clusters running Kubernetes version 1.32 or later, you can associate up to 10 OIDC identity providers. The combined size of all OIDC provider configurations must be less than 12 KB. On clusters running a version earlier than 1.32, you can associate only one OIDC identity provider."

That single sentence changes who the feature is for. Match it against the EKS Kubernetes version lifecycle and the picture is uncomfortable for anyone running an older control plane.

Kubernetes 1.31 is the awkward row. It is still a supported EKS version, it is still accepting clusters, and it is already paying the extended-support premium. It also cannot hold more than one external OIDC provider. Its extended support ends on 26 November 2026, which is 94 days from the date of the announcement. A team on 1.31 that wants separate identity providers for staff and for contractors has to complete a minor-version upgrade first, and it has under a hundred days before the version auto-upgrades anyway.

The rates come from the Amazon EKS pricing page, which states $0.10 per hour for a cluster on a version in standard support and $0.60 per hour once the version enters extended support, for up to 26 months from general availability on EKS. On a 730-hour month that is $73.00 against $438.00 per cluster. The gap is $365.00 per cluster per month, and it applies to two of the four version rows that can actually use the new cap.

The plain reading: the cheapest cluster version that can hold 10 OIDC providers at the standard rate is 1.34, which itself leaves standard support on 2 December 2026.

The 12 KB ceiling, and the arithmetic that does not close

The 12 KB figure is the second omission, and it is the one that will surprise people who plan for 10 providers and then find out what a provider configuration weighs.

Twelve kilobytes divided across 10 providers leaves about 1,228 bytes for each one. A minimal configuration is small: name, type, issuer URL, client ID. The size comes from the optional fields, above all requiredClaims, the map of claim names to values that every presented token must match.

The AssociateIdentityProviderConfig API reference sets the per-request limits on that map: a maximum of 50 entries, keys between 1 and 128 characters, values up to 256 characters. Take those maxima literally and one provider's requiredClaims map alone can reach 50 x (128 + 256) = 19,200 characters, or roughly 18.75 KB. That is more than the entire 12 KB budget the user guide allots to all 10 providers combined.

The two documents are not contradicting each other on purpose. The API reference describes what a single request will accept; the user guide describes what the cluster will hold. But an engineer reading only the API reference can build a configuration the API validates and the cluster refuses. Where the two pages disagree, size your configuration against the smaller number.

The practical rule is to treat 12 KB as a cluster-wide budget and to trim requiredClaims to the claims you actually enforce, rather than mirroring your identity provider's full claim set into EKS.

Ten providers means ten cluster updates

The user guide is explicit that "associating an OIDC identity provider is a cluster update. The cluster enters the UPDATING state, and the change can take several minutes to be fully applied to the cluster's API servers." Progress is tracked with the DescribeUpdate operation.

Read that as a rollout constraint rather than a footnote. Onboarding a full set of providers is a sequence of control plane updates, each taking minutes to propagate to the API servers, not a single declarative apply. If your change process requires a maintenance window for control plane updates, the number of windows scales with the number of providers. Teams that treat control plane changes as routine will not notice; teams with a change-approval board will.

Two smaller constraints sit alongside it, and both restrict the exact scenario the announcement advertises:

The issuer URL and the provider name must each be unique across all providers on the cluster, and the same provider cannot be associated twice. If your employees, your contractors and your CI/CD runners all authenticate against a single identity tenant with different client IDs, you cannot register that one issuer three times. Separate populations require separate issuers, not separate audiences on a shared issuer.

The issuer URL must be publicly reachable so that EKS can fetch the signing keys, and EKS does not support providers with self-signed certificates. Clusters using customer-routed control plane egress (controlPlaneEgressMode=CUSTOMER_ROUTED) have to make the issuer endpoint reachable through the configured egress path, which is a VPC routing task, not an identity task.

The cap is not a Service Quota

There is a quiet detail worth checking before anyone opens a support case asking for more than 10.

The AWS General Reference quota table for Amazon EKS lists nine cluster-scoped and account-scoped quotas: access entries per cluster, clusters per Region, control plane security groups per cluster, Fargate profiles per cluster, managed node groups per cluster, public endpoint access CIDR ranges per cluster, registered clusters, remote node networks per cluster and remote pod networks per cluster. There is no entry for OIDC identity provider configurations. The EKS service quotas page likewise routes readers to that table.

A limit absent from Service Quotas is not adjustable through the Service Quotas console or a quota-increase request. Plan for 10 as a fixed number.

What upstream Kubernetes allows, for comparison

The gap between EKS and upstream is wide enough to be worth stating. Structured authentication configuration reached stable in Kubernetes v1.34 and is enabled by default. The Kubernetes authentication reference describes it as the mechanism that "allows you to configure multiple JWT authenticators," and the annotated example in that page carries the comment that "the maximum number of allowed authenticators is 64."

EKS sits at roughly one sixth of the upstream authenticator ceiling and does not expose the CEL-based claim validation rules that upstream offers. On a managed control plane you do not pass --authentication-config to the API server yourself, so the EKS-shaped API is the whole surface. That is the trade for not running the control plane.

Who this changes something for

Check three things in order. If all three are true, the announcement is directly useful this week.

Your cluster runs Kubernetes 1.32 or later. Run aws eks describe-cluster-versions to confirm what is available and where your cluster sits. If you are below 1.32, the version upgrade is the project, not the identity work. Our note on EKS 1.33 standard support ending and the upgrade path cost covers how those upgrade windows tend to be scoped.

Your populations authenticate against genuinely distinct issuers. One corporate tenant serving staff, contractors and pipelines through different client IDs does not qualify, because the issuer URL must be unique per provider.

You still need IAM. It cannot be disabled, because nodes join the cluster through it, and the cluster itself must be created by an IAM principal rather than an OIDC user. Users authenticated through an external OIDC provider also cannot sign in to the AWS Management Console or view Kubernetes resources there. Console access stays an IAM story.

For CI/CD in particular, the honest question is whether a cluster-attached OIDC provider is the right shape at all when the alternative is short-lived workload identity. The same short-lived-token argument has been playing out in package publishing, which we looked at in our piece on npm OIDC trusted publishing.

India-specific considerations

Indian teams running EKS in ap-south-1 or ap-south-2 get the feature at the same time and the same price as everywhere else, since it is Region-agnostic. The interesting constraint is local: the issuer URL has to be publicly reachable from the EKS control plane, which rules out an identity provider that only answers inside a private network or behind a VPN. Organisations that keep their identity provider entirely on-premises in India, a common pattern in BFSI, will need a publicly resolvable, properly certificated issuer endpoint before any of this applies.

Under the Digital Personal Data Protection Act, 2023, mapping contractor and vendor identities into a production cluster is a processing decision worth writing down. Each provider carries its own username and group prefixes, so the audit trail in CloudWatch control plane logs will distinguish the populations if, and only if, the prefixes are set deliberately at association time. Setting them later means a second cluster update.

What is still unknown

Three things the published documentation does not answer.

Whether the 12 KB ceiling counts the serialised configuration or the raw field values is not stated, so a configuration close to the line may behave differently from the arithmetic.

Whether AWS intends to raise 10 towards the upstream 64 is not signalled anywhere in the announcement or the user guide, and the absence of a Service Quotas entry suggests it is not currently treated as a tunable.

Whether clusters below 1.32 will ever receive the higher cap is not addressed. Given that 1.31 exits extended support on 26 November 2026, the practical answer is likely no.

How eCorpIT can help

We run AWS platform work for teams whose Kubernetes upgrade backlog and identity backlog have become the same project. That usually means sequencing the control plane upgrade first, then the provider associations, with the cluster update windows planned rather than discovered. If you are on a version below 1.32 and paying the extended-support rate, ask our AWS platform team for an upgrade and identity review and we will map the version path against your change windows. eCorpIT is ISO 27001:2022 certified and CMMI Level 5 appraised.

FAQ

References

1. Amazon EKS now supports multiple external OIDC identity providers per cluster, AWS What's New, 24 August 2026

1. Grant users access to Kubernetes with an external OIDC provider, Amazon EKS User Guide

1. Understand the Kubernetes version lifecycle on EKS, Amazon EKS User Guide

1. Review release notes for Kubernetes versions on standard support, Amazon EKS User Guide

1. Amazon EKS pricing

1. AssociateIdentityProviderConfig, Amazon EKS API Reference

1. DescribeUpdate, Amazon EKS API Reference

1. View and manage Amazon EKS and Fargate service quotas, Amazon EKS User Guide

1. Amazon Elastic Kubernetes Service endpoints and quotas, AWS General Reference

1. Authenticating, Kubernetes documentation

1. Using RBAC Authorization, Kubernetes documentation

1. Configuring control plane egress routing, Amazon EKS User Guide

Last updated: 25 August 2026.