EKS Auto cannot create AWSServiceRoleForEC2Spot Service Linked Role

The error you're encountering is related to session policies when EKS Auto assumes the CustomRoleForAmazonEKSAutoCluster role. Even though your role has the iam:CreateServiceLinkedRole permission, the session policy applied during role assumption is restricting this action.

There are a few approaches to resolve this issue:

1. Pre-create the service-linked role in each account. You can do this by running the AWS CLI command you mentioned:

aws iam create-service-linked-role --aws-service-name spot.amazonaws.com

If the role already exists, you'll see an error message indicating that the role name has been taken, which you can safely ignore.

2. For automation across multiple accounts, you could create a script or use AWS automation tools (like AWS Systems Manager Automation or AWS Lambda) to create this service-linked role in all your accounts.

3. Ensure that the IAM policy attached to your CustomRoleForAmazonEKSAutoCluster includes the proper permission without restrictions. The inline policy you've added looks correct, but make sure there are no contradicting deny statements elsewhere in the policy.

4. If you're using AWS Organizations, you could consider using Service Control Policies (SCPs) to ensure this permission is available across all accounts.

Note that when you run the create-service-linked-role command and see the error message about the role already existing, this is expected behavior and confirms that the role is already set up correctly in that account.
Sources
Tutorial: Create Amazon EC2 spot fleet roles with the AWS CLI - AWS Batch
Community | Run Kubernetes Clusters for Less with Amazon EC2 Spot and Karpenter
Community | Run Kubernetes Clusters for Less with Amazon EC2 Spot and Karpenter

You're right -->this is a common issue when using EKS Auto with Spot capacity, especially in multi-account setups. Here’s what’s happening under the hood:

Even though your custom EKS cluster role (CustomRoleForAmazonEKSAutoCluster) has iam:CreateServiceLinkedRole in its IAM policy, the STS AssumeRole call from EKS includes a session policy that doesn’t include this permission. As a result, even though the base role allows it, the session is effectively restricted. Hence, the no session policy allows the iam:CreateServiceLinkedRole error.

Why This Happens:

1. EKS Auto tries to create the AWSServiceRoleForEC2Spot service-linked role if it doesn’t already exist.
2. The iam:CreateServiceLinkedRole call requires that:
3. The IAM role has permission in its policy AND
4. The STS session policy includes this permission (explicitly or by default)

When EKS assumes your cluster role, the session policy restricts permissions further, and iam:CreateServiceLinkedRole isn't included.

Solution (Fully Automated, Zero Manual Step) To solve this at scale for 100s of accounts and new account provisioning, you need to proactively create the service-linked role in each account using automation. EKS Auto will then skip trying to create it, since it already exists.

Option A: Use an Account Bootstrapping Lambda (preferred) Set up a centralized pipeline or Account Vending Machine (AVM) that runs this once per account when created:

aws iam create-service-linked-role --aws-service-name spot.amazonaws.com

Wrap this in an automation pipeline (e.g., Control Tower lifecycle event, Terraform, or AWS Config Custom Rule + Lambda).

Option B: SCP Bypass (not recommended long-term) You could remove session restrictions via SCP or adjust the way the EKS Auto cluster role is assumed, but this is fragile and not officially supported. The STS session policy used by EKS Auto is managed by AWS and can’t be customized directly.

The only reliable fix: Pre-create the AWSServiceRoleForEC2Spot service-linked role in every account during provisioning. Once it exists, EKS Auto doesn’t attempt to create it, and the session policy restriction is avoided entirely.

Note: Please ignore that he Option B... The intention was to flag it as a common rabbit hole that people look into, but not a recommended or functional solution, which is why it was marked: "Option B: SCP Bypass (not recommended long-term)" "...but this is fragile and not officially supported."