The error message you shared seems to be suggesting that the assume role policy for the given role does not include any of the service principals used by Step Functions. The role would need an assume role policy that lists this service as one of its allowed principals:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "sts:AssumeRole",
"Principal": {
"Service": "states.amazonaws.com"
},
"Effect": "Allow",
"Sid": ""
}
]
}
In Terraform we'd usually set this as an argument of an aws_iam_role resource:
resource "aws_iam_role" "example" {
name = "stepfunctions"
assume_role_policy = jsonencode({
"Version": "2012-10-17",
"Statement": [
{
"Action": "sts:AssumeRole",
"Principal": {
"Service": "states.amazonaws.com"
},
"Effect": "Allow",
"Sid": ""
}
]
})
}
We can then refer to that role's ARN in a aws_sfn_state_machine resource, which will automatically create a dependency to ensure that Terraform will not try to create the step function until it has created the role:
resource "aws_sfn_state_machine" "example" {
name = "my-state-machine"
role_arn = aws_iam_role.example.arn
# ...
}
Unfortunately due to the internal design of AWS IAM it can sometimes take a few minutes after creating an IAM object before that object becomes fully-functional. The AWS API does not expose any totally-reliable way to detect when an IAM principal is fully-functional after a settings change, so the Terraform AWS provider often makes a best effort to poll for the completion but cannot always guarantee that.
If you still see the error you mentioned with a configuration like the above, I'd suggest to wait 10 minutes after you see the error and try running terraform apply again (without destroying the role and recreating it) to see if it works. Of course, needing to run Terraform twice to get the desired answer is far from convenient, but at least identifying delayed consistency as the cause will avoid spending time investigating other possible problems.