For a new workload on a supported Linux EC2-backed EKS cluster, EKS Pod Identity is usually the simpler starting point; for an established IRSA setup or an unsupported environment, keep IRSA. The choice is not just a change to a service-account annotation: the methods use different trust relationships and credential paths, so migration requires checking SDK behavior, IAM policies, cross-account access, and network reachability.
How EKS Pod Identity and IRSA differ
Both methods let a Kubernetes workload receive AWS credentials through a Kubernetes service account, without relying on the node role for the workload’s permissions. The difference is how the role is trusted and how credentials reach the application.
As an Amazon Associate I earn from qualifying purchases.
| Decision point | EKS Pod Identity | IRSA |
|---|---|---|
| Role trust | Trusts the pods.eks.amazonaws.com service principal. The association between the cluster, namespace, service account, and role is configured in EKS. |
Trusts the cluster’s OIDC identity provider, with the role scoped to the intended service account. |
| Credential path | The EKS Pod Identity Agent runs on eligible worker nodes; EKS Auth handles the role assumption and credentials are made available to the pod. | The supported AWS SDK uses the projected service-account token to call STS AssumeRoleWithWebIdentity. |
| Cluster IAM setup | Does not require an IAM OIDC provider for each cluster. | Requires an IAM OIDC provider for the cluster. AWS’s comparison page lists a default limit of 100 IAM OIDC providers per account. |
| Session tags | Supports session tags, including cluster, namespace, and service-account context, which can be used in carefully designed attribute-based access control (ABAC) policies. | AWS’s comparison says IRSA does not support these session tags. |
| Platform coverage | For EKS workloads on eligible Linux EC2 worker nodes; it does not support Fargate pods, Windows EC2 pods, Outposts, EKS Anywhere, or self-managed Kubernetes. | Available across a broader set of environments, including Fargate and the other environments AWS lists in its comparison. |
| Cross-account access | Uses role chaining to reach a role in another account. | Can use direct web-identity federation to assume a role in another account. |
| Operational dependency | Requires the Pod Identity Agent add-on on eligible worker nodes. | Does not require the Pod Identity Agent. |
These distinctions and AWS’s recommendation to use Pod Identity for pods whenever possible are described in AWS’s service-account access comparison. The recommendation is qualified by support: IRSA remains a valid choice for existing OIDC patterns and workloads or platforms Pod Identity does not support.
Which one should you choose?
Choose Pod Identity when the workload is eligible
- You are setting up a new workload on a supported Linux EC2-backed EKS cluster.
- Your application uses a supported AWS SDK version and its default credential provider chain.
- You want to avoid maintaining an IAM OIDC provider and corresponding trust setup for every cluster.
- You have a policy design that can make intentional use of Pod Identity session tags, or can safely use a shared role with appropriate conditions.
Keep IRSA when it fits the workload better
- The workload runs on Fargate, Windows EC2, Outposts, EKS Anywhere, or self-managed Kubernetes, where Pod Identity is not supported according to AWS’s documented restrictions.
- The application depends on an unsupported SDK version, a non-default credential provider, or an established OIDC-based trust pattern that you do not intend to change.
- Your cross-account design requires direct web-identity federation rather than the role chain used by Pod Identity.
- The current IRSA setup is working and the operational benefit of migrating does not justify changing the workload’s identity and policy path.
You can run both approaches in the same environment. There is no requirement to move every working IRSA workload as part of adopting Pod Identity for eligible applications.
#1 Best Overall
Check compatibility before changing a workload
Build an inventory for each workload before creating associations. Pod Identity support depends on more than the Kubernetes version: AWS documents a platform-version condition for Kubernetes 1.28, while its table says unlisted versions support all platform versions. Check the current Pod Identity requirements and restrictions against the target cluster rather than relying on the Kubernetes version alone.
- Workload placement: Record the cluster, namespace, service account, node operating system and compute type. Exclude workloads on unsupported platforms from a Pod Identity migration plan.
- SDK and credential chain: Confirm the exact language and SDK version against AWS’s live SDK compatibility table. Supported SDKs discover Pod Identity credentials through the container credential provider when the default chain is used. An application that hard-codes another provider or static credentials may not use them.
- IAM behavior: Record the existing role, permissions, trust conditions, resource policies, and any policies that rely on the current role identity or separation between roles.
- Network path: Note whether the cluster has outbound internet access and which AWS service endpoints are reachable from worker nodes.
- Account boundaries: Identify AWS calls made in other accounts and decide whether the existing direct-federation pattern must be preserved or can be redesigned for role chaining.
Do not infer a minimum SDK version from a different language or release. The supported-version matrix is language-specific and can change.
Migrate from IRSA to Pod Identity in controlled steps
Treat the migration as an identity and authorization change. Make the change for one workload first, verify both successful and denied access, and retain a rollback path until the new credential flow is proven in your environment.
- Document the current behavior. Record the service account, IRSA role, policy permissions, relevant resource policies, cross-account calls, and private-cluster endpoint configuration. Establish which AWS actions the application must be able to perform and which it must not.
- Confirm the workload is supported. Check its node type, operating system, EKS platform requirements, and SDK version against AWS’s current documentation. If any of those requirements fail, keep IRSA for that workload.
- Install and check the Pod Identity Agent. The agent is a required part of the credential path and runs as a DaemonSet on eligible worker nodes. Confirm it is healthy and present on the nodes where the workload may run; an association alone is not sufficient if the pod’s node cannot use the agent.
- Prepare the role trust policy. The role needs the
pods.eks.amazonaws.comservice principal and the actionssts:AssumeRoleandsts:TagSession. Apply conditions to restrict which clusters, namespaces, and service accounts may use the role. AWS provides examples and explains the conditions in its guide to creating the required Pod Identity role trust policy. - Review permission and resource policies. Do not treat session tags as a replacement for least-privilege role permissions. If you use ABAC, inspect the relevant tag keys, capitalization, trust conditions, and resource-policy evaluation. Policies written around distinct IRSA roles may need an intentional redesign before multiple workloads share a role.
- Create the association. Associate the role with the intended cluster, namespace, and service account using the EKS Pod Identity association procedure. A service account can have one Pod Identity role association in a cluster. Reuse a role only when its permissions and trust conditions are appropriate for every associated workload. The principal or automation that creates associations also needs
iam:PassRole, as noted in AWS’s EKS identity and access management best practices. - Verify network access. In a private cluster without outbound internet, Pod Identity requires connectivity to the regional EKS Auth API through the VPC endpoint named
com.amazonaws.region-code.eks-auth. If you retain IRSA for another workload, verify its STS path as well: IRSA obtains credentials through an STS API call. AWS documents the private-cluster endpoint considerations in its guide to deploying private clusters with limited internet access. - Canary the workload and test its effective identity. Confirm the application obtains credentials for the intended role, refreshes them successfully, and can perform its required actions. Also test actions that should be denied. Review the identity and API activity using your normal IAM and CloudTrail procedures; do not treat a successful pod start as proof that authorization is correct.
- Roll out in slices and preserve rollback. Move one workload or deployment slice at a time. Keep the prior IRSA configuration available until the canary and rollout are stable. Define rollback triggers for credential acquisition failures, unexpected authorization changes, and application error signals; the exact mechanism depends on your deployment tooling.
Migration gotchas that can cause a failed or unsafe rollout
A healthy cluster does not guarantee a usable credential path
The Pod Identity agent must be available on the workload’s eligible worker node, and the node must be able to reach EKS Auth. Check the agent’s node coverage and the network path together. In a private cluster without internet egress, configure the EKS Auth VPC endpoint before expecting Pod Identity credentials to work.
Session tags can change policy outcomes
Pod Identity adds session tags that can support conditions such as aws:PrincipalTag/<tag-key> in resource policies. That can reduce the need for a separate role per cluster or service account, but it also makes tag conditions part of the authorization boundary. Validate the exact tags and policy evaluation rather than assuming that a role which worked with IRSA will behave identically. AWS’s role-trust documentation also notes that packed policy size limits can produce PackedPolicyTooLarge; reducing session tags is one possible response.
Cross-account access is not a drop-in equivalent
IRSA can federate directly to a target-account role using web identity. Pod Identity’s cross-account approach chains from the associated role to a target-account role. Review the trust and permissions on both roles, session duration, and the audit trail across accounts before changing that design.
Quotas and setup permissions affect automation
AWS’s current user guide lists a limit of 5,000 Pod Identity associations per cluster. The identity used by deployment automation must also be allowed to pass the role when creating an association. Include both the association quota and iam:PassRole in infrastructure-as-code and account-permission reviews.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Credential-provider assumptions can hide the old identity
A supported SDK can discover Pod Identity credentials through its default chain, but application code may explicitly select a different provider or use static credentials. Verify the provider the process actually uses, not just the cluster association. Consult the current SDK matrix for the language and version in the application.
Best Value
Decide workload by workload, not by slogan
Pod Identity removes per-cluster OIDC-provider setup and offers session tags, which can make it a good default for eligible new workloads. That does not make IRSA obsolete: platform support, SDK compatibility, existing trust patterns, and cross-account requirements can make IRSA the safer or only workable option. A mixed estate is a reasonable design when those differences are real.
Quick Recap
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.
