One way to troubleshoot would be to build a test user in IAM with admin rights (Delete this user when done with the test)
Try your step function with these enhanced rights. If it now works . . .
Use IAM Acccess analyser to build a policy that has all the needed access. https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_generate-policy.html
I'm sorry to hear that this was confusing, but the feature is working as expected. Please see the help link below. The .waitForTaskToken integration pattern allows you to pass a token to a the target of a Task that you then need to call back to Step Functions with (using the SendTaskSuccess, SendTaskFailure, etc API Actions). In the meantime, the workflow execution will wait. https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token
I believe what you expected was the behavior of the .sync / Run A Job integration pattern. Unfortunately, this is only available for a select set of API actions via Optimized Service Integrations. https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-sync https://docs.aws.amazon.com/step-functions/latest/dg/connect-supported-services.html
Given we do not have such an optimized integration for ec2:createVolume, I suggest you consider using a job-poller-pattern to check for status and continue the workflow. https://docs.aws.amazon.com/step-functions/latest/dg/sample-project-job-poller.html
A handy approach is to encapsulate this in a separate state machine that can be called using the .sync service integration for Step Functions so you can reuse it in different workflows. You can see that approach in action in this blog post: https://aws.amazon.com/blogs/compute/orchestrating-aws-glue-crawlers-using-aws-step-functions/