What causes "Unsupported AWS Caller Identity ARN detected" in remotion-dev/remotion?

Run `aws sts get-caller-identity` and inspect the Arn field; if it is not an iam user or an sts assumed-role ARN, re-authenticate as one of those (e.g. `aws sts assume-role` and export the resulting credentials).

remotion-dev/remotion · error · Error

Unsupported AWS Caller Identity ARN detected

Error message

Unsupported AWS Caller Identity ARN detected

What it means

Thrown by resolveCallerArnForSimulation when simulating IAM permissions (e.g. `npx remotion lambda policies validate`). The function parses the AWS Caller Identity ARN and only supports `arn:<partition>:iam::<account>:user/<name>` and STS assumed-role ARNs `arn:<partition>:sts::<account>:assumed-role/<role>/<session>`, rewriting the latter to an IAM role ARN. Any other ARN shape (e.g. `sts:federated-user`, `sts` with a resource type other than `assumed-role`) cannot be mapped to a principal for policy simulation, so the library refuses it.

Solutions

Run `aws sts get-caller-identity` and inspect the Arn field; if it is not an iam user or an sts assumed-role ARN, re-authenticate as one of those (e.g. `aws sts assume-role` and export the resulting credentials).
If you are federated, assume an IAM role inside the account first (`aws sts assume-role --role-arn ... --role-session-name remotion`) and run the validation with those temporary credentials.
As a workaround, skip the policy simulation and grant the documented Remotion Lambda permissions manually, or run the simulation from a regular IAM user.

Example fix

# before: authenticated as federated-user
aws sts get-caller-identity
# "Arn": "arn:aws:sts::123456789012:federated-user/alice"
npx remotion lambda policies validate --region us-east-1  # -> Unsupported AWS Caller Identity ARN detected

# after: assume a role first
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/remotion-validate --role-session-name validate
export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_SESSION_TOKEN=...
npx remotion lambda policies validate --region us-east-1

Defensive patterns

Strategy: try-catch

Validate before calling

// Check the identity shape before running policy validation
import {STSClient, GetCallerIdentityCommand} from '@aws-sdk/client-sts';
const id = await new STSClient({}).send(new GetCallerIdentityCommand());
const arn = id.Arn ?? '';
const ok =
  /^arn:[^:]+:iam::\d{12}:user\/.+/.test(arn) ||
  /^arn:[^:]+:sts::\d{12}:assumed-role\/[^/]+\/.+$/.test(arn);
if (!ok) throw new Error(`Re-authenticate as IAM user or assumed role: ${arn}`);

Type guard

const isSupportedCallerArn = (arn: string): boolean =>
  /^arn:[^:]+:iam::\d{12}:user\/[A-Za-z0-9+=,.@\/_-]+$/.test(arn) ||
  /^arn:[^:]+:sts::\d{12}:assumed-role\/[^/]+\/.+$/.test(arn);

Try / catch

try {
  await validatePermissions({...});
} catch (e) {
  if (e instanceof Error && /Caller Identity ARN/i.test(e.message)) {
    // re-authenticate (assume-role) and retry, or skip simulation
  } else throw e;
}

Prevention

Run `aws sts get-caller-identity` before invoking permission validation scripts.
In CI, always run validation through an assumed IAM role, not a federated or root identity.
Keep a small preflight that asserts the ARN is a user or assumed-role shape.

When it happens

Trigger: Running `npx remotion lambda permissions validate` (or the validatePermissions API / simulate IAM flow) while authenticated with an STS identity that is not an assumed-role, such as `arn:aws:sts::123456789012:federated-user/bob` or an irregular role-session ARN that fails the `/role/session` split.

Common situations: Using SAML/OIDC federation or a web-identity session whose get-caller-identity output is a federated-user ARN; using a customSTS setup or an AWS SSO token broker that produces non-standard session ARNs; running the validation from a CI role that was assumed through a tool producing exotic session names with extra slashes.

Related errors

AI-assisted analysis of remotion-dev/remotion@10db9de073 (2026-08-22). Data as JSON: /api/errors/d9b264bfc88bd86d. Report an issue: GitHub.

Appendix: source

Thrown at packages/lambda/src/api/iam-validation/resolve-caller-arn.ts:44

	const service = components[2];
	const accountId = components[3];
	const resourceType = components[4];
	if (service === 'iam' && resourceType === 'user') {
		return callerIdentityArn;
	}

	if (service === 'sts' && resourceType === 'assumed-role') {
		const assumedRoleComponents = components[5].match(/^\/([^/]+)\/(.*)$/);
		if (!assumedRoleComponents) {
			throw new Error(
				'Unsupported AWS Caller Identity as Assumed-Role ARN detected',
			);
		}

		return `arn:${callerPartition}:iam::${accountId}:role/${assumedRoleComponents[1]}`;
	}

	throw new Error('Unsupported AWS Caller Identity ARN detected');
};

View on GitHub (pinned to 10db9de073)