AWS DynamoDB

AWS DynamoDB

  • Amazon DynamoDB is a fully managed, serverless NoSQL database service that
    • makes it simple and cost-effective to store and retrieve any amount of data and serve any level of request traffic.
    • provides fast and predictable performance with seamless scalability
    • offers single-digit millisecond performance at any scale
  • DynamoDB enables customers to offload the administrative burdens of operating and scaling distributed databases to AWS, without having to worry about hardware provisioning, setup and configuration, replication, software patching, or cluster scaling.
  • DynamoDB offers zero infrastructure management, zero downtime maintenance, instant scaling to any application demand, and pay-per-request billing. There are no cold starts, no version upgrades, and no maintenance windows.
  • DynamoDB tables do not have fixed schemas, and the table consists of items and each item may have a different number of attributes.
  • DynamoDB synchronously replicates data across three facilities in an AWS Region, giving high availability and data durability.
  • DynamoDB supports fast in-place updates. A numeric attribute can be incremented or decremented in a row using a single API call.
  • DynamoDB uses proven cryptographic methods to securely authenticate users and prevent unauthorized data access.
  • Durability, performance, reliability, and security are built in, with SSD (solid state drive) storage and automatic 3-way replication.
  • DynamoDB supports two different kinds of primary keys:
    • Partition Key (previously called the Hash key)
      • A simple primary key, composed of one attribute
      • The partition key value is used as input to an internal hash function; the output from the hash function determines the partition where the item will be stored.
      • No two items in a table can have the same partition key value.
    • Partition Key and Sort Key (previously called the Hash and Range key)
      • A composite primary key is composed of two attributes. The first attribute is the partition key, and the second attribute is the sort key.
      • The partition key value is used as input to an internal hash function; the output from the hash function determines the partition where the item will be stored.
      • All items with the same partition key are stored together, in sorted order by sort key value.
      • The combination of the partition key and sort key must be unique.
      • It is possible for two items to have the same partition key value, but those two items must have different sort key values.
  • DynamoDB Table classes currently support
    • DynamoDB Standard table class is the default and is recommended for the vast majority of workloads.
    • DynamoDB Standard-Infrequent Access (DynamoDB Standard-IA) table class which is optimized for tables where storage is the dominant cost.
  • DynamoDB Throughput Capacity determines the read/write capacity for processing reads and writes on the tables and it currently supports
    • Provisioned – maximum amount of capacity in terms of reads/writes per second that an application can consume from a table or index
    • On-demand – serves thousands of requests per second without capacity planning.
  • DynamoDB Secondary indexes
    • add flexibility to the queries, without impacting performance.
    • are automatically maintained as sparse objects, items will only appear in an index if they exist in the table on which the index is defined making queries against an index very efficient
  • DynamoDB throughput and single-digit millisecond latency make it a great fit for gaming, ad tech, mobile, and many other applications
  • ElastiCache or DAX can be used in front of DynamoDB in order to offload a high amount of reads for non-frequently changed data

DynamoDB Consistency

  • Each DynamoDB table is automatically stored in the three geographically distributed locations for durability.
  • Read 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 allows the user to specify whether the read should be eventually consistent or strongly consistent at the time of the request
    • 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.
    • Strongly Consistent Reads
      • Strongly consistent read returns a result that reflects all writes that received a successful response prior to the read
      • Strongly consistent reads are 2x the cost of Eventually consistent reads
      • Strongly Consistent Reads come with 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.
        • Strongly consistent reads are not supported on global secondary indexes.
        • Strongly consistent reads use more throughput capacity than eventually consistent reads.
  • Read operations (such as GetItem, Query, and Scan) provide a ConsistentRead parameter, if set to true, DynamoDB uses strongly consistent reads during the operation.
  • Query, GetItem, and BatchGetItem operations perform eventually consistent reads by default.
    • Query and GetItem operations can be forced to be strongly consistent
    • Query operations cannot perform strongly consistent reads on Global Secondary Indexes
    • BatchGetItem operations can be forced to be strongly consistent on a per-table basis

DynamoDB Throughput Capacity

  • DynamoDB throughput capacity depends on the read/write capacity modes for processing reads and writes on the tables.
  • DynamoDB supports two types of read/write capacity modes:
    • Provisioned – maximum amount of capacity in terms of reads/writes per second that an application can consume from a table or index
    • On-demand – serves thousands of requests per second without capacity planning.
  • DynamoDB Auto Scaling helps dynamically adjust provisioned throughput capacity on your behalf, in response to actual traffic patterns.
  • DynamoDB Adaptive capacity is a feature that enables DynamoDB to run imbalanced workloads indefinitely.

Warm Throughput (November 2024)

  • Warm throughput provides visibility into the number of read and write operations a DynamoDB table or index can immediately support.
  • Warm throughput values grow automatically as usage increases over time.
  • Pre-warming allows proactively setting higher warm throughput values to meet anticipated future traffic demands.
  • Warm throughput values are available for all provisioned and on-demand tables and indexes at no cost.
  • Pre-warming incurs an additional charge based on the DynamoDB pricing page.
  • Useful for planned events like product launches, sales events, or traffic migrations where a sudden spike is expected.

Configurable Maximum Throughput for On-Demand (May 2024)

  • Allows optionally configuring maximum read or write (or both) throughput for individual on-demand DynamoDB tables and associated secondary indexes.
  • Throughput requests exceeding the configured maximum are automatically throttled.
  • Simplifies balancing cost and performance for on-demand mode.
  • Protects against accidental surges in consumed resources and excessive use.
  • Safeguards downstream services with fixed capacity from potential overloading.
  • Maximum throughput can be modified at any time based on application requirements.

DynamoDB Secondary Indexes

  • DynamoDB Secondary indexes
    • add flexibility to the queries, without impacting performance.
    • are automatically maintained as sparse objects, items will only appear in an index if they exist in the table on which the index is defined making queries against an index very efficient
  • DynamoDB Secondary indexes on a table allow efficient access to data with attributes other than the primary key.
  • DynamoDB Secondary indexes support two types

Multi-Attribute Composite Keys in GSIs (November 2025)

  • DynamoDB now supports primary keys composed of up to eight attributes in Global Secondary Indexes (GSIs).
  • Allows up to four attributes each for the partition key and sort key in a GSI.
  • Previously, partition and sort keys were limited to one attribute each.
  • Enables querying data at scale across multiple dimensions without client-side composite key construction.
  • Reduces client-side code and makes it easier to initially model data and add new access patterns later.
  • Each index key attribute must be a scalar of type String, Number, or Binary.
  • Base table primary keys still use the traditional structure (single partition key + optional single sort key).

