remotion-dev/remotion · error · Error

Unsupported AWS Caller Identity ARN detected

Error message

Unsupported AWS Caller Identity ARN detected

What it means

After parsing the caller identity ARN type, simulatePermissions() only supports two principal types: an IAM user (partition type 'iam' with subtype 'user') and an STS assumed-role (partition type 'sts' with subtype 'assumed-role'). If the caller identity is neither — for example a role principal, federated user, or service role — Remotion throws this error because it cannot determine the correct role ARN to simulate permissions against.

Source

Thrown at packages/lambda/src/api/iam-validation/simulate.ts:76

		callerIdentityArnType === 'iam' &&
		callerIdentityArnComponents[3] === 'user'
	) {
		callerArn = callerIdentity.Arn as string;
	} else if (
		callerIdentityArnType === 'sts' &&
		callerIdentityArnComponents[3] === 'assumed-role'
	) {
		const assumedRoleComponents =
			callerIdentityArnComponents[4].match(/\/([^/]+)\/(.*)/);
		if (!assumedRoleComponents) {
			throw new Error(
				'Unsupported AWS Caller Identity as Assumed-Role ARN detected',
			);
		}

		callerArn = `arn:aws:iam::${callerIdentityArnComponents[2]}:role/${assumedRoleComponents[1]}`;
	} else {
		throw new Error('Unsupported AWS Caller Identity ARN detected');
	}

	const results: SimulationResult[] = [];

	for (const per of requiredPermissions) {
		const result = await simulateRule({
			actionNames: per.actions,
			arn: callerArn,
			region: options.region,
			resource: per.resource,
			retries: 2,
			requestHandler: options.requestHandler,
		});
		for (const res of result) {
			results.push(res);
			options.onSimulation?.(res);
		}
	}

View on GitHub (pinned to 78fe4bb3fd)

Solutions

  1. Run simulatePermissions() from a context that uses a standard IAM user or assumed-role principal (e.g. an IAM user with access keys).
  2. If running inside an EC2/instance profile, try assuming a role explicitly first so the caller identity is an assumed-role.
  3. Report the principal type to Remotion maintainers if it is a common deployment pattern that should be supported.
Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED_PRINCIPAL = /arn:aws:(iam):.*:(user)\/|^arn:aws:(sts):.*:(assumed-role)\//;

function isSupportedCallerPrincipal(arn: string): boolean {
  if (arn.startsWith('arn:aws:iam::') && arn.includes(':user/')) return true;
  if (arn.startsWith('arn:aws:sts::') && arn.includes(':assumed-role/')) return true;
  return false;
}

// Verify principal type before simulatePermissions():
if (!isSupportedCallerPrincipal(identity.Arn)) {
  throw new Error('Caller principal type is not supported by simulatePermissions(). Use an IAM user or assumed-role.');
}

Prevention

When it happens

Trigger: The GetCallerIdentity ARN's type/subtype does not match iam/user or sts/assumed-role. Examples: arn:aws:sts::<acct>:assumed-role with a different subtype, an IAM role principal (arn:aws:iam::<acct>:role/...), or a web-identity/federated principal.

Common situations: Running Remotion Lambda permission simulation from within an EC2 instance with an instance profile role (whose caller identity may resolve differently); using a web identity or SAML federation; running inside a container task role that presents an unexpected principal type.

Related errors


AI-assisted analysis of remotion-dev/remotion@78fe4bb3fd (2026-08-12). Data as JSON: /api/errors/8d96103d3852c961. Report an issue: GitHub.