Introduction

This error usually appears when a parent AWS Step Functions state machine starts another state machine synchronously and the execution role does not have permission to work with the EventBridge rule that Step Functions uses internally. The phrase not authorized to create managed-rule is a clue that the missing permission is not only states:StartExecution.

In practice, nested workflows are simple when started asynchronously, but synchronous nested workflows need extra permissions. The hidden dependency is what catches most people.

Why Nested Step Functions Need More Than StartExecution

If the parent workflow uses a synchronous integration such as states:startExecution.sync or states:startExecution.sync:2, Step Functions has to wait for the child execution to finish. To do that efficiently, AWS uses EventBridge behind the scenes.

That is why a role with only this permission is not enough:

1{
2  "Effect": "Allow",
3  "Action": "states:StartExecution",
4  "Resource": "arn:aws:states:us-east-1:123456789012:stateMachine:ChildWorkflow"
5}

The parent can start the child, but it cannot create or manage the AWS-managed EventBridge rule needed to observe the child execution lifecycle.

Typical Parent State Definition

A synchronous nested execution often looks like this:

1{
2  "Type": "Task",
3  "Resource": "arn:aws:states:::states:startExecution.sync:2",
4  "Arguments": {
5    "StateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:ChildWorkflow",
6    "Input": {
7      "jobId": "abc-123"
8    }
9  },
10  "End": true
11}

This pattern is valid, but it implies more IAM permissions than an ordinary async states:startExecution call.

Permissions the Execution Role Usually Needs

The execution role for the parent state machine typically needs permission to:

• start the child execution
• describe the child execution while waiting
• sometimes stop the child execution if the parent is canceled or times out
• work with the EventBridge managed rule used by Step Functions

A representative policy looks like this:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": [
7        "states:StartExecution"
8      ],
9      "Resource": "arn:aws:states:us-east-1:123456789012:stateMachine:ChildWorkflow"
10    },
11    {
12      "Effect": "Allow",
13      "Action": [
14        "states:DescribeExecution",
15        "states:StopExecution"
16      ],
17      "Resource": "arn:aws:states:us-east-1:123456789012:execution:ChildWorkflow:*"
18    },
19    {
20      "Effect": "Allow",
21      "Action": [
22        "events:PutRule",
23        "events:PutTargets",
24        "events:DescribeRule"
25      ],
26      "Resource": "arn:aws:events:us-east-1:123456789012:rule/StepFunctionsGetEventsForStepFunctionsExecutionRule"
27    }
28  ]
29}

Depending on how you manage the environment and cleanup path, you may also need related EventBridge rule-management permissions. The exact least-privilege shape depends on the integration pattern and account setup, but the missing EventBridge actions are the core reason for this error.

Async Nested Workflows Are Different

If you do not need the parent to wait for the child result, an asynchronous nested start is simpler.

1{
2  "Type": "Task",
3  "Resource": "arn:aws:states:::states:startExecution",
4  "Arguments": {
5    "StateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:ChildWorkflow",
6    "Input": {
7      "jobId": "abc-123"
8    }
9  },
10  "End": true
11}

In that case, states:StartExecution may be enough because the parent is not waiting on the child with the synchronous integration behavior.

How to Diagnose It Quickly

When you see not authorized to create managed-rule, check three things in order:

1. whether the parent uses a synchronous nested Step Functions integration
2. which IAM role the parent state machine is actually assuming at runtime
3. whether that role has the required EventBridge rule permissions on the managed rule resource

CloudWatch logs and the execution history usually make it clear that the failure happens during orchestration setup, not inside the child workflow logic itself.

Common Pitfalls

• Granting only states:StartExecution and assuming that is sufficient for synchronous nested workflows.
• Forgetting that .sync integrations add hidden infrastructure permissions through EventBridge.
• Updating the wrong IAM role because the deployed state machine is using a different execution role than expected.
• Debugging the child workflow definition even though the failure occurs before the child is fully orchestrated.
• Using overly broad permissions to make the error disappear instead of understanding which EventBridge actions are actually required.

Summary

• The error usually means a synchronous nested Step Functions workflow lacks EventBridge managed-rule permissions.
• 'states:StartExecution alone is not enough for .sync nested executions.'
• The parent execution role typically also needs states:DescribeExecution, possibly states:StopExecution, and EventBridge rule permissions.
• If you do not need to wait for the child result, asynchronous states:startExecution avoids this specific requirement.
• Focus on the parent workflow's IAM role, not just the child state machine definition.