Non-Breaking Lambda Deployments for Alexa Skills using Versions and Aliases

No Comments

Let’s say we have a certified Amazon Alexa Skill that has an endpoint pointing to an AWS Lambda function. We want to update the Lambda function but the update contains breaking changes for the current live version of the Alexa Skill. It is necessary to update the Alexa Skill Model to work with the new Lambda function. As each change on the Alexa Skill Model needs to be certified by the Alexa Team – and this may take several days – we have a time gap where our existing live Skill would break if we deploy the new version of our Lambda function. How do we deploy the new Lambda code without risking that our skill is broken for the time of certification? In this tutorial I’m going to use Lambda Versions and Aliases to set up a non-breaking Lambda deployment strategy.

Using Versions for Lambda Deployments

Whenever new code is deployed to a Lambda function, the current one will be replaced. The only way to avoid this is using versions. When creating a version for a Lambda the current code and all configurations are frozen and cannot be modified any more. This is exactly what we need for our Alexa Skill endpoints.

To create a version go to your Lambda function in the AWS console and click on “Actions -> Publish new version”.

Publish new Lambda Version

Each version gets a unique id starting from 1. When you push new code to the Lambda function it will be mapped to the predefined version $LATEST by default.

Note: You need to set the Alexa Skills Kit trigger again for the each created Lambda version.

You can reference the Lambda function with version 1 by adding the version to the Lambda ARN at the end:


You can use this ARN in your Alexa Skill endpoint and you will never risk breaking your Lambda when pushing new changes.

You can find more information about versions in the AWS documentation:

Using Aliases for flexibility

But wait, what if I want to fix a small bug in my Lambda and don’t want to recertify my Alexa Skill again? Remember, even changing only the endpoint of your Alexa Skill would mean a new certification roundtrip for the Skill as the endpoint is part of the Alexa Skill Model. To solve that problem the Lambda Aliases are a perfect solution. An Alias gives you the opportunity to point to a specific version of a Lambda and change the reference at any time.

To create an Alias go to “Actions -> Create alias” in your Lambda function:

Create new Lambda Alias

In the following dialog specify the name of the Alias, i.e. PROD1 and which version the alias should reference.

Note: After creating the Alias you need to set the Alexa Skills Kit trigger for that Alias again. Otherwise the Alias cannot be used for the Alexa Skill endpoint.

The Alias can be referenced by adding the Alias name at the end of the Lambda ARN:


Create another Alias with the name PROD2 and point it to the version $LATEST. This is necessary if you want to certify a new Alexa Skill version. Whenever you are ready to certify a new Skill version you will create a new Lambda version and change the reference for the Alias PROD2 to this version and use the Alias PROD2 for the endpoint of your skill to be certified.

The Alias can be edited in the dropdown “Qualifiers -> Aliases”:

Edit Lambda Alias

Change Lambda Alias Version

You need to rotate the aliases PROD1 and PROD2 for each certification process.


By using Lambda versions you can easily deploy new code to your Lambda function without breaking the current live Alexa Skill. You can even deploy bug fixes without the need to recertify the Skill when using Lambda Aliases. Here is an overview of the whole process:

Lambda Alias Versions Overview Architecture

By the way, you can use this strategy together with an API Gateway, too. There need to be two API Gateway endpoints that are pointing to the Lambda Aliases PROD1 and PROD2.

If you have any questions or new ideas, feel free to use the comment section below. Check out my last blog post where I explained how to quickly setup a Alexa Skill using AWS Codestar (

René Bohrenfeldt has been involved in software development for more than 12 years, focusing primarily on front-end technologies. At codecentric AG, as an IT consultant, he uses both his development know-how and his communication skills as a PO and moderator for our customers.

