Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News AWS Step Functions Introduces Versions and Aliases for Enhanced Deployment Resiliency

AWS Step Functions Introduces Versions and Aliases for Enhanced Deployment Resiliency

Recently, AWS announced the availability of versions and aliases in Step Functions to improve resiliency for deployments of serverless workflows.

AWS Step Functions is a serverless workflow service that allows developers to automate multiple AWS services into serverless workflows using visual workflows and state machines. It received several enhancements over the years, with workflow collections, additional observability features, and intrinsic functions of the more recent ones. The latest addition, versions and aliases, provide enhanced workflow deployment capabilities – offering developers a more resilient deployment experience.

Previously, developers required another Amazon States Language (ASL) update to fix the problem in their definition or an explicit action to revert the state machine to a previous definition.

With the versions and aliases feature, developers can manage multiple workflow versions, track their usage in each execution, and create aliases to route traffic between versions efficiently. By leveraging industry-standard techniques like blue-green, linear, and canary-style deployments, developers can gradually deploy workflows with swift rollbacks, enhancing deployment safety, minimizing downtime, and mitigating risks associated with Step Functions workflows.

Developers can leverage the AWS Step Functions Versions and Aliases feature in the AWS console, AWS CloudFormation, the AWS Command Line Interface (CLI), or the AWS Cloud Development Kit (CDK).

Peter Smith, a principal engineer for AWS Step Functions, outlines several scenarios for deploying state machines incrementally with versions and aliases in an AWS Compute blog post. One example is the blue-green deployment:

In this approach, the existing state machine version (currently used in production) is the "blue" version, whereas a newly deployed state machine is the "green" version. As a rule, you should deploy the blue version in production while testing the newer green version in a separate environment. Once the green version is validated, use it in production (it becomes the new blue version). If version 6 causes issues in production, roll back the "blue" alias to the previous value so that executions revert to version 5.


Benjamen Pyle, an AWS Community Builder in Serverless, concluded in a blog post:

My first thoughts when using this capability were, how have I been using Step Functions without Versions and Aliases the whole time? But then, as a stepped back, Lambda went through the same type of transition where you just always overwrote the existing function and didn’t do much canary or linear type rollouts. I have a feeling that I’m not going to use this technique for everything but for mission-critical workflows, it’s going to be a requirement.

In addition, Mario Bittencourt, a principal software architect, concluded in a medium blog post:

With this latest release of AWS you can bridge the gap for your step function-based processes as their support of aliases and versions give you enough built-in capabilities to address your needs.

Developers are not charged any extra fees for using Versions and Aliases; they only pay for what they use as per existing AWS Step Functions pricing.

About the Author

Rate this Article