Skip to content
R&D

DynamoDB Deep Dive — Study Notes

Notes from the Deep Dive on Amazon DynamoDB webinar, cross-referenced with the 11447-question CCP bank.

Composite keys (HASH + RANGE)

Section titled “Composite keys (HASH + RANGE)”
  • Partition key (HASH): hashed (MD5) → hash mod N → picks physical partition. Items with same PK live on same partition. High-cardinality values spread evenly; low-cardinality → hot partitions.
  • Sort key (RANGE): orders items within a partition (B-tree). Enables range queries (<, <=, >, BETWEEN, begins_with).
  • AttributeDefinitions = type registry ONLY for keys/indexes (S/N/B). Non-key attributes are schemaless — any item can have any fields.
  • “HASH”/“RANGE” are legacy terms (mechanism); docs use partition/sort (purpose). Both mean the same thing; kept for backwards compat.
  • Example: (username HASH, last_name RANGE) — all of a user’s items in one partition, sorted by last_name.
  • Scalability comes from hash+mod: add partitions → automatic redistribution, linear throughput scaling.

Query vs Scan

Section titled “Query vs Scan”
  • Query: requires partition key. Direct lookup, O(log n), cheap. Can filter by sort key.
  • Scan: reads every item. O(table size), expensive. FilterExpression doesn’t reduce RCU (pay for all scanned).
  • Rule: always Query. Add GSI for non-key query patterns. Scan only for exports/audits/backfills.

Secondary indexes

Section titled “Secondary indexes”
  • GSI (Global): different partition key from base. Own partitions, separate storage. Up to 20, addable anytime. 2× write cost (base + GSI write).
  • LSI (Local): same partition key as base, different sort key. Shares base partition. Up to 5, must be defined at creation. Cheaper writes.
  • GSIs are COPIES of projected attributes, not foreign keys / references. No referential integrity in DynamoDB — denormalize.
  • Projection types: KEYS_ONLY / INCLUDE / ALL (ALL = full copy, most storage cost).

Table classes + billing modes

Section titled “Table classes + billing modes”
Class Storage cost Read cost Use for
Standard $0.25/GB-mo $0.25/M reads Hot data, default
Standard-IA $0.10/GB-mo $0.38/M reads Archives, ≤1 read/day
Glacier IR (2023) ~$0.03/GB-mo $0.10/M reads 7yr audits, ms reads
Glacier FR (2024) cheapest most True cold storage, seconds-hours latency
  • Provisioned: set RCU/WCU, auto-scale within min/max, cheaper per unit. “Pay for what you provision.”
  • On-Demand: pay per request, no capacity planning, ~1.5-1.8× provisioned price (was 2.5× pre-2024).
  • Independent choices: class (storage trade-off) + mode (throughput trade-off).
  • Can switch modes once per day, free.

Consistency

Section titled “Consistency”
  • Default eventual: write → leader → async replicate to 2 other AZs. Reads hit any replica. Fast, <1s convergence.
  • Strong: ConsistentRead=True → reads hit leader. 2× RCU cost.
  • NOT a race condition — deliberate CAP trade-off (availability + low latency over strict freshness).
  • Durability: 3 AZ replication. Availability during partition > consistency (DynamoDB’s choice).

DynamoDB Streams

Section titled “DynamoDB Streams”
  • Chronological log of table changes (24h retention). Enabled via StreamSpecification, StreamViewType: KEYS_ONLY / NEW_IMAGE / OLD_IMAGE / NEW_AND_OLD_IMAGES.
  • Lambda event source mapping polls automatically (pull, not push). Batches, retries, per-partition ordering.
  • Classic pattern: new item → stream → Lambda → SES welcome email.
  • Decoupled + reliable: table write succeeds even if consumer down; records replayable.
  • Kinesis Data Streams (different service): longer retention (up to 365d), shards, multiple independent consumers. Not pub/sub — pull-based managed log.
  • EventBridge Pipes (2022+): pull from stream internally + built-in filter/enrich + push to target. Hybrid.

Video source

Section titled “Video source”

/home/fep/PARA/Projects/AWS/Meeting+Recording+-+Webinar+-+Deep+Dive+on+Amazon+DynamoDB.mp4 (archie, 12GB AWS collection). Filename uses + instead of spaces.

DAX (DynamoDB Accelerator)

Section titled “DAX (DynamoDB Accelerator)”
  • In-memory cache between app and DynamoDB. Microsecond reads vs ~5ms direct.
  • VPC-only. Runs as a cluster of cache nodes (3 nodes typical).
  • Drop-in: DaxClient SDK uses same DynamoDB API. Cache invalidation automatic on writes.
  • Eventually consistent (matches DynamoDB default).
  • DAX ≠ ElastiCache: DAX is DynamoDB-aware (auto-invalidate), ElastiCache is generic (manual).
  • Use when: read-heavy, microsecond latency needed, can pay for cluster overhead.
  • Skip when: low QPS, write-heavy, cost-sensitive.

IAM access control

Section titled “IAM access control”
  • Action-level: dynamodb:Get* (read), Put*/Update*/Delete* (write), Describe* (admin).
  • Resource-level: per-table ARN, per-index, per-item (dynamodb:LeadingKeys).
  • Condition keys: dynamodb:LeadingKeys (per-PK row access), dynamodb:Attributes (per-column), dynamodb:ReturnValues.
  • Item-level policy example: restrict user alice to table/Orders items where PK = alice (multi-tenant pattern).
  • IAM does NOT validate write content, schema, or app-level authz.

PITR (Point-In-Time Recovery)

Section titled “PITR (Point-In-Time Recovery)”
  • Continuous backup, 35-day retention. Restore to any second in window.
  • Opt-in per table. ~10-20% extra storage cost. Worth it for production.
  • Use cases: app bug wipes rows, wrong UPDATE, accidental DROP TABLE, ransomware, audit/regulatory.
  • Creates NEW table on restore (original intact). Free restore operation (pay new table storage).
  • Always enable on production tables. Skip on dev/test.
Section titled “Related”
  • [[aws/index]]