AWS 133: DynamoDB Streams, DAX and Global Tables
Why this lesson matters
Separate change capture, in-memory read acceleration, and multi-Region replication because they solve different problems.
Streams, DAX, and Global Tables solve three separate problems: change capture, read caching, and multi-Region data. Combining their names without understanding ordering, cache consistency, conflicts, capacity, retries, and recovery produces incorrect systems.
What you will be able to do
By the end, you can:
- explain dynamodb streams, dax and global tables in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Separate change capture, in-memory read acceleration, and multi-Region replication because they solve different problems. |
| Scope and boundary | Streams record item-level changes for a limited period. DAX is a DynamoDB-compatible cache for microsecond reads. Global Tables replicate table data across chosen Regions with version-specific behavior. |
| Evidence of success | Evidence proves stream view type and consumers, cache hit behavior and invalidation expectations, replica Regions, conflict behavior, lag, and failover runbook. |
| Cost model | Stream reads, Lambda, DAX nodes, replica writes, storage, cross-Region transfer, backups, and monitoring can charge. |
| Safe rejection rule | Avoid using DAX for write scaling, treating Streams as an unlimited event archive, or assuming active-active replication eliminates conflict design. |
How the request flows
+----------------------+
| Table write |
+----------------------+
|
v
+--------------------------------------+
| Stream record and regional replica |
+--------------------------------------+
|
v
+---------------------------+
| Consumer or cached read |
+---------------------------+
|
v
+----------------------------------------+
| Lag, hit rate, and conflict evidence |
+----------------------------------------+
For DynamoDB Streams, DAX, and Global Tables, the important boundary is this: Streams record item-level changes for a limited period. DAX is a DynamoDB-compatible cache for microsecond reads. Global Tables replicate table data across chosen Regions with version-specific behavior. Evidence proves stream view type and consumers, cache hit behavior and invalidation expectations, replica Regions, conflict behavior, lag, and failover runbook. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use Streams for event-driven reactions, DAX for read-heavy eventually consistent access that benefits from a cache, and Global Tables for multi-Region DynamoDB workloads. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid using DAX for write scaling, treating Streams as an unlimited event archive, or assuming active-active replication eliminates conflict design. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
DynamoDB Streams
A stream records item-level INSERT, MODIFY, and REMOVE events for a rolling 24-hour window. Select keys-only, new image, old image, or both images. Changes for one item preserve order; consumers must not assume one global table-wide order.
table commit -> stream shard/record -> Lambda event-source mapping or consumer
-> retry / partial batch / failure destination
-> idempotent side effect and checkpoint
Lambda mapping controls starting position, batch size/window, concurrency/parallelization, filtering, retry attempts, maximum age, bisect-on-error, partial-batch response, and failure destination. Delivery is at least once, so duplicates are normal. Make handlers idempotent and prevent recursion when they write to the source table.
A poison record can block a shard when retries are unbounded. Alarm on iterator age and errors, preserve enough event data for diagnosis/replay, and respect 24-hour retention. Streams are neither a permanent audit log nor a backup; copy durable events to an owned long-retention system when required.
DAX
DAX is a VPC-resident managed in-memory cache accessed with a DAX-aware client. It reduces latency and table read demand for cacheable key operations. It does not scale writes, cache arbitrary SQL, or replace DynamoDB as system of record.
| Path | Behavior |
|---|---|
| Item cache | Caches key gets; writes sent through DAX update relevant cache state |
| Query cache | Caches exact Query/Scan request/result combinations for configured TTL |
| Strong read | Passed through to DynamoDB rather than served from stale cache |
| Unsupported/admin/transaction API | Use the normal DynamoDB client according to current support matrix |
DAX adds subnet group, SG, endpoint discovery, nodes/AZs, IAM service role, encryption/TLS, maintenance, TTL/eviction, client library, failover, and hourly cost. Writers that bypass DAX can leave cached values stale until TTL. Benchmark cold/warm latency, hit rate, evictions, errors, table units saved, and total cost. ElastiCache may fit general cache data structures; local cache may fit simpler cases.
Global Tables: MREC and MRSC
Current Global Tables support two distinct consistency directions where available:
- Multi-Region eventual consistency (MREC): every replica is active for reads/writes and changes replicate asynchronously. Concurrent same-item writes can conflict; design owner-Region routing, immutable operations, optimistic versions, or application merge. Transactions are atomic only in their invocation Region and can appear progressively in other replicas.
- Multi-Region strong consistency (MRSC): supported topologies provide strongly consistent multi-Region operations with different Region, latency, availability, API, stream, and feature constraints. Current MRSC does not support transaction APIs. It does not use Streams for replication, although a stream can be enabled separately.
Do not assume old “last writer wins everywhere” material fully describes current Global Tables, and do not assume stronger consistency is automatically better. Test cross-Region write latency, required operations, Region set, and failure behavior.
Region A app -> replica A <--- global consistency/replication ---> replica B <- Region B app
| IAM, KMS, endpoint, capacity, backup and alarms per Region |
Global Tables do not copy all application infrastructure. Each Region needs deployable clients, roles, VPC endpoints, KMS/key policy, quotas, alarms, and routing. On-demand write settings synchronize; provisioned global-table scaling coordinates write capacity while read overrides can differ. Replicated writes and storage are billed in every replica.
Failover is application traffic routing, not promotion of a primary table. For MREC, quantify replication lag and conflicts before/after isolating a Region. AWS FIS can pause replication in an approved experiment. TTL deletion and stream consumers can create replicated costs or duplicate side effects; make one Region the side-effect owner or handlers globally idempotent.
Worked designs
- Search projection: stream handler writes by source event/version, uses partial batch retry and failure destination, and alarms on iterator age. Search is eventually consistent; checkout reads authoritative state.
- Hot product read: DAX caches gets, but price updates bypassing DAX can be stale. Route writes consistently or use accepted TTL/invalidation and revalidate at purchase.
- Global preferences: MREC can fit local writes if conflicts are mergeable; avoid whole-document last-writer overwrite.
- Financial balance: MREC last-writer conflict is unsafe. Evaluate MRSC constraints, regional write ownership with an immutable ledger, or another transactional architecture.
Required tests
- Generate all stream event types; explain view images and per-item ordering.
- Force partial Lambda batch failure, retry only failed work, and prove no duplicate side effect/recursion.
- Compare direct DynamoDB with DAX cold, warm, and strong reads; measure hit rate, p99, table units, and staleness.
- Remove a DAX node/path in a controlled lab and verify discovery/retry without public access.
- Produce conflicting MREC writes in two Regions and demonstrate conflict handling.
- Compare MREC and MRSC Region, transaction, stream, latency, and failure constraints using current docs.
- Run an approved replication-pause/routing game day, quantify recovery and convergence.
- Calculate stream/Lambda, DAX, replica write/storage/transfer, backup, KMS, and monitoring costs, then clean every Regional dependency.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Open DynamoDB Tables, then Exports and streams, and inspect stream state and view type.
- Open DAX and inventory clusters, subnet groups, security groups, node types, and status without creating one.
- Open the Global Tables tab and identify replica Regions, status, and consistency mode from supplied evidence.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list
Redact the account part of the ARN in shared evidence. Now run the topic queries:
aws dynamodb describe-table --table-name replace-with-table-name --query 'Table.{StreamArn:LatestStreamArn,View:StreamSpecification.StreamViewType,Replicas:Replicas[].{Region:RegionName,Status:ReplicaStatus}}' --output json
aws dax describe-clusters --query 'Clusters[].{Name:ClusterName,Status:Status,Nodes:TotalNodes,Endpoint:ClusterDiscoveryEndpoint.Address}' --output table
Expected interpretation
A stream ARN, DAX cluster, or replica list proves configuration only. Consumer checkpoints, cache effectiveness, replication convergence, and application failover require separate tests.
Practical work
For a global order-status system, decide which changes publish events, which reads may use DAX, which Regions accept writes, how conflicts are prevented, and how failover is tested.
Diagnose this topic from its own evidence
For Streams, trace the item key and event ID through shard/iterator or Lambda event-source metrics, consumer logs, retries, bisected batches and dead-letter/on-failure handling. Check the stream view type before expecting old/new images and remember the 24-hour retention window. For DAX, compare hit/miss/error/eviction and cluster health with direct DynamoDB behavior; strongly consistent reads bypass DAX. For global tables, compare replication latency, Region routing, conflict/consistency mode, KMS/IAM dependencies and application idempotency before declaring a Region healthy.
Negative tests: make the consumer process the same stream record twice and prove the side effect remains single; bypass/stop DAX and prove correctness survives at higher latency; route a test client away from one Region and prove the documented regional dependency and failback path.
Cost and cleanup
Stream reads, Lambda, DAX nodes, replica writes, storage, cross-Region transfer, backups, and monitoring can charge.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Separate change capture, in-memory read acceleration, and multi-Region replication because they solve different problems.
- Which scope or ownership boundary must be proved first?
Expected direction: Streams record item-level changes for a limited period. DAX is a DynamoDB-compatible cache for microsecond reads. Global Tables replicate table data across chosen Regions with version-specific behavior.
- What evidence is strong enough to accept the result?
Expected direction: Evidence proves stream view type and consumers, cache hit behavior and invalidation expectations, replica Regions, conflict behavior, lag, and failover runbook.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid using DAX for write scaling, treating Streams as an unlimited event archive, or assuming active-active replication eliminates conflict design.
- Which cost dimensions and retained resources need an owner?
Expected direction: Stream reads, Lambda, DAX nodes, replica writes, storage, cross-Region transfer, backups, and monitoring can charge.
Lesson acceptance
Pass when the learner distinguishes change capture, cache and multi-Region replication rather than combining them as one feature; documents ordering scope, duplicate delivery, retention and replay; keeps DAX non-authoritative; and accurately compares current MREC and MRSC restrictions. The solution must include regional dependencies, conflict/idempotency behavior, RPO/RTO, routing, failure tests, security, monitoring, cost and cleanup. Fail if Streams is called a permanent audit log, DAX is required for correctness, or global tables are claimed to provide globally atomic transactions without evidence.