Manage your Amazon Lex bot via AWS CloudFormation templates

Amazon Lex is a fully managed artificial intelligence (AI) service with advanced natural language models to design, build, test, and deploy conversational interfaces in applications. It employs advanced deep learning technologies to understand user input, enabling developers to create chatbots, virtual assistants, and other applications that can interact with users in natural language.

Managing your Amazon Lex bots using AWS CloudFormation allows you to create templates defining the bot and all the AWS resources it depends on. AWS CloudFormation provides and configures those resources on your behalf, removing the risk of human error when deploying bots to new environments. The benefits of using CloudFormation include:

Consistency – A CloudFormation template provides a more consistent and automated way to deploy and manage the resources associated with an Amazon Lex bot.
Version control – With AWS CloudFormation, you can use version control systems like Git to manage your CloudFormation templates. This allows you to maintain different versions of your bot and roll back to previous versions if needed.
Reusability – You can reuse CloudFormation templates across multiple environments, such as development, staging, and production. This saves time and effort in defining the same bot across different environments.
Expandability – As your Amazon Lex bot grows in complexity, managing it through the AWS Management Console becomes more challenging. AWS CloudFormation allows for a more streamlined and efficient approach to managing the bot’s definition and resources.
Automation – Using a CloudFormation template allows you to automate the deployment process. You can use AWS services like AWS CodePipeline and AWS CodeBuild to build, test, and deploy your Amazon Lex bot automatically.

In this post, we guide you through the steps involved in creating a CloudFormation template for an Amazon Lex V2 bot.

Solution overview

We have chosen the Book Trip bot as our starting point for this exercise. We use a CloudFormation template to create a new bot from scratch, including defining intents, slots, and other required components. Additionally, we explore topics such as version control, aliases, integrating AWS Lambda functions, creating conditional branches, and enabling logging.

Prerequisites

You should have the following prerequisites:

An AWS account to create and deploy a CloudFormation template
The necessary AWS Identity and Access Management (IAM) permissions to deploy AWS CloudFormation and the resources used in the template
Basic knowledge of Amazon Lex, Lambda functions, and associated services
Basic knowledge of creating and deploying CloudFormation templates

Create an IAM role

To begin, you need to create an IAM role that the bot will use. You can achieve this by initializing a CloudFormation template and adding the IAM role as a resource. You can use the following template to create the role. If you download the example template and deploy it, you should see that an IAM role has been created. We provide examples of templates as we go through this post and merge them as we get further along.

AWSTemplateFormatVersion: “2010-09-09”
Transform: AWS::Serverless-2016-10-31
Description: CloudFormation template for book hotel bot.
Resources:
# 1. IAM role that is used by the bot at runtime
BotRuntimeRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: “2012-10-17”
Statement:
– Effect: Allow
Principal:
Service:
– lexv2.amazonaws.com
Action:
– “sts:AssumeRole”
Path: “/”
Policies:
– PolicyName: LexRuntimeRolePolicy
PolicyDocument:
Version: 2012-10-17
Statement:
– Effect: Allow
Action:
– “polly:SynthesizeSpeech”
– “comprehend:DetectSentiment”
Resource: “*”

Configure the Amazon Lex bot

Next, you need to add the bot definition. The following is the YAML template for the Amazon Lex bot definition; you construct the necessary components one by one:

Type: AWS::Lex::Bot
Properties:
AutoBuildBotLocales: Boolean
BotFileS3Location:
S3Location
BotLocales:
– BotLocale
BotTags:
– Tag
DataPrivacy:
DataPrivacy
Description: String
IdleSessionTTLInSeconds: Integer
Name: String
RoleArn: String
TestBotAliasSettings:
TestBotAliasSettings
TestBotAliasTags:
– Tag

To create a bot that only includes the bot definition without any intent, you can use the following template. Here, you specify the bot’s name, the ARN of the role that you previously created, data privacy settings, and more:

BookHotelBot:
DependsOn: BotRuntimeRole # The role created in the previous step
Type: AWS::Lex::Bot
Properties:
Name: “BookHotel”
Description: “Sample Bot to book a hotel”
RoleArn: !GetAtt BotRuntimeRole.Arn
#For each Amazon Lex bot created with the Amazon Lex Model Building Service, you must specify whether your use of Amazon Lex
#is related to a website, program, or other application that is directed or targeted, in whole or in part, to children under
#age 13 and subject to the Children’s Online Privacy Protection Act (COPPA) by specifying true or false in the
#childDirected field.
DataPrivacy:
ChildDirected: false
IdleSessionTTLInSeconds: 300

