Service-Linked Role Calls Fail AccessDenied When IAM or an SCP Blocks Creation

Symptom

An AWS service call fails with AccessDenied when the service needs a service-linked role that does not yet exist or cannot be used.

The failure is often seen on first use of a feature in an account, and the error text may mention iam:CreateServiceLinkedRole or iam:PassRole. Exact messages vary by service, so confirm wording against that service’s documentation.

False assumption

The common assumption is that the calling user already has broad service permissions, so the service itself must be at fault. That is an inference, not a fact. Service-linked role creation is a separate IAM action evaluated against the caller, and a deny from any layer overrides an allow elsewhere.

Root cause

The root cause is an IAM identity policy, permissions boundary or organisation-level service control policy (SCP) that does not allow, or explicitly denies, creating or using the service-linked role.

Typical patterns are a blanket deny on iam:* outside an approved administrator role, an allow-list SCP that omits iam:CreateServiceLinkedRole, or a boundary that omits it. Which pattern applies in your account is something only the evidence in your environment can show.

Impact

The affected AWS service cannot act in the account until the role exists and is usable, so the feature, scaling or integration that depends on it stays unavailable.

The risk is moderate: the blast radius is the service workflow, but a rushed fix such as granting iam:* creates a wider exposure. Compare the related trap on IAM role chaining through PassRole wildcards.

Diagnosis

Begin with read-only evidence, in an isolated or non-production account where possible.

1. Record the exact error, the calling principal and the time from the failing request.
2. Look up the event in CloudTrail and note the error code and the action that was denied.
3. Check whether the role already exists with a read-only IAM lookup.
4. Review identity policies and permissions boundaries on the caller, then the SCPs applied to the account. See also how a permissions boundary interacts with other policy types.
5. Use the IAM policy simulator for the specific action, noting that its results may not reflect every SCP condition.

Confirm version-specific behaviour and the list of services that use service-linked roles in the AWS documentation listed in the sources.

Correction

Apply the narrowest change at the layer that denies. Allow iam:CreateServiceLinkedRole for the named service principal only, rather than all services, and add exceptions to an SCP only for the required role path. Where an administrator can create the role once, that avoids widening every caller’s permissions.

Do not apply any change until the denying layer is identified from evidence. Stop if the change would grant iam:* or alter policies beyond the scoped account.

Validation

Success means the role exists and the service call completes without AccessDenied.

1. Retry the original service operation and confirm it succeeds.
2. Check CloudTrail for the role creation event and a later successful service event.
3. Re-run the simulator for an unrelated principal and confirm it is still denied.

Rollback

If the change causes unexpected access, restore the previous policy version or SCP document that you saved before editing.

Record the prior policy text first, revert only that policy, and re-run the validation checks to confirm the original state. Deleting an existing service-linked role is not part of this procedure; escalate to a human owner instead, because dependent resources may break.

Prevention

Keep SCP and boundary allow-lists reviewed whenever a new AWS service is adopted, and test first use in a non-production account. Related guidance: AWS identity controls that need verification. Next safe decision: if the denying layer cannot be identified, escalate to the identity owner rather than broadening permissions.