DynamoDB Time to Live – TTL

• DynamoDB Time to Live – TTL enables a per-item timestamp to determine when an item is no longer needed.
• After the date and time of the specified timestamp, DynamoDB deletes the item from the table without consuming any write throughput.

• DynamoDB TTL is provided at no extra cost and can help reduce data storage by retaining only required data.
• Items that are deleted from the table are also removed from any local secondary index and global secondary index in the same way as a DeleteItem operation.
• Expired items are typically deleted within a few days of their expiration time (DynamoDB documentation states items are typically deleted within two days of expiration).
• Items with valid, expired TTL attributes may be deleted by the system at any time after expiration. You can still update expired items that are pending deletion, including changing or removing their TTL attributes.
• DynamoDB Streams tracks the TTL delete operation as a system delete (service deletion), not a regular user delete. The streams record contains userIdentity.type: "Service" and userIdentity.principalId: "dynamodb.amazonaws.com".
• TTL deletions can be identified in DynamoDB Streams only in the Region where the deletion occurred. TTL deletions replicated to global table replica regions are not identifiable in DynamoDB Streams in those replica regions.
• TTL requirements
  • TTL attributes must use the Number data type. Other data types, such as String, are not supported and will be ignored by the TTL process.
  • TTL attributes must use the Unix epoch time format (seconds granularity). Ensure the timestamp is in seconds, not milliseconds.
• TTL is useful if the stored items lose relevance after a specific time. for e.g.
  • Remove user or sensor data after a year of inactivity in an application
  • Archive expired items to an S3 data lake via DynamoDB Streams and AWS Lambda.
  • Retain sensitive data for a certain amount of time according to contractual or regulatory obligations.
  • Manage session data, temporary tokens, or short-lived cache entries.

TTL Best Practices

• Use filter expressions in Scan and Query operations to exclude expired items that are pending deletion, as they still appear in read results until physically removed.
• Use condition expressions to avoid writing to expired items that are pending deletion.
• Expired items still count towards storage and read costs until they are physically deleted by the background process.
• For Global Tables (version 2019.11.21), DynamoDB replicates TTL deletes to all replica tables. The initial TTL delete does not consume WCU in the region where expiry occurs, but replicated TTL deletes consume a replicated Write Capacity Unit (provisioned) or Replicated Write Unit (on-demand) in each replica region.
• TTL will continue to process deletions for approximately 30 minutes after it is disabled on a table.

Near Real-Time Data Eviction (Alternative Patterns)

• DynamoDB’s native TTL deletes items within a few days (typically within two days), which may not suit time-sensitive use cases.
• For applications requiring near real-time data eviction (less than one minute), consider using Amazon EventBridge Scheduler in combination with DynamoDB to schedule precise deletions.
• Another pattern uses a purpose-built Global Secondary Index (GSI) for strict data management and precise eviction control.
• These event-driven architecture patterns can reduce deletion latency from days to under one minute but require additional infrastructure.

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. A company developed an application by using AWS Lambda and
   Amazon DynamoDB. The Lambda function periodically pulls data from the company’s S3 bucket based on date and time tags and inserts specific values into a DynamoDB table for further processing. The company must remove data that is older than 30 days from the DynamoDB table. Which solution will meet this requirement with the MOST operational efficiency?
   1. Update the Lambda function to add the Version attribute in the DynamoDB table. Enable TTL on the DynamoDB table to expire entries that are older than 30 days based on the TTL attribute.
   2. Update the Lambda function to add the TTL attribute in the DynamoDB table. Enable TTL on the DynamoDB table to expire entries that are older than 30 days based on the TTL attribute.
   3. Use AWS Step Functions to delete entries that are older than 30 days.
   4. Use EventBridge to schedule the Lambda function to delete entries that are older than 30 days.
2. A company stores session data in a DynamoDB table. Each session must be automatically removed exactly when it expires, with no tolerance for delay. The application requires sub-minute deletion precision. Which approach provides the MOST precise deletion timing?
   1. Enable DynamoDB TTL on the session table with the expiration timestamp attribute.
   2. Use a scheduled Lambda function running every minute to scan and delete expired items.
   3. Use Amazon EventBridge Scheduler to schedule individual delete operations for each session at its exact expiration time.
   4. Create a DynamoDB Stream with a Lambda function to delete items when they are marked as expired.
