In this lab, we are presented with a site that is struggling under load because the backing DynamoDB table has had its Read and Write provisioning drastically reduced to avoid incurring significant cost. To correct this, we will provision a DynamoDB Accelerator (DAX) cluster and modify the Lambda functions in the site architecture to implement caching to return the site to a functional state.
Learning Objectives
Successfully complete this lab by achieving the following learning objectives:
- Launch a DynamoDB Accelerator (DAX) Cluster
- Navigate to DynamoDB.
- Click Dashboard in the left-hand menu.
- Click Create cluster.
- Set the following values:
- Cluster name: tatourneycache
- Node type: dax.t2.small
- Cluster size: 1
- IAM Service role for DynamoDB access: Create new
- IAM role name: DAXtoDynamoDB
- IAM policy name: DAXtoDynamoDBPolicy
- IAM role policy: Read/Write
- Target DynamoDB table: TaTourneyStats
- Subnet group: Create new
- Name: tatourney
- VPC: Select the provided VPC
- Subnets: Check both subnets listed
- Security group: default (not the cfst- one)
- Click Launch cluster.
- Modify `getTaStats` Lambda Function
- Navigate to the Lambda service.
- Select the function with getTaStats in the name.
- Modify the function to utilize the DAX client in place of the Boto3 DynamoDB client.
Note: If you’re not comfortable editing code, a modified version of this function is available at the GitHub link on the lab page.
- Modify `taStreamProcessor` Lambda Function
- Navigate to the Lambda service.
- Select the function with taStreamProcessor in the name.
- Modify the function to replace the Boto3 DynamoDB client with the DAX client.
Note: If you’re not comfortable editing code, a modified version of this function is available at the GitHub link on the lab page.
