AWS Contact Center

Invoke an AWS Lambda Function Alias from Amazon Connect

Amazon Connect enables you to create dynamic, personalized user engagements by integrating your contact center with AWS Lambda to access virtually any backend system, customer relationship management system, or other AWS services. Currently, Amazon Connect allows you to specify AWS Lambda functions in Contact Flows through the user interface. However, Amazon Connect calls the latest version of the Lambda function by default, meaning any changes to these Lambda functions become live immediately. Through the use of AWS Lambda Aliases, customers can continue to build and enhance their Lambda functions and backend systems without impacting their production traffic, minimizing the risk of new code or infrastructure deployments to improve customer experience.

This post shows how you can use AWS Lambda Aliases and the AWS Serverless Application Model to couple DevOps best practices to backend systems supporting your implementation of Amazon Connect. AWS Lambda Aliases allow you to safely and efficiently deploy new versions of backend infrastructure without making modifications to Amazon Connect Contact flows, allowing your developers to develop code without impacting your production contact center.

Overview of solution

AWS Lambda offers the capability to publish different versions of an AWS Lambda function over time while retaining the code, configuration, environment variables, and unique ARN for that particular version. AWS Lambda functions can be invoked using an Unqualified ARN or a Qualified ARN. By using a Qualified ARN, you can call a particular version of an AWS Lambda Function Alias.

Aliases are used to create a layer of abstraction between services or applications and the particular instantiation of a function. They allow you to shift traffic from one version to another incrementally or all at once, creating a way to reduce the risk of deploying new versions. Meanwhile, developers can continue to work on new versions of the AWS Lambda Function without impacting production traffic.

An architecture diagram demonstration how traffic can shift from one AWS Lambda function version to another using AWS Lambda Function Aliases

The architectural diagram above shows how we can introduce Blue Green deployments using AWS Lambda Aliases by shifting traffic from one version of a Lambda function to another. In this example, we show an AWS CodeDeploy Deployment that is managing the shift in traffic from Version 1 of our function to Version 2. Meanwhile, we are able to make changes to the latest version of the function without having an impact on the traffic coming from our production Amazon Connect instance.

Walkthrough

In this example, we will show how to dynamically shift traffic to an AWS Lambda function from an Amazon Connect contact center using AWS Lambda Aliases. We will be using the AWS Serverless Application Model or AWS SAM. AWS SAM is a framework that allows customers to quickly build and deploy serverless applications utilizing AWS CloudFormation.

Then, we will walk through how to use AWS SAM to automate the deployment of new versions of a function. AWS SAM includes useful deployment features that allow you to maintain different versions of a SAM application using AWS Lambda Aliases. With a couple lines in an AWS SAM template, you can determine how traffic transitions from one version of an AWS Lambda function to another and roll back changes based on CloudWatch Alarms.

The high-level steps we will follow are:

Prerequisites

For this walkthrough, you should have the following prerequisites:

  • An AWS account
  • An Amazon Connect instance
  • A basic understanding of AWS CloudFormation, Amazon Connect, and AWS Lambda

Step-by-step Instructions

These instructions assume a general working knowledge of Amazon Connect and AWS CloudFormation. For details on how to perform basic administration tasks with either, please refer to:

Deploy the CloudFormation Template

  1. Download the resource pack
  2. Unzip the file to your local machine, this will create a Resources folder which contains
    1. CloudFormation template lambdaalias.yml
    2. Amazon Connect contact flow for one time testing LambdaAlias-test
    3. Amazon Connect contact flow for testing in a loop LambdaAlias-loop
  3. Login to the AWS Console
  4. Open the AWS CloudFormation Console
  5. Make sure that you have the console open to the same Region as your Amazon Connect instance. See Choosing a Region in the Getting Started Guide In the CloudFormation console, choose Create stack
  6. On the Create stack screen, leave the Prerequisite set to Template is ready
  7. In the Specify template section, select Upload a template file, then select the Choose file button
  8. Navigate to the Resources folder that you created in step 2, open the CloudFormation folder inside, and select lambdaalias.yaml
  9. Once the template loads, choose Next
  10. Provide a name for the stack
  11. In the Parameters section, complete the values as follows:
    1. ConnectInstanceArn: enter in the ARN of your existing Amazon Connect instance. For help finding the ARN, refer to the AWS Premium Support page for finding your Amazon Connect instance ID.
    2. SAMAlias: leave as PROD. You can change this value to change the name of the AWS Lambda Alias.

