{"id":13527600,"url":"https://github.com/serverless-operations/serverless-step-functions","last_synced_at":"2026-04-01T17:15:09.545Z","repository":{"id":38175754,"uuid":"77513644","full_name":"serverless-operations/serverless-step-functions","owner":"serverless-operations","description":"AWS Step Functions plugin for Serverless Framework ⚡️","archived":false,"fork":false,"pushed_at":"2026-03-27T00:12:53.000Z","size":6386,"stargazers_count":1044,"open_issues_count":91,"forks_count":218,"subscribers_count":20,"default_branch":"master","last_synced_at":"2026-03-27T04:55:09.653Z","etag":null,"topics":["aws","serverless","serverless-architectures","serverless-framework","serverless-plugin","step-functions"],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/serverless-operations.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2016-12-28T07:47:43.000Z","updated_at":"2026-03-26T14:49:30.000Z","dependencies_parsed_at":"2023-02-18T13:16:24.963Z","dependency_job_id":"85bc85ac-8947-46b0-8201-dd31f7214a34","html_url":"https://github.com/serverless-operations/serverless-step-functions","commit_stats":{"total_commits":658,"total_committers":119,"mean_commits":5.529411764705882,"dds":0.7234042553191489,"last_synced_commit":"2472cc0b1795a6e51c5c82613e6283333251ef6b"},"previous_names":["horike37/serverless-step-functions"],"tags_count":149,"template":false,"template_full_name":null,"purl":"pkg:github/serverless-operations/serverless-step-functions","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-operations%2Fserverless-step-functions","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-operations%2Fserverless-step-functions/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-operations%2Fserverless-step-functions/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-operations%2Fserverless-step-functions/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/serverless-operations","download_url":"https://codeload.github.com/serverless-operations/serverless-step-functions/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/serverless-operations%2Fserverless-step-functions/sbom","scorecard":{"id":469152,"data":{"date":"2025-08-11","repo":{"name":"github.com/serverless-operations/serverless-step-functions","commit":"ab6f6e663ff1a5591d9fc2851d0fb57aaf67f270"},"scorecard":{"version":"v5.2.1-40-gf6ed084d","commit":"f6ed084d17c9236477efd66e5b258b9d4cc7b389"},"score":3.9,"checks":[{"name":"Maintained","score":9,"reason":"7 commit(s) and 4 issue activity found in the last 90 days -- score normalized to 9","details":null,"documentation":{"short":"Determines if the project is \"actively maintained\".","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#maintained"}},{"name":"Dangerous-Workflow","score":10,"reason":"no dangerous workflow patterns detected","details":null,"documentation":{"short":"Determines if the project's GitHub Action workflows avoid dangerous patterns.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#dangerous-workflow"}},{"name":"Packaging","score":-1,"reason":"packaging workflow not detected","details":["Warn: no GitHub/GitLab publishing workflow detected."],"documentation":{"short":"Determines if the project is published as a package that others can easily download, install, easily update, and uninstall.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#packaging"}},{"name":"Code-Review","score":6,"reason":"Found 9/14 approved changesets -- score normalized to 6","details":null,"documentation":{"short":"Determines if the project requires human code review before pull requests (aka merge requests) are merged.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#code-review"}},{"name":"Binary-Artifacts","score":10,"reason":"no binaries found in the repo","details":null,"documentation":{"short":"Determines if the project has generated executable (binary) artifacts in the source repository.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#binary-artifacts"}},{"name":"Token-Permissions","score":0,"reason":"detected GitHub workflow tokens with excessive permissions","details":["Warn: topLevel 'checks' permission set to 'write': .github/workflows/config.yml:9","Warn: topLevel 'contents' permission set to 'write': .github/workflows/config.yml:11","Info: no jobLevel write permissions found"],"documentation":{"short":"Determines if the project's workflows follow the principle of least privilege.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#token-permissions"}},{"name":"Pinned-Dependencies","score":0,"reason":"dependency not pinned by hash detected -- score normalized to 0","details":["Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/config.yml:18: update your workflow using https://app.stepsecurity.io/secureworkflow/serverless-operations/serverless-step-functions/config.yml/master?enable=pin","Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/config.yml:19: update your workflow using https://app.stepsecurity.io/secureworkflow/serverless-operations/serverless-step-functions/config.yml/master?enable=pin","Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/config.yml:28: update your workflow using https://app.stepsecurity.io/secureworkflow/serverless-operations/serverless-step-functions/config.yml/master?enable=pin","Warn: npmCommand not pinned by hash: .github/workflows/config.yml:23","Info:   0 out of   3 GitHub-owned GitHubAction dependencies pinned","Info:   0 out of   1 npmCommand dependencies pinned"],"documentation":{"short":"Determines if the project has declared and pinned the dependencies of its build process.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#pinned-dependencies"}},{"name":"CII-Best-Practices","score":0,"reason":"no effort to earn an OpenSSF best practices badge detected","details":null,"documentation":{"short":"Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#cii-best-practices"}},{"name":"Security-Policy","score":0,"reason":"security policy file not detected","details":["Warn: no security policy file detected","Warn: no security file to analyze","Warn: no security file to analyze","Warn: no security file to analyze"],"documentation":{"short":"Determines if the project has published a security policy.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#security-policy"}},{"name":"License","score":9,"reason":"license file detected","details":["Info: project has a license file: LICENSE.txt:0","Warn: project license file does not contain an FSF or OSI license."],"documentation":{"short":"Determines if the project has defined a license.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#license"}},{"name":"Fuzzing","score":0,"reason":"project is not fuzzed","details":["Warn: no fuzzer integrations found"],"documentation":{"short":"Determines if the project uses fuzzing.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#fuzzing"}},{"name":"Branch-Protection","score":0,"reason":"branch protection not enabled on development/release branches","details":["Warn: branch protection not enabled for branch 'master'"],"documentation":{"short":"Determines if the default and release branches are protected with GitHub's branch protection settings.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#branch-protection"}},{"name":"Signed-Releases","score":-1,"reason":"no releases found","details":null,"documentation":{"short":"Determines if the project cryptographically signs release artifacts.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#signed-releases"}},{"name":"SAST","score":0,"reason":"SAST tool is not run on all commits -- score normalized to 0","details":["Warn: 0 commits out of 27 are checked with a SAST tool"],"documentation":{"short":"Determines if the project uses static code analysis.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#sast"}},{"name":"Vulnerabilities","score":0,"reason":"25 existing vulnerabilities detected","details":["Warn: Project is vulnerable to: GHSA-968p-4wvh-cqc8","Warn: Project is vulnerable to: GHSA-h5c3-5r3r-rr8q","Warn: Project is vulnerable to: GHSA-rmvr-2pp2-xj38","Warn: Project is vulnerable to: GHSA-xx4v-prfh-6cgc","Warn: Project is vulnerable to: GHSA-8hc4-vh64-cxmj","Warn: Project is vulnerable to: GHSA-jr5f-v2jv-69x6","Warn: Project is vulnerable to: GHSA-v6h2-p8h4-qcjw","Warn: Project is vulnerable to: GHSA-grv7-fg5c-xmjg","Warn: Project is vulnerable to: GHSA-3xgq-45jj-v275","Warn: Project is vulnerable to: GHSA-fjxv-7rqg-78g4","Warn: Project is vulnerable to: GHSA-75v8-2h7p-7m2m","Warn: Project is vulnerable to: GHSA-78xj-cgh5-2h22","Warn: Project is vulnerable to: GHSA-2p57-rm9w-gvfp","Warn: Project is vulnerable to: GHSA-952p-6rrq-rcjv","Warn: Project is vulnerable to: GHSA-mwcw-c2x4-8c55","Warn: Project is vulnerable to: GHSA-6fx8-h7jm-663j","Warn: Project is vulnerable to: GHSA-9wv6-86v2-598j","Warn: Project is vulnerable to: GHSA-p8p7-x288-28g6","Warn: Project is vulnerable to: GHSA-c2qf-rxjj-qqgw","Warn: Project is vulnerable to: GHSA-9p95-fxvg-qgq2","Warn: Project is vulnerable to: GHSA-9w5j-4mwv-2wj8","Warn: Project is vulnerable to: GHSA-f5x3-32g6-xq36","Warn: Project is vulnerable to: GHSA-52f5-9888-hmc6","Warn: Project is vulnerable to: GHSA-72xf-g2v4-qvf3","Warn: Project is vulnerable to: GHSA-j8xg-fqg3-53r7"],"documentation":{"short":"Determines if the project has open, known unfixed vulnerabilities.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#vulnerabilities"}}]},"last_synced_at":"2025-08-19T13:20:26.947Z","repository_id":38175754,"created_at":"2025-08-19T13:20:26.947Z","updated_at":"2025-08-19T13:20:26.947Z"},"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31290537,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-01T13:12:26.723Z","status":"ssl_error","status_checked_at":"2026-04-01T13:12:25.102Z","response_time":53,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aws","serverless","serverless-architectures","serverless-framework","serverless-plugin","step-functions"],"created_at":"2024-08-01T06:01:53.485Z","updated_at":"2026-04-01T17:15:09.538Z","avatar_url":"https://github.com/serverless-operations.png","language":"JavaScript","readme":"# Serverless Step Functions\n\n![CI](https://github.com/serverless-operations/serverless-step-functions/actions/workflows/config.yml/badge.svg) [![npm version](https://badge.fury.io/js/serverless-step-functions.svg)](https://badge.fury.io/js/serverless-step-functions) [![codecov](https://codecov.io/gh/serverless-operations/serverless-step-functions/branch/master/graph/badge.svg)](https://codecov.io/gh/serverless-operations/serverless-step-functions) [![Coverage Status](https://coveralls.io/repos/github/serverless-operations/serverless-step-functions/badge.svg?branch=master)](https://coveralls.io/github/serverless-operations/serverless-step-functions?branch=master) [![MIT License](https://img.shields.io/badge/license-MIT-blue.svg?style=flat)](LICENSE)\n\nThis is the Serverless Framework plugin for AWS Step Functions.\n\n## Requirement\nServerless Framework v2.32.0 or later is required.\n\n## TOC\n\n- [Install](#install)\n- [Setup](#Setup)\n  - [Adding a custom name for a state machine](#adding-a-custom-name-for-a-statemachine)\n  - [Adding a custom logical id for a stateMachine](#adding-a-custom-logical-id-for-a-statemachine)\n  - [Depending on another logical id](#depending-on-another-logical-id)\n  - [Adding retain property for a state machine](#adding-retain-property-for-a-statemachine)\n  - [CloudWatch Alarms](#cloudwatch-alarms)\n  - [CloudWatch Notifications](#cloudwatch-notifications)\n  - [Blue-Green deployments](#blue-green-deployment)\n  - [Pre-deployment validation](#pre-deployment-validation)\n  - [Express Workflow](#express-workflow)\n  - [CloudWatch Logs](#cloudwatch-logs)\n  - [X-Ray](#x-ray)\n- [Current Gotcha](#current-gotcha)\n- [Events](#events)\n  - [API Gateway](#api-gateway)\n    - [Simple HTTP endpoint](#simple-http-endpoint)\n    - [Custom Step Functions Action](#custom-step-functions-action)\n    - [HTTP Endpoint with custom IAM Role](#http-endpoint-with-custom-iam-role)\n    - [Share API Gateway and API Resources](#share-api-gateway-and-api-resources)\n    - [Enabling CORS](#enabling-cors)\n    - [HTTP Endpoints with AWS_IAM Authorizers](#http-endpoints-with-aws_iam-authorizers)\n    - [HTTP Endpoints with Custom Authorizers](#http-endpoints-with-custom-authorizers)\n    - [Shared Authorizer](#shared-authorizer)\n    - [LAMBDA_PROXY request template](#lambda_proxy-request-template)\n    - [Customizing request body mapping templates](#customizing-request-body-mapping-templates)\n    - [Customizing response headers and templates](#customizing-response-headers-and-templates)\n    - [Send request to an API](#send-request-to-an-api)\n    - [Setting API keys for your Rest API](#setting-api-keys-for-your-rest-api)\n    - [Request Schema Validators](#request-schema-validators)\n  - [Schedule](#schedule)\n    - [Enabling / Disabling](#enabling--disabling)\n    - [Specify Name and Description](#specify-name-and-description)\n    - [Scheduled Events IAM Role](#scheduled-events-iam-role)\n    - [Specify InputTransformer](#specify-inputtransformer)\n    - [Use EventBridge Scheduler instead of EventBridge rules](#use-eventbridge-scheduler-instead-of-eventbridge-rules)\n  - [CloudWatch Event](#cloudwatch-event)\n    - [Simple event definition](#simple-event-definition)\n    - [Enabling / Disabling](#enabling--disabling-1)\n    - [Specify Input or Inputpath or InputTransformer](#specify-input-or-inputpath-or-inputtransformer)\n    - [Specifying a Description](#specifying-a-description)\n    - [Specifying a Name](#specifying-a-name)\n    - [Specifying a RoleArn](#specifying-a-rolearn)\n    - [Specifying a custom CloudWatch EventBus](#specifying-a-custom-cloudwatch-eventbus)\n    - [Specifying a custom EventBridge EventBus](#specifying-a-custom-eventbridge-eventbus)\n    - [Specifying a DeadLetterQueue](#specifying-a-deadletterqueue)\n    - [Specifying a RetryPolicy](#specifying-a-retrypolicy)\n- [Tags](#tags)\n- [Commands](#commands)\n  - [deploy](#deploy)\n  - [invoke](#invoke)\n- [IAM Role](#iam-role)\n- [Tips](#tips)\n  - [How to specify the stateMachine ARN to environment variables](#how-to-specify-the-statemachine-arn-to-environment-variables)\n  - [How to split up state machines into files](#how-to-split-up-state-machines-into-files)\n- [Sample statemachines setting in serverless.yml](#sample-statemachines-setting-in-serverlessyml)\n  - [Wait State](#wait-state)\n  - [Retry Failure](#retry-failure)\n  - [Parallel](#parallel)\n  - [Catch Failure](#catch-failure)\n  - [Choice](#choice)\n  - [Map](#map)\n\n## Install\n\nRun `npm install` in your Serverless project.\n\n`$ npm install --save-dev serverless-step-functions`\n\nAdd the plugin to your serverless.yml file\n\n```yml\nplugins:\n  - serverless-step-functions\n```\n\n## Setup\n\nSpecify your state machine definition using Amazon States Language in a `definition` statement in serverless.yml. You can use CloudFormation intrinsic functions such as `Ref` and `Fn::GetAtt` to reference Lambda functions, SNS topics, SQS queues and DynamoDB tables declared in the same `serverless.yml`. Since `Ref` returns different things (ARN, ID, resource name, etc.) depending on the type of CloudFormation resource, please refer to [this page](https://theburningmonk.com/cloudformation-ref-and-getatt-cheatsheet/) to see whether you need to use `Ref` or `Fn::GetAtt`.\n\nAlternatively, you can also provide the raw ARN, or SQS queue URL, or DynamoDB table name as a string. If you need to construct the ARN by hand using pseudo-parameters such as `${AWS::Region}` or `${AWS::AccountId}`, use the `Fn::Sub` CloudFormation intrinsic function directly — no extra plugins required.\n\nIn addition, if you want to reference a DynamoDB table managed by an external CloudFormation Stack, as long as that table name is exported as an output from that stack, it can be referenced by importing it using `Fn::ImportValue`. See the `ddbtablestepfunc` Step Function definition below for an example.\n\n```yml\nfunctions:\n  hello:\n    handler: handler.hello\n\nstepFunctions:\n  stateMachines:\n    hellostepfunc1:\n      events:\n        - http:\n            path: gofunction\n            method: GET\n        - schedule:\n            rate: rate(10 minutes)\n            enabled: true\n            input:\n              key1: value1\n              key2: value2\n              stageParams:\n                stage: dev\n      name: myStateMachine\n      definition:\n        Comment: \"A Hello World example of the Amazon States Language using an AWS Lambda Function\"\n        StartAt: HelloWorld1\n        States:\n          HelloWorld1:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello, Arn]\n            End: true\n      dependsOn: CustomIamRole\n      tags:\n        Team: Atlantis\n      alarms:\n        topics:\n          ok: arn:aws:sns:us-east-1:1234567890:NotifyMe\n          alarm: arn:aws:sns:us-east-1:1234567890:NotifyMe\n          insufficientData: arn:aws:sns:us-east-1:1234567890:NotifyMe\n        metrics:\n          - executionsTimedOut\n          - executionsFailed\n          - executionsAborted\n          - metric: executionThrottled\n            treatMissingData: breaching # overrides below default\n          - executionsSucceeded\n        treatMissingData: ignore # optional\n    hellostepfunc2:\n      definition:\n        StartAt: HelloWorld2\n        States:\n          HelloWorld2:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello, Arn]\n            End: true\n    ddbtablestepfunc:\n      definition:\n        Comment: Demonstrates how to reference a DynamoDB Table Name exported from an external CloudFormation Stack\n        StartAt: ImportDDBTableName\n        States:\n          ImportDDBTableName:\n            Type: Task\n            Resource: \"arn:aws:states:::dynamodb:updateItem\"\n            Parameters:\n              TableName:\n                Fn::ImportValue: MyExternalStack:ToDoTable:Name # imports a table name from an external stack\n              Key:\n                id:\n                  S.$: \"$.todoId\"\n              UpdateExpression: \"SET #status = :updatedStatus\"\n              ExpressionAttributeNames:\n                \"#status\": status\n              ExpressionAttributeValues:\n                \":updatedStatus\":\n                  S: DONE\n            End: true\n      dependsOn:\n        - DynamoDBTable\n        - KinesisStream\n        - CustomIamRole\n      tags:\n        Team: Atlantis\n  activities:\n    - myTask\n    - yourTask\n  validate: true # enable pre-deployment definition validation (disabled by default)\n\nplugins:\n  - serverless-step-functions\n```\n\nIn the example above, notice that we used `Fn::GetAtt: [hello, Arn]` to get the ARN for the `hello` function defined earlier. This means you don't have to know how the `Serverless` framework converts these local names to CloudFormation logical IDs (e.g. `hello-world` becomes `HelloDashworldLambdaFunction`).\n\nHowever, if you prefer to work with logical IDs, you can. You can also express the above `Fn::GetAtt` function as `Fn::GetAtt: [HelloLambdaFunction, Arn]`. If you're unfamiliar with the convention the `Serverless` framework uses, then the easiest thing to do is to first run `sls package` then look in the `.serverless` folder for the generated CloudFormation template. Here you can find the logical resource names for the functions you want to reference.\n\n### Adding a custom name for a stateMachine\n\nIn case you need to interpolate a specific stage or service layer variable as the\nstateMachines name you can add a `name` property to your yaml.\n\n```yml\nservice: messager\n\nfunctions:\n  sendMessage:\n    handler: handler.sendMessage\n\nstepFunctions:\n  stateMachines:\n    sendMessageFunc:\n      name: sendMessageFunc-${self:custom.service}-${opt:stage}\n      definition:\n        \u003cyour definition\u003e\n\nplugins:\n  - serverless-step-functions\n```\n\n### Adding a custom logical id for a stateMachine\n\nYou can use a custom logical id that is only unique within the stack as opposed to the name that needs to be unique globally. This can make referencing the state machine easier/simpler because you don't have to duplicate the interpolation logic everywhere you reference the state machine.\n\n```yml\nservice: messager\n\nfunctions:\n  sendMessage:\n    handler: handler.sendMessage\n\nstepFunctions:\n  stateMachines:\n    sendMessageFunc:\n      id: SendMessageStateMachine\n      name: sendMessageFunc-${self:custom.service}-${opt:stage}\n      definition:\n        \u003cyour definition\u003e\n\nplugins:\n  - serverless-step-functions\n```\n\nYou can then `Ref: SendMessageStateMachine` in various parts of CloudFormation or serverless.yml\n\n### Depending on another logical id\n\nIf your state machine depends on another resource defined in your `serverless.yml` then you can add a `dependsOn` field to the state machine `definition`. This would add the `DependsOn`clause to the generated CloudFormation template.\n\nThis `dependsOn` field can be either a string, or an array of strings.\n\n```yaml\nstepFunctions:\n  stateMachines:\n    myStateMachine:\n      dependsOn: myDB\n\n    myOtherStateMachine:\n      dependsOn:\n        - myOtherDB\n        - myStream\n```\n### Adding retain property for a stateMachine\nThere are some practical cases when you would like to prevent state machine from deletion on stack delete or update. This can be achieved by adding `retain` property to the state machine section.\n\n```yaml\nstepFunctions:\n  stateMachines:\n    myStateMachine:\n      retain: true\n```\n\nConfiguring in such way adds `\"DeletionPolicy\" : \"Retain\"` to the state machine within CloudFormation template.\n\n### CloudWatch Alarms\n\nIt's common practice to want to monitor the health of your state machines and be alerted when something goes wrong. You can either:\n\n* do this using the [serverless-plugin-aws-alerts](https://github.com/ACloudGuru/serverless-plugin-aws-alerts), which lets you configure custom CloudWatch Alarms against the various metrics that Step Functions publishes.\n* or, you can use the built-in `alarms` configuration from this plugin, which gives you an opinionated set of default alarms (see below)\n\n```yaml\nstepFunctions:\n  stateMachines:\n    myStateMachine:\n      alarms:\n        topics:\n          ok: arn:aws:sns:us-east-1:1234567890:NotifyMe\n          alarm: arn:aws:sns:us-east-1:1234567890:NotifyMe\n          insufficientData: arn:aws:sns:us-east-1:1234567890:NotifyMe\n        metrics:\n          - executionsTimedOut\n          - executionsFailed\n          - executionsAborted\n          - executionThrottled\n          - executionsSucceeded\n        treatMissingData: missing\n```\n\nBoth `topics` and `metrics` are required properties. There are 4 supported metrics, each map to the CloudWatch Metrics that Step Functions publishes for your executions.\n\nYou can configure how the CloudWatch Alarms should treat missing data:\n\n* `missing` (AWS default): The alarm does not consider missing data points when evaluating whether to change state.\n* `ignore`: The current alarm state is maintained.\n* `breaching`: Missing data points are treated as breaching the threshold.\n* `notBreaching`: Missing data points are treated as being within the threshold.\n\nFor more information, please refer to the [official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).\n\nThe generated CloudWatch alarms would have the following configurations:\n\n```yaml\nnamespace: 'AWS/States'\nmetric: \u003cExecutionsTimedOut | ExecutionsFailed | ExecutionsAborted | ExecutionThrottled\u003e\nthreshold: 1\nperiod: 60\nevaluationPeriods: 1\nComparisonOperator: GreaterThanOrEqualToThreshold\nStatistic: Sum\ntreatMissingData: \u003cmissing (default) | ignore | breaching | notBreaching\u003e\nDimensions:\n  - Name: StateMachineArn\n    Value: \u003cArnOfTheStateMachine\u003e\n```\n\nYou can also override the default `treatMissingData` setting for a particular alarm by specifying an override:\n\n```yml\nalarms:\n  topics:\n    ok: arn:aws:sns:us-east-1:1234567890:NotifyMe\n    alarm: arn:aws:sns:us-east-1:1234567890:NotifyMe\n    insufficientData: arn:aws:sns:us-east-1:1234567890:NotifyMe\n  metrics:\n    - executionsTimedOut\n    - executionsFailed\n    - executionsAborted\n    - metric: executionThrottled\n      treatMissingData: breaching # override\n    - executionsSucceeded\n  treatMissingData: ignore # default\n```\n\nYou can also override the default `period` (in seconds) for all alarms or for a specific alarm:\n\n```yml\nalarms:\n  topics:\n    ok: arn:aws:sns:us-east-1:1234567890:NotifyMe\n    alarm: arn:aws:sns:us-east-1:1234567890:NotifyMe\n    insufficientData: arn:aws:sns:us-east-1:1234567890:NotifyMe\n  metrics:\n    - executionsTimedOut\n    - executionsFailed\n    - metric: executionThrottled\n      period: 300 # override for this alarm only\n    - executionsSucceeded\n  period: 120 # default for all alarms (defaults to 60 if omitted)\n```\n\n#### Custom CloudWatch Alarm names\n\nBy default, the CloudFormation assigns names to the alarms based on the CloudFormation stack and the resource logical Id, and in some cases and these names could be confusing.\n\nTo use custom names to the alarms add `nameTemplate` property in the `alarms` object.\n\nexample:\n\n```yaml\nservice: myservice\n\nplugins:\n  - serverless-step-functions\n\nstepFunctions:\n  stateMachines:\n    main-workflow:\n      name: main\n      alarms:\n        nameTemplate: $[stateMachineName]-$[cloudWatchMetricName]-alarm\n        topics:\n          alarm: !Ref AwsAlertsGenericAlarmTopicAlarm\n        metrics:\n          - executionsFailed\n          - executionsAborted\n          - executionsTimedOut\n          - executionThrottled\n        treatMissingData: ignore\n      definition: ${file(./step-functions/main.asl.yaml)}\n```\n\nSupported variables to the `nameTemplate` property:\n\n- `stateMachineName`\n- `metricName`\n- `cloudWatchMetricName`\n\n##### Per-Metric Alarm Name\n\nTo overwrite the alarm name for a specific metric, add the `alarmName` property in the metric object.\n\n```yaml\nservice: myservice\n\nplugins:\n  - serverless-step-functions\n\nstepFunctions:\n  stateMachines:\n    main-workflow:\n      name: main\n      alarms:\n        nameTemplate: $[stateMachineName]-$[cloudWatchMetricName]-alarm\n        topics:\n          alarm: !Ref AwsAlertsGenericAlarmTopicAlarm\n        metrics:\n          - metric: executionsFailed\n            alarmName: mycustom-name-${self:stage.region}-Failed-alarm\n          - executionsAborted\n          - executionsTimedOut\n          - executionThrottled\n        treatMissingData: ignore\n      definition: ${file(./step-functions/main.asl.yaml)}\n```\n\n### CloudWatch Notifications\n\nYou can monitor the execution state of your state machines [via CloudWatch Events](https://aws.amazon.com/about-aws/whats-new/2019/05/aws-step-functions-adds-support-for-workflow-execution-events/). It allows you to be alerted when the status of your state machine changes to `ABORTED`, `FAILED`, `RUNNING`, `SUCCEEDED` or `TIMED_OUT`.\n\nYou can configure CloudWatch Events to send notification to a number of targets. Currently this plugin supports `sns`, `sqs`, `kinesis`, `firehose`, `lambda` and `stepFunctions`.\n\nTo configure status change notifications to your state machine, you can add a `notifications` like below:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hellostepfunc1:\n      name: test\n      definition:\n        ...\n      notifications:\n        ABORTED:\n          - sns: SNS_TOPIC_ARN\n          - sqs: SQS_TOPIC_ARN\n          - sqs: # for FIFO queues, which requires you to configure the message group ID\n              arn: SQS_TOPIC_ARN\n              messageGroupId: 12345\n          - lambda: LAMBDA_FUNCTION_ARN\n          - kinesis: KINESIS_STREAM_ARN\n          - kinesis:\n              arn: KINESIS_STREAM_ARN\n              partitionKeyPath: $.id # used to choose the parition key from payload\n          - firehose: FIREHOSE_STREAM_ARN\n          - stepFunctions: STATE_MACHINE_ARN\n        FAILED:\n          ... # same as above\n        ... # other status\n```\n\nAs you can see from the above example, you can configure different notification targets for each type of status change. If you want to configure the same targets for multiple status changes, then consider using [YML anchors](https://blog.daemonl.com/2016/02/yaml.html) to keep your YML succinct.\n\nCloudFormation intrinsic functions such as `Ref` and `Fn::GetAtt` are supported.\n\nWhen setting up a notification target against a FIFO SQS queue, the queue must enable the content-based deduplication option and you must configure the `messageGroupId`.\n\nYou can also control the event payload delivered to each notification target using `inputPath` or `inputTransformer`:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hellostepfunc1:\n      name: test\n      definition:\n        ...\n      notifications:\n        FAILED:\n          - sns: SNS_TOPIC_ARN\n            inputTransformer:\n              inputPathsMap:\n                status: '$.detail.status'\n                name: '$.detail.name'\n              inputTemplate: '\"State machine \u003cname\u003e finished with status \u003cstatus\u003e\"'\n          - sqs: SQS_QUEUE_ARN\n            inputPath: '$.detail'\n```\n\n`inputPath` selects a sub-tree of the event to pass to the target. `inputTransformer` lets you map fields from the event and embed them in a custom template string.\n\n### Blue green deployment\n\nTo implement a [blue-green deployment with Step Functions](https://theburningmonk.com/2019/08/how-to-do-blue-green-deployment-for-step-functions/) you need to reference the exact versions of the functions.\n\nTo do this, you can specify `useExactVersion: true` in the state machine.\n\n```yml\nstepFunctions:\n  stateMachines:\n    hellostepfunc1:\n      useExactVersion: true\n      definition:\n        ...\n```\n\n### Pre-deployment validation\n\nBy default, your state machine definition will be validated during deployment by StepFunctions. This can be cumbersome when developing because you have to upload your service for every typo in your definition. In order to go faster, you can enable pre-deployment validation using [asl-validator](https://www.npmjs.com/package/asl-validator) which should detect most of the issues (like a missing state property).\n\n```yaml\nstepFunctions:\n  validate: true\n```\n\n### Disable Output Cloudformation Outputs section\n\nDisables the generation of outputs in the CloudFormation Outputs section. If you define many state machines in serverless.yml you may reach the CloudFormation limit of 60 outputs. If you define `noOutput: true` then this plugin will not generate outputs automatically.\n\n```yaml\nstepFunctions:\n  noOutput: true\n```\n\n### Express Workflow\n\nAt re:invent 2019, AWS [introduced Express Workflows](https://aws.amazon.com/about-aws/whats-new/2019/12/introducing-aws-step-functions-express-workflows/) as a cheaper, more scalable alternative (but with a cut-down set of features). See [this page](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-standard-vs-express.html) for differences between standard and express workflows.\n\nTo declare an express workflow, specify `type` as `EXPRESS` and you can specify the logging configuration:\n\n```yaml\nstepFunctions:\n  stateMachines:\n    hellostepfunc1:\n      type: EXPRESS\n      loggingConfig:\n        level: ERROR\n        includeExecutionData: true\n        destinations:\n          - Fn::GetAtt: [MyLogGroup, Arn]\n```\n\n### CloudWatch Logs\n\nYou can enable CloudWatch Logs for standard Step Functions, the syntax is\nexactly like with Express Workflows.\n\n```yaml\nstepFunctions:\n  stateMachines:\n    hellostepfunc1:\n      loggingConfig:\n        level: ERROR\n        includeExecutionData: true\n        destinations:\n          - Fn::GetAtt: [MyLogGroup, Arn]\n```\n\n### X-Ray\n\nYou can enable X-Ray for your state machine, specify `tracingConfig` as shown below.\n\n```yaml\nstepFunctions:\n  stateMachines:\n    hellostepfunc1:\n      tracingConfig:\n        enabled: true\n```\n\n## Current Gotcha\n\nPlease keep this gotcha in mind if you want to reference the `name` from the `resources` section. To generate Logical ID for CloudFormation, the plugin transforms the specified name in serverless.yml based on the following scheme.\n\n* Transform a leading character into uppercase\n* Transform `-` into Dash\n* Transform `_` into Underscore\n\nIf you want to use variables system in name statement, you can't put the variables as a prefix like this:`${self:service}-${opt:stage}-myStateMachine` since the variables are transformed within Output section, as a result, the reference will be broken.\n\nThe correct sample is here.\n\n```yaml\nstepFunctions:\n  stateMachines:\n    myStateMachine:\n      name: myStateMachine-${self:service}-${opt:stage}\n...\n\nresources:\n  Outputs:\n    myStateMachine:\n      Value:\n        Ref: MyStateMachineDash${self:service}Dash${opt:stage}\n```\n\n## Events\n\n### API Gateway\n\nTo create HTTP endpoints as Event sources for your StepFunctions statemachine\n\n#### Simple HTTP Endpoint\n\nThis setup specifies that the hello state machine should be run when someone accesses the API gateway at hello via a GET request.\n\nHere's an example:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: hello\n            method: GET\n      definition:\n```\n\nHere You can define an POST endpoint for the path posts/create.\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: posts/create\n            method: POST\n      definition:\n```\n\n#### Custom Step Functions Action\n\nStep Functions have custom actions like DescribeExecution or StopExecution to fetch and control them. You can use custom actions like this:\n\n```yml\nstepFunctions:\n  stateMachines:\n    start:\n      events:\n        - http:\n            path: action/start\n            method: POST\n      definition:\n        ...\n    status:\n      events:\n        - http:\n            path: action/status\n            method: POST\n            action: DescribeExecution\n      definition:\n        ...\n    stop:\n      events:\n        - http:\n            path: action/stop\n            method: POST\n            action: StopExecution\n      definition:\n        ...\n```\n\nRequest template is not used when action is set because there're a bunch of actions. However if you want to use request template you can use [Customizing request body mapping templates](#customizing-request-body-mapping-templates).\n\n#### HTTP Endpoint with custom timeout\n\nYou can configure the API Gateway integration timeout (in milliseconds) at the event level or as a default for all events via `provider.apiGateway.timeoutInMillis`:\n\n```yml\nprovider:\n  name: aws\n  apiGateway:\n    timeoutInMillis: 15000 # default for all step function http events\n\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: hello\n            method: GET\n            timeoutInMillis: 29000 # override per event\n      definition:\n```\n\n#### HTTP Endpoint with custom IAM Role\n\nThe plugin would generate an IAM Role for you by default. However, if you wish to use an IAM role that you have provisioned separately, then you can override the IAM Role like this:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: posts/create\n            method: POST\n            iamRole: arn:aws:iam::\u003caccountId\u003e:role/\u003croleName\u003e\n      definition:\n```\n\n#### Share API Gateway and API Resources\n\nYou can [share the same API Gateway](https://serverless.com/framework/docs/providers/aws/events/apigateway/#share-api-gateway-and-api-resources) between multiple projects by referencing its REST API ID and Root Resource ID in serverless.yml as follows:\n\n```yml\nservice: service-name\nprovider:\n  name: aws\n  apiGateway:\n    # REST API resource ID. Default is generated by the framework\n    restApiId: xxxxxxxxxx\n    # Root resource, represent as / path\n    restApiRootResourceId: xxxxxxxxxx\n\nfunctions:\n  ...\n```\n\nIf your application has many nested paths, you might also want to break them out into smaller services.\n\nHowever, Cloudformation will throw an error if we try to generate an existing path resource. To avoid that, we reference the resource ID:\n\n```yml\nservice: service-a\nprovider:\n  apiGateway:\n    restApiId: xxxxxxxxxx\n    restApiRootResourceId: xxxxxxxxxx\n    # List of existing resources that were created in the REST API. This is required or the stack will be conflicted\n    restApiResources:\n      /users: xxxxxxxxxx\n\nfunctions:\n  ...\n```\n\nNow we can define endpoints using existing API Gateway ressources\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: users/create\n            method: POST\n```\n\n#### Enabling CORS\n\nTo set CORS configurations for your HTTP endpoints, simply modify your event configurations as follows:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: posts/create\n            method: POST\n            cors: true\n      definition:\n```\n\nSetting cors to true assumes a default configuration which is equivalent to:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: posts/create\n            method: POST\n            cors:\n              origin: '*'\n              headers:\n                - Content-Type\n                - X-Amz-Date\n                - Authorization\n                - X-Api-Key\n                - X-Amz-Security-Token\n                - X-Amz-User-Agent\n              allowCredentials: false\n      definition:\n```\n\nConfiguring the cors property sets Access-Control-Allow-Origin, Access-Control-Allow-Headers, Access-Control-Allow-Methods,Access-Control-Allow-Credentials headers in the CORS preflight response.\nTo enable the Access-Control-Max-Age preflight response header, set the maxAge property in the cors object:\n\n```yml\nstepFunctions:\n  stateMachines:\n    SfnApiGateway:\n      events:\n        - http:\n            path: /playground/start\n            method: post\n            cors:\n              origin: '*'\n              maxAge: 86400\n```\n\n#### HTTP Endpoints with AWS_IAM Authorizers\n\nIf you want to require that the caller submit the IAM user's access keys in order to be authenticated to invoke your Lambda Function, set the authorizer to AWS_IAM as shown in the following example:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: posts/create\n            method: POST\n            authorizer: aws_iam\n      definition:\n```\n\n#### HTTP Endpoints with Custom Authorizers\n\n[Custom Authorizers](https://serverless.com/framework/docs/providers/aws/events/apigateway/#http-endpoints-with-custom-authorizers) allow you to run an AWS Lambda Function before your targeted AWS Lambda Function. This is useful for Microservice Architectures or when you simply want to do some Authorization before running your business logic.\n\nYou can enable Custom Authorizers for your HTTP endpoint by setting the Authorizer in your http event to another function in the same service, as shown in the following example:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      - http:\n          path: posts/create\n          method: post\n          authorizer: authorizerFunc\n      definition:\n```\n\nIf the Authorizer function does not exist in your service but exists in AWS, you can provide the ARN of the Lambda function instead of the function name, as shown in the following example:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      - http:\n          path: posts/create\n          method: post\n          authorizer: xxx:xxx:Lambda-Name\n      definition:\n```\n\n#### Shared Authorizer\n\nAuto-created Authorizer is convenient for conventional setup. However, when you need to define your custom Authorizer, or use COGNITO_USER_POOLS authorizer with shared API Gateway, it is painful because of AWS limitation. Sharing Authorizer is a better way to do.\n\n```yml\nstepFunctions:\n  stateMachines:\n    createUser:\n      ...\n      events:\n          - http:\n            path: /users\n            ...\n            authorizer:\n              # Provide both type and authorizerId\n              type: COGNITO_USER_POOLS # TOKEN, CUSTOM or COGNITO_USER_POOLS, same as AWS Cloudformation documentation\n              authorizerId:\n                Ref: ApiGatewayAuthorizer  # or hard-code Authorizer ID\n              # [Optional] you can also specify the OAuth scopes for Cognito\n              scopes:\n                - scope1\n                ...\n```\n\n#### LAMBDA_PROXY request template\n\nThe plugin generates default body mapping templates for `application/json` and `application/x-www-form-urlencoded` content types. The default template would pass the request body as input to the state machine. If you need access to other contextual information about the HTTP request such as headers, path parameters, etc. then you can also use the `lambda_proxy` request template like this:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: posts/create\n            method: POST\n            request:\n              template: lambda_proxy\n```\n\nThis would generate the normal LAMBDA_PROXY template used for API Gateway integration with Lambda functions.\n\n#### Customizing request body mapping templates\n\nIf you'd like to add content types or customize the default templates, you can do so by including your custom [API Gateway request mapping template](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html) in `serverless.yml` like so:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: posts/create\n            method: POST\n            request:\n              template:\n                application/json: |\n                  #set( $body = $util.escapeJavaScript($input.json('$')) )\n                  #set( $name = $util.escapeJavaScript($input.json('$.data.attributes.order_id')) )\n                  {\n                    \"input\": \"$body\",\n                    \"name\": \"$name\",\n                    \"stateMachineArn\":\"arn:aws:states:#{AWS::Region}:#{AWS::AccountId}:stateMachine:processOrderFlow-${opt:stage}\"\n                  }\n      name: processOrderFlow-${opt:stage}\n      definition:\n```\n\n#### Customizing response headers and templates\n\nIf you'd like to add custom headers in the HTTP response, or customize the default response template (which just returns the response from Step Function's StartExecution API), then you can do so by including your custom headers and [API Gateway response mapping template](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html) in `serverless.yml` like so:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: posts/create\n            method: POST\n            response:\n              headers:\n                Content-Type: \"'application/json'\"\n                X-Application-Id: \"'my-app'\"\n              template:\n                application/json: |\n                  {\n                    \"status\": 200,\n                    \"info\": \"OK\"\n                  }\n      definition:\n```\n\nIf you want to add multiple custom templates for different status codes, headers and content types, you can do so by including them in the `responses` object like so:\n\n```yml\n\nstepFunctions:\n  stateMachines:\n    hello:\n      events:\n        - http:\n            path: posts/create\n            method: POST\n            responses:\n              200:\n                statusCode: 200\n                responseParameters:\n                  method.response.header.Content-Type: \"'application/json'\"\n                  method.response.header.X-Application-Id: \"'my-app'\"\n                responseTemplates:\n                  application/json: |\n                    {\n                      \"status\": 200,\n                      \"info\": \"OK\"\n                    }\n              400:\n                statusCode: 400\n                responseParameters:\n                  method.response.header.Content-Type: \"'application/json'\"\n                  method.response.header.X-Application-Id: \"'my-app'\"\n                responseTemplates:\n                  application/json: |\n                    {\n                      \"status\": 400,\n                      \"info\": \"Bad Request\"\n                    }\n      definition:\n```\n\n#### Send request to an API\n\nYou can input an value as json in request body, the value is passed as the input value of your statemachine\n\n`$ curl -XPOST https://xxxxxxxxx.execute-api.us-east-1.amazonaws.com/dev/posts/create -d '{\"foo\":\"bar\"}'`\n\n#### Setting API keys for your Rest API\n\nYou can specify a list of API keys to be used by your service Rest API by adding an apiKeys array property to the apiGateway subsection of the provider object in serverless.yml. You'll also need to explicitly specify which endpoints are private and require one of the api keys to be included in the request by adding a private boolean property to the http event object you want to set as private. API Keys are created globally, so if you want to deploy your service to different stages make sure your API key contains a stage variable as defined below. When using API keys, you can optionally define usage plan quota and throttle, using usagePlan object.\n\nHere's an example configuration for setting API keys for your service Rest API:\n\n```yml\nservice: my-service\nprovider:\n  name: aws\n  apiGateway:\n    apiKeys:\n      - myFirstKey\n      - ${opt:stage}-myFirstKey\n      - ${env:MY_API_KEY} # you can hide it in a serverless variable\n      - name: myKeyWithValue  # object form — lets you set a specific key value\n        value: myApiKeyValue\n    usagePlan:\n      quota:\n        limit: 5000\n        offset: 2\n        period: MONTH\n      throttle:\n        burstLimit: 200\n        rateLimit: 100\nfunctions:\n  hello:\n    handler: handler.hello\n\nstepFunctions:\n      stateMachines:\n        statemachine1:\n          name: ${self:service}-${opt:stage}-statemachine1\n          events:\n            - http:\n                path: /hello\n                method: post\n                private: true\n          definition:\n            Comment: \"A Hello World example of the Amazon States Language using an AWS Lambda Function\"\n            StartAt: HelloWorld1\n            States:\n              HelloWorld1:\n                Type: Task\n                Resource:\n                  Fn::GetAtt: [hello, Arn]\n                End: true\n\n\n    plugins:\n      - serverless-step-functions\n```\n\nAPI key entries can be plain strings (the key name) or objects with a `name` and an optional `value` property. When `value` is provided, the API key is created with that specific value; otherwise AWS auto-generates the value.\n\nPlease note that those are the API keys names, not the actual values. Once you deploy your service, the value of those API keys will be auto generated by AWS and printed on the screen for you to use. The values can be concealed from the output with the --conceal deploy option.\n\nClients connecting to this Rest API will then need to set any of these API keys values in the x-api-key header of their request. This is only necessary for functions where the private property is set to true.\n\n#### Request Schema Validators\n\nTo use [request schema validation](https://serverless.com/framework/docs/providers/aws/events/apigateway/#request-schema-validators) with API gateway, add the [JSON Schema](https://json-schema.org/) for your content type. Since JSON Schema is represented in JSON, it's easier to include it from a file.\n\n```yaml\nstepFunctions:\n  stateMachines:\n    create:\n      events:\n        - http:\n            path: posts/create\n            method: post\n            request:\n              schemas:\n                application/json: ${file(create_request.json)}\n```\n\nIn addition, you can also customize created model with name and description properties.\n\n```yaml\nstepFunctions:\n  stateMachines:\n    create:\n      events:\n        - http:\n            path: posts/create\n            method: post\n            request:\n              schemas:\n                application/json:\n                  schema: ${file(create_request.json)}\n                  name: PostCreateModel\n                  description: 'Validation model for Creating Posts'\n```\n\nTo reuse the same model across different events, you can define global models on provider level. In order to define global model you need to add its configuration to `provider.apiGateway.request.schemas`. After defining a global model, you can use it in the event by referencing it by the key. Provider models are created for application/json content type.\n\n```yaml\nprovider:\n    ...\n    apiGateway:\n      request:\n        schemas:\n          post-create-model:\n            name: PostCreateModel\n            schema: ${file(api_schema/post_add_schema.json)}\n            description: \"A Model validation for adding posts\"\n\nstepFunctions:\n  stateMachines:\n    create:\n      events:\n        - http:\n            path: posts/create\n            method: post\n            request:\n              schemas:\n                application/json: post-create-model\n```\n\nA sample schema contained in `create_request.json` might look something like this:\n\n```json\n{\n  \"definitions\": {},\n  \"$schema\": \"http://json-schema.org/draft-04/schema#\",\n  \"type\": \"object\",\n  \"title\": \"The Root Schema\",\n  \"required\": [\"username\"],\n  \"properties\": {\n    \"username\": {\n      \"type\": \"string\",\n      \"title\": \"The Foo Schema\",\n      \"default\": \"\",\n      \"pattern\": \"^[a-zA-Z0-9]+$\"\n    }\n  }\n}\n```\n\n**NOTE:** schema validators are only applied to content types you specify. Other content types are not blocked. Currently, API Gateway [supports](https://docs.aws.amazon.com/apigateway/latest/developerguide/models-mappings.html) JSON Schema draft-04.\n\n### Schedule\n\nThe following config will attach a schedule event and causes the stateMachine `crawl` to be called every 2 hours. The configuration allows you to attach multiple schedules to the same stateMachine. You can either use the `rate` or `cron` syntax. Take a look at the [AWS schedule syntax documentation](http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html) for more details.\n\n```yaml\nstepFunctions:\n  stateMachines:\n    crawl:\n      events:\n        - schedule: rate(2 hours)\n        - schedule: cron(0 12 * * ? *)\n      definition:\n```\n\n#### Enabling / Disabling\n\n**Note:** `schedule` events are enabled by default.\n\nThis will create and attach a schedule event for the `aggregate` stateMachine which is disabled. If enabled it will call\nthe `aggregate` stateMachine every 10 minutes.\n\n```yaml\nstepFunctions:\n  stateMachines:\n    aggregate:\n      events:\n        - schedule:\n            rate: rate(10 minutes)\n            enabled: false\n            input:\n              key1: value1\n              key2: value2\n              stageParams:\n                stage: dev\n        - schedule:\n            rate: cron(0 12 * * ? *)\n            enabled: false\n            inputPath: '$.stageVariables'\n```\n\n#### Specify Name and Description\n\nName and Description can be specified for a schedule event. These are not required properties.\n\n```yaml\nevents:\n  - schedule:\n      name: your-scheduled-rate-event-name\n      description: 'your scheduled rate event description'\n      rate: rate(2 hours)\n```\n\n#### Scheduled Events IAM Role\n\nBy default, the plugin will create a new IAM role that allows AWS Events to start your state machine. Note that this role is different than the role assumed by the state machine. You can specify your own role instead (it must allow `events.amazonaws.com` to assume it, and it must be able to run `states:StartExecution` on your state machine):\n\n```yaml\nevents:\n  - schedule:\n      rate: rate(2 hours)\n      role: arn:aws:iam::xxxxxxxx:role/yourRole\n```\n\n#### Specify InputTransformer\n\nYou can specify input values ​​to the Lambda function.\n\n```yml\nstepFunctions:\n  stateMachines:\n    stateMachineScheduled:\n      events:\n        - schedule:\n            rate: cron(30 12 ? * 1-5 *)\n            inputTransformer:\n              inputPathsMap:\n                time: '$.time'\n                stage: '$.stageVariables'\n              inputTemplate: '{\"time\": \u003ctime\u003e, \"stage\" : \u003cstage\u003e }'\n      definition:\n        ...\n```\n\n#### Use EventBridge Scheduler instead of EventBridge rules\n\nAWS has account-wide limits on the number of `AWS::Event::Rule` triggers per bus (300 events), and all Lambda schedules go into a single bus with no way to override it. This can lead to a situation where large projects hit the limit with no ability to schedule more events.\n\nHowever, `AWS::Scheduler::Schedule` has much higher limits (1,000,000 events), and is configured identically. `method` can be set in order to migrate to this trigger type seamlessly. It also allows you to specify a timezone to run your event based on local time.\n\n```yml\nstepFunctions:\n  stateMachines:\n    stateMachineScheduled:\n      events:\n        - schedule:\n            method: scheduler\n            rate: cron(30 12 ? * 1-5 *)\n            enabled: true\n            timezone: America/New_York\n      definition:\n        ...\n```\n\n### CloudWatch Event / EventBridge\n\n#### Simple event definition\n\nThis will enable your Statemachine to be called by an EC2 event rule.\nPlease check the page of [Event Types for CloudWatch Events](http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html).\n\n```yml\nstepFunctions:\n  stateMachines:\n    first:\n      events:\n        - cloudwatchEvent:\n            event:\n              source:\n                - \"aws.ec2\"\n              detail-type:\n                - \"EC2 Instance State-change Notification\"\n              detail:\n                state:\n                  - pending\n      definition:\n        ...\n```\n\nYou can alternatively use EventBridge:\n\n```yml\nstepFunctions:\n  stateMachines:\n    first:\n      events:\n        - eventBridge:\n            event:\n              source:\n                - \"aws.ec2\"\n              detail-type:\n                - \"EC2 Instance State-change Notification\"\n              detail:\n                state:\n                  - pending\n      definition:\n        ...\n```\n\nAll the configurations in this section applies to both `cloudwatchEvent` and `eventBridge`.\n\n#### Enabling / Disabling\n\n**Note:** `cloudwatchEvent` and `eventBridge` events are enabled by default.\n\nThis will create and attach a disabled `cloudwatchEvent` event for the `myCloudWatch` statemachine.\n\n```yml\nstepFunctions:\n  stateMachines:\n    cloudwatchEvent:\n      events:\n        - cloudwatchEvent:\n            event:\n              source:\n                - \"aws.ec2\"\n              detail-type:\n                - \"EC2 Instance State-change Notification\"\n              detail:\n                state:\n                  - pending\n            enabled: false\n      definition:\n        ...\n```\n\n#### Specify Input or Inputpath or InputTransformer\n\nYou can specify input values ​​to the Lambda function.\n\n```yml\nstepFunctions:\n  stateMachines:\n    cloudwatchEvent:\n      events:\n        - cloudwatchEvent:\n            event:\n              source:\n                - \"aws.ec2\"\n              detail-type:\n                - \"EC2 Instance State-change Notification\"\n              detail:\n                state:\n                  - pending\n            input:\n              key1: value1\n              key2: value2\n              stageParams:\n                stage: dev\n        - cloudwatchEvent:\n            event:\n              source:\n                - \"aws.ec2\"\n              detail-type:\n                - \"EC2 Instance State-change Notification\"\n              detail:\n                state:\n                  - pending\n            inputPath: '$.stageVariables'\n        - cloudwatchEvent:\n            event:\n              source:\n                - \"aws.ec2\"\n              detail-type:\n                - \"EC2 Instance State-change Notification\"\n              detail:\n                state:\n                  - pending\n            inputTransformer:\n              inputPathsMap:\n                stage: '$.stageVariables'\n              inputTemplate: '{ \"stage\": \u003cstage\u003e }'\n      definition:\n        ...\n```\n\n#### Specifying a Description\n\nYou can also specify a CloudWatch Event description.\n\n```yml\nstepFunctions:\n  stateMachines:\n    cloudwatchEvent:\n      events:\n        - cloudwatchEvent:\n            description: 'CloudWatch Event triggered on EC2 Instance pending state'\n            event:\n              source:\n                - \"aws.ec2\"\n              detail-type:\n                - \"EC2 Instance State-change Notification\"\n              detail:\n                state:\n                  - pending\n      definition:\n        ...\n```\n\n#### Specifying a Name\n\nYou can also specify a CloudWatch Event name. Keep in mind that the name must begin with a letter; contain only ASCII letters, digits, and hyphens; and not end with a hyphen or contain two consecutive hyphens. More infomation [here](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-name.html).\n\n```yml\nstepFunctions:\n  stateMachines:\n    cloudwatchEvent:\n      events:\n        - cloudwatchEvent:\n            name: 'my-cloudwatch-event-name'\n            event:\n              source:\n                - \"aws.ec2\"\n              detail-type:\n                - \"EC2 Instance State-change Notification\"\n              detail:\n                state:\n                  - pending\n      definition:\n        ...\n```\n\n#### Specifying a RoleArn\n\nYou can also specify a CloudWatch Event RoleArn.\nThe Amazon Resource Name (ARN) of the role that is used for target invocation.\n\nRequired: No\n\n```yml\nstepFunctions:\n  stateMachines:\n    cloudwatchEvent:\n      events:\n        - cloudwatchEvent:\n            name: 'my-cloudwatch-event-name'\n            iamRole: 'arn:aws:iam::012345678910:role/Events-InvokeStepFunctions-Role'\n            event:\n              source:\n                - \"aws.ec2\"\n              detail-type:\n                - \"EC2 Instance State-change Notification\"\n              detail:\n                state:\n                  - pending\n      definition:\n        ...\n```\n\n#### Specifying a custom CloudWatch EventBus\n\nYou can choose which CloudWatch Event bus:\n\n```yml\nstepFunctions:\n  stateMachines:\n    exampleCloudwatchEventStartsMachine:\n      events:\n        - cloudwatchEvent:\n            eventBusName: 'my-custom-event-bus'\n            event:\n              source:\n                - \"my.custom.source\"\n              detail-type:\n                - \"My Event Type\"\n              detail:\n                state:\n                  - pending\n      definition:\n        ...\n```\n\n#### Specifying a custom EventBridge EventBus\n\nYou can choose which EventBridge Event bus:\n\n```yml\nstepFunctions:\n  stateMachines:\n    exampleEventBridgeEventStartsMachine:\n      events:\n        - eventBridge:\n            eventBusName: 'my-custom-event-bus'\n            event:\n              source:\n                - \"my.custom.source\"\n              detail-type:\n                - \"My Event Type\"\n              detail:\n                state:\n                  - pending\n      definition:\n        ...\n```\n\n#### Specifying a DeadLetterQueue\n\nYou can configure a target queue to send dead-letter queue events to:\n\n```yml\nstepFunctions:\n  stateMachines:\n    exampleEventBridgeEventStartsMachine:\n      events:\n        - eventBridge:\n            eventBusName: 'my-custom-event-bus'\n            event:\n              source:\n                - \"my.custom.source\"\n              detail-type:\n                - \"My Event Type\"\n              detail:\n                state:\n                  - pending\n            deadLetterConfig: 'arn:aws:sqs:us-east-1:012345678910:my-dlq' # SQS Arn\n      definition:\n        ...\n```\n##### Important point\nDon't forget to [Grant permissions to the dead-letter queue](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rule-dlq.html#eb-dlq-perms), to do that you may need to have the `ARN` of the generated `EventBridge Rule`.\n\nIn order to get the `ARN` you can use [intrinsic functions](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html) against the `logicalId`, this plugin generates `logicalIds` following this format:\n```ts\n`${StateMachineName}EventsRuleCloudWatchEvent${index}`\n```\nGiven this example 👇\n```yml\nstepFunctions:\n  stateMachines:\n    hellostepfunc1: # \u003c---- StateMachineName\n      events:\n        - eventBridge:\n            eventBusName: 'my-custom-event-bus'\n            event:\n              source:\n                - \"my.custom.source\"\n        - eventBridge:\n            eventBusName: 'my-custom-event-bus'\n            event:\n              source:\n                - \"my.custom.source\"\n            deadLetterConfig: 'arn:aws:sqs:us-east-1:012345678910:my-dlq'\n      name: myStateMachine\n      definition:\n        Comment: \"A Hello World example of the Amazon States Language using an AWS Lambda Function\"\n        StartAt: HelloWorld1\n        States:\n          HelloWorld1:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello, Arn]\n            End: true\n```\nThen\n```yaml\n# to get the Arn of the 1st EventBridge rule\n!GetAtt Hellostepfunc1EventsRuleCloudWatchEvent1.Arn\n\n  # to get the Arn of the 2nd EventBridge rule\n  !GetAtt Hellostepfunc1EventsRuleCloudWatchEvent2.Arn\n```\n\n#### Specifying a RetryPolicy\n\nYou can configure a retry policy for `schedule` and `eventBridge`/`cloudwatchEvent` rule targets. This controls how EventBridge retries failed invocations before sending the event to a dead-letter queue (if configured).\n\n```yml\nstepFunctions:\n  stateMachines:\n    myMachine:\n      events:\n        - schedule:\n            rate: rate(10 minutes)\n            retryPolicy:\n              maximumEventAgeInSeconds: 3600\n              maximumRetryAttempts: 3\n        - eventBridge:\n            event:\n              source:\n                - aws.ec2\n            retryPolicy:\n              maximumEventAgeInSeconds: 7200\n              maximumRetryAttempts: 5\n      definition:\n        ...\n```\n\nBoth `maximumEventAgeInSeconds` (60–86400) and `maximumRetryAttempts` (0–185) are optional. When omitted, AWS applies its default retry behaviour.\n\n## Tags\n\nYou can specify tags on each state machine. Additionally any global tags (specified under `provider` section in your `serverless.yml`) would be merged in as well.\n\nIf you _don't_ want for global tags to be merged into your state machine, you can include the `inheritGlobalTags` property for your state machine.\n\n```yaml\nprovider:\n  tags:\n    app: myApp\n    department: engineering\nstepFunctions:\n  stateMachines:\n    hellostepfunc1:\n      name: myStateMachine\n      inheritGlobalTags: false\n      tags:\n        score: 42\n      definition: something\n```\n\nAs a result, `hellostepfunc1` will only have the tag of `score: 42`, and _not_ the tags at the provider level\n\n## Commands\n\n### deploy\n\nRun `sls deploy`, the defined Stepfunctions are deployed.\n\n### invoke\n\n`$ sls invoke stepf --name \u003cstepfunctionname\u003e --data '{\"foo\":\"bar\"}'`\n\n#### options\n\n* --name or -n The name of the step function in your service that you want to invoke. Required.\n* --stage or -s The stage in your service you want to invoke your step function.\n* --region or -r The region in your stage that you want to invoke your step function.\n* --data or -d String data to be passed as an event to your step function.\n* --path or -p The path to a json file with input data to be passed to the invoked step function.\n\n## IAM Role\n\nThe IAM roles required to run Statemachine are automatically generated for each state machine in the `serverless.yml`, with the IAM role name of `StatesExecutionPolicy-\u003cenvironment\u003e`. These roles are tailored to the services that the state machine integrates with, for example with Lambda the `InvokeFunction` is applied. You can also specify a custom ARN directly to the step functions lambda.\n\nHere's an example:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      role: arn:aws:iam::xxxxxxxx:role/yourRole\n      definition:\n```\n\nIt is also possible to use the [CloudFormation intrinsic functions](https://docs.aws.amazon.com/en_en/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html) to reference resources from elsewhere. This allows for an IAM role to be created, and applied to the state machines all within the serverless file.\n\nThe below example shows the policy needed if your step function needs the ability to send a message to an sqs queue. To apply the role either the RoleName can be used as a reference in the state machine, or the role ARN can be used like in the example above. It is important to note that if you want to store your state machine role at a certain path, this must be specified on the `Path` property on the new role.\n\n```yml\nstepFunctions:\n  stateMachines:\n    hello:\n      role:\n        Fn::GetAtt: [\"StateMachineRole\", \"Arn\"]\n      definition:\n        ...\n\nresources:\n  Resources:\n    StateMachineRole:\n      Type: AWS::IAM::Role\n      Properties:\n        RoleName: RoleName\n        Path: /path_of_state_machine_roles/\n        AssumeRolePolicyDocument:\n          Statement:\n            - Effect: Allow\n              Principal:\n                Service:\n                  - states.amazonaws.com\n              Action:\n                - sts:AssumeRole\n        Policies:\n          - PolicyName: statePolicy\n            PolicyDocument:\n              Version: \"2012-10-17\"\n              Statement:\n                - Effect: Allow\n                  Action:\n                    - lambda:InvokeFunction\n                  Resource:\n                    - arn:aws:lambda:lambdaName\n                - Effect: Allow\n                  Action:\n                    - sqs:SendMessage\n                  Resource:\n                    - arn:aws:sqs::xxxxxxxx:queueName\n```\n\nThe short form of the intrinsic functions (i.e. `!Sub`, `!Ref`) is not supported at the moment.\n\n## Tips\n\n### How to specify the stateMachine ARN to environment variables\n\nHere is serverless.yml sample to specify the stateMachine ARN to environment variables.\nThis makes it possible to trigger your statemachine through Lambda events\n\n```yml\nfunctions:\n  hello:\n    handler: handler.hello\n    environment:\n      statemachine_arn: ${self:resources.Outputs.MyStateMachine.Value}\n\nstepFunctions:\n  stateMachines:\n    hellostepfunc:\n      name: myStateMachine\n      definition:\n        \u003cyour definition\u003e\n\nresources:\n  Outputs:\n    MyStateMachine:\n      Description: The ARN of the example state machine\n      Value:\n        Ref: MyStateMachine\n\nplugins:\n  - serverless-step-functions\n```\n\n### How to split up state machines into files\n\nWhen you have a large serverless project with lots of state machines\nyour serverless.yml file can grow to a point where it is unmaintainable.\n\nYou can split step functions into external files and import them\ninto your serverless.yml file.\n\nThere are two ways you can do this:\n\n#### Single external file\n\nYou can define the entire `stateMachines` block in a separate file\nand import it in its entirety.\n\nincludes/state-machines.yml:\n\n```yml\nstateMachines:\n  hellostepfunc1:\n    name: myStateMachine1\n    definition:\n      \u003cyour definition\u003e\n  hellostepfunc2:\n    name: myStateMachine2\n    definition:\n      \u003cyour definition\u003e\n```\n\nserverless.yml:\n\n```yml\nstepFunctions:\n  ${file(includes/state-machines.yml)}\n\nplugins:\n  - serverless-step-functions\n```\n\n#### Separate Files\n\nYou can split up the `stateMachines` block into separate files.\n\nincludes/state-machine-1.yml:\n\n```yml\nname: myStateMachine1\ndefinition:\n  \u003cyour definition\u003e\n```\n\nincludes/state-machine-2.yml:\n\n```yml\nname: myStateMachine2\ndefinition:\n  \u003cyour definition\u003e\n```\n\nserverless.yml:\n\n```yml\nstepFunctions:\n  stateMachines:\n    hellostepfunc1:\n      ${file(includes/state-machine-1.yml)}\n    hellostepfunc2:\n      ${file(includes/state-machine-2.yml)}\n\nplugins:\n  - serverless-step-functions\n```\n\n## Sample statemachines setting in serverless.yml\n\n### Wait State\n\n``` yaml\nfunctions:\n  hello:\n    handler: handler.hello\n\nstepFunctions:\n  stateMachines:\n    yourWateMachine:\n      definition:\n        Comment: \"An example of the Amazon States Language using wait states\"\n        StartAt: FirstState\n        States:\n          FirstState:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello, Arn]\n            Next: wait_using_seconds\n          wait_using_seconds:\n            Type: Wait\n            Seconds: 10\n            Next: wait_using_timestamp\n          wait_using_timestamp:\n            Type: Wait\n            Timestamp: '2015-09-04T01:59:00Z'\n            Next: wait_using_timestamp_path\n          wait_using_timestamp_path:\n            Type: Wait\n            TimestampPath: \"$.expirydate\"\n            Next: wait_using_seconds_path\n          wait_using_seconds_path:\n            Type: Wait\n            SecondsPath: \"$.expiryseconds\"\n            Next: FinalState\n          FinalState:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello, Arn]\n            End: true\nplugins:\n  - serverless-step-functions\n```\n\n### Retry Failure\n\n``` yaml\nfunctions:\n  hello:\n    handler: handler.hello\n\nstepFunctions:\n  stateMachines:\n    yourRetryMachine:\n      definition:\n        Comment: \"A Retry example of the Amazon States Language using an AWS Lambda Function\"\n        StartAt: HelloWorld\n        States:\n          HelloWorld:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello, Arn]\n            Retry:\n            - ErrorEquals:\n              - HandledError\n              IntervalSeconds: 1\n              MaxAttempts: 2\n              BackoffRate: 2\n            - ErrorEquals:\n              - States.TaskFailed\n              IntervalSeconds: 30\n              MaxAttempts: 2\n              BackoffRate: 2\n            - ErrorEquals:\n              - States.ALL\n              IntervalSeconds: 5\n              MaxAttempts: 5\n              BackoffRate: 2\n            End: true\nplugins:\n  - serverless-step-functions\n```\n\n### Parallel\n\n```yaml\nfunctions:\n  hello:\n    handler: handler.hello\n\nstepFunctions:\n  stateMachines:\n    yourParallelMachine:\n      definition:\n        Comment: \"An example of the Amazon States Language using a parallel state to execute two branches at the same time.\"\n        StartAt: Parallel\n        States:\n          Parallel:\n            Type: Parallel\n            Next: Final State\n            Branches:\n              - StartAt: Wait 20s\n                States:\n                  Wait 20s:\n                    Type: Wait\n                    Seconds: 20\n                    End: true\n              - StartAt: Pass\n                States:\n                  Pass:\n                    Type: Pass\n                    Next: Wait 10s\n                  Wait 10s:\n                    Type: Wait\n                    Seconds: 10\n                    End: true\n          Final State:\n            Type: Pass\n            End: true\nplugins:\n  - serverless-step-functions\n```\n\n### Catch Failure\n\n```yaml\nfunctions:\n  hello:\n    handler: handler.hello\n\nstepFunctions:\n  stateMachines:\n    yourCatchMachine:\n      definition:\n        Comment: \"A Catch example of the Amazon States Language using an AWS Lambda Function\"\n        StartAt: HelloWorld\n        States:\n          HelloWorld:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello, Arn]\n            Catch:\n              - ErrorEquals: [\"HandledError\"]\n                Next: CustomErrorFallback\n              - ErrorEquals: [\"States.TaskFailed\"]\n                Next: ReservedTypeFallback\n              - ErrorEquals: [\"States.ALL\"]\n                Next: CatchAllFallback\n            End: true\n          CustomErrorFallback:\n            Type: Pass\n            Result: \"This is a fallback from a custom lambda function exception\"\n            End: true\n          ReservedTypeFallback:\n            Type: Pass\n            Result: \"This is a fallback from a reserved error code\"\n            End: true\n          CatchAllFallback:\n            Type: Pass\n            Result: \"This is a fallback from a reserved error code\"\n            End: true\nplugins:\n  - serverless-step-functions\n```\n\n### Choice\n\n```yaml\nfunctions:\n  hello1:\n    handler: handler.hello1\n  hello2:\n    handler: handler.hello2\n  hello3:\n    handler: handler.hello3\n  hello4:\n    handler: handler.hello4\n\nstepFunctions:\n  stateMachines:\n    yourChoiceMachine:\n      definition:\n        Comment: \"An example of the Amazon States Language using a choice state.\"\n        StartAt: FirstState\n        States:\n          FirstState:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello, Arn]\n            Next: ChoiceState\n          ChoiceState:\n            Type: Choice\n            Choices:\n              - Variable: \"$.foo\"\n                NumericEquals: 1\n                Next: FirstMatchState\n              - Variable: \"$.foo\"\n                NumericEquals: 2\n                Next: SecondMatchState\n            Default: DefaultState\n          FirstMatchState:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello2, Arn]\n            Next: NextState\n          SecondMatchState:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello3, Arn]\n            Next: NextState\n          DefaultState:\n            Type: Fail\n            Cause: \"No Matches!\"\n          NextState:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [hello4, Arn]\n            End: true\nplugins:\n  - serverless-step-functions\n```\n\n### Map\n\n```yaml\n\nfunctions:\n  entry:\n    handler: handler.entry\n  mapTask:\n    handler: handler.mapTask\n\nstepFunctions:\n  stateMachines:\n    yourMapMachine:\n      definition:\n        Comment: \"A Map example of the Amazon States Language using an AWS Lambda Function\"\n        StartAt: FirstState\n        States:\n          FirstState:\n            Type: Task\n            Resource:\n              Fn::GetAtt: [entry, Arn]\n            Next: mapped_task\n          mapped_task:\n            Type: Map\n            Iterator:\n              StartAt: FirstMapTask\n              States:\n                FirstMapTask:\n                  Type: Task\n                  Resource:\n                    Fn::GetAtt: [mapTask, Arn]\n                  End: true\n            End: true\n\nplugins:\n  - serverless-step-functions\n```\n","funding_links":[],"categories":["JavaScript"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fserverless-operations%2Fserverless-step-functions","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fserverless-operations%2Fserverless-step-functions","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fserverless-operations%2Fserverless-step-functions/lists"}