You can download the updated template. Deploying the updated template allows you to create both the role and the bot definition. Note that you’re updating the stack you created in the previous step.

The final step entails defining the BotLocales, which form the majority of the bot’s functionality. This includes, for example, Intents and Slot types. The following is the YAML template:

CustomVocabulary:
CustomVocabulary
Description: String
Intents:
– Intent
LocaleId: String
NluConfidenceThreshold: Number
SlotTypes:
– SlotType
VoiceSettings:
VoiceSettings

In this case, you build the BookHotel intent, which requires a custom slot type for room types. You set the LocaleId, then the VoiceSettings. Then you add the SlotTypes and their corresponding values.

The next step is to define the Intents, starting with the first intent, BookHotel, which involves adding utterances, slots, and slot priorities. The details of these nodes are demonstrated in the provided template. Finally, you add the second intent, which is the FallbackIntent. See the following code:

BotLocales:
– LocaleId: “en_US”
Description: “en US locale”
NluConfidenceThreshold: 0.40
VoiceSettings:
VoiceId: “Matthew”
SlotTypes:
– Name: “RoomTypeValues”
Description: “Type of room”
SlotTypeValues:
– SampleValue:
Value: queen
– SampleValue:
Value: king
– SampleValue:
Value: deluxe
ValueSelectionSetting:
ResolutionStrategy: ORIGINAL_VALUE
Intents:
– Name: “BookHotel”
Description: “Intent to book a hotel room”
SampleUtterances:
– Utterance: “Book a hotel”
– Utterance: “I want a make hotel reservations”
– Utterance: “Book a {Nights} night stay in {Location}”
IntentConfirmationSetting:
PromptSpecification:
MessageGroupsList:
– Message:
PlainTextMessage:
Value: “Okay, I have you down for a {Nights} night stay in {Location} starting {CheckInDate}. Shall I book the reservation?”
MaxRetries: 3
AllowInterrupt: false
DeclinationResponse:
MessageGroupsList:
– Message:
PlainTextMessage:
Value: “Okay, I have cancelled your reservation in progress.”
AllowInterrupt: false
SlotPriorities:
– Priority: 1
SlotName: Location
– Priority: 2
SlotName: CheckInDate
– Priority: 3
SlotName: Nights
– Priority: 4
SlotName: RoomType
Slots:
– Name: “Location”
Description: “Location of the city in which the hotel is located”
SlotTypeName: “AMAZON.City”
ValueElicitationSetting:
SlotConstraint: “Required”
PromptSpecification:
MessageGroupsList:
– Message:
PlainTextMessage:
Value: “What city will you be staying in?”
MaxRetries: 2
AllowInterrupt: false
– Name: “CheckInDate”
Description: “Date of check-in”
SlotTypeName: “AMAZON.Date”
ValueElicitationSetting:
SlotConstraint: “Required”
PromptSpecification:
MessageGroupsList:
– Message:
PlainTextMessage:
Value: “What day do you want to check in?”
MaxRetries: 2
AllowInterrupt: false
– Name: “Nights”
Description: “something”
SlotTypeName: “AMAZON.Number”
ValueElicitationSetting:
SlotConstraint: “Required”
PromptSpecification:
MessageGroupsList:
– Message:
PlainTextMessage:
Value: “How many nights will you be staying?”
MaxRetries: 2
AllowInterrupt: false
– Name: “RoomType”
Description: “Enumeration of types of rooms that are offered by a hotel.”
SlotTypeName: “RoomTypeValues”
ValueElicitationSetting:
SlotConstraint: “Required”
PromptSpecification:
MessageGroupsList:
– Message:
PlainTextMessage:
Value: “What type of room would you like, queen, king or deluxe?”
MaxRetries: 2
AllowInterrupt: false
– Name: “FallbackIntent”
Description: “Default intent when no other intent matches”
ParentIntentSignature: “AMAZON.FallbackIntent”

You can download the CloudFormation template for the work done until now. After you update your stack with this template, a functional bot will be deployed. On the Amazon Lex console, you can confirm that there is a draft version of the bot, and a default alias named TestBotAlias has been created.

