Amazon SQS Parameters

An Amazon SQS message has three basic states:

1. Sent to a queue by a producer
2. Received from the queue by a consumer
3. Deleted from the queue

A message is stored after it is sent to a queue by a producer but not yet received from the queue by a consumer (that is, between states 1 and 2). There is no limit to the number of stored messages. A message is considered to be in-flight after it is received from a queue by a consumer but not yet deleted from the queue (that is, between states 2 and 3). There is a limit to the number of in-flight messages.

Limits that apply to in-flight messages are unrelated to the unlimited number of stored messages.

For most standard queues (depending on queue traffic and message backlog), there can be a maximum of approximately 120,000 in-flight messages (received from a queue by a consumer but not yet deleted from the queue). If you reach this limit, Amazon SQS returns the OverLimit error message. To avoid reaching the limit, delete messages from the queue after they are processed. You can also increase the number of queues if you file an AWS Support request.

For first-in, first-out (FIFO) queues, there can be a maximum of 20,000 in-flight messages (received from a queue by a consumer but not yet deleted from the queue). If you reach this limit, Amazon SQS returns no error messages.

Dead-Letter Queue

Amazon SQS supports dead-letter queues, which other queues (source queues) can target for messages that cannot process (be consumed) successfully. Dead-letter queues are useful when you debug your application or message system because the queues let you isolate problematic messages to determine why their process did not succeed.

Sometimes messages do not process because of a variety of possible issues, such as erroneous conditions within the producer or consumer application or an unexpected state change that causes an issue with your application code. For example, if a user places a web order with a particular product ID but the product ID is deleted, the web store’s code fails and displays an error, and the message with the order request is sent to a dead-letter queue.

Occasionally, producers and consumers might fail to interpret aspects of the protocol that they use to communicate, causing message corruption or loss. Also, the consumer’s hardware errors might corrupt message payload.

If the consumer of the source queue fails to process a message in the number of times you specify, the redrive policy (RedrivePolicy) specifies the source queue, the dead-letter queue, and the conditions under which Amazon SQS moves messages from the former to the latter. When the ReceiveCount value for a message exceeds the maxReceiveCount value for a queue, Amazon SQS moves the message to a dead-letter queue. For example, if the source queue has a redrive policy with maxReceiveCount set to 5 and the consumer of the source queue receives a message five times and it does not delete, Amazon SQS moves the message to the dead-letter queue.

To specify a dead-letter queue, you can use the AWS Management Console or the AWS SDK for Java for each queue that sends messages to a dead-letter queue. Multiple queues can target a single dead-letter queue. The dead-letter queue uses the CreateQueue or SetQueueAttributes action.

Use the same AWS account to create the dead-letter queue and the other queues that send messages to the dead-letter queue. Also, dead-letter queues must reside in the same region as the other queues that use the dead-letter queue. For example, if you create a queue in the US East (Ohio) Region, and you want to use a dead-letter queue with that queue, the second queue must also be in the US East (Ohio) Region.

The expiration of a message is based on its original enqueue timestamp. When a message moves to a dead-letter queue, the enqueue timestamp does not change. For example, if a message spends one day in the original queue before it moves to a dead-letter queue and the retention period of the dead-letter queue is set to 5 days, the message is deleted from the dead-letter queue after 3 days. Thus, AWS recommends that you set the retention period of a dead-letter queue to be longer than the retention period of the original queue.

Monitoring Amazon SQS Queues Using Amazon CloudWatch

Amazon CloudWatch monitors your AWS resources and the applications you run on AWS in real time. You can use CloudWatch to collect and track metrics, which are variables that you can measure for your resources and applications.

CloudWatch alarms send notifications or automatically make changes to the resources you monitor based on rules that you define, for example, when a message is sent to the dead-letter queue.

If you must pass messages to other users, create an Amazon SQS queue, subscribe all the administrators to this queue, and then configure Amazon CloudWatch Events to send a message on a daily cron schedule into the Amazon SQS queue.

CloudWatch provides a reliable, scalable, and flexible monitoring solution with no need to set up, manage, and scale your own monitoring systems and infrastructure. You may also use Amazon CloudWatch Logs to monitor, store, and access your log files from Amazon EC2 instances, AWS CloudTrail, or other sources.

