DynamoDB Caching: DAX, TTL and ElastiCache

You can use DynamoDB as a durable cache for computed or external data, or put an in-memory cache in front of DynamoDB to accelerate repeated reads. DAX provides DynamoDB-aware caching for eventually consistent reads; ElastiCache provides a general-purpose cache whose keys and invalidation your application manages. DynamoDB's own TTL feature deletes expired items asynchronously, so a DynamoDB-backed cache must check expiration on read.

Which kind of DynamoDB cache do you need?

Caching is optional. Start with a useful key design and measure application latency before adding another service. A cache is most effective when the same results are requested repeatedly and can safely remain unchanged for a defined period.

Using DynamoDB as a cache store

A DynamoDB cache table can hold a cache key, the computed value and an expiration timestamp. The source of truth might be another database, an external API or an expensive calculation. DynamoDB supplies persistence and managed throughput; it is not an in-memory store with an automatic LRU eviction policy.

Choose keys that include every input that changes the cached result. Tenant, locale, query parameters and data version may all belong in the key. Reusing a key across tenants can leak data even if the cache entry itself is technically valid.

Enable DynamoDB TTL on a Number attribute containing Unix epoch seconds, for example expiresAt. TTL typically removes expired records within a few days. Until deletion, expired items can still be returned and billed for storage and reads. Treat the timestamp as the validity boundary in application code; treat TTL deletion as cleanup.

A cache-aside example with AWS SDK v3

This example assumes an existing ResponseCache table with String partition key cacheKey and TTL enabled on expiresAt. The caller supplies an asynchronous loadFreshValue function. Cache values must fit within DynamoDB's item-size limit, including their keys and metadata.

import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import {
  DynamoDBDocumentClient,
  GetCommand,
  PutCommand,
} from "@aws-sdk/lib-dynamodb"

const db = DynamoDBDocumentClient.from(new DynamoDBClient({}))
const tableName = "ResponseCache"

export async function getCachedValue(cacheKey, loadFreshValue) {
  const { Item } = await db.send(new GetCommand({
    TableName: tableName,
    Key: { cacheKey },
  }))

  const now = Math.floor(Date.now() / 1000)
  if (Item && typeof Item.expiresAt === "number" && Item.expiresAt > now) {
    return Item.payload
  }

  const payload = await loadFreshValue()
  const expiresAt = Math.floor(Date.now() / 1000) + 60
  await db.send(new PutCommand({
    TableName: tableName,
    Item: { cacheKey, payload, expiresAt },
  }))
  return payload
}
import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import {
  DynamoDBDocumentClient,
  GetCommand,
  PutCommand,
} from "@aws-sdk/lib-dynamodb"

const db = DynamoDBDocumentClient.from(new DynamoDBClient({}))
const tableName = "ResponseCache"

export async function getCachedValue(cacheKey, loadFreshValue) {
  const { Item } = await db.send(new GetCommand({
    TableName: tableName,
    Key: { cacheKey },
  }))

  const now = Math.floor(Date.now() / 1000)
  if (Item && typeof Item.expiresAt === "number" && Item.expiresAt > now) {
    return Item.payload
  }

  const payload = await loadFreshValue()
  const expiresAt = Math.floor(Date.now() / 1000) + 60
  await db.send(new PutCommand({
    TableName: tableName,
    Item: { cacheKey, payload, expiresAt },
  }))
  return payload
}

The 60-second lifetime is an application choice. This code allows multiple callers to refresh the same key and uses eventually consistent reads. It is suitable for replaceable results where that behavior is acceptable, not a distributed lock or an authorization decision. For concurrent refresh control, add a conditional lease or request coalescing and define how failures release or expire it.

A session cache also needs explicit validity checks. Logging a user out cannot rely on TTL eventually deleting the session, and cached authorization decisions need a revocation strategy. Use the consistency and conditional-write behavior appropriate to that requirement.

How DAX caches DynamoDB reads

DynamoDB Accelerator sits between the application and DynamoDB. A DAX data client connects to a cluster in a VPC and issues supported DynamoDB operations. On an eventually consistent cache hit, DAX returns the stored result without reading the table. On a miss, it reads DynamoDB, caches the result and returns it.

DAX maintains two separate caches:

• Item cache: results from GetItem and BatchGetItem, indexed by primary key.
• Query cache: result sets from Query and Scan, indexed by request parameters.

A Scan does not populate the item cache. A write through DAX can refresh the corresponding item-cache entry, but it does not invalidate matching query-cache result sets. A direct write to DynamoDB bypasses DAX and can leave existing cached items stale until refresh or eviction. These behaviors are documented in AWS's DAX consistency model.

Strongly consistent reads pass through to DynamoDB and are not cached. DAX therefore does not provide cached strongly consistent reads or turn an eventually consistent index into a strongly consistent one. Decide which application paths can tolerate cached results before routing them through DAX.

When caching helps, and when it does not

Caching fits product descriptions, popular content, repeated lookups and derived responses that many callers read before they change. It can reduce repeated read load on hot items and improve response time when the cache hit rate is high.

