Introduction

This error means the IAM role you gave to EventBridge Scheduler cannot be assumed by the Scheduler service. The fix is usually in the role's trust policy, not in your schedule expression or target configuration.

Why the Error Happens

EventBridge Scheduler needs permission to call sts:AssumeRole on the execution role before it can invoke the target service. If the trust relationship does not name the correct service principal, AWS rejects the schedule creation or update request.

The most important detail is that EventBridge Scheduler uses the scheduler.amazonaws.com service principal.

A minimal trust policy looks like this:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Principal": {
7        "Service": "scheduler.amazonaws.com"
8      },
9      "Action": "sts:AssumeRole"
10    }
11  ]
12}

If you use events.amazonaws.com instead, you may be thinking of EventBridge rules rather than EventBridge Scheduler. They are related services, but the assume-role principal for Scheduler is different.

The Role Also Needs Target Permissions

The trust policy only answers "who may assume this role?" The permissions policy answers "what may the assumed role do?"

For example, if the schedule target is SQS, the role also needs permission such as:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": "sqs:SendMessage",
7      "Resource": "arn:aws:sqs:us-east-1:123456789012:my-queue"
8    }
9  ]
10}

Without the trust policy, Scheduler cannot assume the role. Without the permissions policy, Scheduler can assume the role but still cannot call the target service successfully.

Example Schedule Creation Flow

A schedule creation command may look like this:

1aws scheduler create-schedule \
2  --name daily-job \
3  --schedule-expression "rate(1 day)" \
4  --flexible-time-window Mode=OFF \
5  --target '{
6    "Arn":"arn:aws:sqs:us-east-1:123456789012:my-queue",
7    "RoleArn":"arn:aws:iam::123456789012:role/MySchedulerRole",
8    "Input":"{\"message\":\"hello\"}"
9  }'

If MySchedulerRole does not trust scheduler.amazonaws.com, AWS returns the assume-role error before the schedule can function.

How to Fix It Safely

The practical repair sequence is:

1. Open the execution role in IAM
2. Edit the trust relationship
3. Ensure the principal is scheduler.amazonaws.com
4. Confirm the role's permissions allow the specific target action
5. Retry the schedule creation

If you manage IAM in infrastructure as code, update the policy there rather than patching only in the console.

This is especially important in Terraform, CloudFormation, or CDK projects. If the trust policy is only fixed manually in the console, the next deployment can overwrite the role and reintroduce the same error.

Common Pitfalls

The biggest mistake is using the wrong service principal. This happens often because people copy a trust policy from EventBridge rules or another AWS service and assume Scheduler is identical.

Another issue is fixing the trust policy but forgetting the role still needs permissions for the actual target, such as Lambda invoke, SQS send, or ECS run-task permissions.

Developers also sometimes attach permissions to the user creating the schedule and assume that is enough. It is not. Scheduler runs later as the execution role, so the role itself needs the correct trust and action permissions.

Finally, be careful with broad trust policies. The correct fix is usually a precise service principal plus least-privilege target permissions, not an overly permissive wildcard trust relationship.

Summary

• This error is usually caused by a bad trust relationship on the execution role.
• EventBridge Scheduler must be allowed to assume the role as scheduler.amazonaws.com.
• The role also needs action permissions for the target AWS service.
• Trust policy and permissions policy solve different parts of the problem.
• If you copied events.amazonaws.com from ordinary EventBridge examples, update it for Scheduler.