The AWS/Events namespace includes the DeadLetterInvocations metric, as shown in Table 11.4. The DeadLetterInvocations metric uses Count as the unit, so Sum and SampleCount are the most useful statistics.

Features and Functionality

Amazon SNS topic names have a limit of 256 characters. Topic names must be unique within an AWS account and can include alphanumeric characters plus hyphens (-) and underscores (_). After you delete a topic, you can reuse the topic name. When a topic is created, Amazon SNS assigns a unique Amazon Resource Name (ARN) to the topic, which includes the service name (SNS), AWS Region, AWS ID of the user, and topic name. The ARN returns as part of the API call to create the topic. Whenever a producer or consumer needs to perform any action on the topic, you reference the unique topic ARN.

For example, Amazon SNS clients use the ARN address to identify the right topic.

aws sns publish --topic-arn topic-arn --message "message" --message-attributes '{"store":{"DataType":"String","StringValue":"example_corp"}}'

This is the ARN for a topic named mytopic that you create with the account ID 123456789012 and host in the US East Region:

arn:aws:sns:us-east-1:1234567890123456:mytopic

Do not attempt to build the topic ARN from its separate components—topics should use the name the API calls to create the topic returns.

Amazon SNS APIs

Amazon SNS provides a set of simple APIs to enable event notifications for topic owners, consumers, and producers.

Transport Protocols

Amazon SNS supports notifications over multiple transport protocols. You can select transports as part of the subscription requests.

• HTTP, HTTPS: Subscribers specify a URL as part of the subscription registration; notifications are delivered through an HTTP POST to the specified URL.
• Email, Email-JSON: Messages are sent to registered addresses as email. Email-JSON sends notifications as a JSON object, while Email sends text-based email.
• Amazon SQS: Users specify an Amazon SQS standard queue as the endpoint. Amazon SNS enqueues a notification message to the specified queue (which subscribers can then process with Amazon SQS APIs, such as ReceiveMessage and DeleteMessage). Amazon SQS does not support FIFO queues.
• SMS: Messages are sent to registered phone numbers as AWS SMS text messages.

Amazon SNS Mobile Push Notifications

With Amazon SNS, you can send push notification messages directly to apps on mobile devices. Push notification messages sent to a mobile endpoint can appear in the mobile app as message alerts, badge updates, or even sound alerts.

You send push notification messages to both mobile devices and desktops with the following push notification services:

• Amazon Device Messaging (ADM)
• Apple Push Notification Service (APNS) for both iOS and macOS
• Baidu Cloud Push (Baidu)
• Google Cloud Messaging for Android (GCM)
• Microsoft Push Notification Service for Windows Phone (MPNS)
• Windows Push Notification Services (WNS)

Push notification services, such as APNS and GCM, maintain a connection with each app and mobile device registered to use their service. When an app and mobile device are registered, the push notification service returns a device token. Amazon SNS uses the device token to create a mobile endpoint to which it can send direct push notification messages. For Amazon SNS to communicate with the different push notification services, you submit your push notification service credentials to Amazon SNS.

You can also use Amazon SNS to send messages to mobile endpoints subscribed to a topic. The concept is the same as subscribing other endpoint types. The difference is that Amazon SNS communicates with the push notification services for the subscribed mobile endpoints to receive push notification messages sent to the topic. Figure 11.10 shows a mobile endpoint as a subscriber to an Amazon SNS topic. The mobile endpoint communicates with push notification services, whereas the other endpoints do not.

Billing, Limits, and Restrictions

Amazon SNS includes a Free Tier, which allows you to use Amazon SNS free of charge for the first 1 million Amazon SNS requests, and with no charges for the first 100,000 notifications over HTTP, no charges for the first 100 notifications over SMS, and no charges for the first 1,000 notifications over email.

With Amazon SNS, there is no minimum fee, and you pay only for what you use. You pay $0.50 per 1 million Amazon SNS requests, $0.06 per 100,000 notification deliveries over HTTP, and $2 per 100,000 notification deliveries over email. For SMS messaging, users can send 100 free notification deliveries, and for subsequent messages, charges vary by destination country.