It is less useful for one-time reads, continually changing queries or workloads dominated by writes. An analytical scan performed only once still has to read the table and can fill a cache with data that will not be reused. A large cache is not a substitute for an analytical store when the access pattern is fundamentally different.

Measure the latency of hits, misses and refreshes separately. A miss introduces cache work before the database work, and a cold cache after deployment or failover can temporarily increase source load. Provision the source and limit concurrent refreshes so that recovery remains manageable.

Caching strategies

Read-through and cache-aside

With read-through, the cache service fetches a missing value from the source. DAX uses this model for supported eventually consistent reads: the application asks DAX, and DAX handles a miss.

With cache-aside, the application checks the cache, calls the source on a miss and stores the result. The DynamoDB example above uses this model. The cache is not the source of truth merely because it is checked first. Set explicit expiration and decide whether a refresh failure returns an error, retries or serves an older value.

Write-through

Write-through keeps a source update and cache update on the request path. In DAX, an ordinary write reaches DynamoDB first. Only after DynamoDB accepts it does DAX update its item cache and return success. This adds a network hop and does not reduce DynamoDB write charges.

DAX read replicas receive updates asynchronously, so cached reads remain eventually consistent. Query results have their own lifetime even after a successful item write. Applications that write outside DAX must account for the additional stale-cache window.

Write-behind

Write-behind acknowledges a cache write before asynchronously persisting it to the source. It can reduce foreground latency, but creates a durability gap: the acknowledged value can be lost if the cache or delivery path fails before persistence.

DAX is not a write-behind cache. Implementing this pattern elsewhere requires a durable delivery mechanism, retries, ordering and idempotency. A volatile cache alone is a poor place to hold the only copy of an acknowledged business transaction.

Write-around

Write-around writes directly to the source and lets later reads populate the cache. It can avoid polluting the cache during a bulk load, but it does not refresh existing entries. With DAX, direct DynamoDB writes leave the item and query caches unchanged. Use an acceptable cache lifetime and ensure the application tolerates stale results.

TTL, eviction and invalidation are different

DAX's default cache TTL is five minutes. Item and query TTL settings are separate. Setting the item-cache TTL to zero disables time-based expiration, leaving LRU eviction and write-through as refresh mechanisms. Setting query-cache TTL to zero disables query-result caching. These two zero settings have different effects; see how DAX works.

DAX also caches missing items and empty query results. A new item written directly to DynamoDB may therefore remain invisible through a negative cache entry until it expires. For caches you manage yourself, choose negative-result lifetimes deliberately and use versioned keys or explicit invalidation where needed.

DAX versus ElastiCache, Redis and Valkey

ElastiCache supports Valkey, Redis OSS and Memcached. DAX is specialized for DynamoDB. The choice is primarily about the data and consistency model, not which product is universally faster.

ElastiCache for Valkey and Redis OSS supports encryption and role-based access control. Claims that Redis-compatible caching cannot support TLS or authorization are incorrect. Check the ElastiCache security documentation for your engine and deployment. Self-managed Redis and Valkey have their own operational responsibilities and licensing terms; they are not the same product as a managed ElastiCache deployment.

DynamoDB's advantages as a cache store are managed persistence, IAM integration and avoiding a fixed in-memory cluster for a sparse workload. Its trade-offs include billed reads/writes, the 400 KB item limit and application-managed expiration checks. DAX adds fixed node costs and is useful specifically for repeated DynamoDB reads. ElastiCache gives more control over cache behavior and derived data, at the cost of additional integration code.

Cost and sizing

DAX is billed by node-hour, including idle time. In us-east-1, a dax.t3.small node is $0.04/hour, so three nodes for an illustrative 730-hour month cost $87.60, before remaining DynamoDB requests and other charges. Small burstable nodes are not a universal production sizing recommendation; select capacity from the working set and measured load. Rates are listed on the AWS pricing page, and the DAX pricing calculator compares a cluster with the reads it would save.

For a DynamoDB-backed cache, writes that refresh entries and reads that check them are billable under the selected capacity mode. An expired entry still consumes read capacity when retrieved. The DynamoDB free tier has always-free Standard storage and provisioned-capacity allowances, but no free on-demand request allowance.

Use the item size calculator to estimate capacity for your payloads, then compare total cost: cache infrastructure, residual source traffic, refreshes and operational effort. An on-demand cache hit saves the consumed request charge; a provisioned cache hit only reduces the bill if you can reduce the allocation or avoid an increase.

Operational checks before adding a cache

Define the acceptable age of every cached response, including missing results. Measure the working set and repeated-read rate. Test concurrent writes, direct writes that bypass the cache, cache failure and the initial cold-cache period.

Avoid synchronized expiry by spreading refresh times where the application controls them. Coalesce concurrent requests for the same missing key, bound retries and choose whether fallback to DynamoDB is allowed during a cache outage. Unrestricted fallback can move the entire peak load back to the source at once.

Monitor hit/miss rates, source read consumption, latency and errors together. A high hit rate is useful only when it serves the right data within the application's freshness requirement.