DynamoDB & Cognito
Last updated
Last updated
DynamoDB is a serverless NoSQL database that requires traffic limits provisioning. It’s called that way because it dynamically shards tables based on a proprietary algorithm that hashes a primary key, and distributes the data to a cluster. A successful primary key strategy involves randomizing as much as possible the key and avoid sequences.
You can access DynamoDB in this link: https://console.aws.amazon.com/dynamodb/home?region=us-east-1#
The tables we created for cognito are extremely simple. Currently, we only have need for at least two fields:
User ID (string uuid)
Claims (string)
The claims in plain text for a user looks like this:
The value of this JSON string is completely trivial to DynamoDB, meaning it does not care what is stored there or if it is valid. It only cares if there is a claims column and if the value is a string.
Diagram owner
Team
@ Team member
Informed
@ Stakeholder
@ Stakeholder
Status
Last date updated
e.g.,24 Sep 2020
On this page
Name
Description
Operational Excellence
The ability to run and monitor systems to deliver business value and to continually improve supporting processes and procedures.
Security
The ability to protect information, systems, and assets while delivering business value through risk assessments and mitigation strategies.
Reliability
The ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.
Performance Efficiency
The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve
Cost Optimization
The ability to run systems to deliver business value at the lowest price point.
AWS Well Architected Framework PDF
note
Storing the token Claims for every individual user
Storing the claims safely and not in plain text (keeping them encrypted)
Serverless access to those claims for Cognito
There is no grand architecture in this space; however, a user pool uuid maps directly to the user_id column in the dynamo db table.
There are currently two tables in DynamoDB for the use of Cognito
atd-moped-users-production
atd-moped-users-staging
As you may have guessed, one is for each environment in cognito, which also has a staging and production separation.
In order to be able to access DynamoDB, the lambda trigger needs to have the following permissions (policy name: atd-moped-users-cognito-hook-secrets-access, role name: atd-moped-cognito-hook)
The deployment of the DynamoDB was manual. There is no real need to keep the deployment automated as there aren’t going to be a lot of changes to it.
Requests Per Second (RPS): The tables present a maximum reads per second and writes per second, this needs to be changed as the amount of traffic changes.
Action
Description
Owner
Due date
GitHub ticket
1
Change RPS
There needs to be a change in the RPS, currently at 5 r/w ps.
e.g.,24 Sep 2020
None Yet.
2
If you are new to DynamoDB, here is an excellent resource to learn it quickly: https://www.linkedin.com/learning/aws-for-developers-dynamodb/why-dynamodb?u=55898036
Cognito provides us a UUID string for each individual user, this is what we use as our primary. Since it is random by nature, it’s the perfect pick for our primary key strategy.
This field is just a string, in Dynamo it looks like this (encrypted):
()