By default, Amazon SNS offers 10 million subscriptions per topic and 100,000 topics per account. To request a higher limit, contact AWS Support.

When compared with Amazon SQS, which is a queue with a pull mechanism, Amazon SNS is a fanout with a push mechanism to send messages to subscribers. This means that the Amazon SNS message is sent to a topic and then replicated and pushed to multiple Amazon SQS queues, HTTP endpoints, or email addresses. This operation eliminates the need for the message consumers to poll for any new messages. There several differences between the Amazon SNS and Amazon SQS event-driven solutions, as listed in Table 11.5.

Multiple Applications

There are several differences between Amazon Kinesis Data Streams and Amazon SQS.

In Amazon SQS, when a consumer receives a message off the queue and then processes and deletes it, the message is no longer available for any other consumer.

In Amazon Kinesis Data Streams, you can process the same message by multiple applications. Each application tracks which records it last processed. Then it requests the records that came after it. It is the application’s responsibility to track its checkpoint within the data stream.

Amazon Kinesis Data Streams do not delete records after they process them, as it is possible that another application will request the message. Records automatically delete after their retention interval expires, which you configure. The default retention interval is 1 day, but you can extend it up to 7 days. Before the record’s interval expires, multiple applications can consume the message.

High Throughput

Amazon Kinesis uses shards to configure and support high throughput. When you create an Amazon Kinesis data stream, specify the number of shards in your stream. You can increase or decrease the number of shards through the API.

On the producer side, the shard supports 1 MB per second of ingest, or 1,000 transactions per second. Producers can write up to 1 MB per second of data, or 1000 writes.

On the consumer side, each shard supports 2 MB per second of reads, or five transactions per second. Amazon Kinesis Data Streams support twice as much data for reads as they do for writes (2 MB per second of read versus 1 MB per second of write) per shard. This allows multiple applications to read from a stream to enable more reads. Because the same records might be read by multiple applications, you require more throughput on the read side.

Amazon Kinesis Data Streams support 5,000 transactions per second for writes, but only five transactions per second for reads per shard. Reads frequently acquire many records at once. When a read request asks for all the records that came in after the last read, it acquires a large number of records. Because of this, five transactions per second per shard is sufficient to handle reads.

To increase your throughput capacity, reshard the stream to adjust the number of shards.

Real-Time Analytics

Unlike Amazon SQS, Amazon Kinesis Data Streams enable real-time analytics, which produces metrics from incoming data as it arrives. The alternative is batch analytics in which the data accumulates for a period, such as 24 hours, and then is analyzed as a batch job. Real-time analytics allow you to detect patterns in the data immediately as it arrives, with a delay of only a few seconds to a few minutes.

After you define your monitoring goals and create your monitoring plan, the next step is to establish a baseline for normal Kinesis Video Streams performance in your environment. Measure Kinesis Video Streams performance at various times and under different load conditions. As you monitor Kinesis Video Streams, you should store a history of the monitored data that you collect. You can compare current Kinesis Video Streams performance to this historical data to help you identify normal performance patterns and performance anomalies and devise methods to address issues that may arise.

Open Source Tools

Open source tools, such as Fluentd and Flume, support Amazon Kinesis Data Streams as a destination, and you can use them to publish messages into an Amazon Kinesis data stream.

Your custom applications, real-time or batch-oriented, can run on Amazon EC2 instances. These applications might process data with open source deep-learning algorithms or use third-party applications that integrate with Kinesis Video Streams.

Producer Options

After you create the stream in Amazon Kinesis data stream, you need two applications to build your pipeline: a collection of producers that write data into the stream and consumers to read the data from the stream.

Here are options for you to build producers that can write into Amazon Kinesis Data Streams:

Amazon Kinesis Agent This is an application that reads data, appends to a log file, and writes to the stream. The benefit of the Amazon Kinesis Agent is that it does not require you to write application code.

Amazon Kinesis Data Steams API You write an application to use the Amazon Kinesis Data Streams API to put data on the stream.

