In my we talked about how we can implement semaphores with Step Functions. Another common scenario that many people have is to handle errors from a block of states like we’re used to with a block. last post try-catch try {step1()step2()step3()} catch (States.Timeout) {...} catch (States.ALL) {...} With Step Functions, you can use and clauses to from states. There are a number of , and you can also handle custom errors that are thrown by your Lambda functions. Retry Catch handle errors Task predefined system errors You can do this by adding the same clause to each of the Task states. Catch "Catch": [{"ErrorEquals": [ "States.ALL" ],"Next": "NotifyError"}] However, this approach requires you to add the same boilerplate to every state. As your error handling strategy, or the state machine itself becomes more complex, this becomes a maintenance headache. Task Fortunately, both and can be used on states too! Retry Catch Parallel Even if you’re not looking to perform tasks in parallel, you can still use it to simplify your error handling. In this case, if I wrap , and into a single branch inside a state, then I can with one clause. Step1 Step2 Step3 Parallel catch unhandled errors from any of the steps Catch {"StartAt": "Try","States": {"Try": {"Type": "Parallel","Branches": [{"StartAt": "Step1","States": {"Step1": {"Type": "Task","Resource": "...","Next": "Step2"},"Step2": {"Type": "Task","Resource": "...","Next": "Step3"},"Step3": {"Type": "Task","Resource": "...","End": true}}}],"Catch": [{"ErrorEquals": [ "States.ALL" ],"Next": "NotifyError"}],"Next": "NotifySuccess"},...} One final caveat with this approach is that, a state wraps the output from its branches into an array. So if subsequent states?—?such as the state in the example above?—?wants to use the output from then it’ll have to take that into consideration. Parallel NotifySuccess Step3 What you can do instead, is to add a state to unwrap the array, like this: Pass "UnwrapOutput": {"Type": "Pass","InputPath": "$[0]","Next": "NotifySuccess"} This technique is useful when you want to apply the same error handling to block of states without having to resorting to boilerplates. You can add clause to the state to retry the entire block (i.e. from , even if errored). You can also add and for individual states to mix things up too. Retry Parallel Step1 Step3 Retry Catch So that’s it, a nice and short post to share with you a simple technique that I have found useful with Step Functions. I have been spending a fair bit of time with Step Functions and enjoying the service. Let me know in the comments if you have use cases that you find difficult to implement with Step Functions, I would love to hear what others are doing with it. Hi, my name is . I’m an and the author of . I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless. Yan Cui AWS Serverless Hero Production-Ready Serverless You can contact me via , and . Email Twitter LinkedIn Check out my new course, . Complete Guide to AWS Step Functions In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, design patterns and best practices. Get your copy . here Come learn about operational for AWS Lambda: CI/CD, testing & debugging functions locally, logging, monitoring, distributed tracing, canary deployments, config management, authentication & authorization, VPC, security, error handling, and more. BEST PRACTICES You can also get off the face price with the code . 40% ytcui Get your copy . here