Why use DynamoDb with Amazon Connect?
Amazon Connect allows accessing external resources through integration with AWS Lambda. Seems like databases and CRM systems are some of the resources that first come to mind when thinking how to add value to a contact center deployment.
With Amazon Connect, it’s quite easy to customize call experience for your customers. While a caller is in the IVR, it’s possible to do a simple background database lookup based on the incoming phone number. As a result, you’ll be able to provide an experience tailored to that particular customer. Also, it’s possible to populate call context for agents within the softphone window (CCP) using the Amazon Connect StreamsAPI.
DynamoDb could be a good choice to help implement a call experience like that. This is a NoSQL cloud database service that allows you to store key-value pairs. There are multiple reasons to use DynamoDb for data management but let’s focus on the contact center domain here.
Here’s why it may be convenient for use with Amazon Connect:
- It’s there. Any AWS user can start using DynamoDb service in minutes.
- It’s easy to use. Non-technical people can easily create tables and populate them.
- It’s scalable. Even better, it’s auto-scalable based on specified utilization.
Going with DynamoDb means you’ll need to add some permissions for the Lambda function to access database resources. Let’s review different access levels and what are some minimum permissions, based on your requirements.
DynamoDb Access levels
Access Level groups: List/ Read/ Write
IAM Console policy creator provides a visual editor for granting permissions graphically. DynamoDb access levels are grouped by List, Read and Write actions. To select permissions graphically:
- Navigate to the IAM Console and create a new policy. Click on DynamoDb service.
2. Select minimum permissions required for your Lambda function to execute. If you’re not sure which ones do you need, read further to see what are some common actions and how to find minimum permissions.
Access Level: Most common actions
Some of the most common operations used are data reading (Scan, Query, GetItem) and data writing actions (PutItem, UpdateItem).
- “dynamodb:Scan”
- “dynamodb:GetItem”
- “dynamodb:Query”
- “dynamodb:PutItem”
- “dynamodb:UpdateItem”
Here is a sample JSON policy that grants all permissions listed above, on all DynamoDb resources.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:GetItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:UpdateItem"
],
"Resource": "*"
}
]
}
Need to limit access to certain tables?
Going more granular
It’s possible to specify a certain resource in the policy document. For example, here is a JSON policy that allows using only GetItem action against votingTable resource.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "dynamodb:GetItem",
"Resource": "arn:aws:dynamodb:us-east-1:*:table/votingResults"
}
]
}
Finding minimum permissions
Here’s a tip on how to find the bare minimum of DynamoDb permissions for your case. This can be useful if your organization requires using the principle of least privilege.
- Write your Lambda function. Do not provide any database permissions just yet.
- Run it and let it fail.
- You’ll find the minimum permissions by inspecting the error you get.
“errorMessage”: “An error occurred (AccessDeniedException) when calling the GetItem operation: User: arn:aws:sts::XXXXXXXXXXXXX:assumed-role/LambdaDynamoRole/PyDynamoDbVoting is not authorized to perform: dynamodb:GetItem on resource: arn:aws:dynamodb:us-east-1:XXXXXXXXXXXXX:table/votingResults”
4. Add the missing permissions to the IAM policy, then assign the custom policy to the Lambda execution role.
5. Re-run the function and keep on adding permissions until all permission errors have cleared out.
If you’re interested to learn more, ask for a demo or contact us here.