Amazon Kinesis Producer Library (KPL) The KPL gives you a higher-level interface over the low-level Amazon Kinesis Data Streams API. It has the logic to retry failures and to buffer and batch-send multiple messages together. The KPL makes it easier to write messages into a stream than if you use the low-level API.

Consumer Options

Consumers have the following options for the Amazon Kinesis Data Streams:

Amazon Kinesis Data Streams API You can write an application with the Amazon Kinesis Data Streams API to read data from a stream. To scale this to process large volumes of data, create a shard for each consumer. With multiple consumers that run independently, there is a risk that one of them might fail. To handle failure, coordinate between the consumers. Use the Amazon Kinesis Client Library (KCL) to track your consumers and shards.

Amazon Kinesis Client Library The Amazon Kinesis Client Library handles the complexity of coordinating between different consumers that read from different shards in a stream. It ensures that no shard is ignored, and no shard is processed by two consumers. The library creates a table in Amazon DynamoDB with the same name as the application name and uses this table to coordinate between the different consumers.

AWS Lambda AWS Lambda is another option that you can use to build Amazon Kinesis Data Streams for consumers. AWS Lambda can scale and handle fault tolerance automatically. It does not require the use of the KCL.

Amazon DynamoDB Streams Use Case

Amazon DynamoDB Streams is a database trigger for Amazon DynamoDB tables that you can use in any situation in which you continuously poll the database to indicate if a variable changes. An example would be a customer who publishes a vote in an Amazon DynamDB table called votes in an online application. With Amazon DynamoDB Streams, you can automatically track that change in both the votes table and in the consumer table to update the aggregate votes counted.

Amazon DynamoDB Streams Consumers

Amazon DynamoDB integrates with AWS Lambda so that you can create triggers, which are pieces of code that automatically respond to events in DynamoDB Streams. With triggers, you can build applications that react to data modifications in DynamoDB tables.

An AWS Lambda function or application that accesses the Amazon DynamoDB Streams API consumes the event when it publishes in the stream.

If you enable DynamoDB Streams on a table, you can associate the stream ARN with a Lambda function that you write. Immediately after you modify an item in the table, a new record appears in the table’s stream. AWS Lambda polls the stream and invokes your AWS Lambda function synchronously when it detects new stream records.

The AWS Lambda function can perform any actions you specify, such as to send a notification or initiate a workflow. For example, you can write a Lambda function simply to copy each stream record to persistent storage, such as Amazon S3, to create a permanent audit trail of write activity in your table. Or, suppose that you have a mobile gaming app that writes to a GameScores table. Whenever the TopScore attribute of the GameScores table updates, a stream record writes to the table’s stream. This event could then trigger an AWS Lambda function that posts a congratulatory message on a social media network. The function would ignore any stream records that are not updates to GameScores or that do not modify the TopScore attribute.

Amazon DynamoDB Streams Concurrency and Shards

When you run an Amazon DynamoDB as a database backend, a large number of changes can occur at the same time. Amazon DynamoDB Streams publishes the changes in your table into multiple shards.

If you create a consumer application using AWS Lambda, each AWS Lambda instance processes the messages in a particular shard. This enables concurrent processing and allows Amazon DynamoDB Streams to scale to handle a high volume of concurrent changes. At any given time, each partition in an Amazon DynamoDB table maps to a single shard. The single shard captures all updates to that partition.

Rules Engine

When messages enter the AWS IoT Device Management service, the service dispatches them to different AWS endpoints. AWS IoT rule actions specify what to do when a rule is triggered. AWS IoT can dispatch the messages to AWS Lambda, an Amazon Kinesis data stream, a DynamoDB database, and other services. This dispatch is done through the AWS IoT rules engine. Rules give your devices the ability to interact with AWS products and services. Rules are analyzed, and actions occur based on the MQTT topic stream.

The IoT rules engine supports the following actions:

CloudWatch alarm action Use this to change the Amazon CloudWatch alarm state. Specify the state change reason and value in this call.

Amazon CloudWatch metric action The CloudWatch metric action allows you to capture an Amazon CloudWatch metric. Specify the metric namespace, name, value, unit, and timestamp.

DynamoDB action The dynamoDB action allows you to write all or part of an MQTT message to an Amazon DynamoDB table.