Create a new bot version and alias

Amazon Lex supports publishing versions of bots, intents, and slot types so that you can control your client applications’ implementation. A version is a numbered snapshot of your bot definition that you can publish for use in different parts of your workflow, such as development, beta deployment, and production. Amazon Lex bots also support aliases. An alias is a pointer to a specific version of a bot. With an alias, you can update your client applications’ version. In practical scenarios, bot aliases are used for blue/green deployments and managing environment-specific configurations like development and production environments.

To illustrate, let’s say you point an alias to version 1 of your bot. When it’s time to update the bot, you can publish version 2 and change the alias to point to the new version. Because your applications use the alias instead of a specific version, all clients receive the new functionality without requiring updates.

Keep in mind that when you modify the CloudFormation template and initiate deployment, the changes are implemented within the draft version, primarily meant for testing. After you complete your testing phase, you can establish a new version to finalize the changes you’ve incorporated so far.

Next, you create a new bot version based on your draft, set up a new alias, and link the version to this alias. The following are the two new resources to add to your template:

BookHotelInitialVersion:
DependsOn: BookHotelBot
Type: AWS::Lex::BotVersion
Properties:
BotId: !Ref BookHotelBot
BotVersionLocaleSpecification:
– LocaleId: en_US
BotVersionLocaleDetails:
SourceBotVersion: DRAFT
Description: Hotel Bot initial version

BookHotelDemoAlias:
Type: AWS::Lex::BotAlias
Properties:
BotId: !Ref BookHotelBot
BotAliasName: “BookHotelDemoAlias”
BotVersion: !GetAtt BookHotelInitialVersion.BotVersion

You can download the new version of the template and deploy it by updating your stack. You can see on the Amazon Lex console that a new version is created and associated with a new alias called BookHotelDemoAlias.

When you create a new version of an Amazon Lex bot, it typically increments the version number sequentially, starting from 1. To discern a specific version, you can refer to its description.

Add a Lambda function

To initialize values or validate user input for your bot, you can add a Lambda function as a code hook to your bot. Similarly, you can use a Lambda function for fulfillment as well, for example writing data to databases or calling APIs save the collected information. For more information, refer to Enabling custom logic with AWS Lambda functions.

Let’s add a new resource for the Lambda function to the CloudFormation template. Although it’s generally not advised to embed code in CloudFormation templates, we do so here solely for the sake of making the demo deployment less complicated. See the following code:

HotelBotFunction:
DependsOn: BotRuntimeRole # So that the Lambda function is ready before the bot deployment
Type: AWS::Serverless::Function
Properties:
FunctionName: book_hotel_lambda
Runtime: python3.11
Timeout: 15
Handler: index.lambda_handler
InlineCode: |
import os
import json

def close(intent_request):
intent_request[‘sessionState’][‘intent’][‘state’] = ‘Fulfilled’

message = {“contentType”: “PlainText”,
“content”: “Your Booking is confirmed”}

session_attributes = {}
sessionState = intent_request[‘sessionState’]
if ‘sessionAttributes’ in sessionState:
session_attributes = sessionState[‘sessionAttributes’]

requestAttributes = None
if ‘requestAttributes’ in intent_request:
requestAttributes = intent_request[‘requestAttributes’]

return {
‘sessionState’: {
‘sessionAttributes’: session_attributes,
‘dialogAction’: {
‘type’: ‘Close’
},
‘intent’: intent_request[‘sessionState’][‘intent’],
‘originatingRequestId’: ‘xxxxxxx-xxxx-xxxx-xxxx’
},
‘messages’: [message],
‘sessionId’: intent_request[‘sessionId’],
‘requestAttributes’: requestAttributes
}

def router(event):
intent_name = event[‘sessionState’][‘intent’][‘name’]
slots = event[‘sessionState’][‘intent’][‘slots’]
if (intent_name == ‘BookHotel’):
# invoke lambda and return result
return close(event)

raise Exception(
‘The intent is not supported by Lambda: ‘ + intent_name)

def lambda_handler(event, context):
response = router(event)
return response

To use this Lambda function for the fulfillment, enable the code hook settings in your intent:

Intents:
– Name: “BookHotel”
Description: “Intent to book a hotel room”
FulfillmentCodeHook:
Enabled: true
SampleUtterances:
– Utterance: “Book a hotel”
– Utterance: “I want a make hotel reservations”
– Utterance: “Book a {Nights} night stay in {Location}”