3. A developer is implementing DynamoDB TTL for a global table replicated across three regions. Which statement correctly describes how TTL deletions are handled in global tables?
   1. TTL deletions consume Write Capacity Units in all regions including the region where expiry occurs.
   2. The initial TTL delete does not consume WCU in the region where expiry occurs, but replicated deletes consume replicated Write Capacity Units in each replica region.
   3. TTL deletions are not replicated to other regions and must be handled separately in each region.
   4. TTL deletions consume no capacity in any region as they are system operations.

References

• Using time to live (TTL) in DynamoDB
• Enable time to live (TTL) in DynamoDB
• Computing time to live (TTL) in DynamoDB
• Working with expired items and time to live (TTL)
• Implement event-driven architectures with Amazon DynamoDB

Amazon DynamoDB Global Tables

• DynamoDB Global Tables is a fully managed, serverless, multi-Region, multi-active database.
• Global tables provide 99.999% availability, increased application resiliency, and improved business continuity.
• Global table’s automatic cross-Region replication capability helps achieve fast, local read and write performance and regional fault tolerance for database workloads.
• Applications can now perform reads and writes to DynamoDB in AWS Regions around the world, with changes in any Region propagated to every Region where a table is replicated.
• Global Tables help in building applications to advantage of data locality to reduce overall latency.
• Global Tables replicates data among Regions within a single AWS account.

Global Tables Working

• Global Table is a collection of one or more replica tables, all owned by a single AWS account.
• A single Amazon DynamoDB global table can only have one replica table per AWS Region.
• Each replica table stores the same set of data items, has the same table name, and the same primary key schema.
• When an application writes data to a replica table in one Region, DynamoDB replicates the writes to other replica tables in the other AWS Regions.
• All replicas in a global table share the same table name, primary key schema, and item data.

Consistency Modes

• When creating a global table, a consistency mode must be configured.
• Global tables support two consistency modes: Multi-Region Eventual Consistency (MREC) and Multi-Region Strong Consistency (MRSC).
• If no consistency mode is specified, the global table defaults to MREC.
• A global table cannot contain replicas configured with different consistency modes.
• Consistency mode cannot be changed after creation.

Multi-Region Eventual Consistency (MREC) – Default

• MREC is the default consistency mode for global tables.
• Item changes are asynchronously replicated to all other replicas, typically within a second or less.
• Conflict Resolution: Uses Last Write Wins approach based on the latest internal timestamp on a per-item basis.
• Consistency Behavior:
  • Supports eventual consistency for cross-Region reads.
  • Supports strong consistency for same-Region reads (returns latest version if item was last updated in that Region).
  • May return stale data for strongly consistent reads if the item was last updated in a different Region.
• Recovery Point Objective (RPO): Equal to replication delay between replicas (usually a few seconds).
• Replica Management:
  • Create by adding a replica to an existing DynamoDB table.
  • Can add replicas to expand to more Regions or remove replicas if no longer needed.
  • Can have a replica in any Region where DynamoDB is available.
  • No performance impact when adding replicas.
• Requirements: Requires DynamoDB Streams enabled with New and Old image settings.
• Use Cases:
  • Applications that can tolerate stale data from strongly consistent reads if data was updated in another Region.
  • Prioritize lower write and strongly consistent read latencies over multi-Region read consistency.
  • Multi-Region high availability strategy can tolerate RPO greater than zero.

Multi-Region Strong Consistency (MRSC) – January 2025

• Announced at AWS re:Invent 2024 (preview) and generally available in January 2025.
• Item changes are synchronously replicated to at least one other Region before the write operation returns a successful response.
• Zero RPO: Provides Recovery Point Objective (RPO) of zero for highest resilience.
• Consistency Behavior:
  • Strongly consistent read operations on any MRSC replica always return the latest version of an item.
  • Conditional writes always evaluate against the latest version of an item.
  • Provides strong read-after-write consistency across all Regions.
• Deployment Requirements:
  • Must be deployed in exactly three Regions.
  • Can configure with three replicas OR two replicas + one witness.
  • Witness: A component that contains data written to replicas and supports MRSC’s availability architecture. Cannot perform read/write operations on a witness. Witness is owned and managed by DynamoDB.