DynamoDBv2 action The dynamoDBv2 action allows you to write all or part of an MQTT message to an Amazon DynamoDB table. Each attribute in the payload is written to a separate column in the Amazon DynamoDB database.

Elasticsearch action The elasticsearch action allows you to write data from MQTT messages to an Amazon ES domain. You can query and visualize data in Amazon ES with tools such as Kibana.

Firehose action A firehose action sends data from an MQTT message that triggers the rule to a Kinesis Data Firehose stream.

IoT Analytics action An iotAnalytics action sends data from the MQTT message that triggers the rule to an AWS IoT Analytics channel.

Kinesis action The kinesis action allows you to write data from MQTT messages into a Kinesis stream.

Lambda action A lambda action calls an AWS Lambda function to pass it to a MQTT message that triggers the rule.

Republish action The republish action allows you to republish the message that triggers the role to another MQTT topic.

S3 action An s3 action writes the data from the MQTT message that triggers the rule to an Amazon S3 bucket.

Salesforce action A salesforce action sends data from the MQTT message that triggers the rule to a Salesforce IoT Input Stream.

SNS action An sns action sends the data from the MQTT message that triggers the rule as an Amazon SNS push notification.

Amazon SQS action An sqs action sends data from the MQTT message that triggers the rule to an Amazon SQS queue.

Step Functions action A stepFunctions action starts execution of an AWS Step Functions state machine.

Message Broker

The AWS IoT message broker is a publish/subscribe broker service that enables you to send messages to and receive messages from IoT. When you communicate with AWS IoT, a client sends a message to a topic address such as Sensor/temp/room1. The message broker then sends the message to all clients that have registered to receive messages for that topic. The act of sending the message is referred to as publishing. The act of registering to receive messages for a topic filter is referred to as subscribing.

The topic namespace is isolated for each account and region pair. For example, the Sensor/temp/room1 topic for an account is independent from the Sensor/temp/room1 topic for another account. This is true of regions, too. The Sensor/temp/room1 topic in the same account in us-east-1 is independent from the same topic in us-east-2.

The message broker maintains a list of all client sessions and the subscriptions for each session. When a message publishes on a topic, the broker checks for sessions with subscriptions that map to the topic. The broker then forwards the message to all sessions that have a currently connected client.

Device Shadow

The AWS IoT device shadow is an always-available representation of the device, which allows communications back from cloud applications to the IoT devices. Cloud applications can update the device shadow even when the underlying IoT device is offline. Then when the device is brought back online, it synchronizes its final state with a query to the AWS IoT service for the current state of the instances.

A device’s shadow is a JavaScript Object Notation (JSON) document that stores and retrieves current state information for a device. The device shadow service maintains a shadow for each device that you connect to AWS IoT. You can use the shadow to get and set the state of a device over MQTT or HTTP, regardless of whether the device is connected to the internet. Each device’s shadow is uniquely identified by the name of the corresponding thing. The device shadow service acts as an intermediary that allows devices and applications to retrieve and update a device’s shadow.

Amazon MQ is a managed message broker service that provides compatibility with many popular message brokers. AWS recommends Amazon MQ to migrate applications from current message brokers that rely on compatibility with APIs, such as JMS, or protocols like Advanced Message Queuing Protocol (AMQP), MQTT, OpenWire, and STOMP.

Amazon SQS and Amazon SNS are queue and topic services that are highly scalable, simple to use, and do not require you to set up message brokers. AWS recommends these services for new applications that can benefit from nearly unlimited scalability and simple APIs.

State Machine

The state machine is the workflow template that is made up of a collection of states. Each time you launch a workflow, you provide it with an input. Each state that is part of the state machine receives the input, modifies it, and passes it to the next state.

These workflow templates are called state machines. You can use AWS Step Functions as event sources to trigger AWS Lambda. Figure 11.16 is an example of using the AWS Step Functions service.

Use AWS Step Functions to build visual workflows that enable fast translation of business requirements into technical requirements. You can build applications in a matter of minutes. When your needs change, you can swap or reorganize components without customizing any code.

AWS Step Functions manages state, checkpoints, and restarts for you to make sure that your application executes in order and as you would expect. Built-in try/catch, retry, and rollback capabilities deal with errors and exceptions automatically.