DynamoDB Secondary Indexes - GSI vs LSI

DynamoDB Advanced Topics

  • DynamoDB Secondary indexes on a table allow efficient access to data with attributes other than the primary key.
  • DynamoDB Time to Live – TTL enables a per-item timestamp to determine when an item is no longer needed.
  • DynamoDB cross-region replication allows identical copies (called replicas) of a DynamoDB table (called master table) to be maintained in one or more AWS regions.
  • DynamoDB Global Tables is a fully managed, serverless, multi-Region, and multi-active database that provides up to 99.999% availability.
  • DynamoDB Streams provides a time-ordered sequence of item-level changes made to data in a table.
  • DynamoDB Triggers (just like database triggers) are a feature that allows the execution of custom actions based on item-level updates on a table.
  • DynamoDB Accelerator – DAX is a fully managed, highly available, in-memory cache for DynamoDB that delivers up to a 10x performance improvement – from ms to µs – even at millions of requests per second.
  • VPC Gateway Endpoints provide private access to DynamoDB from within a VPC without the need for an internet gateway or NAT gateway.
  • AWS PrivateLink (Interface Endpoints) – DynamoDB also supports interface VPC endpoints via AWS PrivateLink, enabling private connectivity from on-premises workloads using Direct Connect or VPN without requiring an internet gateway.

DynamoDB Global Tables

  • DynamoDB Global Tables is a fully managed, serverless, multi-Region, and multi-active database.
  • Provides up to 99.999% availability and increased application resiliency.
  • Automatically replicates tables across selected AWS Regions for fast, local read and write performance.
  • Supports two versions:
    • Version 2019.11.21 (Current) – recommended version with latest features
    • Version 2017.11.29 (Legacy) – original version, AWS recommends upgrading to current version

Multi-Region Strong Consistency (MRSC) – GA June 2025

  • DynamoDB Global Tables now supports Multi-Region Strong Consistency (MRSC), enabling zero Recovery Point Objective (RPO).
  • Ensures applications can consistently read the latest data version from any Region in a global table.
  • Eliminates the need for manual cross-Region consistency management.
  • Particularly beneficial for:
    • User profile management
    • Inventory tracking
    • Financial transaction processing
    • Any application with strict consistency requirements
  • Supports application resiliency testing with AWS Fault Injection Service (FIS).
  • Previously, Global Tables only supported eventual consistency across Regions.

DynamoDB Zero-ETL Integrations

  • DynamoDB offers zero-ETL integrations that automatically replicate data to analytics services without building complex ETL pipelines.

Zero-ETL with Amazon Redshift (GA October 2024)

  • Enables seamless analytics on DynamoDB data without impacting production workloads.
  • Data written to DynamoDB becomes immediately available in Amazon Redshift.
  • Allows using Amazon Redshift capabilities: high-performance SQL, built-in ML, Spark integrations, and data sharing.
  • Supports Redshift Serverless workgroups and provisioned clusters using RA3 instance types.
  • Eliminates the need to build and maintain custom ETL pipelines.

Zero-ETL with Amazon OpenSearch Service

  • Provides a fully managed, no-code solution for ingesting data from DynamoDB into OpenSearch Service.
  • Uses the DynamoDB plugin for Amazon OpenSearch Ingestion.
  • Enables near real-time analytics, full-text search, and vector search on DynamoDB data.
  • Supports complex search queries and analytics capabilities not natively available in DynamoDB.

Zero-ETL with Amazon SageMaker Lakehouse (December 2024)

  • Automates extracting and loading data from DynamoDB into SageMaker Lakehouse.
  • Enables analytics and machine learning (ML) workloads on DynamoDB data.
  • SageMaker Lakehouse provides integrated access control and open source Apache Iceberg for data interoperability.

DynamoDB S3 Import and Export

  • DynamoDB supports import and export features to easily move, transform, and copy table data.
  • Export to S3
    • Exports data to S3 without consuming read capacity units (RCUs).
    • Leverages Point-in-Time Recovery (PITR) capability.
    • Supports both full exports and incremental exports (only changed data between two time points).
    • Supports DynamoDB JSON and Amazon Ion formats.
  • Import from S3
    • Allows bulk importing S3 data into a new DynamoDB table.
    • Supports up to 50,000 S3 objects in a single bulk import (increased from previous limits in March 2024).
    • Supports DynamoDB JSON, Amazon Ion, and CSV formats.
  • Incremental exports enable change data capture (CDC) pipelines more efficiently and cost-effectively.

DynamoDB Performance

  • Automatically scales horizontally
  • runs exclusively on Solid State Drives (SSDs).
    • SSDs help achieve the design goals of predictable low-latency response times for storing and accessing data at any scale.
    • SSDs High I/O performance enables them to serve high-scale request workloads cost-efficiently and to pass this efficiency along in low request pricing.
  • allows provisioned table reads and writes
    • Scale up throughput when needed
    • Scale down throughput four times per UTC calendar day
  • automatically partitions, reallocates and re-partitions the data and provisions additional server capacity as the
    • table size grows or
    • provisioned throughput is increased
  • Global Secondary indexes (GSI)
    • can be created upfront or added later
  • Supports IPv6 addressing (October 2025), allowing connections to DynamoDB tables, streams, and DAX in IPv4-only, IPv6-only, or dual-stack networking modes.

DynamoDB Security

  • AWS handles basic security tasks like guest operating system (OS) and database patching, firewall configuration, and disaster recovery.
  • DynamoDB protects user data stored at rest and in transit between on-premises clients and DynamoDB, and between DynamoDB and other AWS resources within the same AWS Region.
  • Encryption at rest is enabled on all DynamoDB table data and cannot be disabled.
  • Encryption at rest includes the base tables, primary key, local and global secondary indexes, streams, global tables, backups, and DynamoDB Accelerator (DAX) clusters.
  • Fine-Grained Access Control (FGAC) gives a high degree of control over data in the table and helps control who (caller) can access which items or attributes of the table and perform what actions (read/write capability).
  • Resource-Based Policies (March 2024)
    • Allow specifying IAM principals and their allowed actions on tables, streams, and indexes.
    • Simplify cross-account access control without needing to configure IAM roles in each account.
    • Integrate with AWS IAM Access Analyzer and Block Public Access capabilities.
    • Available at no additional cost.
  • Attribute-Based Access Control – ABAC (November 2024)
    • DynamoDB supports ABAC for tables and indexes.
    • Uses tag-based conditions in IAM policies to allow or deny specific actions based on IAM principals’ tags matching table/index tags.
    • Automatically applies tag-based permissions to new employees and changing resource structures without rewriting policies.
    • Provides more granular access permissions based on organizational structures.
  • AWS PrivateLink (March 2024)
    • DynamoDB supports interface VPC endpoints via AWS PrivateLink for private network connectivity.
    • Eliminates the need to use public IP addresses, configure firewall rules, or set up an internet gateway.
    • Compatible with Direct Connect and AWS VPN for end-to-end private network connectivity from on-premises.
    • Available in addition to VPC Gateway Endpoints.
  • VPC Endpoints allow private connectivity from within a VPC only to DynamoDB.
  • DynamoDB supports FIPS 140-3 compliant interface VPC and Streams endpoints in US and Canada Regions (December 2024).