Because you made changes to your bot, you can create a new version of the bot by adding a new resource named BookHotelVersionWithLambda in the template:

BookHotelVersionWithLambda:
DependsOn: BookHotelInitialVersion
Type: AWS::Lex::BotVersion
Properties:
BotId: !Ref BookHotelBot
BotVersionLocaleSpecification:
– LocaleId: en_US
BotVersionLocaleDetails:
SourceBotVersion: DRAFT
Description: Hotel Bot with a lambda function

The Lambda function is associated with a bot alias. Amazon Lex V2 can use one Lambda function per bot alias per language. Therefore, you must update your alias in the template to add the Lambda function resource. You can do so in the BotAliasLocalSettings section. You also need to point the alias to the new version you created. The following code is the modified alias configuration:

BookHotelDemoAlias:
Type: AWS::Lex::BotAlias
Properties:
BotId: !Ref BookHotelBot
BotAliasName: “BookHotelDemoAlias”
BotVersion: !GetAtt BookHotelVersionWithLambda.BotVersion
# Remove BotAliasLocaleSettings if you aren’t concerned with Lambda setup.
# If you are you can modify the LambdaArn below to get started.
BotAliasLocaleSettings:
– LocaleId: en_US
BotAliasLocaleSetting:
Enabled: true
CodeHookSpecification:
LambdaCodeHook:
CodeHookInterfaceVersion: “1.0”
LambdaArn: !GetAtt HotelBotFunction.Arn

Up until now, you have only linked the Lambda function with the alias. However, you need to grant permission to allow the alias to invoke the Lambda function. In the following code, you add the Lambda invoke permission for Amazon Lex and specify the alias ARN as the source ARN:

LexInvokeLambdaPermission:
Type: AWS::Lambda::Permission
Properties:
Action: “lambda:InvokeFunction”
FunctionName: !GetAtt HotelBotFunction.Arn
Principal: “lexv2.amazonaws.com”
SourceArn: !GetAtt BookHotelDemoAlias.Arn

You can download the latest version of the template. After updating your stack with this version, you will have an Amazon Lex bot integrated with a Lambda function.

Conditional branches

Now let’s explore the conditional branch feature of the Amazon Lex bot and consider a scenario where booking more than five nights in Seattle is not allowed for the next week. As per the business requirement, the conversation should end with an appropriate message if the user attempts to book more than five nights in Seattle. The conditional branch for that is represented in the CloudFormation template under the SlotCaptureSetting:

– Name: “Nights”
Description: “Number of nights.”
SlotTypeName: “AMAZON.Number”
ValueElicitationSetting:
SlotConstraint: “Required”
SlotCaptureSetting:
CaptureConditional:
DefaultBranch:
NextStep:
DialogAction:
Type: “ElicitSlot”
SlotToElicit: “RoomType”
ConditionalBranches:
– Name: “Branch1”
Condition:
ExpressionString: ‘{Nights}>5 AND {Location} = “Seattle”‘
Response:
AllowInterrupt: true
MessageGroupsList:
– Message:
PlainTextMessage:
Value: “Sorry, we cannot book more than five nights in {Location} right now.”
NextStep:
DialogAction:
Type: “EndConversation”
IsActive: true

PromptSpecification:
MessageGroupsList:
– Message:
PlainTextMessage:
Value: “How many nights will you be staying?”
MaxRetries: 2
AllowInterrupt: false

Because you changed the bot definition, you need to create a new version in the template and link it with the alias. This is a temporary modification because the business plans to allow large bookings in Seattle soon. The following are the two new resources you add to the template:

BookHotelConditionalBranches:
DependsOn: BookHotelVersionWithLambda
Type: AWS::Lex::BotVersion
Properties:
BotId: !Ref BookHotelBot
BotVersionLocaleSpecification:
– LocaleId: en_US
BotVersionLocaleDetails:
SourceBotVersion: DRAFT
Description: Hotel Bot Version with conditional branches

