DynamoDB Accelerator (DAX): Caching, Networking, and Exam Decisions – SAP-C02 Study Guide

Purpose of This Lesson

DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache designed specifically for Amazon DynamoDB. It is used to reduce read latency from milliseconds to microseconds and can also support write-through caching.

For SAP-C02 questions, recognize DAX when an application already uses DynamoDB and requires extremely low-latency access without significant application-code changes.

Key Concepts

What DAX Provides

DAX is a clustered caching layer deployed inside a VPC. Applications connect to the DAX cluster, which checks the cache before accessing DynamoDB.

DAX can provide:

• Microsecond read latency for cached DynamoDB items.
• Read-through caching, where a cache miss causes DAX to retrieve the item from DynamoDB and populate the cache.
• Write-through caching, where writes are sent through DAX and the cache is updated as part of the write operation.
• High availability through a multi-node cluster design.
• DynamoDB API compatibility, reducing or eliminating application changes when replacing a DynamoDB client with a DAX client.
• A managed caching service optimized for DynamoDB data access patterns.

DAX is not a replacement for DynamoDB. DynamoDB remains the durable data store, while DAX is an acceleration layer for frequently accessed data.

Request Flow

A typical architecture looks like this:

1. An application running in a VPC sends a request to the DAX cluster.
2. DAX checks whether the requested item is cached.
3. On a cache hit, DAX returns the result without querying DynamoDB.
4. On a cache miss, DAX retrieves the item from DynamoDB and can cache the result.
5. Writes can pass through DAX and update the cache and DynamoDB according to the configured access pattern.

DAX nodes are deployed in a VPC, while DynamoDB is an AWS-managed regional service accessed through its service endpoint. Network access must therefore be designed for both the application-to-DAX path and the DAX-to-DynamoDB path.

Application Compatibility

DAX is intended to work with existing DynamoDB operations through a DAX-compatible client. The application generally does not need to implement its own cache lookup, cache population, or invalidation logic.

This is a major distinction from using ElastiCache directly. With ElastiCache, the application commonly needs to:

• Determine whether an item exists in the cache.
• Retrieve data from the cache.
• Query the database on a cache miss.
• Populate or invalidate cache entries.
• Handle consistency and serialization behavior.

Security and Permissions

A DAX deployment requires both network controls and IAM permissions.

#### Network Controls

Use security groups to restrict which application resources can connect to the DAX cluster. DAX client connections commonly use TCP port 8111; allow this port only from the application security group or other narrowly defined source.

DAX must also be able to reach DynamoDB. The DynamoDB service endpoint is normally accessed over HTTPS, TCP port 443, using a NAT gateway, an appropriate VPC endpoint, or another supported private connectivity design. Do not confuse the DAX client port with the DynamoDB service endpoint port.

#### IAM Roles

DAX requires an IAM role that permits it to access the relevant DynamoDB resources. Follow least privilege by restricting permissions to the required table or tables and required actions.

The application also requires permissions for its intended operations. Depending on the design, those permissions may include:

• Direct DynamoDB actions.
• DAX-related access through the application’s DAX client.
• Read and write permissions limited to specific tables and indexes.

Use resource-level restrictions and condition keys where supported rather than granting broad access to all DynamoDB resources.

Architecture Decision Guide

Requirement	Recommended choice	Reason
Existing application uses DynamoDB and needs microsecond read latency	DAX	Purpose-built, managed DynamoDB cache
Need caching with minimal application changes	DAX	Uses a DynamoDB-compatible client model and manages cache behavior
Need a cache shared across several different database technologies	ElastiCache	Supports broader application and data-store patterns
Application needs custom cache keys, data structures, or workflows	ElastiCache	Provides more direct control over cache behavior
Need durable authoritative storage	DynamoDB	DAX is a cache, not the system of record
Need to reduce repeated reads of hot DynamoDB items	DAX	In-memory caching reduces database reads and latency
Need a general-purpose Redis or Memcached cache	ElastiCache	Supports Redis and Memcached use cases beyond DynamoDB

DAX Versus ElastiCache

Both services provide in-memory caching, but they solve different architectural problems.

Choose DAX when:

• DynamoDB is the primary data store.
• The workload has frequently accessed or hot items.
• Microsecond response times are important.
• The team wants managed read-through and write-through behavior.
• Avoiding custom cache-management logic is valuable.

Choose ElastiCache when:

• The cache must support data from multiple types of backends.
• The application needs custom caching logic or data structures.
• Redis or Memcached capabilities are required.
• The application team is willing to manage cache lookup, population, expiration, and invalidation behavior.

DAX is not automatically the best choice for every DynamoDB workload. If the workload has low cache reuse, highly unique keys, or strict read-after-write requirements that do not align with the cache behavior, the cache may provide limited benefit or require careful consistency design.

Exam-Relevant Takeaways

• DAX is optimized specifically for DynamoDB.
• The strongest exam clue is a requirement to reduce DynamoDB latency from milliseconds to microseconds.
• DAX supports both read-through and write-through caching patterns.
• DAX is deployed in a VPC and applications connect to the DAX cluster rather than treating it as a generic internet-facing endpoint.
• DAX can reduce application complexity compared with implementing an ElastiCache-based caching layer manually.
• DynamoDB remains the durable source of truth; DAX is an acceleration layer.
• Restrict DAX network access to application resources using security groups.
• DAX client connections commonly use TCP port 8111; DynamoDB service access generally uses HTTPS on port 443.
• DAX needs an IAM role with permission to access the required DynamoDB resources.
• ElastiCache is more flexible across data stores but usually requires more application-level cache management.

Common Exam Traps

• Choosing ElastiCache just because it is a caching service: If the requirement is specifically high-performance caching for DynamoDB with minimal code changes, DAX is usually the better fit.
• Treating DAX as the database: DAX does not replace DynamoDB’s durable storage, scaling model, or availability characteristics.
• Assuming every DynamoDB request becomes faster: DAX improves cache hits. Cache misses still require a DynamoDB lookup, and workloads with little key reuse may gain limited benefit.
• Ignoring consistency requirements: Cached data can introduce staleness considerations. Examine whether the application requires strongly consistent reads or immediate visibility of updates.
• Opening DAX broadly: DAX should be reachable only by the required application resources, not by all VPC clients or the public internet.
• Confusing ports: The DAX client port is commonly 8111. DynamoDB API access generally uses HTTPS on port 443; do not blindly apply a database-server port model to DynamoDB.
• Assuming no client-side consideration is required: DAX is API-compatible in purpose, but the application still needs to use the appropriate DAX client or integration mechanism.
• Using DAX for arbitrary cached objects: DAX is designed around DynamoDB data access, whereas ElastiCache is better suited to general-purpose caching and custom data structures.

Real-World Engineer Notes

• Place DAX nodes in subnets and Availability Zones that provide resilient connectivity from the application tier.
• Use security-group references instead of broad CIDR ranges where possible. For example, allow TCP 8111 from the application security group.
• Ensure DAX has a valid network path to DynamoDB, such as a NAT gateway for private subnets or a suitable DynamoDB VPC endpoint configuration.
• Scope the DAX IAM role to the required DynamoDB tables and actions. Avoid granting unrestricted access to all tables in the account.
• Evaluate cache hit rate, item popularity, item size, and access patterns before deploying DAX. A low-reuse workload may not justify the cost or operational complexity.
• Review data freshness and write behavior carefully. Caching can affect how quickly all readers observe changes, especially when applications mix direct DynamoDB access with DAX access.
• DAX is most valuable for read-heavy workloads with repeated access to a relatively hot set of DynamoDB items.
• Test failure behavior. Applications should be designed so that a DAX disruption does not result in unacceptable data loss; DynamoDB remains the persistence layer.

Quick Reference Summary

• Service: DynamoDB Accelerator (DAX)
• Primary purpose: Managed in-memory caching for DynamoDB
• Latency target: Microseconds for cached access
• Caching modes: Read-through and write-through
• Deployment: Cluster nodes in a VPC
• Data store: DynamoDB remains the source of truth
• Typical DAX client port: TCP 8111
• Typical DynamoDB service endpoint: HTTPS/TCP 443
• Permissions: IAM role for DAX plus application IAM permissions
• Best alternative comparison: ElastiCache is more general-purpose but normally requires more application-managed cache logic

Flashcards

1. What is DAX?

DAX is a fully managed, highly available, in-memory cache optimized for Amazon DynamoDB.

2. What latency improvement is associated with DAX?

DAX can reduce cached DynamoDB access from millisecond-level latency to microsecond-level latency.

3. Is DAX a replacement for DynamoDB?