Refer blog post @ DynamoDB Security

DynamoDB Costs

  • Index Storage
    • DynamoDB is an indexed data store
      • Billable Data = Raw byte data size + 100 byte per-item storage indexing overhead
  • Provisioned throughput
    • Pay flat, hourly rate based on the capacity reserved as the throughput provisioned for the table
    • one Write Capacity Unit provides one write per second for items < 1KB in size.
    • one Read Capacity Unit provides one strongly consistent read (or two eventually consistent reads) per second for items < 4KB in size.
    • Provisioned throughput charges for every 10 units of Write Capacity and every 50 units of Read Capacity.
  • On-demand throughput
    • Pay per read/write request consumed with no minimum capacity required.
    • Effective November 1, 2024, DynamoDB reduced on-demand throughput prices by 50%.
    • Makes on-demand mode significantly more cost-effective for variable workloads.
  • Reserved capacity
    • Significant savings over the normal price
    • Pay a one-time upfront fee
    • Available for 1-year or 3-year terms
    • AWS Cost Explorer now provides purchase recommendations for DynamoDB reserved capacity.
  • Global Tables
    • Effective November 1, 2024, DynamoDB reduced global tables pricing by up to 67% for on-demand and 33% for provisioned capacity.
    • Replicated write capacity units (rWCU/rWRU) are now priced identically to standard single-region writes.
  • DynamoDB also charges for storage, backup, replication, streams, caching, data transfer out, and S3 exports.

DynamoDB Best Practices

