DynamoDB Streams and Global Tables

DynamoDB Streams captures a time-ordered sequence of item-level modifications in a DynamoDB table. Every time an item is created, updated, or deleted, DynamoDB writes a stream record describing the change. Stream records are available for 24 hours after they are written.

Streams are the foundation of event-driven architectures with DynamoDB. Common uses include triggering Lambda functions for real-time processing, maintaining an audit log, replicating data to another store, or invalidating a cache when data changes.

When enabling a stream, you choose a StreamViewType that determines what data each stream record contains:

• KEYS_ONLY: only the primary key attributes of the modified item
• NEW_IMAGE: the entire item as it appears after the change
• OLD_IMAGE: the entire item as it appeared before the change
• NEW_AND_OLD_IMAGES: both the before and after state of the item

Choose NEW_AND_OLD_IMAGES for auditing (to see what changed), NEW_IMAGE for replication or cache updates, and KEYS_ONLY when you only need to know which item changed and will fetch the current state separately.

The most common way to consume a DynamoDB Stream is with AWS Lambda. Lambda polls the stream and invokes your function with a batch of stream records. Lambda handles polling, checkpointing, and retry automatically.

Key configuration parameters: batch size (number of records per invocation, up to 10,000), bisect on error (split a failed batch to isolate the bad record), and destination on failure (SQS or SNS for unprocessable records). Lambda reads from each shard in parallel, so the parallelism equals the number of shards in the stream.

Practical DynamoDB Streams use cases on the SAA-C03 exam:

• Cross-region replication: Lambda reads the stream and writes changes to a table in another Region (before Global Tables existed, this was the standard pattern)
• ElastiCache invalidation: when a DynamoDB item changes, Lambda invalidates or updates the corresponding cache key
• Search index synchronisation: push item changes to OpenSearch Service to enable full-text search on DynamoDB data
• Audit logging: write every change to S3 or a compliance store for regulatory purposes
• Event-driven microservices: trigger downstream services when specific items change

DynamoDB Global Tables provide fully managed, multi-region, multi-active replication. Each Region gets a full copy of the table, and all copies are writeable simultaneously. Writes in any Region are asynchronously replicated to all other Regions within approximately 1 second.

Global Tables enable two critical scenarios: low-latency reads and writes for globally distributed users (each user writes to and reads from the nearest Region), and multi-region active-active disaster recovery (the application continues running in any surviving Region with no data loss from after the last replication).

To create a Global Table, you first create a table with DynamoDB Streams enabled (NEW_AND_OLD_IMAGES is required for Global Tables internally). Then you add replica Regions. AWS creates a replica table in each added Region and begins synchronising data bidirectionally.

Global Tables (Version 2019.11.21) are the current standard and support On-Demand or Provisioned capacity with Auto Scaling. Each Region replica must have the same table name. You can add or remove Regions from a Global Table at any time.

Because Global Tables allow writes in multiple Regions simultaneously, write conflicts can occur if two Regions update the same item at almost the same time. DynamoDB resolves conflicts using a last-writer-wins approach based on timestamps stored in the stream records.

In practice, this means two near-simultaneous conflicting updates will result in one winning and one being overwritten. Applications should be designed to avoid concurrent writes to the same item from different Regions. For use cases where conflicts are common, consider routing all writes for a specific user or entity to a single home Region.

With Global Tables, writes in one Region are automatically replicated to all other Regions. Each replicated write consumes WCUs in the destination Regions—if you have 3 Regions, a single write costs roughly 3× the WCUs across all Regions. Plan capacity accordingly.

Reads in each Region consume the local replica's RCUs. Eventually consistent reads (the default) use local data, while strongly consistent reads are not supported across Regions. For most global applications, eventual consistency within ~1 second between Regions is acceptable.

A key SAA-C03 exam distinction: DynamoDB Global Tables are multi-active (all Regions accept reads AND writes), while RDS cross-region Read Replicas are read-only (you can only promote a replica to make it writeable, breaking replication).

Use DynamoDB Global Tables when you need: multi-region active-active writes, sub-100ms access globally, or zero-RPO multi-region DR for NoSQL data. Use RDS cross-region replicas when you need: global read scalability for a relational database, or a warm DR standby you can promote for failover.

Common architecture patterns combining Streams and Lambda:

• Fan-out: Lambda reads the stream and publishes to SNS, which fans out to multiple SQS queues for independent consumers
• Aggregation: Lambda accumulates changes and updates aggregate totals in a separate DynamoDB table (e.g., daily order count)
• Write-behind cache: on each stream event, Lambda updates ElastiCache so reads can be served from cache
• Notification: stream triggers Lambda which sends an SES email or SNS push notification when a specific condition changes

As an alternative to DynamoDB Streams, you can direct item-level changes to an Amazon Kinesis Data Stream. This is useful when you need longer retention (up to 1 year vs 24 hours for native DynamoDB Streams), more consumers, or integration with services that read from Kinesis.

Kinesis Data Streams integration is enabled per table and does not replace DynamoDB Streams—you can have both enabled simultaneously. This is a newer feature (2021) that extends the DynamoDB change event pipeline without requiring custom replication logic.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: DynamoDB Streams capture item-level changes for 24 hours and integrate with Lambda for event-driven processing, Global Tables provide multi-active multi-region replication with last-writer-wins conflict resolution, and Kinesis Data Streams integration extends retention beyond the 24-hour stream window. Next up we explore Route 53 hosted zones and DNS record types.