• Regional Availability: Available in three Region sets:
  • US Region set: US East (N. Virginia), US East (Ohio), US West (Oregon)
  • EU Region set: Europe (Ireland), Europe (London), Europe (Paris), Europe (Frankfurt)
  • AP Region set: Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Osaka)
  • MRSC global tables cannot span Region sets (e.g., cannot mix US and EU Regions).
• Creation Requirements:
  • Create by adding one replica and a witness OR two replicas to an existing DynamoDB table.
  • Table must be empty when converting to MRSC (existing items not supported).
  • Cannot add additional replicas after creation.
  • Cannot delete a single replica or witness (must delete two replicas or one replica + witness to convert back to single-Region table).
• Write Conflicts: Write operation fails with ReplicatedWriteConflictException when attempting to modify an item already being modified in another Region. Failed writes can be retried.
• Limitations:
  • Time to Live (TTL): Not supported
  • Local Secondary Indexes (LSIs): Not supported
  • Transactions: Not supported (TransactWriteItems and TransactGetItems return errors)
  • DynamoDB Streams: Not used for replication (can be enabled separately)
• Performance Trade-off: Higher write and strongly consistent read latencies compared to MREC.
• Use Cases:
  • Need strongly consistent reads across multiple Regions.
  • Prioritize global read consistency over lower write latency.
  • Multi-Region high availability strategy requires RPO of zero.
  • Financial applications, inventory management, or any system requiring strict consistency.

Pricing Reduction (November 2024)

• Effective November 1, 2024, DynamoDB reduced prices for global tables by up to 67%.
• On-demand mode: Global tables cost 67% less than before.
• Provisioned capacity mode: Global tables cost 33% less than before.
• Makes global tables significantly more cost-effective for multi-Region deployments.

Replication and Throughput

• MREC Replication:
  • Uses DynamoDB Streams to replicate changes.
  • Streams are enabled by default on all replicas and cannot be disabled.
  • Replication process may combine multiple changes into a single replicated write.
  • Stream records are ordered per-item but ordering between items may differ between replicas.
• MRSC Replication:
  • Does not use DynamoDB Streams for replication.
  • Streams can be enabled separately if needed.
  • Stream records are identical for every replica, including ordering.
• Provisioned Mode:
  • Replication consumes write capacity.
  • Auto scaling settings for read and write capacities are synchronized between replicas.
  • Read capacity can be independently configured per replica using ProvisionedThroughputOverride.
• On-demand Mode:
  • Write capacity is automatically synchronized across all replicas.
  • DynamoDB automatically adjusts capacity based on traffic.

Monitoring and Testing

• Replication Latency (MREC only):
  • MREC global tables publish ReplicationLatency metric to CloudWatch.
  • Tracks elapsed time between item write in one replica and appearance in another replica.
  • Expressed in milliseconds for every source-destination Region pair.
  • MRSC global tables do not publish this metric (synchronous replication).
• Fault Injection Testing:
  • Both MREC and MRSC integrate with AWS Fault Injection Service (AWS FIS).
  • Can simulate Region isolation by pausing replication to/from a selected replica.
  • Test error handling, recovery mechanisms, and multi-Region traffic shift behavior.

Additional Features and Considerations

• Time to Live (TTL):
  • MREC: Supported. TTL settings synchronized across all replicas. TTL deletes replicated to all replicas (charged for replicated deletes).
  • MRSC: Not supported.
• Transactions:
  • MREC: Supported but only atomic within the Region where invoked. Not replicated as a unit.
  • MRSC: Not supported.
• Point-in-Time Recovery (PITR):
  • Can be enabled on each local replica independently.
  • PITR settings are not synchronized between replicas.
• DynamoDB Accelerator (DAX):
  • Writes to global table replicas bypass DAX, updating DynamoDB directly.
  • DAX caches can become stale and are only refreshed when cache TTL expires.
• Settings Synchronization:
  • Always synchronized: Capacity mode, write capacity, GSI definitions, encryption, TTL (MREC)
  • Can be overridden per replica: Read capacity, table class
  • Never synchronized: Deletion protection, PITR, tags, Contributor Insights