Refer blog post @ DynamoDB Best Practices

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 are use cases for Amazon DynamoDB? Choose 3 answers
    1. Storing BLOB data.
    2. Managing web sessions
    3. Storing JSON documents
    4. Storing metadata for Amazon S3 objects
    5. Running relational joins and complex updates.
    6. Storing large amounts of infrequently accessed data.
  2. You are configuring your company’s application to use Auto Scaling and need to move user state information. Which of the following AWS services provides a shared data store with durability and low latency?
    1. AWS ElastiCache Memcached (does not allow writes)
    2. Amazon Simple Storage Service (does not provide low latency)
    3. Amazon EC2 instance storage (not durable)
    4. Amazon DynamoDB
  3. Does Dynamo DB support in-place atomic updates?
    1. It is not defined
    2. No
    3. Yes
    4. It does support in-place non-atomic updates
  4. What is the maximum write throughput I can provision for a single Dynamic DB table?
    1. 1,000 write capacity units
    2. 100,000 write capacity units
    3. Dynamic DB is designed to scale without limits, but if you go beyond 10,000 you have to contact AWS first
    4. 10,000 write capacity units
  5. For a DynamoDB table, what happens if the application performs more reads or writes than your provisioned capacity?
    1. Nothing
    2. requests above the provisioned capacity will be performed but you will receive 400 error codes.
    3. requests above the provisioned capacity will be performed but you will receive 200 error codes.
    4. requests above the provisioned capacity will be throttled and you will receive 400 error codes.
  6. In which of the following situations might you benefit from using DynamoDB? (Choose 2 answers)
    1. You need fully managed database to handle highly complex queries
    2. You need to deal with massive amount of “hot” data and require very low latency
    3. You need a rapid ingestion of clickstream in order to collect data about user behavior
    4. Your on-premises data center runs Oracle database, and you need to host a backup in AWS cloud
  7. You are designing a file-sharing service. This service will have millions of files in it. Revenue for the service will come from fees based on how much storage a user is using. You also want to store metadata on each file, such as title, description and whether the object is public or private. How do you achieve all of these goals in a way that is economical and can scale to millions of users? [PROFESSIONAL]
    1. Store all files in Amazon Simple Storage Service (S3). Create a bucket for each user. Store metadata in the filename of each object, and access it with LIST commands against the S3 API. (expensive and slow as it returns only 1000 items at a time)
    2. Store all files in Amazon S3. Create Amazon DynamoDB tables for the corresponding key-value pairs on the associated metadata, when objects are uploaded.
    3. Create a striped set of 4000 IOPS Elastic Load Balancing volumes to store the data. Use a database running in Amazon Relational Database Service (RDS) to store the metadata.(not economical with volumes)
    4. Create a striped set of 4000 IOPS Elastic Load Balancing volumes to store the data. Create Amazon DynamoDB tables for the corresponding key-value pairs on the associated metadata, when objects are uploaded. (not economical with volumes)
  8. A utility company is building an application that stores data coming from more than 10,000 sensors. Each sensor has a unique ID and will send a datapoint (approximately 1KB) every 10 minutes throughout the day. Each datapoint contains the information coming from the sensor as well as a timestamp. This company would like to query information coming from a particular sensor for the past week very rapidly and want to delete all the data that is older than 4 weeks. Using Amazon DynamoDB for its scalability and rapidity, how do you implement this in the most cost effective way? [PROFESSIONAL]
    1. One table, with a primary key that is the sensor ID and a hash key that is the timestamp (Single table impacts performance)
    2. One table, with a primary key that is the concatenation of the sensor ID and timestamp (Single table and concatenation impacts performance)
    3. One table for each week, with a primary key that is the concatenation of the sensor ID and timestamp (Concatenation will cause queries would be slower, if at all)
    4. One table for each week, with a primary key that is the sensor ID and a hash key that is the timestamp (Composite key with Sensor ID and timestamp would help for faster queries)
  9. You have recently joined a startup company building sensors to measure street noise and air quality in urban areas. The company has been running a pilot deployment of around 100 sensors for 3 months. Each sensor uploads 1KB of sensor data every minute to a backend hosted on AWS. During the pilot, you measured a peak of 10 IOPS on the database, and you stored an average of 3GB of sensor data per month in the database. The current deployment consists of a load-balanced auto scaled Ingestion layer using EC2 instances and a PostgreSQL RDS database with 500GB standard storage. The pilot is considered a success and your CEO has managed to get the attention or some potential investors. The business plan requires a deployment of at least 100K sensors, which needs to be supported by the backend. You also need to store sensor data for at least two years to be able to compare year over year Improvements. To secure funding, you have to make sure that the platform meets these requirements and leaves room for further scaling. Which setup will meet the requirements? [PROFESSIONAL]
    1. Add an SQS queue to the ingestion layer to buffer writes to the RDS instance (RDS instance will not support data for 2 years)
    2. Ingest data into a DynamoDB table and move old data to a Redshift cluster (Handle 10K IOPS ingestion and store data into Redshift for analysis. Note: DynamoDB zero-ETL integration with Redshift (GA 2024) can now simplify this architecture.)
    3. Replace the RDS instance with a 6 node Redshift cluster with 96TB of storage (Does not handle the ingestion issue)
    4. Keep the current architecture but upgrade RDS storage to 3TB and 10K provisioned IOPS (RDS instance will not support data for 2 years)
  10. Does Amazon DynamoDB support both increment and decrement atomic operations?
    1. No, neither increment nor decrement operations.
    2. Only increment, since decrement are inherently impossible with DynamoDB’s data model.
    3. Only decrement, since increment are inherently impossible with DynamoDB’s data model.
    4. Yes, both increment and decrement operations.
  11. What is the data model of DynamoDB?
    1. “Items”, with Keys and one or more Attribute; and “Attribute”, with Name and Value.
    2. “Database”, which is a set of “Tables”, which is a set of “Items”, which is a set of “Attributes”.
    3. “Table”, a collection of Items; “Items”, with Keys and one or more Attribute; and “Attribute”, with Name and Value.
    4. “Database”, a collection of Tables; “Tables”, with Keys and one or more Attribute; and “Attribute”, with Name and Value.
  12. In regard to DynamoDB, for which one of the following parameters does Amazon not charge you?
    1. Cost per provisioned write units
    2. Cost per provisioned read units
    3. Storage cost
    4. I/O usage within the same Region
  13. Which statements about DynamoDB are true? Choose 2 answers.
    1. DynamoDB uses a pessimistic locking model
    2. DynamoDB uses optimistic concurrency control
    3. DynamoDB uses conditional writes for consistency
    4. DynamoDB restricts item access during reads
    5. DynamoDB restricts item access during writes
  14. Which of the following is an example of a good DynamoDB hash key schema for provisioned throughput efficiency?
    1. User ID, where the application has many different users.
    2. Status Code where most status codes is the same.
    3. Device ID, where one is by far more popular than all the others.
    4. Game Type, where there are three possible game types.
  15. You are inserting 1000 new items every second in a DynamoDB table. Once an hour these items are analyzed and then are no longer needed. You need to minimize provisioned throughput, storage, and API calls. Given these requirements, what is the most efficient way to manage these Items after the analysis?
    1. Retain the items in a single table
    2. Delete items individually over a 24 hour period
    3. Delete the table and create a new table per hour
    4. Create a new table per hour
  16. When using a large Scan operation in DynamoDB, what technique can be used to minimize the impact of a scan on a table’s provisioned throughput?
    1. Set a smaller page size for the scan (Refer link)
    2. Use parallel scans
    3. Define a range index on the table
    4. Prewarm the table by updating all items
  17. In regard to DynamoDB, which of the following statements is correct?
    1. An Item should have at least two value sets, a primary key and another attribute.
    2. An Item can have more than one attributes
    3. A primary key should be single-valued.
    4. An attribute can have one or several other attributes.
  18. Which one of the following statements is NOT an advantage of DynamoDB being built on Solid State Drives?
    1. serve high-scale request workloads
    2. low request pricing
    3. high I/O performance of WebApp on EC2 instance (Not related to DynamoDB)
    4. low-latency response times
  19. Which one of the following operations is NOT a DynamoDB operation?
    1. BatchWriteItem
    2. DescribeTable
    3. BatchGetItem
    4. BatchDeleteItem (DeleteItem deletes a single item in a table by primary key, but BatchDeleteItem doesn’t exist)
  20. What item operation allows the retrieval of multiple items from a DynamoDB table in a single API call?
    1. GetItem
    2. BatchGetItem
    3. GetMultipleItems
    4. GetItemRange
  21. An application stores payroll information nightly in DynamoDB for a large number of employees across hundreds of offices. Item attributes consist of individual name, office identifier, and cumulative daily hours. Managers run reports for ranges of names working in their office. One query is. “Return all Items in this office for names starting with A through E”. Which table configuration will result in the lowest impact on provisioned throughput for this query? [PROFESSIONAL]
    1. Configure the table to have a hash index on the name attribute, and a range index on the office identifier
    2. Configure the table to have a range index on the name attribute, and a hash index on the office identifier
    3. Configure a hash index on the name attribute and no range index
    4. Configure a hash index on the office Identifier attribute and no range index
  22. You need to migrate 10 million records in one hour into DynamoDB. All records are 1.5KB in size. The data is evenly distributed across the partition key. How many write capacity units should you provision during this batch load?
    1. 6667
    2. 4166
    3. 5556 ( 2 write units (1 for each 1KB) * 10 million/3600 secs, refer link)
    4. 2778
  23. A meteorological system monitors 600 temperature gauges, obtaining temperature samples every minute and saving each sample to a DynamoDB table. Each sample involves writing 1K of data and the writes are evenly distributed over time. How much write throughput is required for the target table?
    1. 1 write capacity unit
    2. 10 write capacity units ( 1 write unit for 1K * 600 gauges/60 secs)
    3. 60 write capacity units
    4. 600 write capacity units
    5. 3600 write capacity units
  24. You are building a game high score table in DynamoDB. You will store each user’s highest score for each game, with many games, all of which have relatively similar usage levels and numbers of players. You need to be able to look up the highest score for any game. What’s the best DynamoDB key structure?
    1. HighestScore as the hash / only key.
    2. GameID as the hash key, HighestScore as the range key. (hash (partition) key should be the GameID, and there should be a range key for ordering HighestScore. Refer link)
    3. GameID as the hash / only key.
    4. GameID as the range / only key.
  25. You are experiencing performance issues writing to a DynamoDB table. Your system tracks high scores for video games on a marketplace. Your most popular game experiences all of the performance issues. What is the most likely problem?
    1. DynamoDB’s vector clock is out of sync, because of the rapid growth in request for the most popular game.
    2. You selected the Game ID or equivalent identifier as the primary partition key for the table. (Refer link)
    3. Users of the most popular video game each perform more read and write requests than average.
    4. You did not provision enough read or write throughput to the table.
  26. You are writing to a DynamoDB table and receive the following exception:” ProvisionedThroughputExceededException”. Though according to your Cloudwatch metrics for the table, you are not exceeding your provisioned throughput. What could be an explanation for this?
    1. You haven’t provisioned enough DynamoDB storage instances
    2. You’re exceeding your capacity on a particular Range Key
    3. You’re exceeding your capacity on a particular Hash Key (Hash key determines the partition and hence the performance)
    4. You’re exceeding your capacity on a particular Sort Key
    5. You haven’t configured DynamoDB Auto Scaling triggers
  27. Your company sells consumer devices and needs to record the first activation of all sold devices. Devices are not activated until the information is written on a persistent database. Activation data is very important for your company and must be analyzed daily with a MapReduce job. The execution time of the data analysis process must be less than three hours per day. Devices are usually sold evenly during the year, but when a new device model is out, there is a predictable peak in activation’s, that is, for a few days there are 10 times or even 100 times more activation’s than in average day. Which of the following databases and analysis framework would you implement to better optimize costs and performance for this workload? [PROFESSIONAL]
    1. Amazon RDS and Amazon Elastic MapReduce with Spot instances.
    2. Amazon DynamoDB and Amazon Elastic MapReduce with Spot instances.
    3. Amazon RDS and Amazon Elastic MapReduce with Reserved instances.
    4. Amazon DynamoDB and Amazon Elastic MapReduce with Reserved instances
  28. A company needs to analyze DynamoDB transactional data in near real-time using SQL queries and generate business intelligence dashboards. Which solution requires the LEAST operational overhead?
    1. Use DynamoDB Streams with AWS Lambda to write data to Amazon RDS for analytics.
    2. Export DynamoDB data to S3 and use Amazon Athena for querying.
    3. Use DynamoDB zero-ETL integration with Amazon Redshift and run SQL queries directly. (Zero-ETL integration (GA Oct 2024) automatically replicates data without building custom ETL pipelines)
    4. Set up an AWS Glue ETL job to copy data from DynamoDB to Amazon Redshift on a schedule.
  29. A global e-commerce application uses DynamoDB global tables with replicas in US, Europe, and Asia. The application requires that all users always read the most recent data regardless of which Region they connect to. Which DynamoDB capability supports this requirement?
    1. Enable strongly consistent reads on the global table.
    2. Use DynamoDB Streams to synchronize data between Regions.
    3. Enable Multi-Region Strong Consistency (MRSC) on the global table. (MRSC (GA June 2025) ensures applications always read the latest data from any Region, providing zero RPO)
    4. Implement a custom conflict resolution strategy using Lambda triggers.
  30. A team wants to control costs for their DynamoDB on-demand table by preventing accidental traffic spikes from consuming excessive throughput. Which feature should they use?
    1. Switch to provisioned mode with Auto Scaling.
    2. Configure maximum throughput limits on the on-demand table. (Configurable maximum throughput (May 2024) allows setting max read/write throughput on on-demand tables)
    3. Use DynamoDB Accelerator (DAX) to absorb traffic spikes.
    4. Enable adaptive capacity for the table.
  31. A company wants to grant a partner organization’s AWS account access to specific DynamoDB tables without creating IAM roles in their own account. Which approach requires the LEAST configuration?
    1. Create an IAM role with a trust policy for the partner account.
    2. Set up AWS Organizations with shared access policies.
    3. Attach a resource-based policy to the DynamoDB table specifying the partner account as principal. (Resource-based policies (March 2024) simplify cross-account access without IAM role configuration)
    4. Use AWS RAM (Resource Access Manager) to share the table.
  32. An application team expects a major product launch will triple their DynamoDB table traffic within the first minute. They want to ensure the table can immediately handle the increased load. What should they do?
    1. Switch the table to on-demand mode the day before launch.
    2. Increase provisioned capacity to triple the current value.
    3. Pre-warm the table using DynamoDB warm throughput to set the expected read and write capacity. (Warm throughput (Nov 2024) allows pre-warming tables to handle anticipated traffic spikes immediately)
    4. Enable DynamoDB Auto Scaling with aggressive scaling policies.

