DynamoDB Scan with the AWS CLI

aws dynamodb scan reads every item in a table or index, then optionally drops rows with --filter-expression. The filter shrinks the output, not the cost — you pay for every item scanned.

Code

aws dynamodb scan \
  --table-name Music \
  --filter-expression "#yr >= :year" \
  --expression-attribute-names '{"#yr": "Year"}' \
  --expression-attribute-values '{":year": {"N": "2010"}}' \
  --region us-east-1

By default the CLI auto-paginates — it follows LastEvaluatedKey for you and prints the combined result. For big tables, page manually with --page-size / --max-items and resume with the emitted NextToken:

aws dynamodb scan \
  --table-name Music \
  --page-size 500 \
  --max-items 100 \
  --starting-token "$NEXT_TOKEN" \
  --region us-east-1

Explanation

• --filter-expression — evaluated after the read. Year is a reserved word, so it's aliased through --expression-attribute-names.
• --expression-attribute-values — the :placeholder → typed-value map in DynamoDB JSON.
• --page-size — items DynamoDB reads per underlying request (a throttling knob), not the number returned.
• --max-items — caps items the CLI returns and emits a NextToken; resume with --starting-token.
• Parallel scan — split a big table across workers by giving each a --segment N --total-segments M.
• Prefer query. scan reads the whole table; on anything but a tiny table it's slow and expensive.

Do it visually

The DynamoDB Expression Builder generates the filter + name/value JSON and hands you a copy-paste CLI command.

To explore tables in a GUI — filtered, paginated grids and copy-as-CLI — download DynoTable, instead of scanning blind from the terminal.

Related guides

• Query vs. Scan — when (rarely) a scan is justified.
• Why is my DynamoDB Scan slow and expensive? — the cost model and how to avoid it.