Introduction

In DynamoDB, nested values inside map and list attributes are accessed through document paths. When you use the AWS Console to filter items by a nested attribute, the important part is writing the correct attribute path and understanding that a filter expression reduces returned results after the read, not before it.

Understand Nested Attribute Paths

If an item contains a map attribute like this:

1{
2  "userId": "42",
3  "profile": {
4    "address": {
5      "city": "Toronto"
6    }
7  }
8}

the nested path to the city value is:

profile.address.city

That dotted path is what you use in expressions when referencing nested map members. For list elements, use numeric indexes such as orders[0].status.

Using a Filter in the AWS Console

In the console, the exact screen layout can vary, but the logic is the same:

1. open the table and browse or query items
2. choose to add a filter expression
3. reference the nested document path in the expression

A simple example filter is:

profile.address.city = "Toronto"

If the console asks for expression attribute values separately, bind the value there instead of embedding raw literals into more complex expressions.

Key Condition vs Filter Expression

This distinction matters more than the path syntax itself.

• a key condition decides which partition or sort-key range DynamoDB reads
• a filter expression is applied after matching items are read

So if you scan a large table and filter on profile.address.city, DynamoDB may still read many items and then discard most of them. That is why nested filters in the console are convenient for investigation, but not a substitute for access patterns designed around keys and indexes.

Example from the SDK Perspective

Even if you are using the console, it helps to understand the expression model underneath. Here is the same idea in Python with boto3:

1from boto3.dynamodb.conditions import Attr
2
3filter_expr = Attr("profile.address.city").eq("Toronto")
4print(filter_expr)

The important point is not the Python object itself. It is the same document path syntax: profile.address.city.

Reserved Names and Awkward Attributes

If an attribute name conflicts with reserved words or contains awkward characters, DynamoDB expressions can require expression attribute names such as #p.#a.#c. The console may expose this more or less directly depending on the view you are using.

For straightforward nested attribute names, direct dotted paths are usually enough. If the filter keeps failing even though the data looks correct, check whether one of the attribute names needs aliasing.

Practical Limits

Nested filtering is useful for:

• quick console inspection
• debugging document-shaped items
• verifying that data was written as expected

It is less useful as a performance strategy. If a nested attribute is part of a frequent lookup pattern, consider reshaping the data model or adding a secondary index based on a value you can query efficiently.

Common Pitfalls

• Assuming a filter expression reduces read cost the same way a key condition does.
• Writing the wrong document path for nested map or list members.
• Forgetting that list access uses index syntax such as items[0].status.
• Ignoring reserved-word issues when a nested attribute name needs aliasing.
• Designing an access pattern around console filters instead of DynamoDB keys and indexes.

Summary

• Nested attributes in DynamoDB are referenced with document paths such as profile.address.city.
• The AWS Console filter feature uses the same expression ideas as the SDKs.
• Filters are applied after items are read, so they are not a performance substitute for proper keys.
• Map members use dotted paths and list members use index notation.
• If nested filtering becomes common in production logic, revisit the table design instead of relying on scans and filters.