Amazon EKS now supports multiple external OIDC providers per cluster

Amazon just handed platform teams a new identity surface — and it's going to change how you partition trust in clusters. EKS now supports multiple external OIDC identity providers per cluster (public reporting shows higher caps), which means you no longer need to cram many teams, tenants, or agent runtimes through a single cluster-level issuer or invent ad-hoc token routers.

This is the right call. The alternative has been ugly: per-team token-injection hacks, brittle kubeconfigs, or consolidating wildly different trust domains behind one issuer and losing auditability. Multiple issuers per cluster lets you map issuers to workload classes (CI agents, tenant A, tenant B, operator tooling) and keep RBAC, scope, and audience constraints explicit — but it also widens the attack surface and raises lifecycle questions that most organizations aren't prepared to answer.

The IAM problem nobody planned for

More OIDC issuers is powerful, but it isn't free. Each issuer is a trust boundary: keys, rotation schedules, thumbprints, discovery endpoints, and revocation channels. If you run ephemeral agent runtimes or self-hosted controllers that request short-lived credentials, you now need lifecycle and audit tooling that treats issuers as first-class resources. Expect teams that haven't automated issuer onboarding, rotation, and centralized logging to be the ones digging through audit trails late at night.

Bedrock and the economics of agentic AI

While EKS opens identity doors, Amazon Bedrock is lowering the friction to run inference at lower latency and cost in specific regions. Bedrock continues to add model providers and expand regional availability and runtimes exposed via its runtime/InvokeModel APIs and SDKs. Combine that with periodic model pricing and performance adjustments and you get cheaper, lower-latency regional inference for agent frameworks.

Practically, these moves shift architectures toward agentic, distributed inference: run orchestration on EKS, persist embeddings in a managed vector store (for example, OpenSearch, a dedicated vector DB, or a DynamoDB-backed index with custom integration), and execute heavy model work in-region using Bedrock runtimes. For scale, teams will pair managed Ray on SageMaker or EKS-backed clusters with Bedrock-hosted models to host agents and tooling. If you think of Bedrock as "model compute" and a vector store as the semantic index, the plumbing is falling into place for production agent systems.

Lambda networking and ingestion: stop treating serverless as slow pipes

Augmenting that stack, Lambda's networking and SQS polling limits have been improved: larger memory configurations get materially higher network bandwidth, and SQS polling/concurrency limits have increased to support higher-throughput consumers. Combined with larger async invocation payload support, these changes alter serverless trade-offs: Lambda is now a viable, higher-throughput ingress and fan-in fabric for model inference pipelines and event-driven agent orchestration.

That doesn't mean "lift-and-shift everything to Lambda" — it means reassess designs that previously leaned on bulky EC2 for network IO. Eliminate NAT bottlenecks, reconsider VPC vs. non‑VPC placement, and use the increased SQS poller scale for massively parallel consumers feeding vectorization and inference stages. For background on async invocation limits and best practices, see AWS documentation on Lambda invocation payloads and SQS integrations.

What to do about it

If you're owning platform identity: inventory issuers, automate OIDC thumbprint verification, and add issuer-aware policy drift detection. If you own ML infra: re-evaluate region placement for latency-sensitive models, benchmark Bedrock runtime costs and latency, and design your embedding store and agent orchestrator to tolerate cross-region inference fallbacks. If you're a serverless architect: use Lambda's higher network capacity to collapse some ingestion tiers, but add network egress budgeting and NAT/egress monitoring before you run heavy model traffic through Lambdas.

Real installation: EKS Distro and upstream Kubernetes releases continue to evolve, and AWS guidance around control-plane practices and certificate rotation is nudging reference architectures toward managed control-plane patterns. If you missed the EKS control-plane and CA rotation guidance, our recent writeup on Amazon EKS advanced control-plane configuration is a useful companion.

Final thought

Together, these changes are less about discrete features and more about enabling a new class of distributed, identity-rich AI infrastructure: many issuers, many regions, and serverless pipes that actually move data. Teams that treat issuers as configuration knobs will get bitten. The smart ones will treat them as products — with lifecycle, audit, and rotation baked in — and build agent stacks that can operate across regions without shipping credentials around like confetti.

Amazon EKS now supports multiple external OIDC providers per cluster

Sources

Amazon Bedrock AgentCore runtimes GA: AWS-managed GPU EC2 instances for stateful agents and 14-day sessions

Amazon EKS: advanced control-plane configuration and managed CA rotation

AWS increases async payload limit to 1 MB for Lambda, SQS, and EventBridge