Default to Pod Identity for new EKS workloads; keep IRSA where portability or Fargate demands it.

	IRSA	Pod Identity
Setup	OIDC provider per cluster, trust policy per cluster, SA annotation	Add-on plus one association, no annotation
Trust policy	Cluster and ServiceAccount specific	Cluster-agnostic, reusable
Role reuse across clusters	Edit the trust policy each time	Just create another association
Where it works	EKS (incl. Fargate), and other Kubernetes via OIDC	EKS EC2 nodes; not Fargate
AWS recommendation	Supported, older	Default for new setups

Migration is incremental

Both can trust the same role at once, so move workload by workload with no big bang.

create an association

$ aws eks create-pod-identity-association \
    --cluster-name shop-eu --namespace shop \
    --service-account checkout \
    --role-arn arn:aws:iam::111122223333:role/checkout-s3

1 InstallPod Identity Agent add-on.

2 TrustAdd pods.eks.amazonaws.com to the role.

3 AssociateSame namespace and ServiceAccount.

4 VerifyCheck the Pod's credentials source; upgrade SDKs if needed.

5 Clean upRemove the annotation and the OIDC trust statement.

Pod Identity or IRSA, and how to migrate

IRSA (IAM Roles for Service Accounts) federates a ServiceAccount's projected token through the cluster's OIDC identity provider. It works but has friction: each cluster needs a registered OIDC provider in IAM, each role's trust policy must name that provider and the exact namespace and ServiceAccount, and the ServiceAccount carries an annotation. Pod Identity removes all three: the trust policy is generic, the association is created through the EKS API, and no annotation is needed.

The practical rule is simple. For a new workload on an EC2-backed EKS cluster, use Pod Identity. Use IRSA when the workload runs on Fargate (which Pod Identity does not support), or when you need the same federation mechanism to work identically on non-EKS Kubernetes clusters, such as the on-prem estate in Deck 4.

Migration can be incremental because a role can trust both mechanisms at once. Reveal the five steps with the right arrow: install the agent add-on, add the pods.eks.amazonaws.com principal to the role's trust policy beside the existing OIDC statement, create the association, verify that the Pod now receives credentials from the new source (upgrading any old SDKs), and finally remove the annotation and the OIDC trust statement.

Gotchas: a missing sts:TagSession in the trust policy makes the association fail in a confusing way, and SDKs older than the supported versions silently fall back to the node role. Test with a throwaway Pod that calls sts get-caller-identity and confirm the assumed role.