BookHotelDemoAlias:
Type: AWS::Lex::BotAlias
Properties:
BotId: !Ref BookHotelBot
BotAliasName: “BookHotelDemoAlias”
BotVersion: !GetAtt BookHotelConditionalBranches.BotVersion
# Remove BotAliasLocaleSettings if you aren’t concerned with Lambda setup.
# If you are you can modify the LambdaArn below to get started.
BotAliasLocaleSettings:
– LocaleId: en_US
BotAliasLocaleSetting:
Enabled: true
CodeHookSpecification:
LambdaCodeHook:
CodeHookInterfaceVersion: “1.0”
LambdaArn: !GetAtt HotelBotFunction.Arn

You can download the updated template. After you update your stack with this template version, the alias will be directed to the version incorporating the conditional branching feature. To undo this modification, you can update the alias to revert back to the previous version.

Logs

You can also enable logs for your Amazon Lex bot. To do so, you must update the bot’s role to grant permissions for writing Amazon CloudWatch logs. The following is an example of adding a CloudWatch policy to the role:

BotRuntimeRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: “2012-10-17”
Statement:
– Effect: Allow
Principal:
Service:
– lexv2.amazonaws.com
Action:
– “sts:AssumeRole”
Path: “/”
Policies:
– PolicyName: LexRuntimeRolePolicy
PolicyDocument:
Version: 2012-10-17
Statement:
– Effect: Allow
Action:
– “polly:SynthesizeSpeech”
– “comprehend:DetectSentiment”
Resource: “*”
– PolicyName: CloudWatchPolicy
PolicyDocument:
Version: 2012-10-17
Statement:
– Effect: Allow
Action:
– “logs:CreateLogStream”
– “logs:PutLogEvents”
Resource: “*”

To ensure consistent and predictable behavior, you should be as specific as possible when defining resource names and properties in CloudFormation templates. This is because the use of the wildcard character (*) in CloudFormation templates can pose potential security risks and lead to unintended consequences. Therefore, it’s recommended to avoid using wildcards and instead use explicit values wherever possible.

Next, you create a CloudWatch log group resource, as shown in the following code, to direct your logs to this group:

#Log Group
LexLogGroup:
Type: AWS::Logs::LogGroup
Properties:
LogGroupName: /lex/hotel-bot
RetentionInDays: 5

Finally, you update your alias to enable conversation log settings:

BookHotelDemoAlias:
Type: AWS::Lex::BotAlias
Properties:
BotId: !Ref BookHotelBot
BotAliasName: “BookHotelDemoAlias”
BotVersion: !GetAtt BookHotelConditionalBranches.BotVersion
BotAliasLocaleSettings:
– LocaleId: en_US
BotAliasLocaleSetting:
Enabled: true
CodeHookSpecification:
LambdaCodeHook:
CodeHookInterfaceVersion: “1.0”
LambdaArn: !GetAtt HotelBotFunction.Arn
ConversationLogSettings:
TextLogSettings:
– Destination:
CloudWatch:
CloudWatchLogGroupArn: !GetAtt LexLogGroup.Arn
LogPrefix: bookHotel
Enabled: true

When you update the stack with this template, you enable the conversation logs for your bot. A new version is not created in this step because there are no changes to your bot resource. You can download the latest version of the template.

Clean Up

To prevent incurring charges in the future, delete the CloudFormation stack you created.

Conclusion

In this post, we discussed the step-by-step process to create a CloudFormation template for an Amazon Lex V2 bot. Initially, we deployed a basic bot, then we explored the potential of aliases and versions and how to use them efficiently with templates. Next, we learned how to integrate a Lambda function with an Amazon Lex V2 bot and implemented conditional branching in the bot’s conversation flow to accommodate business requirements. Finally, we added logging features by creating a CloudWatch log group resource and updating the bot’s role with the necessary permissions.

The template allows for the straightforward deployment and management of the bot, with the ability to revert changes as necessary. Overall, the CloudFormation template is useful for managing and optimizing an Amazon Lex V2 bot.

As the next step, you can explore sample Amazon Lex bots and apply the techniques discussed in this post to convert them into CloudFormation templates. This hands-on practice will solidify your understanding of managing Amazon Lex V2 bots through infrastructure as code.

About the Authors

Thomas Rindfuss is a Sr. Solutions Architect on the Amazon Lex team. He invents, develops, prototypes, and evangelizes new technical features and solutions for Language AI services that improves the customer experience and eases adoption.

Rijeesh Akkambeth Chathoth is a Professional Services Consultant at AWS. He helps customers in achieving their desired business
outcomes in the Contact Center space by leveraging Amazon Connect, Amazon Lex and GenAI features.