'Invalid principal in policy' error

This usually isn't necessary for services like EC2, ECS, EKS, and Lambda because AWS already injects temporary credentials. There are limited circumstances where a role might want to assume itself. These usually relate to the passing of session policies or tags or to the tightly scoping of permissions.

The "invalid principal" error is usually caused by the principal not being a valid ARN or by the principal having been deleted and re-created after the policy was last edited. The editor displays ARNs for entities but they are referred to internally by reference numbers. If you delete an ARN that's used as a principal then create it again, it will have the same ARN name but a different reference number so existing policies that name it will no longer be valid. Such policies will contiue to function for the other principles but they can't be saved again unless the invalid principles are removed. It may also be caused by one of the other principals no longer existing. If you open the policy in the JSON editor, have any of the principals been replaced by a random string of letters/digits you don't recognise? If they have, this indicates that the principal no longer exists. Remove any such principals or, if they have been re-created, replace them with the ARN again and try saving the policy again. The JSON editor should indicate which line(s) it has a problem with by tagging them with a red error mark and the "Errors" tab having contents

Seems no, IAM role may not assume itself. The “Invalid principal in policy” error occurs when the Principal element in a resource‑based policy references a non‑existent or incorrectly formatted ARN. If you specify the same role as both the principal and the target, AWS rejects it because a role cannot be its own principal.

https://repost.aws/knowledge-center/s3-invalid-principal-in-policy-error

https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_policies.html

You'll receive the error "Invalid principal in policy" if you try to grant a role the permission to assume itself while creating the role. That's not because a role couldn't be granted the permission to assume itself, but because the role doesn't yet exist at the time it's being created. A reference to the role cannot be resolved before the role has been created.

It's rare for a role to have any useful reason to assume itself, but in cases where it's needed or preferred, you can first create the role without the self-reference in its trust policy and, after the role has been created, update the trust policy to include the self-reference.

For example, if you run this in CloudShell, with 000000000000 replaced by your account ID:

aws iam create-role \
--role-name 'test-role-self-reference' \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::000000000000:role/test-role-self-reference"},"Action":"sts:AssumeRole"}]}'

it will fail with the error: An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::000000000000:role/test-role-self-reference"

However, if you first create the role with a trust policy that doesn't reference the role, creating the role will succeed:

aws iam create-role \
--role-name 'test-role-self-reference' \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::000000000000:root"},"Action":"sts:AssumeRole"}]}'

and you can subsequently update the trust policy (assume role policy) to reference the role itself, now that it exists:

aws iam update-assume-role-policy \
--role-name 'test-role-self-reference' \
--policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::000000000000:role/test-role-self-reference"},"Action":"sts:AssumeRole"}]}'