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.
• DynamoDB Stream tracks the delete operation as a system delete, not a regular one.

How TTL Works

• TTL allows defining a per-item expiration timestamp that indicates when an item is no longer needed.
• DynamoDB automatically deletes expired items within a few days of their expiration time, without consuming write throughput.
• Deletion Timeline: DynamoDB typically deletes expired items within two days (48 hours) of expiration.
  • The exact duration depends on the workload nature and table size.
  • Deletion rate is proportional to the total number of TTL-expired items.
• Items pending deletion: Expired items that haven’t been deleted yet will still appear in reads, queries, and scans.
  • Use filter expressions to remove expired items from Scan and Query results.
  • Expired items can still be updated, including changing or removing their TTL attributes.
  • When updating expired items, use a condition expression to ensure the item hasn’t been subsequently deleted.
• TTL process runs in the background as a low-priority task to avoid impacting table performance.
• TTL deletions do not consume Write Capacity Units (WCU) in provisioned mode or Write Request Units in on-demand mode.

TTL Requirements and Limitations

• Data Type: TTL attributes must use the Number data type. Other data types, such as String, are not supported.
• Time Format: TTL attributes must use the Unix epoch time format (seconds since January 1, 1970, 00:00:00 UTC).
  • Be sure that the timestamp is in seconds, not milliseconds.
  • Items with TTL attributes that are not a Number type are ignored by the TTL process.
• Five-Year Past Limitation: To be considered for expiry and deletion, the TTL timestamp cannot be more than five years in the past.
  • This prevents accidental deletion of historical data with very old timestamps.
  • Items with TTL values older than five years in the past are ignored by the TTL process.
• Future Expiration: No limit on how far in the future the TTL timestamp can be set.
• Attribute Selection: Only one attribute per table can be designated as the TTL attribute.

TTL with Global Tables

• When using Global Tables version 2019.11.21 (Current), DynamoDB replicates TTL deletes to all replica tables.
• Write Capacity Consumption:
  • The initial TTL delete does not consume WCU in the region where the TTL expiry occurs.
  • The replicated TTL delete to replica table(s) consumes a replicated Write Capacity Unit (provisioned mode) or Replicated Write Unit (on-demand mode) in each replica region.
  • Applicable charges apply for replicated TTL deletes.

TTL and DynamoDB Streams

• Deleted items are sent to DynamoDB Streams as system deletions (not user deletions).
• Stream records for TTL deletions include a special attribute to identify them as TTL-triggered deletions.
• Can be used to trigger downstream actions via AWS Lambda, such as:
  • Archiving expired items to S3 or Amazon S3 Glacier.
  • Sending notifications when items expire.
  • Maintaining audit logs of deleted items.

Common Use Cases

• TTL is useful if the stored items lose relevance after a specific time. For example:
  • Session Management: Remove user session data after inactivity period (e.g., 30 days).
  • IoT and Sensor Data: Remove sensor data after a year of inactivity.
  • Temporary Data: Delete temporary records like shopping carts, draft documents, or cache entries.
  • Compliance and Data Retention: Retain sensitive data for a certain amount of time according to contractual or regulatory obligations (e.g., GDPR, HIPAA).
  • Event Data: Remove event logs, audit trails, or metrics after a retention period.
  • Archive to S3: Archive expired items to an S3 data lake via DynamoDB Streams and AWS Lambda before deletion.

Best Practices

• Calculate TTL on Write: Compute the expiration timestamp when creating or updating items.
  • For new items: TTL = createdAt + retention_period
  • For updated items: TTL = updatedAt + retention_period
• Use Filter Expressions: Filter out expired items in application queries to avoid processing items pending deletion.
• Archive Before Deletion: Use DynamoDB Streams with Lambda to archive important data to S3 before TTL deletion.
• Monitor TTL Deletions: Track TTL deletion metrics using CloudWatch to ensure the deletion rate meets expectations.
• Test TTL Behavior: Use the TTL preview feature in the DynamoDB console to simulate deletions before enabling TTL.
• Avoid Very Old Timestamps: Ensure TTL values are not more than five years in the past to prevent them from being ignored.
• Consider Global Table Costs: Account for replicated write costs when using TTL with Global Tables.

Enabling TTL

• TTL can be enabled on a table through:
  • AWS Management Console
  • AWS CLI
  • AWS SDKs
  • AWS CloudFormation
• Specify the attribute name that will store the TTL timestamp.
• TTL can be enabled or disabled at any time without impacting table performance.
• Changing the TTL attribute requires disabling TTL first, then re-enabling with the new attribute.

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 IoT sensor data in a DynamoDB table. The data must be retained for 90 days for analysis and then automatically deleted. The solution must minimize costs. What should a solutions architect recommend?
   1. Create a Lambda function to scan and delete items older than 90 days, triggered daily by EventBridge.
   2. Enable TTL on the DynamoDB table with an expiration attribute set to 90 days from the item creation time.
   3. Use DynamoDB Streams with Lambda to move data to S3 Glacier after 90 days and delete from DynamoDB.
   4. Create a scheduled AWS Batch job to delete items older than 90 days.
3. A DynamoDB table has TTL enabled. A developer notices that some items with expired TTL timestamps are still appearing in query results. What is the MOST likely explanation?
   1. TTL is not working correctly and needs to be disabled and re-enabled.
   2. The TTL attribute is using the wrong data type.
   3. Items are expired but have not yet been deleted by the background TTL process, which can take up to 48 hours.
   4. The TTL timestamp is more than five years in the past.
4. A company uses DynamoDB Global Tables across three regions. TTL is enabled on the table. How are write capacity units consumed for TTL deletions?
   1. TTL deletions consume WCU in all regions including the region where expiration occurs.
   2. TTL deletions do not consume WCU in the region where expiration occurs, but consume replicated write units in replica regions.
   3. TTL deletions do not consume any WCU in any region.
   4. TTL deletions consume double WCU in the region where expiration occurs.
5. What is the correct format for a DynamoDB TTL attribute value to expire an item on January 1, 2027, at 00:00:00 UTC?
   1. 2027-01-01T00:00:00Z (ISO 8601 format)
   2. 1735689600000 (milliseconds since epoch)
   3. 1735689600 (seconds since epoch)
   4. “1735689600” (string representation of seconds)
6. A company wants to archive expired DynamoDB items to S3 before they are deleted by TTL. What is the BEST approach?
   1. Create a Lambda function that scans the table for expired items and copies them to S3 before TTL deletes them.
   2. Enable DynamoDB Streams and use a Lambda function to detect TTL deletions and archive items to S3.
   3. Disable TTL and use a scheduled Lambda function to manually delete items after archiving to S3.
   4. Use AWS Backup to automatically archive items before TTL deletion.
7. Which of the following statements about DynamoDB TTL are correct? (Select TWO)
   1. TTL deletions consume write capacity units in the source region.
   2. TTL timestamps must be in Unix epoch time format in seconds.
   3. TTL can use String data type for the expiration attribute.
   4. TTL timestamps cannot be more than five years in the past to be considered for deletion.
   5. TTL guarantees deletion within exactly 48 hours of expiration.

References

• Using time to live (TTL) in DynamoDB
• Computing time to live (TTL) in DynamoDB
• Enable time to live (TTL) in DynamoDB
• Working with expired items and time to live (TTL)

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