AWS Step Functions allow you to design and build the flow of execution of AWS serverless modules in an application. This lets developers focus solely on ensuring that each module performs its intended task, without having to worry about connecting each module with others.
Step Functions is an orchestrator that helps to design and implement complex workflows. When we need to build a workflow or have multiple tasks that need orchestration, Step Functions coordinates between those tasks. This makes it simple to build multi-step systems.
Step Functions is built on two main concepts: Tasks and State Machine.
All work in the state machine is done by tasks. A task performs work by using an activity or an AWS Lambda function, or passing parameters to the API actions of other services.
A state machine is defined using the JSON-based Amazon States Language. When an AWS Step Functions state machine is created, it stitches the components together and shows the developers their system and how it is being configured. Have a look at a simple example:
In this article, you will learn:
As discussed earlier, the state machine is a core component of the AWS Step Functions service. It defines communication between states and how data is passed from one state to another.
A state is referred to by its name, which can be any string but must be unique within the scope of the entire state machine. It does the following functions:
Here is an example of a state definition for Task type:
Product
Pricing
Resources
All Resources
Docs
The Serverless Blog
Guides
Company"States": {
"FirstState": {
"Type": "Task",
"Resource": "arn:aws:lambda:ap-southeast-2:710187714096:function:DivideNumbers",
"Next": "ChoiceState"
}Learn more about AWS Serverless in our article: What is AWS X Ray?
A Task is the basic unit of work in Step Functions. It represents a single unit of work performed by a state machine. A Task does its work in one of three ways:
You can define a Task by setting a state to “Type”: “Task” and providing the Amazon Resource Name (ARN) of the activity or Lambda function the Task should invoke.
For Step Functions, input is always passed as a JSON file to the first state. However, it has to pass through InputPath, ResultPath and OutputPath before the final output is generated. JSON output is then passed to the next state.
Image Source: AWS
InputPath – selects which parts of the JSON input to pass to the task of the Task state (for example, an AWS Lambda function).
ResultPath then selects what combination of the state input and the task result to pass to the output.
OutputPath can filter the JSON output to further limit the information that’s passed to the output.
Let’s take a look at an example to better understand this in detail:
For Lambda execution, Input is described as JSON like above. That input is bound to the symbol $ and passed on as the input to the first state in the state machine.
By default, the output of each state would be bound to $ and becomes the input of the next state. In Each state, we have InputPath, ResultPath and OutputPath attributes which filters the input and provide the final output. In the above scenario, “ExamResults” state is filtering “lambda” node, appending the result of a state execution to “results” node and final output is just “result” node rather than the whole JSON object:
Hence, the final output will be:
{
"math": 80,
"eng": 93,
"total": 173
},In Step Functions, you handle errors using retries and catch. The Amazon State Language lets you catch errors and define a retry – what to do to resume the operation.
Step Functions Retry
Here is a simple example (shared in the Step Functions documentation). It shows how Step Functions can identify an error handled in a Lambda function it is invoking, and retry the function invocation. You can also define maximum times to retry when an error is encountered, and a backoff rate – a multiplier by which the retry time increases with every retry attempt.
{
"StartAt": "HelloWorld",
"States": {
"HelloWorld": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:FailFunction",
"Retry": [ {
"ErrorEquals": ["HandledError"],
"IntervalSeconds": 1,
"MaxAttempts": 2,
"BackoffRate": 2.0
} ],
"End": true
}
}
}
In more complex retry scenarios, you can perform different retry logic depending on the specific error thrown by the Lambda function. This also lets you log why specific tasks failed. You can use a Catch clause to define what should happen in case any other error occurs.
"Retry": [ {
"ErrorEquals": [ "ErrorA", "ErrorB" ],
"IntervalSeconds": 1,
"BackoffRate": 2.0,
"MaxAttempts": 2
}, {
"ErrorEquals": [ "ErrorC" ],
"IntervalSeconds": 5
} ],
"Catch": [ {
"ErrorEquals": [ "States.ALL" ],
"Next": "Z"
} ]Step Functions can be triggered in four ways :
As I mentioned earlier, Step Functions is not only about Lambda Functions. It has support for several other Integration Patterns like SQS, DynamoDB, SNS, ECS, and many others.
The Amazon State Language lets you directly call AWS services from your state definition. The following services are available directly from a step function:
These examples were shared in the Step Functions documentation.
The following example shows how to invoke a Lambda function directly from a Task state in Step Functions:
...
"MyStateName":{
"Type":"Task",
"Resource":"arn:aws:lambda:us-west-2:01234567890:function:my_lambda_function",
"End":true
...You can create a state machine that invokes a Lambda function and waits for its input to continue to the next task. In the example below, a Task state invokes a Lambda function called my-function, passing an event payload with three parameters. When the Lambda function succeeds and returns a response, it transitions to “NEXT_STATE”.
...
"Invoke": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Parameters": {
"FunctionName": "arn:aws:lambda:us-east-2:123456789012:function:my-function:1",
"Payload": {
"max-depth": 10,
"current-depth": 0,
"error-rate": 0.05
}
},
"Next": "NEXT_STATE",
"TimeoutSeconds": 25
}
You can also invoke the Lambda function asynchronously by setting “InvocationType“: “Event“.
AWS Step Functions offers a pricing model based on usage, depending on the type of workflow you are using – a standard or an express workflow. Each time a workflow step is executed, the system counts a state transition. The system then creates a billing price according to the total number of state transitions, including all state machines as well as retries.
Step Functions provides a free tier that provides 4,000 state transitions per month at no charge. If you exceed this usage, you are billed according to the official pricing. The system meters all charges daily and bills the total amount on a monthly basis.
Beyond the free tier, there are two main pricing models:
Standard workflows
Express workflows
There are many use cases that can be resolved using Step Functions. However, we’ll restrict ourselves to a few major ones here:
If you have many Batch Jobs to be processed sequentially and need to coordinate the data between those, this is the best solution. For example, an e-commerce website can first read the product data and the next job will find out which products are running out of stock soon and then, the third job can send a notification to all the vendors to expedite the supply process.
If a workflow needs manual approval/intervention, AWS Step Function would be the best solution to coordinate it. For example, the Employee promotion process – It needs approval from the manager. So the Step function can send the email using AWS SES service with Approve or Reject link and once receives it, can trigger the next action using lambda or ECS jobs.
AWS Step functions can help to make a decision about how best to process data. Based on the file size, you can decide to use either lambda, ECS or on-premise activity to optimize the cost and runtime both.
Retry: Before Step Functions, there was no easy way to retry in the event of a timeout error or runtime error or any other type of failure. It also provides an exponential backoff feature.
"Retry": [ {
"ErrorEquals": [ "States.Timeout" ],
"IntervalSeconds": 3,
"MaxAttempts": 2,
"BackoffRate": 1.5
} ]Error Handling: It provides an easy way of error handling at each state. It can handle several types of errors a state can throw out, like:
It can also catch Lambda service exceptions(Lambda.ServiceException) and even the unhandled errors (Lambda.Unknown). A typical example for an error handling:
"Catch": [ {
"ErrorEquals": [ "States.TaskFailed", “States.Permission” ],
"Next": “state x”
} ]Additional benefits of Step Functions include:
Despite all the powerful features Step Functions offers, there are still a few things missing:
In addition to the above drawbacks, the Step Functions service has several built-in service limits you should be aware of:
While the above limitations cannot be changed, others can be increased. You can, for example, request to increase the number of concurrent executions or the number of state machines per each account. You can submit your request in the AWS Support Center.
Here are several alternatives to Step Functions within the AWS ecosystem:
Use the following best practices to avoid common pitfalls with AWS Step Functions:
"ExamResults": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:HelloFunction",
"TimeoutSeconds": 200,
"HeartbeatSeconds": 30,
"End": true
}Using TimeoutSeconds & HeartbeatSeconds, we can design a long-running workflow alive. HeartbeatSeconds value should be less than TimeoutSeconds. And, we need to use SendTaskHeartbeat periodically within the time we set in HeartbeatSeconds in our state machine task definition to keep the task from timing out.
Similar to Lambda functions, Step Functions also sends logs to CloudWatch and it generates several metrics around it. For example, Execution metrics, Activity metrics, Lambda metrics, etc. Below is an example of Execution Metrics:
Visual Workflow panel shows the current status of the execution. Look at the right side of the panel (below picture). We can see the details of any state by clicking on the state in the workflow diagram. It shows the input, output, and an exception (if any) for the state.
It also logs the execution history and status for each state. AWS Console does provide a nice visual of the states from start to end. We can also click on CloudWatch Logs to go to LogGroups and see detail logs.
One recommendation is to create a Unique Trace ID which should be passed to all the integration services these states connect to. It will help to track the transactions easily.
It also has integration with CloudTrail to log the events.
Another option is to integrate Step Functions with Lumigo, the serverless monitoring platform. You can start using Lumigo free, and you’ll be able to see dashboards showing function invocations, cold starts, estimates of costs, and detailed information about every transaction in your system.
To learn more see our blog post, or get a free Lumigo account and start monitoring Step Functions.
In this article, we explored the basic concepts of Step Functions and how it works. We also talked about how with the Visualization panel, Error Handling and Retry features, it makes the workflow creation process much smoother. Step Functions should properly be described as state-as-a-service. Without it, we would not be able to maintain the state of each execution having multiple lambda functions/activities.
Just keep in mind that you need to keep a watch on your bills as it can burn a hole in your pocket very fast. And the best way to do that is to ensure that proper monitoring and metrics are in place.
Learn how easy AWS serverless monitoring can be with Lumigo