References

AWS DynamoDB Secondary Indexes

DynamoDB Secondary Indexes - GSI vs LSI

AWS DynamoDB Secondary Indexes

  • DynamoDB provides fast access to items in a table by specifying primary key values
  • DynamoDB Secondary indexes on a table allow efficient access to data with attributes other than the primary key.
  • DynamoDB Secondary indexes
    • is a data structure that contains a subset of attributes from a table.
    • is associated with exactly one table, from which it obtains its data.
    • requires an alternate key for the index partition key and sort key.
    • additionally can define projected attributes that are copied from the base table into the index along with the primary key attributes.
    • is automatically maintained by DynamoDB.
    • indexes on that table are also updated for any addition, modification, or deletion of items in the base table.
    • helps reduce the size of the data as compared to the main table, depending upon the project attributes, and hence helps improve provisioned throughput performance
    • are automatically maintained as sparse objects. Items will only appear in an index if they exist in the table on which the index is defined, making queries an index very efficient
    • use the same table class and capacity mode (provisioned or on-demand) as the base table they are associated with.
  • DynamoDB Secondary indexes support two types
    • Global secondary index – an index with a partition key and a sort key that can be different from those on the base table.
    • Local secondary index – an index that has the same partition key as the base table, but a different sort key.
  • DynamoDB supports up to 20 global secondary indexes (default quota, can request increase) and up to 5 local secondary indexes per table.