DynamoDB Global Tables vs. Aurora Global Databases

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. A company is building a web application on AWS. The application requires the database to support read and write operations in multiple AWS Regions simultaneously. The database also needs to propagate data changes between Regions as the changes occur. The application must be highly available and must provide a latency of single-digit milliseconds. Which solution meets these requirements?
   1. Amazon DynamoDB global tables
   2. Amazon DynamoDB streams with AWS Lambda to replicate the data
   3. An Amazon ElastiCache for Redis cluster with cluster mode enabled and multiple shards
   4. An Amazon Aurora global database
2. A financial services company requires a multi-Region database with zero data loss (RPO = 0) and strongly consistent reads across all Regions. Which DynamoDB global tables consistency mode should they use?
   1. Multi-Region Eventual Consistency (MREC)
   2. Multi-Region Strong Consistency (MRSC)
   3. Single-Region Strong Consistency
   4. Cross-Region Read Replicas
3. A company wants to create a DynamoDB global table with MRSC for their inventory management system. They have existing data in a table in us-east-1. What must they do before converting to MRSC?
   1. Enable DynamoDB Streams on the table.
   2. Configure three replicas in different Regions.
   3. Empty the table of all existing data.
   4. Enable Point-in-Time Recovery (PITR).
4. A company has a DynamoDB global table with MREC configured across us-east-1, eu-west-1, and ap-southeast-1. An item is updated simultaneously in us-east-1 and eu-west-1. How does DynamoDB resolve this conflict?
   1. The write in the primary Region takes precedence.
   2. Last Write Wins based on the latest internal timestamp.
   3. Both writes are rejected and must be retried.
   4. The write with the larger data size takes precedence.
5. A company wants to deploy a DynamoDB global table with MRSC. They need replicas in us-east-1, eu-west-1, and ap-southeast-1. What will happen?
   1. The global table will be created successfully.
   2. The creation will fail because MRSC cannot span Region sets.
   3. The global table will be created with MREC instead.
   4. A witness will be automatically placed in a fourth Region.
6. Which of the following features are NOT supported with DynamoDB MRSC global tables? (Select THREE)
   1. Time to Live (TTL)
   2. DynamoDB Streams
   3. Local Secondary Indexes (LSIs)
   4. Global Secondary Indexes (GSIs)
   5. Transaction operations (TransactWriteItems)
   6. Point-in-Time Recovery (PITR)
7. A company has a DynamoDB global table with MREC. They perform a strongly consistent read in us-west-2, but the item was last updated in eu-west-1. What will the read return?
   1. The latest version of the item from eu-west-1.
   2. Potentially stale data (the version before the eu-west-1 update).
   3. An error indicating the item is being replicated.
   4. The read will be automatically redirected to eu-west-1.
8. What is the typical replication latency for DynamoDB global tables with MREC?
   1. 5-10 seconds
   2. Within a second or less
   3. Within 5 minutes
   4. Synchronous (no latency)

References

• Amazon DynamoDB Global Tables
• How DynamoDB global tables work
• Multi-Region strong consistency
• Build the highest resilience apps with multi-Region strong consistency
• Amazon DynamoDB lowers pricing for on-demand throughput and global tables
• Amazon DynamoDB re:Invent 2024 recap

Amazon DynamoDB Streams

• DynamoDB Streams provides a time-ordered sequence of item-level changes made to data in a table.
• DynamoDB Streams is a serverless data streaming feature that makes it straightforward to track, process, and react to item-level changes in DynamoDB tables in near real-time.
• DynamoDB Streams stores the data for the last 24 hours, after which they are erased.
• DynamoDB Streams maintains an ordered sequence of the events per item; however, sequence across items is not maintained.
• Example:
  • For e.g., suppose that you have a DynamoDB table tracking high scores for a game and that each item in the table represents an individual player. If you make the following three updates in this order:
    • Update 1: Change Player 1’s high score to 100 points
    • Update 2: Change Player 2’s high score to 50 points
    • Update 3: Change Player 1’s high score to 125 points
  • DynamoDB Streams will maintain the order for Player 1 score events. However, it would not maintain order across the players. So Player 2 score event is not guaranteed between the 2 Player 1 events.
• Applications can access this log and view the data items as they appeared before and after they were modified, in near-real time.
• DynamoDB Streams APIs help developers consume updates and receive the item-level data before and after items are changed.