An example of what the Parameters section   of the Cloudformation Stack might be

  1. Choose Next
  2. Apply any Tags as desired. Leave the rest of the options to their defaults and choose Next.
  3. Review the configuration. At the bottom of the page, select the three checkboxes to acknowledge that AWS CloudFormation might create IAM resources and IAM resources with custom names as well as that AWS CloudFormation might require CAPABILITY_AUTO_EXPAND.
  4. Choose Create stack. This will launch the CloudFormation template and create the resources needed. Creation should only take a couple minutes and deploys the following resources:
    1. ConnectLambdaFunction: a function that returns the invoked version of the function.
    2. ConnectLambdaFunctionAliasPROD: an AWS Lambda function alias
    3. ConnectLambdaFunctionVersion: the first version of the AWS Lambda function
    4. ConnectLambdaFunctionRole: a role with basic execution permissions
    5. AliasErrorMetricGreaterThanZeroAlarm: an Amazon CloudWatch Alarm for the AWS Lambda Alias
    6. ServerlessDeploymentApplication: an AWS SAM application
    7. ConnectLambdaFunctionDeploymentGroup: an AWS CodeDeploy Deployment Group
    8. CodeDeployServiceRole: a role for AWS CodeDeploy
  5. Once the stack is create, the status will change to CREATE_COMPLETE
  6. Select the Outputs tab
  7. Note the fully qualified ARN of the AWS Lambda Function Alias

An example of what the Output tabs of the Cloudformation Stack might look like

Import the Amazon Connect Contact Flow

  1. Log in to your contact center using your access URL.
  2. In the navigation pane, choose Routing, Contact flows.
  3. Choose Create contact flow. This opens the contact flow designer and creates an inbound contact flow (Type = Contact flow).
  4. Select the down arrow next to the greyed out Save button and choose Import flow (beta)
  5. Choose Select
  6. Navigate to the resources folder and select the LambdaAlias-test file, then choose Open
  7. Choose Import
  8. Once the flow imports, edit the Invoke AWS Lambda function node
  9. Replace the value for the function with the output value from your CloudFormation stack noted earlier. This would be the value for the key ConnectLambdaFunctionAlias
  10. Publish the Contact Flow

NOTE: We did not have to explicitly give permission for the Amazon Connect instance to call the fully qualified ARN of the AWS Lambda Function Alias. The AWS CloudFormation template included an explicit permission for the instance to call the Alias. Because permission was granted in such a way, the function will not appear in the drop down menu as described in the documentation. To grant an Amazon Connect instance access to invoke an AWS Lambda Alias, you can use the following command:

aws lambda add-permission –function-name <LAMBDA_ARN>:<ALIAS> –statement-id <UNIQUE_CODE> –action lambda:InvokeFunction –principal connect.amazonaws.com –source-account <ACCOUNT_ID> –source-arn <CONNECT_INSTANCE_ARN>

A contact flow that triggers the AWS Lambda function alias

  1. You can then test your contact flow using either the voice or chat channel
  2. In order to test the contact flow via chat, select Test Settings in the Test Chat page and select LambdaAlias-test under the System Settings’ Contact Flow menu
  3. Select Apply and open the chat window. If using voice, you will need to point a phone number to the LambdaAlias-test contact flow

An example of what the test chat window will show when executing a Lambda function version.