AWS Step Functions manages the logic of your application for you, and it implements basic primitives such as branching, parallel execution, and timeouts. This removes extra code that may be repeated in your microservices and functions.

A finite state machine can express an algorithm as a number of states, their relationships, and their input and output. AWS Step Functions allows you to coordinate individual tasks by expressing your workflow as a finite state machine, written in the Amazon States Language. Individual states can decide based on their input, perform actions, and pass output to other states. In Step Functions, you can express your workflows in the Amazon States Language, and the Step Functions console provides a graphical representation of that state machine to help visualize your application logic.

Names identify states, which can be any string, but must be unique within the state machine specification. Otherwise, it can be any valid string in JSON text format.

States can perform the following functions in your state machine:

• Task state: Performs work in your state machine
• Choice state: Makes a choice between branches of execution
• Fail or Succeed state: Stops an execution with a failure or success
• Pass state: Passes inputs to outputs or inject corrected data
• Wait state: Provides a delay for a certain amount of time or until a specified time/date
• Parallel state: Begins parallel branches of execution

Here is an example state named HelloWorld, which performs an AWS Lambda function:

"HelloWorld": {
  "Type": "Task",
  "Resource": "arn:aws:lambda:us-east-1:123456789012:function:HelloFunction",
  "Next": "AfterHelloWorldState",
  "Comment": "Run the HelloWorld Lambda function"
}

States share the following common features:

• Each state must have a Type field to indicate what type of state it is.
• Each state can have an optional Comment field to hold a human-readable comment about, or description of, the state.
• Each state (except a Succeed or Fail state) requires a Next field or, alternatively, can become a terminal state if you specify an End field.

These fields are common within each state:

• Type (Required): The state’s type.
• Next: The name of the next state that runs when the current state finishes. Some state types, such as Choice, allow multiple transition states.
• End: Designates this state as a terminal state (it ends the execution) if set to true. There can be any number of terminal states per state machine. State supports only one Next or End statement. Some state types, such as Choice, do not support or use the End field.
• Comment (Optional): Holds a human-readable description of the state.
• InputPath (Optional): A path that selects a portion of the state’s input to pass to the state’s task process. If omitted, it has the value $, which designates the entire input.
• OutputPath (Optional): A path that selects a portion of the state’s input to pass to the state’s output. If omitted, it has the value $, which designates the entire input.

To see the Amazon Function State Language, refer to Figure 11.17.

Task State

A task state involves a form of compute. A task executes on an AWS Lambda function or on an Amazon EC2 instance. An activity is a task that executes on an Amazon EC2 instance.

A task state ("Type": "Task") represents a single unit of work that a state machine performs.

In addition to the common state fields, task state fields include the following:

• Resource (Required): Amazon Resource Name (ARN) that uniquely identifies the specific task to execute.
• ResultPath (Optional): Specifies where in the input to place the results from the task Resource. The input is filtered as prescribed by the OutputPath field (if present) before being used as the state’s output.
• Retry (Optional): An array of objects, called Retriers, that define a retry policy if the state encounters runtime errors.
• Catch (Optional): An array of objects, called Catchers, that define a fallback state. This state is executed if the state encounters runtime errors and the retry policy has been exhausted or is not defined.
• TimeoutSeconds (Optional): If the task runs longer than the specified number of seconds, this state fails with a States.Timeout error name. This must be a positive, nonzero integer. If not provided, the default value is 99999999.
• HeartbeatSeconds (Optional): If more time than the specified seconds elapses between heartbeats from the task, then this state fails with a States.Timeout error name. This must be a positive, nonzero integer less than the number of seconds specified in the TimeoutSeconds field. If not provided, the default value is 99999999.

A Task state either must set the End field to true if the state ends the execution or must provide a state in the Next field that runs upon completion of the Task state. Here’s an example:

"ActivityState": {
  "Type": "Task",
  "Resource": "arn:aws:states:us-east-1:123456789012:activity:HelloWorld",
  "TimeoutSeconds": 300,
  "HeartbeatSeconds": 60,
  "Next": "NextState"
}