DynamoDB Streams Features

• Streams allow reads at up to twice the rate of the provisioned write capacity of the DynamoDB table.
• Streams have to be enabled on a per-table basis. When enabled on a table, DynamoDB captures information about every modification to data items in the table.
• Streams support Encryption at rest to encrypt the data.
• Streams are designed for No Duplicates so that every update made to the table will be represented exactly once in the stream.
• Streams write stream records in near-real time so that applications can consume these streams and take action based on the contents.
• Stream records contain information about a data modification to a single item in a DynamoDB table.
• Each stream record has a sequence number that reflects the order in which the record was published to the stream.

Stream View Types

• When enabling a stream on a table, you must specify the stream view type, which determines what information is written to the stream:
• KEYS_ONLY: Only the key attributes of the modified item.
• NEW_IMAGE: The entire item, as it appears after it was modified.
• OLD_IMAGE: The entire item, as it appeared before it was modified.
• NEW_AND_OLD_IMAGES: Both the new and the old images of the item (recommended for maximum flexibility).

Use Cases

• Multi-Region Replication: Keep other data stores up-to-date with the latest changes to DynamoDB (used by DynamoDB Global Tables).
• Real-time Analytics: Stream data to analytics services for real-time insights.
• Event-Driven Architectures: Trigger actions based on changes made to the table.
• Data Aggregation: Aggregate data from multiple tables into a single view.
• Audit and Compliance: Maintain audit logs of all changes to data.
• Search Index Updates: Keep search indexes (e.g., OpenSearch) synchronized with DynamoDB data.
• Cache Invalidation: Invalidate caches when data changes.
• Notifications: Send notifications when specific data changes occur.

Processing DynamoDB Streams

• Stream records can be processed using multiple methods:

AWS Lambda

• Most common and recommended approach for processing DynamoDB Streams.
• Lambda polls the stream and invokes the function synchronously when new records are available.
• Lambda automatically handles scaling, retries, and error handling.
• Supports batch processing of stream records.
• Can filter events using event filtering to reduce invocations and costs.

Kinesis Data Streams

• DynamoDB can stream change data directly to Amazon Kinesis Data Streams.
• Provides longer data retention (up to 365 days vs. 24 hours for DynamoDB Streams).
• Enables integration with Kinesis Data Firehose, Kinesis Data Analytics, and other Kinesis consumers.
• Supports fan-out to multiple consumers.
• Better for high-throughput scenarios requiring multiple consumers.

Kinesis Client Library (KCL)

• KCL can be used to build custom applications that process DynamoDB Streams.
• DynamoDB Streams Kinesis Adapter allows KCL applications to consume DynamoDB Streams.
• KCL 3.0 Support (June 2025): DynamoDB Streams now supports Kinesis Client Library 3.0.
  • Reduces compute costs to process streaming data by up to 33% compared to previous KCL versions.
  • Improved load balancing algorithm based on CPU utilization.
  • Enhanced performance and efficiency.
  • Note: KCL 1.x reaches end-of-support on January 30, 2026. Migrate to KCL 3.x.

AWS PrivateLink Support (March 2025)

• Announced in March 2025, DynamoDB Streams now supports AWS PrivateLink.
• Allows invoking DynamoDB Streams APIs from within your Amazon VPC without traversing the public internet.
• Only interface endpoints are supported for DynamoDB Streams (gateway endpoints are not supported).
• Enables private connectivity for stream processing applications running on-premises or in other Regions.
• Supports FIPS endpoints in US and Canada commercial AWS Regions (announced November 2025).
• Enhances security by keeping stream data within the AWS network.
• Critical for compliance requirements that mandate private network connectivity.
• Can be accessed from on-premises via AWS Direct Connect or Site-to-Site VPN.

DynamoDB Streams vs. Kinesis Data Streams

• DynamoDB Streams:
  • 24-hour data retention
  • Automatically scales with table
  • No additional cost (included with DynamoDB)
  • Simpler to set up and use
  • Best for simple event-driven architectures
• Kinesis Data Streams:
  • Up to 365 days data retention
  • Manual capacity management (or on-demand mode)
  • Additional cost for Kinesis
  • More complex but more flexible
  • Best for multiple consumers and longer retention needs