No. DynamoDB remains the durable source of truth; DAX is a caching and acceleration layer.

4. What caching patterns does DAX support?

DAX supports read-through and write-through caching.

5. Where are DAX nodes deployed?

DAX nodes are deployed inside a VPC.

6. What is a key reason to choose DAX over implementing ElastiCache manually?

DAX is optimized for DynamoDB and reduces the need for custom cache lookup, population, and invalidation logic.

7. What is a common DAX client port?

TCP port 8111 is commonly used for DAX client connections.

8. How does DAX access DynamoDB?

DAX uses IAM permissions and a network path to the DynamoDB service endpoint, typically over HTTPS/TCP 443.

9. When is ElastiCache preferable to DAX?

ElastiCache is preferable when the application needs a general-purpose cache, custom data structures, or support for multiple backend data stores.

10. What workload benefits most from DAX?

A read-heavy DynamoDB workload with repeated access to a hot set of items and a requirement for very low latency.

Practice Questions

Question 1

A gaming application stores player profiles in DynamoDB. During peak periods, millions of requests repeatedly read a small set of popular player profiles. The application must achieve microsecond-level response times, and the team wants to avoid implementing cache lookup and invalidation logic. Which solution best meets the requirements?

A. Amazon ElastiCache for Memcached with custom application logic
B. DynamoDB Accelerator (DAX)
C. Amazon S3 Transfer Acceleration
D. DynamoDB Streams with AWS Lambda

Correct answer: B. DynamoDB Accelerator (DAX)

DAX is purpose-built for DynamoDB, provides in-memory caching for hot items, and supports managed read-through behavior with microsecond-level cached access. ElastiCache could cache the data but would generally require more application-managed logic.

Question 2

A company deploys a DAX cluster in private subnets. The application instances can reach the DAX cluster, but cache misses fail because DAX cannot retrieve items from DynamoDB. Which configuration should the architect investigate first?

A. Whether DAX is assigned a public IPv4 address
B. Whether DAX has an IAM role and a valid network path to DynamoDB
C. Whether DynamoDB tables are configured with a local secondary index
D. Whether the application security group allows inbound traffic on port 22

Correct answer: B. Whether DAX has an IAM role and a valid network path to DynamoDB

DAX needs permissions to access DynamoDB and connectivity to the DynamoDB service endpoint. A private-subnet design commonly requires appropriate VPC endpoint or NAT connectivity. Public IP addresses are not required, and SSH access is unrelated.

Question 3

An architect must choose between DAX and ElastiCache. The workload uses DynamoDB as its data store, requires extremely low-latency access, and the application team wants direct control over custom cache keys and Redis data structures. Which choice is most appropriate?

A. DAX, because it supports all Redis data structures
B. DAX, because it replaces DynamoDB as the durable data store
C. ElastiCache for Redis, because the workload requires custom cache behavior and Redis capabilities
D. Amazon Neptune, because graph databases provide low-latency lookups

Correct answer: C. ElastiCache for Redis

DAX is the simpler DynamoDB-optimized cache, but ElastiCache for Redis is more appropriate when custom cache keys, Redis data structures, or application-controlled caching behavior are explicit requirements.

Question 4

A security review finds that the DAX cluster security group allows inbound TCP 8111 from the entire VPC CIDR. The application runs in a dedicated application security group. What is the best improvement?

A. Allow TCP 8111 from the application security group only
B. Allow TCP 8111 from the public internet
C. Disable IAM permissions on the DAX cluster
D. Replace DAX with DynamoDB Streams

Correct answer: A. Allow TCP 8111 from the application security group only

Security-group references provide a narrower and more maintainable rule than allowing every resource in the VPC. The DAX client port should be reachable only by authorized application resources.

Question 5

A workload generates nearly unique DynamoDB read keys, so most requests are cache misses. The architect proposes DAX solely to reduce DynamoDB costs. Which assessment is most accurate?

A. DAX will always reduce costs because all DynamoDB requests are free after deployment
B. DAX may provide limited benefit because low cache reuse produces few cache hits
C. DAX converts DynamoDB eventually consistent reads into strongly consistent reads
D. DAX permanently stores all DynamoDB items in memory

Correct answer: B. DAX may provide limited benefit because low cache reuse produces few cache hits

DAX is most effective when requests repeatedly access a hot set of items. A workload dominated by unique keys receives little caching benefit while still incurring the cost of operating the DAX cluster.