Skip to content
Latchkey

Amplify "amplify push" You are not authorized in CI

amplify push translated your backend into CloudFormation and tried to act on a resource, but the IAM identity in CI is denied that action. The message names the exact action and resource that was refused.

What this error means

amplify push (or amplify push --yes) stops while updating the backend with "You are not authorized to perform: <service>:<action> on resource ...". The deployment rolls the stack back.

amplify
An error occurred during the push operation: Resource is not authorized.
User: arn:aws:iam::123456789012:user/ci is not authorized to perform:
iam:CreateRole on resource: arn:aws:iam::123456789012:role/amplify-app-dev-authRole

Common causes

The CI IAM principal is too narrowly scoped

Amplify backends create roles, Cognito pools, AppSync APIs, and S3 buckets. A CI user limited to a subset of services is denied the first action it is missing.

A new category was added without widening the policy

Adding auth, storage, or function to the backend introduces new actions (for example iam:CreateRole) that the existing CI policy never granted.

How to fix it

Grant the missing action to the CI principal

  1. Read the action and resource ARN from the "not authorized to perform" line.
  2. Add that action to the IAM policy attached to the CI role or user.
  3. Re-run amplify push so the rolled-back stack can complete.
IAM policy
# the denied action is named explicitly in the error
{ "Effect": "Allow", "Action": "iam:CreateRole", "Resource": "*" }

Use a role with the Amplify-managed policy

Drive CI with a role that carries the backend deploy permissions Amplify needs, assumed via OIDC rather than a long-lived user.

.github/workflows/ci.yml
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/amplify-ci-deploy
    aws-region: us-east-1

How to prevent it

  • Scope the CI deploy role to every service your backend categories use.
  • Update the policy when you add auth, storage, or function categories.
  • Prefer OIDC role assumption over static keys for backend deploys.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →