AWS DynamoDB Tutorial via the Console: A Complete Beginner Walkthrough

You log into the AWS console for the first time, click DynamoDB, and stare at a blank screen. Where do you even start? A table needs a name, a key, maybe a sort key, and then you are looking at five tabs you have never opened. If you want the shortest path from zero to a working DynamoDB table, this walkthrough is it.

This tutorial follows a real console session: creating a users table, inserting two records with wildly different attributes, and poking through every tab in the DynamoDB interface so nothing catches you off guard when you are building your own project.

What You’ll Walk Out With

A working DynamoDB table created entirely through the AWS Management Console
Clear understanding of partition keys and sort keys and why the difference matters
Hands-on experience inserting items with different attribute shapes, no fixed schema required
A mental map of every tab: Overview, Items, Metrics, Alarms, Capacity, Indexes, Backups, Triggers, Access Control, Tags
A working grasp of read and write capacity units and how they connect to your monthly AWS bill
Confidence setting up a Lambda trigger so new table entries fire an automated action
The vocabulary to search for the next level, provisioned vs. on-demand, GSIs, streams, and more
Not sure which AWS service fits your project? Answer five questions at finder.platformproof.com and get a recommendation built for your situation.

What DynamoDB Actually Is (Before You Touch a Single Button)

DynamoDB is Amazon’s managed NoSQL database. Non-relational means you do not write a rigid schema before you start storing data. In a traditional relational database, think MySQL or PostgreSQL, every row in a table must have exactly the columns that table was designed with. If you decide later that some users need a parents_permission field and others do not, you face an awkward ALTER TABLE migration or a pile of NULL columns.

DynamoDB sidesteps that entirely. Each item (the DynamoDB word for a row) can carry whatever attributes it wants, as long as it includes the required key fields. Two items in the same table can look completely different from each other. That flexibility is the core selling point, and the tutorial makes it concrete by inserting one adult user and one minor with a completely different set of fields.

Because Amazon manages the infrastructure, you do not provision servers, configure replication, or worry about disk space. You create a table, set a capacity target, and DynamoDB handles the rest. That is the trade-off: you get simplicity and scale, but you give up the full SQL query surface that relational databases provide.

Step 1: Choose Your Region

The tutorial opens in the AWS Management Console in the North Virginia region, then switches to Canada (Central) before creating anything. This is worth noting because DynamoDB is a regional service. The table you create in Canada is not automatically available in Virginia. Pick the region closest to your users before you build anything, because moving a populated table later is not a one-click operation.

For most North American hobbyist projects, us-east-1 (North Virginia) or us-west-2 (Oregon) are fine. If you are building something for Canadian users or have data residency requirements, Canada Central is the right choice and that is exactly what this tutorial uses.

Step 2: Create the Table, Name, Partition Key, Sort Key

Click DynamoDB in the AWS console, hit Create table, and you reach the only required decisions you have to make before your table exists.

Table name: The tutorial uses users. This is a natural fit for any application that tracks accounts, a blog platform, a forum, a simple web app.

Primary partition key: The tutorial sets this to ID with a data type of Number. Every item you put in the table must include this key, and it must be unique. DynamoDB uses the partition key to distribute data across its internal storage nodes, which is why it is also called the hash key. If two items share the same partition key and there is no sort key, the second write overwrites the first.

Sort key: The tutorial adds email as a String sort key. The sort key is optional but powerful. When you add a sort key, items can share a partition key as long as their sort keys differ, which lets you model one-to-many relationships directly in DynamoDB without a join. In this users table, the combination of ID and email must be unique for each item.

With those two fields filled in, click Create and DynamoDB provisions the table in seconds. The rest of the settings are defaults you can revisit after the table exists.

Step 3: The Overview Tab, Understand Before You Build

Once the table is created, the console lands you on the Overview tab. It shows everything that was configured at creation time, and several things that were left at their defaults.

Table name and keys: You can see the primary partition key (ID) and sort key (email) at a glance. These cannot be changed after the table is created, if you need a different key structure later, you have to create a new table and migrate your data.

Point-in-time recovery (PITR): Not enabled by default. PITR lets you restore the table to any second within a 35-day window, useful insurance for production data. For a tutorial table it is not necessary, but in a real app you want this on.

Encryption: The tutorial table is not encrypted at rest. AWS encrypts DynamoDB tables by default using an AWS-owned key since 2018, so this setting mostly matters if you need a customer-managed KMS key for compliance reasons.

Time to Live (TTL): Not enabled. TTL lets DynamoDB automatically delete items after a timestamp you specify, handy for session data, caches, or anything with a natural expiry.

Read and write capacity: The tutorial uses the default provisioned capacity. This is the billing knob, more on that in the Capacity tab section below.

Step 4: Insert Your First Item

Click the Items tab, then Create item. The form pre-populates fields for the partition key and sort key because DynamoDB requires those. Everything else is optional and you add it by clicking Append.

The tutorial creates a user with:

ID: 1 (Number)
email: johnsmith@gmail.com (String)
first_name: John (String, appended)
last_name: Smith (String, appended)
posts: some value (String, appended, tracking posts made)
over_18: true (Boolean, added via Edit after initial save)

Click Save and the item appears in the table view. Then the tutorial opens that item again via Actions > Edit to add the Boolean field. That edit-after-the-fact workflow is the NoSQL flexibility on display: you did not need to declare over_18 before creating the table. You just append it to this one item and save.

Step 5: Insert a Second Item With a Completely Different Shape

The tutorial adds a second user, Jane Smith at janesmithgmail.com, and the item looks very different from John’s record.

over_18: false (Boolean)
parents_permission: yes (String)
parents_name: Frank (String), a field that does not exist anywhere on John’s record

When you view both items in the table, there are gaps, columns where one user has a value and the other has nothing. DynamoDB does not fill those gaps with NULL or throw an error. It simply stores what is there. The tutorial calls this out as one of the core advantages over relational databases: you do not need to know your full schema ahead of time. As your application changes, you add attributes to new items without touching old ones.

This is also where the trade-off shows up. If you need to query all users where parents_name equals “Frank,” you need an index, you cannot just write WHERE parents_name = 'Frank' the way you would in SQL. DynamoDB’s query model is built around keys and indexes, not arbitrary column filtering.

Not sure which database or AWS service fits your project?

Answer five quick questions and get a personalized recommendation at finder.platformproof.com.

Step 6: Metrics Tab, Reading and Writing Activity

The Metrics tab shows graphs of your table’s read and write activity over time. For a brand-new table with two items and no application traffic, the graphs are flat. In production, this is where you spot read spikes, write bottlenecks, and capacity limit errors.

The metrics are powered by Amazon CloudWatch behind the scenes. You do not need to configure anything to get them, they start the moment your table exists.

Step 7: Alarms Tab, Get Notified on New Entries

The Alarms tab lets you set up CloudWatch alarms tied to DynamoDB metrics. The tutorial highlights a practical use case: send an email every time a new item is added to the table. For a forum or blog platform, that is a “welcome to the community” trigger.

The alarm watches a metric, in this case, successful write operations, and fires an SNS notification when the threshold is crossed. You configure the SNS topic with an email subscription and new users get a welcome message without any application code running.

Alarms are also useful for operations: alert when your table is approaching its provisioned write capacity so you can scale up before requests start getting throttled.

Step 8: Capacity Tab, The Billing Dial

Read and write capacity units (RCUs and WCUs) are how DynamoDB meters throughput and how AWS bills you. One RCU lets you do one strongly-consistent read per second for an item up to 4 KB. One WCU lets you do one write per second for an item up to 1 KB.

The Capacity tab shows a cost estimator. You dial in your expected reads and writes per second and it tells you the projected monthly cost before you commit. This is the right place to check before you scale up a table for a product launch.

The tutorial mentions auto scaling, you can set a minimum and maximum capacity and let DynamoDB adjust within that range based on actual traffic. This prevents you from over-provisioning for steady-state traffic while still handling spikes. For a new project where traffic is unpredictable, the on-demand billing mode (not covered in this 2018 tutorial but available now) is often the safer default: you pay per request with no capacity planning required.

Step 9: Indexes Tab, Query Beyond Your Keys

The Indexes tab is where you create Global Secondary Indexes (GSIs) and Local Secondary Indexes (LSIs). These let you query the table on attributes other than the primary key.

In the users table, you can query by ID out of the box. But if you want to find all users by last_name without scanning the entire table, you need a GSI with last_name as the partition key. The GSI is essentially a copy of the table reorganized around different keys, it has its own read and write capacity and adds to your bill, but it makes your queries fast.

LSIs must be created at table creation time and share the partition key with the main table. GSIs can be added after the fact and use any attribute as their key. For most projects, GSIs are the tool you reach for when you need a new query pattern.

Step 10: Backups Tab, Protect Your Data

The Backups tab lets you create on-demand backups of the entire table. A backup captures the full contents and can be restored into a new table, it does not restore in-place, which means a recovery operation does not overwrite live data. That is a useful property when debugging a bad batch write that corrupted your items.

On-demand backups are stored until you delete them and are billed by storage size. For a small table like this tutorial’s users table, the cost is negligible. For a table with millions of items, factor backup storage into your cost model.

Step 11: Triggers Tab, Connect DynamoDB to Lambda

The Triggers tab is where DynamoDB Streams and Lambda functions meet. When you enable a stream on the table, DynamoDB records every change, inserts, updates, deletes, in an ordered log. You attach a Lambda function to that stream and it fires automatically for each change.

The tutorial’s example is sending a welcome email when Jane joins the forum. The Lambda function reads the new-item event from the stream, extracts the email address, and sends a message via SES or SNS. No polling, no scheduled jobs, the email goes out within seconds of the item being written.

This pattern extends to any downstream action: updating a search index, invalidating a cache, logging to a data warehouse via Kinesis Firehose, or triggering a workflow in Step Functions. DynamoDB Streams is one of the cleanest event sources in the AWS platform.

Step 12: Access Control and Tags

The Access Control tab links to IAM policy management for the table. You can grant specific IAM roles read-only or read-write access, or scope permissions to specific items using condition keys. For a multi-tenant application where users should only read their own data, fine-grained access control at the IAM level is the right tool.

Tags are key-value labels you attach to the table. They do not affect behavior, they affect billing visibility. When you have multiple DynamoDB tables across multiple projects, tags let you filter your AWS Cost Explorer report by project, team, or environment. The tutorial notes this as a useful tool for understanding which table is driving the most cost at the end of the month.

Managing Items: Delete, Export, and TTL

Back on the Items tab, you can select one or all items and delete them or export to CSV. The CSV export drops the data into a spreadsheet-readable format, useful for quick audits or handing data off to a non-developer.

The Manage Time to Live option on the Items tab lets you designate an attribute as the TTL field. Any item with a Unix timestamp in that attribute will be automatically deleted by DynamoDB when the timestamp passes. There is no extra charge for TTL deletes, and the deletion happens in the background within 48 hours of the timestamp, so do not rely on TTL for hard real-time expiry.

The Complete Console Walkthrough in Order

Here is the exact sequence the tutorial follows, distilled into a repeatable checklist:

1. Choose your region in the top-right dropdown before creating anything.
2. Click DynamoDB in the AWS services menu.
3. Click Create table. Enter a table name, set the partition key (name + type), and optionally set a sort key.
4. Accept defaults for capacity, encryption, and streams on first creation. You can change everything later except the key schema.
5. Click Create and wait a few seconds for provisioning to complete.
6. Go to the Items tab and click Create item. Fill in the required key fields, then append any additional attributes.
7. Click Save. Your first item is in the table.
8. Create more items with different attribute shapes to see the schema-free model in action.
9. Check the Metrics tab to verify reads and writes are registering.
10. Review the Capacity tab and adjust read/write units based on your expected traffic.
11. Set up a Trigger if you need Lambda to react to new items.
12. Add Tags so you can track this table’s cost in AWS Cost Explorer.

Honest Drawbacks of DynamoDB

Query limitations. You can only query on your primary key or an index. If you need to filter by an arbitrary attribute, you are doing a full table scan, expensive at scale and slow on large datasets. Relational databases handle ad-hoc queries much better.

No joins. DynamoDB does not support joins. If your data model requires pulling related records from multiple tables in a single query, you are doing that in application code with multiple round-trips.

Capacity planning complexity. Provisioned mode requires you to forecast traffic. Underestimate and your requests get throttled; overestimate and you pay for unused capacity. On-demand mode removes this friction but costs more per request at high volume.

Eventual consistency. By default, DynamoDB reads are eventually consistent, a read immediately after a write might return stale data. You can request strongly consistent reads, but they cost twice as many RCUs.

Key design is permanent. Get your partition and sort key wrong and you are migrating to a new table. Unlike relational databases where you can add or rename columns freely, DynamoDB’s key schema is locked at creation. Think carefully about your access patterns before you build.

Find Your X

DynamoDB is the right tool for high-scale key-value and document workloads where you know your access patterns in advance. It is not the right tool for complex reporting, ad-hoc analytics, or data models that require joins. Knowing which database matches your project before you build saves weeks of rework later.

If you are not sure whether DynamoDB, RDS, Aurora, or a different AWS service fits what you are building, answer five questions at finder.platformproof.com and get a clear recommendation for your specific situation.

Frequently Asked Questions

What is the difference between a partition key and a sort key in DynamoDB?

The partition key (also called a hash key) uniquely identifies an item or a group of items. DynamoDB uses it to distribute data across storage nodes. The sort key (also called a range key) is optional and works alongside the partition key, multiple items can share a partition key as long as their sort keys are unique. Together they form the primary key for the table.

Can I change my DynamoDB table’s primary key after creation?

No. The partition key and sort key are locked at table creation and cannot be changed. If you need a different key structure, you must create a new table, migrate your data into it, and delete the old one. This is the most important decision to get right before building.

What data types does DynamoDB support?

DynamoDB supports three scalar types: String, Number, and Binary. It also supports Set types (String Set, Number Set, Binary Set), and document types: List (ordered collection of any types) and Map (key-value pairs, similar to JSON objects). Boolean and Null are also supported as scalar types.

How does DynamoDB billing work?

DynamoDB bills for read and write capacity, storage, and optional features like backups and global tables. In provisioned mode, you pay per read and write capacity unit per month, whether you use them or not. In on-demand mode, you pay per request with no minimum. Storage is billed per GB per month. The AWS Free Tier includes 25 GB of storage and 25 read/write capacity units per month indefinitely.

When should I use DynamoDB instead of a relational database?

DynamoDB works well when you have a clear, stable access pattern (always look up by user ID, always query by session token), need low-latency reads at scale, and want a fully managed service with no servers to patch. Relational databases are better when you need flexible ad-hoc queries, complex joins, or ACID transactions across many tables.

What is a Global Secondary Index (GSI) in DynamoDB?

A GSI is an additional index you create on a DynamoDB table to support queries on attributes other than the primary key. It has its own partition key and optional sort key, and DynamoDB maintains it automatically as items change. GSIs have their own provisioned or on-demand capacity and add to your bill. You can create up to 20 GSIs per table.

How do DynamoDB Streams and Lambda triggers work together?

DynamoDB Streams records every data modification in the table as an ordered log of events. You attach a Lambda function to the stream and it fires automatically for each event, an insert, update, or delete. The Lambda function receives the before and after state of each changed item and can react to it: sending an email, updating a cache, writing to a data warehouse, or triggering a workflow.

Is DynamoDB good for a beginner’s first AWS project?

DynamoDB is a reasonable starting point for developers who want a managed, serverless database without configuring a server. The console UI makes it easy to create tables and insert items by hand. The main beginner pitfall is designing the key schema before understanding your access patterns, spend time thinking about how your application will query the data before you create the table.

Sources

AWS DynamoDB Tutorial via the Console (2018), Alston Godbolt, YouTube: https://youtu.be/2J8IT5jNS28
Amazon DynamoDB Developer Guide, AWS Documentation
DynamoDB Read/Write Capacity Pricing, AWS Pricing Page
DynamoDB Streams and Lambda Triggers, AWS Documentation