The ActivityState schedules the HelloWorld activity for execution in the us-east-1 region on the caller’s account. When HelloWorld completes, the Next state (NextState) runs.

If this task fails to complete within 300 seconds or it does not send heartbeat notifications in intervals of 60 seconds, then the task is marked as failed. Set a Timeout value and a HeartbeatSeconds interval for long-running activities.

arn:partition:service:region:account:task_type:name

arn:partition:states:region:account:activity:name

arn:partition:lambda:region:account:function:function_name
Here's an example:
"LambdaState": {
  "Type": "Task",
  "Resource": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorld",
  "Next": "NextState"
}

Choice State

The Choice state enables control flow between several different paths based on the input you select. In a choice state, you place a condition on the input. The state machine evaluates the condition, and it follows the path of the first condition that is true about the input.

A Choice state ("Type": "Choice") adds branch logic to a state machine.

Other Choice state fields include the following:

Choices (Required) An array of Choice Rules that determines which state the state machine transitions to next

Default (Optional, Recommended) The name of the state to transition to if none of the transitions in Choices is taken

This is an example of a Choice state and other states to which it transitions:

"ChoiceStateX": {
  "Type": "Choice",
  "Choices": [
    {
        "Not": {
          "Variable": "$.type",
          "StringEquals": "Private"
        },
        "Next": "Public"
    },
    {
      "Variable": "$.value",
      "NumericEquals": 0,
      "Next": "ValueIsZero"
    },
    {
      "And": [
        {
          "Variable": "$.value",
          "NumericGreaterThanEquals": 20
        },
        {
          "Variable": "$.value",
          "NumericLessThan": 30
        }
      ],
      "Next": "ValueInTwenties"
    }
  ],
  "Default": "DefaultState"
},
 
"Public": {
  "Type" : "Task",
  "Resource": "arn:aws:lambda:us-east-1:123456789012:function:Foo",
  "Next": "NextState"
},
 
"ValueIsZero": {
  "Type" : "Task",
  "Resource": "arn:aws:lambda:us-east-1:123456789012:function:Zero",
  "Next": "NextState"
},
 
"ValueInTwenties": {
  "Type" : "Task",
  "Resource": "arn:aws:lambda:us-east-1:123456789012:function:Bar",
  "Next": "NextState"
},
 
"DefaultState": {
  "Type": "Fail",
  "Cause": "No Matches!"
}

In this example, the state machine starts with the input value:

{
  "type": "Private",
  "value": 22
}

Step Functions transitions to the ValueInTwenties state, based on the value field.

If there are no matches for the Choice state’s Choices, the state in the Default field runs instead. If there is no value in the Default state, the execution fails with an error.

{
  "Variable": "$.foo",
  "NumericEquals": 1,
  "Next": "FirstMatchState"
}

{
  "Variable": "$.foo",
  "StringEquals": "MyString",
  "Next": "FirstMatchState"
}

{
  "Variable": "$.foo",
  "StringGreaterThan": "MyStringABC",
  "Next": "FirstMatchState"
}

{
  "Variable": "$.foo",
  "TimestampEquals": "2018-01-01T12:00:00Z",
  "Next": "FirstMatchState"
}

Parallel State

The Parallel state enables control flow to execute several different execution paths at the same time in parallel. This is useful if you have activities or tasks that do not depend on each other, can execute in parallel, and can help your workflow complete faster.

You can use the Parallel state ("Type": "Parallel") to create parallel branches of execution in your state machine.

In addition to the common state fields, Parallel states introduce these additional fields:

Branches (Required) An array of objects that specify state machines to execute in parallel. Each such state machine object must have the fields States and StartAt and mean the same as those in the top level of a state machine.

ResultPath (Optional) Specifies where in the input to place the output of the branches. The OutputPath field (if present) filters the input before it becomes the state’s output.

Retry (Optional) An array of objects, called Retriers, which define a retry policy in case the state encounters runtime errors.

Catch (Optional) An array of objects, called Catchers, which define a fallback state that executes in case the state encounters runtime errors and you do not define the retry policy or it has been exhausted.

