A serverless NoSQL table: DynamoDB on demand, written and read by key

short · 20 min · Task statement 3.4

Before you start — what this lab needs, and what it can cost

You work in your own AWS account, in AWS CloudShell, signed in as a non-root administrative identity: an IAM Identity Center user, or an IAM user with administrator permissions. Never sign in as the root user for this lab. The lab uses the AWS Free Tier where possible, but charges are possible, so do the clean-up the same day and check that it worked. It relies on the AWS Budgets alert you set in lesson 1's lab, which emails you if the account starts to cost money; if you skipped that lab, do it first.

Open CloudShell from the icon in the console's top bar, note the Region shown at the top right, and stay in that Region for the whole lab. Where a command shows the account ID 111122223333, put your own in its place: aws sts get-caller-identity --query Account --output text prints it.

The lab creates one DynamoDB table and nothing else. It uses the on-demand capacity mode, which charges for the requests you make and the data you store rather than for capacity reserved in advance. It never creates an RDS or Aurora database: those are charged for every hour the instance exists, so RDS is only read here.

This lab ends with a clean-up. Do it the same day: anything left running in your account is billed to you.

Task

Create an Amazon DynamoDB table in on-demand mode, write two items with different attributes to it, and read one back by its partition key. Then list the engines Amazon RDS offers, without creating a database. At the end you can show the differences the lesson turns on: DynamoDB has no instance to choose or size and no fixed schema beyond its key, and it is read by key rather than queried with SQL joins, while RDS runs familiar relational engines such as MySQL and PostgreSQL on a database instance you would pay for by the hour.

Steps

Confirm you are not the root user, then create the table. OrderId is its partition key, a string, and it is the only attribute you have to declare:

aws sts get-caller-identity --query Arn --output text
aws dynamodb create-table --table-name clf-lab16-orders --attribute-definitions AttributeName=OrderId,AttributeType=S --key-schema AttributeName=OrderId,KeyType=HASH --billing-mode PAY_PER_REQUEST
aws dynamodb wait table-exists --table-name clf-lab16-orders

PAY_PER_REQUEST is the CLI's name for on-demand mode. You chose no instance class, storage size or engine version, because there is none. 2. Write two items. They are invented sample orders. The second has an attribute the first lacks, which a relational table with a fixed schema would not allow without changing the table:

aws dynamodb put-item --table-name clf-lab16-orders --item '{"OrderId": {"S": "1001"}, "Shop": {"S": "Sample Shop"}, "Total": {"N": "24.50"}}'
aws dynamodb put-item --table-name clf-lab16-orders --item '{"OrderId": {"S": "1002"}, "Shop": {"S": "Sample Shop"}, "Total": {"N": "9.99"}, "GiftWrap": {"BOOL": true}}'

Read one item back by its key. This is the access pattern DynamoDB is built for:

aws dynamodb get-item --table-name clf-lab16-orders --key '{"OrderId": {"S": "1002"}}'

The reply holds the item with all four attributes. There is no SQL and no join here: a design that needs to combine customers, orders and products in one query points to a relational database instead. 4. Read the whole table with a scan, and compare it with the key lookup:

aws dynamodb scan --table-name clf-lab16-orders --select COUNT

It prints "Count": 2. A scan reads every item, which is fine for two items and slow and costly for millions. That is why DynamoDB tables are designed around the key you will look things up by. 5. Look at the table's settings in the DynamoDB console. Open DynamoDB, choose Tables, then clf-lab16-orders. On the Overview tab, Capacity mode reads On-demand, and the Backups tab shows that point-in-time recovery is off. Item count in the console is updated only every few hours, so it may still read 0. 6. Now look at the relational side without building it. These commands only read:

aws rds describe-db-engine-versions --default-only --query 'DBEngineVersions[].Engine' --output text
aws rds describe-db-instances --query 'length(DBInstances)'

The first prints engine names that include mysql, postgres, mariadb and aurora-mysql: the familiar engines RDS manages for you. The second counts your database instances, which is 0 in an account that has never made one, and it stays that way after this lab.

Verify

Run these read-only checks:

aws dynamodb describe-table --table-name clf-lab16-orders --query 'Table.TableStatus' --output text

Expected output: ACTIVE.

aws dynamodb describe-table --table-name clf-lab16-orders --query 'Table.BillingModeSummary.BillingMode' --output text

Expected output: PAY_PER_REQUEST, which is on-demand mode.

aws dynamodb scan --table-name clf-lab16-orders --select COUNT --query 'Count'

Expected output: 2.

aws dynamodb get-item --table-name clf-lab16-orders --key '{"OrderId": {"S": "1002"}}' --query 'Item.GiftWrap.BOOL' --output json

Expected output: true.

Cost and clean-up

DynamoDB on-demand requests and stored data may be charged outside the AWS Free Tier. A table holding two small items for a few minutes costs very little, but a forgotten table keeps its stored data, so delete it. See the Amazon DynamoDB pricing page or the AWS Pricing Calculator for current rates. The RDS commands in step 6 only read and create nothing.

Created by this lab: the DynamoDB table clf-lab16-orders, in on-demand mode, with its two sample items.

Delete the table clf-lab16-orders, which deletes its two items with it, and wait until it has gone:

aws dynamodb delete-table --table-name clf-lab16-orders
aws dynamodb wait table-not-exists --table-name clf-lab16-orders

Confirm in the DynamoDB console that Tables no longer lists clf-lab16-orders. Nothing else was created.

Check it is gone

aws dynamodb list-tables --query "TableNames[?@=='clf-lab16-orders'] | length(@)"

Expected output: 0.

aws rds describe-db-instances --query 'length(DBInstances)'

Expected output: the same number step 6 printed, which is 0 in an account that had no databases, because this lab made none.

Notes

Why not an RDS database? Even the smallest RDS instance is charged for every hour it runs, keeps automated backups and takes several minutes to create and delete, so a forgotten one becomes a bill. A DynamoDB on-demand table teaches the lesson's sharpest contrast, managed NoSQL against managed relational, at almost no risk. Do not switch the table to provisioned capacity: that mode reserves throughput you pay for whether you use it or not. ElastiCache, DocumentDB, Neptune, AWS DMS and AWS SCT all run on capacity that is charged while it exists, so this lab leaves them to the lesson.

This is an independent study companion for the AWS Certified Cloud Practitioner (CLF-C02) exam and is not produced by or endorsed by Amazon Web Services. AWS, Amazon Web Services and AWS Certified Cloud Practitioner are trademarks of Amazon.com, Inc. or its affiliates.

This is an independent study companion for AWS Certified Cloud Practitioner CLF-C02 and is not produced by or endorsed by CompTIA.