Global Secondary Indexes – GSI

  • DynamoDB creates and maintains indexes for the primary key attributes for efficient access to data in the table, which allows applications to quickly retrieve data by specifying primary key values.
  • Global Secondary Indexes – GSI are indexes that contain partition or composite partition-and-sort keys that can be different from the keys in the table on which the index is based.
  • Global secondary index is considered “global” because queries on the index can span all items in a table, across all partitions.
  • Multiple secondary indexes can be created on a table, and queries issued against these indexes.
  • Applications benefit from having one or more secondary keys available to allow efficient access to data with attributes other than the primary key.
  • GSIs support non-unique attributes, which increases query flexibility by enabling queries against any non-key attribute in the table
  • GSIs support eventual consistency only. DynamoDB automatically handles item additions, updates, and deletes in a GSI when corresponding changes are made to the table asynchronously. Strongly consistent reads are NOT supported on GSIs.
  • Data in a secondary index consists of GSI alternate key, primary key and attributes that are projected, or copied, from the table into the index.
  • Attributes that are part of an item in a table, but not part of the GSI key, the primary key of the table, or projected attributes are not returned on querying the GSI index.
  • GSIs can be created at the same time as the table, or added to an existing table. GSIs can also be deleted from an existing table. However, you cannot modify an existing GSI — you must delete and recreate it.
  • GSIs inherit the read/write capacity mode from the base table.
    • Provisioned Mode: GSIs manage throughput independently of the table they are based on. The provisioned throughput for the table and each associated GSI needs to be specified at the creation time.
      • Read provisioned throughput
        • provides one Read Capacity Unit with two eventually consistent reads per second for items < 4KB in size.
      • Write provisioned throughput
        • consumes 1 write capacity unit if,
          • a new item is inserted into the table that defines an indexed attribute
          • existing item is deleted from the table
          • existing items are updated for projected attributes
        • consumes 2 write capacity units if
          • existing item is updated for key attributes, which results in deletion and addition of the new item into the index
    • On-Demand Mode: GSIs automatically scale with the table’s traffic. Configurable maximum throughput can optionally limit on-demand capacity for both tables and their associated secondary indexes.
  • Throttling on a GSI affects the base table depending on whether the throttling is for read or write activity:
    • When a GSI has insufficient read capacity, the base table isn’t affected.
    • When a GSI has insufficient write capacity, write operations won’t succeed on the base table or any of its GSIs (back-pressure).
  • GSIs use the same table class as the base table (DynamoDB Standard or DynamoDB Standard-IA). When the table class is updated, all associated GSIs are updated as well.