• Recommendation: Use DynamoDB Streams for simple use cases with Lambda. Use Kinesis Data Streams for complex scenarios requiring multiple consumers or longer retention.

Best Practices

• Choose the Right View Type: Use NEW_AND_OLD_IMAGES for maximum flexibility unless you have specific requirements.
• Handle Duplicates: Although designed for no duplicates, implement idempotent processing logic.
• Monitor Stream Processing: Use CloudWatch metrics to monitor Lambda invocations, errors, and iterator age.
• Use Event Filtering: Filter events in Lambda to reduce unnecessary invocations and costs.
• Batch Processing: Configure appropriate batch sizes for Lambda to optimize throughput and cost.
• Error Handling: Implement proper error handling and configure dead-letter queues for failed records.
• Consider Kinesis for Multiple Consumers: If you need multiple consumers, use Kinesis Data Streams instead.
• Migrate to KCL 3.0: If using KCL, migrate to version 3.0 for cost savings and performance improvements.
• Use PrivateLink for Security: Enable AWS PrivateLink for enhanced security and compliance.

Limitations and Considerations

• Stream records are available for only 24 hours.
• Streams do not guarantee ordering across different items (only per-item ordering).
• Stream records are eventually consistent with the table.
• Enabling streams does not affect table performance.
• Streams cannot be enabled on tables with local secondary indexes that use non-key attributes in the projection.
• For Global Tables with MREC, streams are enabled by default and cannot be disabled.
• For Global Tables with MRSC, streams are not used for replication but can be enabled separately.

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. An application currently writes a large number of records to a DynamoDB table in one region. There is a requirement for a secondary application to retrieve new records written to the DynamoDB table every 2 hours and process the updates accordingly. Which of the following is an ideal way to ensure that the secondary application gets the relevant changes from the DynamoDB table?
   1. Insert a timestamp for each record and then scan the entire table for the timestamp as per the last 2 hours.
   2. Create another DynamoDB table with the records modified in the last 2 hours.
   3. Use DynamoDB Streams to monitor the changes in the DynamoDB table.
   4. Transfer records to S3 which were modified in the last 2 hours.
2. A company needs to process DynamoDB stream records from an on-premises application without exposing traffic to the public internet. What should they implement?
   1. Use a NAT gateway to access DynamoDB Streams.
   2. Create an interface VPC endpoint for DynamoDB Streams using AWS PrivateLink.
   3. Create a gateway VPC endpoint for DynamoDB Streams.
   4. Use an internet gateway with security groups.
3. A company wants to reduce costs for processing DynamoDB Streams using KCL. What should they do?
   1. Switch from KCL to Lambda for processing.
   2. Migrate from KCL 1.x to KCL 3.0 for up to 33% cost reduction.
   3. Reduce the number of shards in the stream.
   4. Increase the batch size for stream processing.
4. A company needs to maintain an audit log of all changes to a DynamoDB table for 90 days. DynamoDB Streams only retains data for 24 hours. What is the BEST solution?
   1. Enable PITR on the DynamoDB table.
   2. Stream DynamoDB changes to Kinesis Data Streams with 90-day retention.
   3. Use Lambda to copy stream records to S3 every 24 hours.
   4. Create on-demand backups every 24 hours.
5. A developer wants to capture both the old and new values of items when they are modified in a DynamoDB table. Which stream view type should they configure?
   1. KEYS_ONLY
   2. NEW_IMAGE
   3. OLD_IMAGE
   4. NEW_AND_OLD_IMAGES
6. Which of the following statements about DynamoDB Streams are correct? (Select TWO)
   1. Stream records are available for 24 hours.
   2. Streams guarantee ordering across all items in the table.
   3. Streams maintain ordered sequence of events per item.
   4. Streams can be processed only by Lambda functions.
   5. Enabling streams impacts table write performance.
7. A company has multiple applications that need to process the same DynamoDB change events. What is the BEST approach?
   1. Create multiple Lambda functions triggered by the same DynamoDB Stream.
   2. Stream DynamoDB changes to Kinesis Data Streams and use multiple consumers.
   3. Enable multiple DynamoDB Streams on the same table.
   4. Use DynamoDB Streams with fan-out to multiple Lambda functions.

References

