What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For a new workload on a supported Linux EC2-backed EKS cluster, EKS Pod Identity is usually the better starting point; for an established IRSA workload, migrate only when its compatibility, policy, and networking checks support the change. AWS recommends Pod Identity for pods whenever possible, but IRSA remains useful for unsupported environments and existing OIDC-based designs. The two methods provide IAM credentials through Kubernetes service accounts using different trust and credential paths, so a migration is more than swapping an association.
How EKS Pod Identity and IRSA differ
Both let a Kubernetes service account identify an AWS workload, but the trust relationship and credential delivery differ. With IRSA, the cluster’s OIDC issuer is registered with IAM, and the workload’s AWS SDK uses its projected token to call STS AssumeRoleWithWebIdentity. With Pod Identity, IAM trusts the EKS service principal pods.eks.amazonaws.com; the EKS Pod Identity Agent on worker nodes and the EKS Auth API provide the credential path.
| Decision point | EKS Pod Identity | IRSA |
|---|---|---|
| IAM trust setup | Trust the EKS Pod Identity service principal; create a cluster-side association for the service account. | Register an OIDC provider per cluster and scope the role trust to that provider and service account. |
| Credential delivery | EKS handles role assumption; the agent makes credentials available to supported workloads. | The SDK exchanges a projected service-account token with STS using AssumeRoleWithWebIdentity. |
| Node and platform coverage | EKS workloads on supported Linux EC2 worker nodes; not Fargate pods, Windows EC2 pods, Outposts, EKS Anywhere, or self-managed Kubernetes. | Broader coverage, including environments AWS lists as unsupported for Pod Identity, such as EKS Anywhere and self-managed Kubernetes on EC2. |
| Session tags | Supports tags such as cluster, namespace, and service account, which can support attribute-based access control (ABAC). | AWS’s comparison says STS session tags are not supported for this method. |
| Cross-account access | Use role chaining to a role in the target account. | Can use direct web-identity federation to a role in the target account. |
| Per-cluster association or provider scale | AWS’s current user guide lists a limit of 5,000 Pod Identity associations per cluster. | AWS’s comparison page lists 100 IAM OIDC providers per account by default; this may matter in large multi-cluster estates. |
Coverage and limits above reflect AWS documentation checked October 7, 2026; confirm the live requirements for your target cluster before rollout. See AWS’s comparison of workload access methods and Pod Identity requirements and limits.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Which method should you choose?
Choose Pod Identity for a compatible new workload
Pod Identity can reduce IAM administration when multiple EKS clusters need to use roles without registering a separate OIDC provider for each cluster. Its session tags can also support ABAC, provided the role and resource policies deliberately use those tags. AWS recommends Pod Identity for pod access whenever possible; its guidance describes IRSA as appropriate for existing OIDC patterns and cases Pod Identity does not support. Read AWS’s workload access guidance before settling on a standard for a new estate.
#1 Best Overall
Keep IRSA when compatibility or an existing design favors it
There is no requirement to migrate every working IRSA workload. Retaining IRSA is reasonable when a workload runs in an environment outside Pod Identity’s support, relies on a supported IRSA pattern, or would require a risky permissions redesign to adopt session tags. Mixed use is possible: make the choice per workload rather than forcing one identity mechanism across incompatible platforms.
Check eligibility before changing a workload
Build an inventory for each workload: cluster and Kubernetes version, platform version, namespace and service account, node operating system and type, AWS SDK and language version, current IAM role and policies, cross-account calls, and network egress or VPC endpoints. These details determine whether the migration is viable and where a failure will appear.
Quick Recap
Best Value
- Cluster and nodes: Pod Identity requires a supported EKS platform and Linux EC2 worker nodes. It does not support Fargate pods or Windows EC2 pods, and AWS also lists Outposts, EKS Anywhere, and self-managed Kubernetes as unsupported. For Kubernetes 1.28, AWS documents a platform-version condition; for versions not listed in its table, AWS says all platform versions are supported. Check the current requirements table for your cluster.
- SDK credential chain: Confirm the application uses a supported AWS SDK version and its default credential provider chain. AWS says supported SDKs discover Pod Identity credentials through the container credential provider. An application that hard-codes a different provider or static credentials may not use them automatically. Minimum SDK versions vary by language and change over time; consult AWS’s live SDK compatibility table.
- Agent coverage: The Pod Identity Agent add-on is required and runs on eligible worker nodes. An association alone does not provide credentials if the workload lands on a node without a healthy agent.
- Networking: Identify whether workloads have outbound internet access and whether the required AWS service endpoints are reachable. The endpoint differences are covered below.
- Policy model: Find permissions or resource policies that rely on separate IRSA roles, principal ARNs, or other role-specific distinctions. Replacing those distinctions with shared roles and tags requires a deliberate policy review.
Migrate from IRSA in controlled steps
- Inventory and select a canary. Record the workload’s cluster, namespace, service account, nodes, SDK, role, permissions, network path, and any cross-account access. Start with a workload that meets Pod Identity’s platform and SDK requirements and has a clear, testable permission set.
- Install and verify the Pod Identity Agent. Add the EKS Pod Identity Agent and verify it is healthy on every eligible node where the canary can run. Confirm node-to-EKS Auth connectivity before changing the workload.
- Prepare the IAM role trust policy. The role must trust
pods.eks.amazonaws.comfor bothsts:AssumeRoleandsts:TagSession. AWS documents request-tag conditions that can restrict which cluster, namespace, or service account may use the role. Apply least privilege, and grantiam:PassRoleto the principal that creates associations as required by AWS best practices. See AWS’s required role trust policy and EKS identity best practices. - Review session tags and resource policies. Decide whether to use Pod Identity tags, such as cluster, namespace, and service account, in trust or resource policies. Check tag names, case sensitivity, and how each resource policy evaluates
aws:PrincipalTag/<tag-key>. Do not treat tags as a substitute for reviewing the role’s permissions. If policy size or session-tag packing causesPackedPolicyTooLarge, AWS lists reducing session tags as one possible response; see the role setup guidance. - Create the service-account association. Associate the intended role with the correct cluster, namespace, and service account. AWS allows one Pod Identity role association per service account in a cluster; a role may be reused only when its permissions and trust conditions are appropriate for every workload using it. Follow AWS’s association procedure.
- Plan cross-account calls explicitly. If the workload accesses resources in another account, design the Pod Identity role’s role-chaining path to the target-account role. Review trust and permissions on both roles, session duration, and the audit trail. This is not the same flow as IRSA’s direct web-identity federation; AWS explains the distinction in its method comparison.
- Test network access to the credential service. In a private cluster without outbound internet, Pod Identity needs access to the regional EKS Auth VPC endpoint, named
com.amazonaws.region-code.eks-auth. IRSA instead calls STS, so an IRSA workload also needs a working STS path under its endpoint and egress arrangement. Consult AWS’s private-cluster guidance. - Validate effective identity and permissions. Run the canary and confirm it obtains credentials for the intended role, can perform required AWS actions, and is denied actions it should not perform. Check that credentials refresh successfully and review CloudTrail or IAM evidence through your normal operations process.
- Roll out gradually and preserve rollback. Move one workload or deployment slice at a time. Keep the previous IRSA setup available until the canary and rollout meet defined success criteria. Set rollback triggers for credential acquisition failures, unexpected authorization changes, or application error and latency signals; exact deployment mechanics depend on your tooling.
Migration gotchas that can block rollout
- Agent health is part of identity delivery. Check agent health and node placement, not just whether the association exists.
- Cluster version is not the only compatibility signal. Check the EKS platform-version requirement for Kubernetes 1.28 and the current platform support table rather than relying on the Kubernetes version alone.
- SDK support is language- and version-specific. Do not assume a workload is compatible because another service using the same language works; verify its SDK version and credential chain in AWS’s current compatibility matrix.
- ABAC can change authorization semantics. Session tags make role reuse possible, but a broad role or a mis-scoped resource policy can grant access across namespaces or service accounts. Review both role permissions and tag-based resource policies before sharing a role.
- Association management needs IAM permissions. Automation that creates Pod Identity associations must have appropriate
iam:PassRolepermission; include this in the deployment principal’s design. - Association and provider quotas are different constraints. AWS’s current guide lists 5,000 Pod Identity associations per cluster, while its comparison page lists 100 OIDC providers per AWS account by default for IRSA. These are service limits, not evidence of adoption, performance, or savings; check live quotas before designing at scale.
- Mixed identity methods are a valid end state. A workload that cannot meet Pod Identity’s platform, SDK, networking, or policy requirements can remain on IRSA while eligible workloads use Pod Identity.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
