Domain 1 of 4 · Chapter 3 of 3

Application Data Stores

Unlock the complete study guide + 1,040 practice questions across 16 full exams.

Bundled into the existing AWS Certified Developer - Associate premium course — no separate purchase.

Included in this chapter:

  • Pick the store from the access pattern
  • DynamoDB data model: keys, item size, indexes
  • Capacity, consistency, transactions, and conditional writes
  • Reading at scale: Query vs Scan, batch, pagination, TTL, Streams
  • Caching hot reads: DAX vs ElastiCache

Matching the AWS data store to the access pattern

StoreData modelBest access patternConsistency / latency note
Amazon DynamoDBKey/value + document (NoSQL)Single-key lookups and writes at massive scaleEventual by default; strongly consistent on request; single-digit ms
Amazon RDS / AuroraRelational (SQL)Joins, ad hoc filters, multi-row transactionsStrongly consistent on primary; replicas can lag (usually < 100 ms on Aurora)
Amazon ElastiCacheIn-memory key/value (Redis or Memcached)Hot reads, sessions, leaderboards in front of a DBCache, not durable; sub-millisecond reads
Amazon DAXIn-memory cache for DynamoDBRead-heavy DynamoDB tables, same APIWrite-through cache; microsecond cached reads (eventual)
Amazon S3Object store by keyLarge objects, files, backups, static assetsStrong read-after-write for new and overwritten objects

Decision tree

What is the dominant access pattern? Joins / ad hoc filters across many columns? Fetch one item by a known key at scale? Same hot reads far more than writes? Amazon RDS / Aurora (relational SQL) DynamoDB (single-digit-ms key/value) Amazon S3 for large objects; Amazon OpenSearch for full-text Is the backend DynamoDB? DAX in front of DynamoDB ElastiCache in front relational key lookups read-heavy yes yes no yes yes no

Cheat sheet

  • Pick the data store from the access pattern, not the data shape
  • Keep large objects in S3 and store only the key in the database
  • A cache is never the source of truth
  • DynamoDB primary key is partition-only or partition + sort
  • Pick a high-cardinality partition key to avoid hot partitions
  • GSI: different key, addable any time, eventual reads only
  • LSI: same partition key, create-time only, strong reads allowed
  • On-demand absorbs spiky traffic; provisioned is cheaper for steady load
  • Read costs 1 RCU strong / 2 eventual per 4 KB; write 1 WCU per 1 KB
  • DynamoDB reads are eventually consistent by default; ask for strong only when needed
  • DynamoDB transactions are ACID but cost 2x the capacity
  • Use a conditional write with a version attribute for optimistic locking
  • Query targets one partition key; Scan reads the whole table
  • Every Query/Scan is capped at 1 MB and paginates via LastEvaluatedKey
  • Batch APIs cut round trips but are not atomic
  • TTL auto-deletes expired items for free, but on a best-effort delay
  • DynamoDB Streams give an ordered 24-hour change log for event-driven code
  • DAX is a zero-code, write-through cache for DynamoDB only
  • DAX only helps read-heavy DynamoDB workloads, and strong reads bypass it
  • Lazy loading caches on miss; write-through caches on write
  • Redis for replication and data structures; Memcached for simple key/value
  • Choose RDS/Aurora over DynamoDB when you need joins or multi-column filters
  • An AbortIncompleteMultipartUpload lifecycle rule cleans up failed multipart upload parts
  • CompleteMultipartUpload requires the upload ID plus every part's number and ETag
  • Every multipart part except the last must be at least 5 MB
  • A presigned URL dies when its signing credentials expire, regardless of ExpiresIn
  • Control versioned-bucket storage with NoncurrentVersionExpiration and NewerNoncurrentVersions
  • Lifecycle transitions tier objects down for cost; transition to Standard-IA needs a 30-day minimum
  • Deleting in a versioned bucket adds a delete marker; clean expired markers with ExpiredObjectDeleteMarker
  • Enable S3 Bucket Keys to slash SSE-KMS request costs at scale
  • RDS point-in-time recovery restores to a NEW instance within the backup retention window
  • Pick io2 Block Express for max IOPS/durability; gp3 to provision IOPS independently of size
  • Memory-intensive RDS workloads need a memory-optimized instance class
  • A Multi-AZ DB instance takes backups from the standby, avoiding primary I/O suspension
  • RDS storage autoscaling has a 6-hour cooldown and a minimum max-threshold
  • ACUUtilization near 100% means an Aurora Serverless v2 cluster is capped at its max ACUs
  • Set Aurora Serverless v2 minimum capacity to 0 ACUs to auto-pause when idle
  • Use RDS Proxy to stop Lambda concurrency from exhausting database connections

Unlock with Premium — includes all practice exams and the complete study guide.

Also tested in

References

  1. In-memory acceleration with DynamoDB Accelerator (DAX)
  2. Choosing a self-designed cache (ElastiCache for Valkey, Redis OSS, or Memcached)
  3. Quotas in Amazon DynamoDB
  4. Local secondary indexes
  5. DynamoDB provisioned capacity mode
  6. Amazon DynamoDB Transactions: How it works