• Change data capture for DynamoDB Streams
• AWS PrivateLink for DynamoDB Streams
• Amazon DynamoDB Streams APIs now support AWS PrivateLink
• Amazon DynamoDB Streams adds support for KCL 3.0
• Using the DynamoDB Streams Kinesis adapter
• Choose the right change data capture strategy for DynamoDB

DynamoDB Consistency

• AWS has a Region, which is a physical location around the world where we cluster data centers, with one or more Availability Zones which are discrete data centers with redundant power, networking, and connectivity in an AWS Region.
• Amazon automatically stores each DynamoDB table in the three geographically distributed locations or AZs for durability.
• DynamoDB consistency represents the manner and timing in which the successful write or update of a data item is reflected in a subsequent read operation of that same item.

DynamoDB Consistency Modes

Eventually Consistent Reads (Default)

• Eventual consistency option maximizes the read throughput.
• Consistency across all copies is usually reached within a second.
• However, an eventually consistent read might not reflect the results of a recently completed write.
• Repeating a read after a short time should return the updated data.
• DynamoDB uses eventually consistent reads, by default.
• Use Cases:
  • Applications that can tolerate reading slightly stale data.
  • Read-heavy workloads where throughput is more important than immediate consistency.
  • Cost-sensitive applications (eventually consistent reads are half the cost of strongly consistent reads).

Strongly Consistent Reads

• Strongly consistent read returns a result that reflects all writes that received a successful response prior to the read.
• Ensures that the most up-to-date data is returned.
• Cost: Strongly consistent reads are 2x the cost of eventually consistent reads (consume twice the read capacity units).
• Disadvantages:
  • A strongly consistent read might not be available if there is a network delay or outage. In this case, DynamoDB may return a server error (HTTP 500).
  • Strongly consistent reads may have higher latency than eventually consistent reads.
  • Not supported on Global Secondary Indexes (GSIs) – only eventually consistent reads are supported on GSIs.
  • Strongly consistent reads use more throughput capacity than eventually consistent reads.
• Use Cases:
  • Applications requiring immediate read-after-write consistency.
  • Financial transactions or inventory management where stale data is unacceptable.
  • Scenarios where data accuracy is critical.

Specifying Consistency Mode

• DynamoDB allows the user to specify whether the read should be eventually consistent or strongly consistent at the time of the request.
• Read operations (such as GetItem, Query, and Scan) provide a ConsistentRead parameter. If set to true, DynamoDB uses strongly consistent reads during the operation.
• Default Behavior: Query, GetItem, and BatchGetItem operations perform eventually consistent reads by default.
• Forcing Strong Consistency:
  • Query and GetItem operations can be forced to be strongly consistent by setting ConsistentRead=true.
  • Query operations cannot perform strongly consistent reads on Global Secondary Indexes (GSIs).
  • BatchGetItem operations can be forced to be strongly consistent on a per-table basis.
  • Scan operations can be forced to be strongly consistent.

Transactional Consistency

• DynamoDB supports transactions with full ACID (Atomicity, Consistency, Isolation, Durability) properties.
• Transactions provide all-or-nothing execution for multiple operations across one or more tables.
• Transaction Operations:
  • TransactWriteItems – Perform multiple write operations atomically.
  • TransactGetItems – Perform multiple read operations with snapshot isolation.
• Consistency Guarantees:
  • Atomicity: All operations in a transaction succeed or fail together.
  • Consistency: Transactions move the database from one valid state to another.
  • Isolation: Transactions are isolated from each other using snapshot isolation.
  • Durability: Once a transaction is committed, it is durable.
• Regional Scope: Transactional operations provide ACID guarantees within a single Region.
• Global Tables Consideration: For Global Tables with MREC, transactions are only atomic within the Region where invoked (not replicated as a unit).
• Cost: Transactional operations consume 2x the write capacity units compared to standard writes.

Multi-Region Strong Consistency (MRSC) – January 2025

• Announced at AWS re:Invent 2024 and generally available in January 2025.
• Available for DynamoDB Global Tables configured with Multi-Region Strong Consistency mode.
• Capability: Provides strong consistency across multiple AWS Regions.
• Guarantee: Strongly consistent reads on an MRSC table always return the latest version of an item, irrespective of the Region where the read is performed.
• Zero RPO: Enables Recovery Point Objective (RPO) of zero for highest resilience.
• How It Works:
  • Item changes are synchronously replicated to at least one other Region before the write operation returns success.
  • Strongly consistent reads always reflect the latest committed write across all Regions.
  • Conditional writes always evaluate against the latest version of an item globally.