A Parallel state causes AWS Step Functions to execute each branch. The state starts with the name of the state in that branch’s StartAt field, as concurrently as possible, and waits until all branches terminate (reach a terminal state) before it processes the Parallel state’s Next field. Here’s an example:

{
  "Comment": "Parallel Example.",
  "StartAt": "LookupCustomerInfo",
  "States": {
    "LookupCustomerInfo": {
      "Type": "Parallel",
      "End": true,
      "Branches": [
        {
         "StartAt": "LookupAddress",
         "States": {
           "LookupAddress": {
             "Type": "Task",
             "Resource":
               "arn:aws:lambda:us-east-1:123456789012:function:AddressFinder",
             "End": true
           }
         }
       },
       {
         "StartAt": "LookupPhone",
         "States": {
           "LookupPhone": {
             "Type": "Task",
             "Resource":
               "arn:aws:lambda:us-east-1:123456789012:function:PhoneFinder",
             "End": true
           }
         }
       }
      ]
    }
  }
}

In this example, the LookupAddress and LookupPhone branches execute in parallel. Figure 11.18 displays the workflow in the Step Functions console.

Each branch must be self-contained. A state in one branch of a Parallel state must not have a Next field that targets a field outside of that branch, nor can any other state outside the branch transition into that branch.

{
  "Comment": "Parallel Example.",
  "StartAt": "FunWithMath",
  "States": {
    "FunWithMath": {
    "Type": "Parallel",
    "End": true,
    "Branches": [
      {
        "StartAt": "Add",
        "States": {
          "Add": {
            "Type": "Task",
            "Resource": "arn:aws:swf:us-east-1:123456789012:task:Add",
            "End": true
          }
        }
      },
      {
        "StartAt": "Subtract",
        "States": {
          "Subtract": {
            "Type": "Task",
            "Resource": "arn:aws:swf:us-east-1:123456789012:task:Subtract",
            "End": true
          }
        }
      }
    ]
   }
  }
}

[ 5, 1 ]

End State

A state machine completes its execution when it reaches an end state. Each state defines either a next state or an end state, and the end state terminates the execution of the step function.

Input and Output

Each execution of the state machine requires an input as a JSON object and passes that input to the first state in the workflow. The state machine receives the initial input by the process initiating the execution. Each state modifies the input JSON object that it receives and injects its output into this object. The final state produces the output of the state machine.

Individual states receive JSON as the input and usually pass JSON as the output to the next state. Understand how this information flows from state to state and learn how to filter and manipulate this data to design and implement workflows in AWS Step Functions effectively.

In the Amazon States Language, three components filter and control the flow of JSON from state to state: InputPath, OutputPath, and ResultPath.

Figure 11.19 shows how JSON information moves through a task state. InputPath selects which components from the 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 limit further the information that passes to the output.

InputPath, OutputPath, and ResultPath each use paths to manipulate JSON as it moves through each state in your workflow.

{
    "foo": 123,
    "bar": ["a", "b", "c"],
    "car": {
        "cdr": true
    }
}

$.foo => 123
$.bar => ["a", "b", "c"]
$.car.cdr => true

{
  "title": "Numbers to add",
  "numbers": { "val1": 3, "val2": 4 }
}

"InputPath": "$.numbers",
"ResultPath": "$.sum",
"OutputPath": "$"

{
  "title": "Numbers to add",
  "numbers": { "val1": 3, "val2": 4 }
  "sum": 7
}

"InputPath": "$.numbers",
"ResultPath": "$.sum",
"OutputPath": "$.sum"

{
  "numbers": { "val1": 3, "val2": 4 }
}

AWS Step Functions Use Case

You can use state machines to process long-running workflows. For example, if a customer orders a book and it requires several different events, use the state machine to run all the events. When the customer orders the book, the state machine creates a credit card transaction, generates a tracking number for the book, notifies the warehouse to ship the order, and then emails the tracking number to the customer. The AWS Step Functions service runs all these steps.

The benefit of AWS Step Functions is that it enables the compute to be stateless. The AWS Lambda functions and the Amazon EC2 instances provide compute to the state machine to execute in a stateless way. AWS Lambda functions and Amazon EC2 do not have to remember the information about the state of the current execution. The AWS Step Functions service remembers the information about the state of the current execution.