Multi-Attribute Composite Keys (November 2025)

  • GSIs now support multi-attribute composite keys, allowing partition keys and sort keys to be composed of multiple attributes.
  • Partition key can be composed of up to 4 attributes and sort key can be composed of up to 4 attributes, for a total of up to 8 attributes per key schema.
  • Eliminates the need to manually concatenate values into synthetic keys (e.g., no more “TOURNAMENT#WINTER2024#REGION#NA-EAST” patterns).
  • Multi-attribute partition keys improve data distribution and uniqueness.
  • Multi-attribute sort keys enable flexible querying by letting you specify conditions on sort key attributes from left to right (hierarchical querying).
  • When querying, all partition key attributes must be specified using equality conditions. Sort key attributes can be queried left-to-right; inequality conditions must be the last condition.
  • Each attribute in a multi-attribute key can have its own data type: String (S), Number (N), or Binary (B).
  • Multi-attribute keys work particularly well when creating GSIs on existing tables — no need to backfill synthetic keys across data.
  • Available at no additional charge in all AWS Regions where DynamoDB is available.
  • Note: The base table primary key still uses the traditional structure of a single partition key + optional single sort key. Multi-attribute keys are only for GSIs.

Warm Throughput (November 2024)

  • DynamoDB introduced warm throughput for tables and indexes, providing visibility into read and write operations a table or GSI can immediately support.
  • Warm throughput values grow automatically as usage increases.
  • Tables and GSIs can be pre-warmed by proactively setting higher warm throughput values to prepare for anticipated traffic spikes.
  • Warm throughput values are available for all provisioned and on-demand tables and indexes at no cost.
  • Pre-warming incurs a charge (see DynamoDB Pricing).
  • Default warm throughput for a GSI is 12,000 read units and 4,000 write units.

Local Secondary Indexes (LSI)

  • Local secondary indexes are indexes that have the same partition key as the table, but a different sort key.
  • Local secondary index is “local” cause every partition of a local secondary index is scoped to a table partition that has the same partition key.
  • LSI allows search using a secondary index in place of the sort key, thus expanding the number of attributes that can be used for queries that can be conducted efficiently
  • LSI is updated automatically when the primary index is updated and reads support strong, eventual, and transactional consistency options.
  • LSIs can only be queried via the Query API
  • LSIs cannot be added to existing tables — they can only be created at the same time as the table
  • LSIs cannot be modified once created
  • LSIs cannot be removed from a table once they are created
  • For tables with local secondary indexes, there is a 10 GB size limit per partition key value (item collection size limit). This includes all items in the base table and all items in the LSIs that have the same partition key value.
  • LSI consumes provisioned throughput capacity as part of the table with which it is associated
    • Read Provisioned throughput
      • if data read is indexed and projected attributes
        • provides one Read Capacity Unit with one strongly consistent read (or two eventually consistent reads) per second for items < 4KB
        • data size includes the index and projected attributes only
      • if data read is indexed and a non-projected attribute
        • consumes double the read capacity, with one to read from the index and one to read (fetch) from the table with the entire data and not just the non-projected attribute
    • Write provisioned throughput
      • consumes 1 write capacity unit if,
        • a new item is inserted into the table
        • existing item is deleted from the table
        • existing items are updated for projected attributes
      • consumes 2 write capacity units if
        • existing item is updated for key attributes, which results in deletion and addition of the new item into the index

Global Secondary Index vs Local Secondary Index

Characteristic Global Secondary Index (GSI) Local Secondary Index (LSI)
Key Schema Simple (partition key) or composite (partition + sort key). Supports multi-attribute composite keys (up to 4+4 attributes). Must be composite (partition key + sort key). Single attribute only.
Key Attributes Partition key and sort key can be any base table attributes of type String, Number, or Binary. Partition key must be same as base table. Sort key can be any base table attribute of type String, Number, or Binary.
Size Restrictions No size restrictions per partition key value. 10 GB limit per partition key value (item collection).
Online Index Operations Can be created with the table or added/deleted on an existing table. Can only be created at table creation time. Cannot be added, modified, or deleted later.
Queries and Partitions Queries span all items across all partitions (global). Queries scoped to a single partition key value (local).
Read Consistency Eventual consistency only. Supports both eventual and strong consistency.
Provisioned Throughput Has its own independent provisioned throughput settings. Queries consume from the index. Consumes read/write capacity from the base table.
Projected Attributes Can only request projected attributes. DynamoDB does NOT fetch from base table. Can request non-projected attributes. DynamoDB automatically fetches from base table (at higher cost).
Maximum Count Up to 20 per table (default quota, can request increase). Up to 5 per table.

DynamoDB Secondary Indexes - GSI vs LSI

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. In DynamoDB, a secondary index is a data structure that contains a subset of attributes from a table, along with an alternate key to support ____ operations.
    1. None of the above
    2. Both
    3. Query
    4. Scan
  2. In regard to DynamoDB, what is the Global secondary index?
    1. An index with a partition and sort key that can be different from those on the table
    2. An index that has the same sort key as the table, but a different partition key
    3. An index that has the same partition key and sort key as the table
    4. An index that has the same partition key as the table, but a different sort key
  3. In regard to DynamoDB, can I modify the index once it is created?
    1. Yes, if it is a primary hash key index
    2. Yes, if it is a Global secondary index (GSIs can be added or deleted on existing tables, but cannot be modified in place — you must delete and recreate)
    3. No
    4. Yes, if it is a local secondary index
  4. When thinking of DynamoDB, what is true of Global Secondary Key properties?
    1. Both the partition key and sort key can be different from the table.
    2. Only the partition key can be different from the table.
    3. Either the partition key or the sort key can be different from the table, but not both.
    4. Only the sort key can be different from the table.
  5. A team needs to query a DynamoDB table using an attribute that is not part of the primary key. They need strongly consistent reads. Which type of secondary index should they use?
    1. Global Secondary Index with ConsistentRead set to true
    2. Local Secondary Index
    3. Either GSI or LSI supports strongly consistent reads
    4. Neither GSI nor LSI supports strongly consistent reads
  6. A DynamoDB table uses on-demand capacity mode. Which of the following statements about secondary indexes on this table is correct?
    1. Secondary indexes must use provisioned capacity mode
    2. GSIs can use a different capacity mode than the base table
    3. Secondary indexes inherit the capacity mode from the base table
    4. Only LSIs can use on-demand capacity mode
  7. With the multi-attribute composite key feature for DynamoDB GSIs, what is the maximum number of attributes that can compose a GSI key schema?
    1. 2 (one partition key, one sort key)
    2. 4 (two partition keys, two sort keys)
    3. 8 (up to four partition key attributes, up to four sort key attributes)
    4. 16 (up to eight partition keys, up to eight sort keys)
  8. What happens when a Global Secondary Index has insufficient write capacity?
    1. Only reads on the GSI are throttled
    2. The GSI becomes temporarily unavailable
    3. Write operations on the base table and all its GSIs are throttled (back-pressure)
    4. DynamoDB automatically increases the GSI write capacity

References

AWS DynamoDB Best Practices

AWS DynamoDB Best Practices

Primary Key Design

  • Primary key uniquely identifies each item in a DynamoDB table and can be simple (a partition key only) or composite (a partition key combined with a sort key).
  • Partition key portion of a table’s primary key determines the logical partitions in which a table’s data is stored, which in turn affects the underlying physical partitions.
  • Partition key should have many unique values.
  • Distribute reads / writes uniformly across partitions to avoid hot partitions
  • Store hot and cold data in separate tables
  • Consider all possible query patterns to eliminate the use of scans and filters.
  • Choose a sort key depending on the application’s needs.
  • Avoid hot keys and hot partitions – a partition key design that doesn’t distribute I/O requests evenly can create “hot” partitions that result in throttling and use the provisioned I/O capacity inefficiently.
  • Use composite keys for access patterns – compose partition and sort keys by concatenating multiple attributes (e.g., {Type}#{ID}) to enable efficient queries without scans, especially in single-table designs.
  • Write sharding for high-volume keys – for items with high write volumes on the same partition key, add a random suffix or calculated suffix to distribute writes across multiple partitions.

Secondary Indexes

  • Use indexes based on the application’s query patterns.
  • Local Secondary Indexes – LSIs
    • Use primary key or LSIs when strong consistency is desired
    • Watch for expanding item collections (10 GB size limit!)
  • Global Secondary Indexes – GSIs
    • Use GSIs for finer control over throughput or when your application needs to query using a different partition key.
    • Can be used for eventually consistent read replicas – set up a global secondary index that has the same key schema as the parent table, with some or all of the non-key attributes projected into it.
    • Overloaded GSIs – use a single GSI with generic attribute names (e.g., GSI1PK, GSI1SK) to support multiple access patterns in single-table designs, reducing the total number of indexes needed.
  • Project fewer attributes – As secondary indexes consume storage and provisioned throughput, keep the index size as small as possible by projecting only required attributes as it would provide greater performance
  • Keep the number of indexes to a minimum – don’t create secondary indexes on attributes that aren’t queried often. Indexes that are seldom used contribute to increased storage and I/O costs without improving application performance.
  • Sparse indexes – DynamoDB indexes are Sparse and it writes a corresponding index entry only if the index sort key value is present in the item. If the sort key doesn’t appear in every table item, the index will not contain the item.

Large Items and Attributes

  • DynamoDB currently limits the size of each item (400 KB) that is stored in a table, which includes both attribute names and values binary length.
  • Use shorter (yet intuitive!) attribute names
  • Keep item size small.
  • Use compression (GZIP or LZO).
  • Split large attributes across multiple items (vertical partitioning).
  • Store metadata in DynamoDB and large BLOBs or attributes in S3.
  • Vertical partitioning – split items into multiple items using a sort key to distinguish parts, allowing you to exceed the 400 KB limit while maintaining efficient access to individual attribute groups.

Querying and Scanning Data

  • Avoid scans and filters – Scan operations are less efficient than other operations in DynamoDB. A Scan operation always scans the entire table or secondary index. It then filters out values to provide the result, essentially adding the extra step of removing data from the result set.
  • Use eventual consistency for reads.
  • Use parallel scans cautiously – parallel scans can improve throughput for large tables but consume significant read capacity. Use them only for infrequent, large-scale data processing tasks.

Time Series Data

  • Use a table per day, week, month, etc for storing time series data – create one table per period, provisioned with the required read and write capacity and the required indexes.
  • Before the end of each period, prebuild the table for the next period. Just as the current period ends, direct event traffic to the new table. Assign names to the tables that specify the periods they have recorded.
  • As soon as a table is no longer being written to, reduce its provisioned write capacity to a lower value (for example, 1 WCU), and provision whatever read capacity is appropriate. Reduce the provisioned read capacity of earlier tables as they age.
  • Archive or drop the tables whose contents are rarely or never needed.
  • Dropping tables is the fastest, simplest and cost-effective method if all the items are to be deleted from the table, without spending time in scanning and deleting each item.
  • Use TTL for automatic expiry – leverage Time to Live (TTL) to automatically delete expired items without consuming write throughput, ideal for session data, temporary records, and event logs.
  • Use DynamoDB Standard-IA table class – for older time series tables with infrequent access, switch to the Standard-Infrequent Access table class to save up to 60% on storage costs.

Capacity and Throughput Management

  • On-demand mode (recommended default) – on-demand mode is the default and recommended throughput option that eliminates capacity planning. DynamoDB instantly accommodates workloads as they ramp up or down. With the November 2024 pricing reduction (50% off), on-demand is now significantly more cost-effective.
  • Configurable maximum throughput – for on-demand tables, optionally set maximum read/write throughput limits to control costs and protect downstream services from accidental traffic surges (launched May 2024).
  • Warm throughput – provides visibility into the read and write operations your table can immediately support. Pre-warm tables proactively to meet anticipated traffic demands without throttling during sudden spikes (launched November 2024).
  • Burst Capacity reserves a portion of unused capacity (5 mins.) for later bursts of throughput to handle usage spikes.
  • Adaptive capacity helps run imbalanced workloads indefinitely. It minimizes throttling due to throughput exceptions and reduces cost by enabling you to provision only the needed throughput capacity.
  • Provisioned mode with Auto Scaling – for predictable workloads, provisioned mode with auto scaling can be more cost-effective than on-demand. Use scheduled scaling for known traffic patterns.
  • Reserved capacity – for steady-state workloads on provisioned tables, purchase 1-year or 3-year reserved capacity for significant savings. AWS Cost Explorer now provides purchase recommendations for DynamoDB reserved capacity.

Cost Optimization Best Practices

  • Choose the right capacity mode – on-demand mode pricing was reduced by 50% (November 2024). Evaluate whether on-demand or provisioned with auto scaling better suits your workload pattern.
  • DynamoDB Standard-IA table class – use for tables where storage cost exceeds 50% of throughput cost. Saves up to 60% on storage while keeping the same performance. Ideal for infrequently accessed data, logs, and historical records.
  • Use TTL to expire data – TTL deletes expired items without consuming write capacity, reducing both storage costs and manual cleanup effort.
  • Monitor with AWS Compute Optimizer – AWS Compute Optimizer now identifies idle DynamoDB provisioned tables (launched June 2026), helping detect unused resources and potential cost savings.
  • Global tables pricing – global table replicated write costs were reduced by up to 67% (November 2024). Evaluate global tables for multi-Region active-active architectures.

Security Best Practices

  • Resource-based policies (launched March 2024) – attach policies directly to DynamoDB tables, indexes, and streams to simplify cross-account access control. Integrates with IAM Access Analyzer and Block Public Access capabilities.
  • Attribute-Based Access Control (ABAC) – use tag-based conditions in IAM policies to grant access based on tags attached to users, roles, and DynamoDB resources (GA November 2024). ABAC automatically applies permissions as organizations grow without rewriting policies.
  • AWS PrivateLink (launched March 2024) – connect to DynamoDB over a private network without public IP addresses, eliminating the need for internet gateways or firewall rules.
  • Encryption at rest – all DynamoDB tables are encrypted at rest using AWS owned keys by default. Use AWS KMS customer managed keys (CMK) for additional control.
  • Deletion protection can keep the tables from being accidentally deleted.
  • FIPS 140-3 endpoints – FIPS-compliant interface VPC and Streams endpoints available in US, Canada, and GovCloud Regions (launched December 2024).

Global Tables Best Practices

  • Multi-Region strong consistency (GA June 2025) – global tables now support multi-Region strong consistency (MRSC), enabling zero RPO and ensuring applications can read the latest data from any Region. Ideal for user profiles, inventory tracking, and financial transactions.
  • Choose the right consistency mode – MRSC provides strongly consistent reads across Regions with slightly higher write latencies. Choose between MRSC and multi-Region eventually consistent (MREC) based on application needs.
  • Test with AWS FIS – use the AWS Fault Injection Service (FIS) action to pause global table replication and test application resilience during Regional interruptions (launched April 2024).
  • Pricing optimization – global table replicated write costs reduced by up to 67% for on-demand and 33% for provisioned (November 2024).

Zero-ETL Integrations

  • Amazon Redshift integration (GA October 2024) – zero-ETL integration with Amazon Redshift enables high-performance analytics on DynamoDB data without impacting production workloads or building ETL pipelines. Data becomes immediately available in Redshift as it is written to DynamoDB.
  • Amazon SageMaker Lakehouse integration (December 2024) – automates data synchronization between DynamoDB and SageMaker Lakehouse using Apache Iceberg format. Enables analytics and ML workloads with ACID transaction support.
  • Use zero-ETL for analytics – instead of running complex Scan operations for reporting, leverage zero-ETL integrations to offload analytics workloads to purpose-built analytics services.

Other Best Practices

  • Single-table design – for applications with multiple entity types and well-defined access patterns, consider single-table design with composite keys and overloaded GSIs to reduce costs and improve performance.
  • Multi-table design – for applications with simple access patterns or when teams need independent management of entities, multi-table design offers simpler maintenance and clearer data boundaries.
  • DynamoDB Accelerator (DAX) – use DAX for read-heavy workloads requiring microsecond response times. DAX provides up to 10x performance improvement for eventually consistent reads.
  • DynamoDB Streams – use streams for event-driven architectures, cross-Region replication, and real-time data processing. Now supported as a source in Amazon Managed Service for Apache Flink (November 2024).
  • Import from S3 – bulk import supports up to 50,000 S3 objects in a single import operation (increased March 2024), simplifying initial data loading.

AWS Certification Exam Tips

  • Understand partition key design and how to avoid hot partitions – a fundamental topic across all AWS certification exams.
  • Know the difference between on-demand and provisioned capacity modes and when to use each.
  • Understand global tables multi-Region strong consistency vs. eventual consistency trade-offs.
  • Know resource-based policies vs. identity-based policies for cross-account DynamoDB access.
  • Understand TTL for cost optimization and data lifecycle management.
  • Know DynamoDB Standard vs. Standard-IA table class selection criteria.
  • Understand zero-ETL integrations as the recommended approach for analytics on DynamoDB data.
  • Know warm throughput and configurable maximum throughput for performance management.

Reference