• Deployment Requirements:
  • Must be deployed in exactly three Regions.
  • Can configure with 3 replicas OR 2 replicas + 1 witness.
  • Available in three Region sets: US, EU, and AP (cannot span Region sets).
• Trade-offs:
  • Higher write latency compared to MREC (eventual consistency) due to synchronous replication.
  • Higher strongly consistent read latency compared to MREC.
• Use Cases:
  • Financial applications requiring global strong consistency.
  • Inventory management systems across multiple Regions.
  • Applications requiring zero data loss (RPO = 0).
  • Compliance scenarios requiring strict consistency guarantees.
• Limitations:
  • Transactions not supported on MRSC tables.
  • TTL not supported on MRSC tables.
  • Local Secondary Indexes not supported on MRSC tables.

Consistency Comparison

Best Practices

• Default to Eventually Consistent: Use eventually consistent reads by default for cost and performance optimization.
• Use Strong Consistency Selectively: Only use strongly consistent reads when immediate consistency is required.
• Avoid Strong Consistency on GSIs: Design data models to avoid needing strongly consistent reads on GSIs (not supported).
• Consider Read-After-Write Patterns: If your application writes and immediately reads, use strongly consistent reads or implement retry logic.
• Use Transactions for Multi-Item Operations: When multiple items must be updated atomically, use transactions.
• Evaluate MRSC for Global Applications: For applications requiring global strong consistency, consider MRSC Global Tables.
• Monitor Consistency Metrics: Use CloudWatch to monitor read/write patterns and adjust consistency settings accordingly.
• Handle Errors Gracefully: Implement retry logic for strongly consistent reads that may fail during network issues.

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. Which of the following statements is true about DynamoDB?
   1. Requests are eventually consistent unless otherwise specified.
   2. Requests are strongly consistent.
   3. Tables do not contain primary keys.
   4. None of the above
2. How is provisioned throughput affected by the chosen consistency model when reading data from a DynamoDB table?
   1. Strongly consistent reads use the same amount of throughput as eventually consistent reads
   2. Strongly consistent reads use variable throughput depending on read activity
   3. Strongly consistent reads use more throughput than eventually consistent reads.
   4. Strongly consistent reads use less throughput than eventually consistent reads
3. A company needs to perform a query on a Global Secondary Index (GSI) and requires the most up-to-date data. What consistency mode should they use?
   1. Strongly consistent reads
   2. Eventually consistent reads (GSIs do not support strongly consistent reads)
   3. Transactional reads
   4. Multi-Region strong consistency
4. A financial application requires strong consistency across multiple AWS Regions with zero data loss (RPO = 0). Which DynamoDB feature should they use?
   1. DynamoDB Global Tables with MREC (eventual consistency)
   2. DynamoDB Global Tables with MRSC (multi-Region strong consistency)
   3. DynamoDB with strongly consistent reads
   4. DynamoDB transactions
5. A developer needs to update multiple items across two DynamoDB tables atomically. Which feature should they use?
   1. Strongly consistent writes
   2. BatchWriteItem operation
   3. DynamoDB transactions (TransactWriteItems)
   4. Conditional writes
6. What is the cost difference between eventually consistent reads and strongly consistent reads in DynamoDB?
   1. No difference in cost
   2. Strongly consistent reads cost 2x more (consume 2x RCU)
   3. Strongly consistent reads cost 3x more
   4. Eventually consistent reads cost 2x more
7. Which of the following statements about DynamoDB consistency are correct? (Select TWO)
   1. Eventually consistent reads are the default for Query and GetItem operations.
   2. Strongly consistent reads are supported on Global Secondary Indexes.
   3. Strongly consistent reads may return HTTP 500 errors during network issues.
   4. Transactions provide ACID guarantees across multiple Regions.
   5. MRSC Global Tables support local secondary indexes.

References

• Read consistency in DynamoDB
• Multi-Region strong consistency
• Build the highest resilience apps with multi-Region strong consistency
• DynamoDB transactions