Publishing a new version of the AWS Lambda Function

  1. Navigate to AWS Lambda service console
  2. Select the AWS Lambda function created by the template
  3. In order to publish a new version, you will need to make a change to the function. For test purposes, add an additional comment somewhere in the function and save the function.
  4. Under Actions, select Publish a new version
  5. Optionally add a description and select Publish
  6. Under Qualifiers, select the PROD Alias
  7. In the Alias configuration section, select Version 2 of your function
    1. This menu also gives you the ability to shift traffic based on weights or percentages to different versions of your function. For more information, refer to the Alias Routing Configuration section of in the AWS Lambda documentation.
  8. Select Save

Configure the Lambda alias to use a different version.

  1. Test out your contact flow again. Because we reassigned the version associated to the AWS Lambda function alias, version 2 will be executed.

The test chat interface showing a new version of the function was executed.

Using AWS Sam for AWS Lambda deployments

The template provided uses Globals to leverage the gradual deployment mechanisms built into AWS SAM. Globals are AWS SAM properties that will be applied to Resources of a certain type like function runtime, environment variables, or deployment preferences. The template uses the Linear10PercentEvery1Minute parameter to shift 10% of traffic from one version of the function to another every minute when deploying a new version. The template also created a CloudWatch Alarm that will alarm if the new version experiences errors. You can also define other CloudWatch Alarms depending on your specific deployment success criteria. For example, you can define an alarm based on errors experienced in a particular contact flow. If the alarm enters an Alarm state, AWS SAM will stop the deployment and roll back to the previous application state automatically.

You can update the stack in your environment using the AWS CloudFormation console or AWS SAM CLI.

In order to simulate traffic, the LambdaAlias-loop contact flow loops by transferring to itself in the Transfer to flow module and can be run using the Test Chat page. Import the contact flow using the same method as above, making sure to replace the Invoke AWS Lambda function with the fully qualified ARN of the AWS Lambda function alias. In order to publish the flow for the first time, you will need to update the Transfer to flow block to point to an existing contact flow. Then, after publishing the first time, change the target contact flow back to LambdaAlias-loop.

An example  contact flow with looping behavior.

While the Test Chat window was looping through the Amazon Connect contact flow, I deployed three new versions of my AWS Lambda function using the AWS SAM CLI by altering the DeploymentPreference section of the template. For every deployment, I added a comment into the AWS Lambda function code in order to trigger a new build, otherwise the function will not update. First I used the AllAtOnce keyword to instantaneously transfer traffic, then the Linear10PercentEvery1Minute keyword to gradually shift traffic, and finally the Canary10Percent5Minutes keyword to test 10% of traffic for five minutes before rerouting all traffic.

A Cloudwatch graph showing lambda function versions executed over time.

To demonstrate how traffic is shifting from one version to another, we can use Cloudwatch Metrics to visualize the number of invocations against each version of an AWS Lambda function. The transfer of traffic happens utilizing an AWS CodeDeploy Deployment created for you by AWS SAM.

To demonstrate how AWS SAM can roll back changes, I modified the AWS Lambda function in a way I know will fail. Then I deployed a new version using the Linear10PercentEvery1Minute method.

A Cloudwatch graph showing lambda function versions executed over time when an error is introduced in the system.

Due to the relatively low volume of traffic my simulator produces, when the traffic started to shift from an old version to version 6, the CloudWatch alarm was not triggered immediately. However, as soon as more traffic started to flow to the new, erroneous version, the alarm was set to the alarm state. Once the state was picked up by AWS CodeDeploy, the changes were rolled back to the old version automatically.

Cleaning Up

To avoid incurring future charges, delete the resources created via the template by navigating to the AWS CloudFormation service, select the stack created by the template, and click delete. This will remove all resources created by the template. You can also delete the Amazon Connect instance in the Amazon Connect service console.

Conclusion

AWS Lambda Function Aliases provide a way to abstract implementation away from end users and offers a path towards reliable deployments through the AWS Serverless Application Model. By loosely coupling your Amazon Connect contact flows with your backend infrastructure with Aliases, you can quickly and safely iterate on business logic without affecting your production environments. Updating functions can then become a part of a larger CI/CD pipeline, allowing you to bring DevOps into your contact center. As an additional benefit, AWS Lambda Function versions can leverage provisioned concurrency, a feature that provides greater control over performance.