DynamoDB

AWS DynamoDB

~ Last updated on : ~ jayendrapatil ~ 29 Comments

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

DynamoDB Capacity – Provisioned vs On-Demand

~ Last updated on : ~ jayendrapatil ~ 10 Comments

AWS DynamoDB Throughput Capacity

  • AWS 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 (default and recommended) – 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 Burst capacity provides some flexibility in the per-partition throughput provisioning by providing burst capacity.
  • DynamoDB Adaptive capacity is a feature that enables DynamoDB to run imbalanced workloads indefinitely. Adaptive capacity is instant.
  • DynamoDB Warm Throughput (November 2024) provides visibility into table capacity and enables pre-warming for peak events.
  • Configurable Maximum Throughput (May 2024) allows setting per-table maximum throughput limits for on-demand tables.

NOTE – DynamoDB throughput capacity, including both Provisioned and On-demand modes, is covered in the AWS Certified Developer – Associate exam (DVA-C02). RCU/WCU calculations, capacity mode selection, and throttling mitigation are key exam topics.

Pricing Reduction – November 2024

  • Effective November 1, 2024, DynamoDB reduced prices significantly:
    • On-demand throughput: 50% price reduction
    • Global tables (on-demand): Up to 67% price reduction
    • Global tables (provisioned): 33% price reduction
  • Makes DynamoDB more cost-effective for building, scaling, and optimizing applications.
  • Applies to all AWS commercial Regions.
  • On-demand mode is now the default and recommended throughput option for most DynamoDB workloads.

Provisioned Mode

  • Provisioned mode requires you to specify the number of reads and writes per second as required by the application
  • Provisioned throughput is the maximum amount of capacity that an application can consume from a table or index
  • If the provisioned throughput capacity on a table or index is exceeded, it is subject to request throttling
  • Provisioned mode provides the following capacity units
    • Read Capacity Units (RCU)
      • Total number of read capacity units required depends on the item size, and the consistent read model (eventually or strongly)
      • one RCU represents
        • two eventually consistent reads per second, for an item up to 4 KB in size i.e. 8 KB
        • one strongly consistent read per second for an item up to 4 KB in size i.e. 2x cost of eventually consistent reads
        • Transactional read requests require two read capacity units to perform one read per second for items up to 4 KB. i.e. 2x cost of strongly consistent reads
      • DynamoDB must consume additional read capacity units for items greater than 4 KB for e.g. for an 8 KB item size, 2 read capacity units to sustain one strongly consistent read per second, 1 read capacity unit if you choose eventually consistent reads, or 4 read capacity units for a transactional read request would be required
      • Item size is rounded off to 4 KB equivalents for e.g. a 6 KB or a 8 KB item in size would require the same RCU
    • Write Capacity Units (WCU)
      • Total number of write capacity units required depends on the item size only
      • one write per second for an item up to 1 KB in size
      • Transactional write requests require 2 write capacity units to perform one write per second for items up to 1 KB. i.e. 2x cost of general write.
      • DynamoDB must consume additional write capacity units for items greater than 1 KB for a 2 KB item size, 2 write capacity units would be required to sustain one write request per second or 4 write capacity units for a transactional write request
      • Item size is rounded off to 1 KB equivalents for e.g. a 0.5 KB or a 1 KB item would need the same WCU
  • Provisioned capacity mode might be best for use cases where you
    • Have predictable application traffic
    • Run applications whose traffic is consistent or ramps gradually
    • Can forecast capacity requirements to control costs

Provisioned Mode Examples

  • DynamoDB table with provisioned capacity of 10 RCUs and 10 WCUs can support
    • Read throughput
      • Eventual consistency = 4KB * 10 * 2 = 80KB/sec
      • Strong consistency = 4KB * 10 = 40KB/sec
      • Transactional consistency = 4KB * 10 * 1/2 = 20KB/sec
    • Write throughput
      • Eventual and Strong consistency = 10 * 1KB = 10KB/sec
      • Transaction consistency = 10 * 1KB * 1/2 = 5KB/sec
  • Capacity units required for reading and writing 15KB item
    • Read capacity units – 15KB rounded to 4 blocks of 4KB = 4 RCUs
      • Eventual consistency 4 RCUs * 1/2 = 2 RCUs
      • Strong consistency 4 RCUs * 1 = 4 RCUs
      • Transactional consistency 4 RCUs * 2 = 8 RCUs
    • Write capacity units 15KB = 15 WCUs
      • Eventual and Strong consistency 15 WCUs * 1 = 15 WCUs
      • Transactional consistency 15 WCUs * 2 = 30 WCUs

On-demand Mode

  • On-demand mode is the default and recommended throughput option for most DynamoDB workloads.
  • On-demand mode provides a flexible billing option capable of serving thousands of requests per second without capacity planning.
  • No need to specify the expected read and write throughput.
  • Charged for only the reads and writes that the application performs on the tables in terms of read request units and write request units.
  • Offers pay-per-request pricing for read and write requests so that you pay only for what you use.
  • DynamoDB adapts rapidly to accommodate the changing load and can scale down to zero when no requests are being issued.
  • DynamoDB on-demand uses Request units which are similar to provisioned capacity Units.
  • On-demand mode does not support reserved capacity.
  • Pricing reduced by 50% effective November 1, 2024.
  • New on-demand tables can sustain up to 4,000 writes per second and 12,000 reads per second initially.
  • On-demand throughput rate is bounded by a default 40,000 table-level read and write throughput service quota per account (can be increased via Service Quotas).
  • On-demand capacity mode might be best for use cases where you
    • Create new tables with unknown workloads
    • Have unpredictable application traffic
    • Prefer the ease of paying for only what you use

Configurable Maximum Throughput for On-Demand Tables – May 2024

  • Announced in May 2024, allows setting maximum read or write (or both) throughput for individual on-demand tables and associated GSIs.
  • Provides an additional layer of cost predictability and manageability for on-demand tables.
  • Throughput requests in excess of the configured maximum table throughput will be automatically throttled.
  • The maximum throughput can be modified at any time based on application requirements.
  • Key use cases:
    • Cost optimization – Bounds maximum spending per table while retaining on-demand flexibility.
    • Protection against accidental surges – Prevents runaway code from consuming excessive resources.
    • Safeguarding downstream services – Prevents overloading downstream services with fixed capacities.
  • Previously, the on-demand request rate was only limited by the default 40,000 RRU/WRU account-level quota, which could not be customized per table.

DynamoDB Warm Throughput – November 2024

  • Announced in November 2024, warm throughput provides visibility and control over table capacity.
  • Warm throughput is the read and write capacity your DynamoDB table can instantly support based on historical usage.
  • Available for both provisioned and on-demand tables and indexes at no cost.
  • Provides insight into the operations your table or index can immediately support.
  • Warm throughput values grow automatically as usage increases.
  • Once increased, warm throughput values cannot be decreased.
  • Available in all AWS commercial Regions (GovCloud added January 2025).

Pre-warming Tables

  • You can pre-warm your table or index by proactively setting higher warm throughput values.
  • Ideal for anticipated peak events like:
    • Product launches
    • Shopping events (Black Friday, Prime Day)
    • Marketing campaigns
    • Live streaming events
  • Pre-warming ensures tables can handle 10x or 100x traffic surges instantly without throttling.
  • DynamoDB automatically scales, but pre-warming eliminates the scaling delay.
  • Pre-warming is an asynchronous operation; you can carry out other table updates while it completes.
  • You can pre-warm up to the table or index quota limit for your account in that Region.
  • There is no limit to the number of DynamoDB tables you can pre-warm at any time.
  • Warm throughput values are available at no cost.
  • Pre-warming incurs a charge (see DynamoDB pricing for details).

Capacity Mode Switching

  • You can switch between on-demand and provisioned capacity modes.
  • Provisioned to On-demand: Can be switched up to 4 times in a 24-hour rolling window (updated August 2025, previously limited to once per 24 hours).
  • On-demand to Provisioned: Can be switched at any time with no frequency limitation.
  • When switching from provisioned to on-demand:
    • DynamoDB ensures the table is scaled to sustain at least the previously provisioned or peak capacity.
    • New tables with provisioned below 4,000 WCU/12,000 RCU will be scaled to at least 4,000 writes/sec and 12,000 reads/sec.
    • Auto scaling settings are deleted (console) or preserved (CLI/SDK).
  • When switching from on-demand to provisioned:
    • Table delivers throughput consistent with the previous peak reached during on-demand mode.
    • Use CloudWatch metrics (ConsumedWriteCapacityUnits, ConsumedReadCapacityUnits) to determine appropriate provisioned settings.
  • You can bulk edit multiple tables to switch capacity modes in the DynamoDB console.

DynamoDB Throttling

  • DynamoDB distributes the data across partitions and the provisioned throughput capacity is distributed equally across these partitions and these are physical partitions and not the logical partitions based on the primary key.
  • Each partition on a DynamoDB table is subject to a hard limit of 1,000 write capacity units and 3,000 read capacity units.
  • DynamoDB would throttle requests
    • If the workload is unevenly distributed across partitions, or if the workload relies on short periods of time with high usage (a burst of read or write activity), the table might be throttled.
    • When data access is imbalanced, a hot partition can receive a higher volume of read and write traffic compared to other partitions leading to throttling errors on that partition.
    • If the write throughput capacity on the GSI is not sufficient it would lead to throttling on a GSI and this would affect the base table.
    • If configurable maximum throughput is set on an on-demand table, requests exceeding that maximum will be throttled.
  • To avoid and handle throttling issues, you can
    • Distribute read and write operations as evenly as possible across your table. A hot partition can degrade the overall performance of your table.
    • Use warm throughput and pre-warming for anticipated peak events to ensure instant capacity availability.
    • Implement a caching solution. If the workload is mostly read access to static data, then query results can be delivered much faster if the data is in a well‑designed cache rather than in a database. DynamoDB Accelerator (DAX) is a caching service that offers fast in‑memory performance for your application. ElastiCache can be used as well.
    • Implement error retries and exponential backoff. Exponential backoff can improve an application’s reliability by using progressively longer waits between retries. If using an AWS SDK, this logic is built‑in.
    • Switch to on-demand mode if workload is unpredictable to avoid provisioned throughput throttling entirely.

DynamoDB Burst Capacity

  • DynamoDB provides some flexibility in the per-partition throughput provisioning by providing burst capacity.
  • If partition’s throughput is not fully used, DynamoDB reserves a portion of that unused capacity for later bursts of throughput to handle usage spikes.
  • DynamoDB currently retains up to 5 minutes (300 seconds) of unused read and write capacity.
  • During an occasional burst of read or write activity, these extra capacity units can be consumed quickly – even faster than the per-second provisioned throughput capacity that you’ve defined for your table.
  • DynamoDB can also consume burst capacity for background maintenance and other tasks without prior notice.
  • Burst capacity details may change in the future.

DynamoDB Adaptive Capacity

  • DynamoDB Adaptive capacity is a feature that enables DynamoDB to run imbalanced workloads indefinitely.
  • Adaptive capacity is instant — it responds immediately to traffic imbalances by increasing throughput capacity for partitions that receive more traffic.
  • Adaptive capacity enables the application to continue read/write to hot partitions without being throttled, provided that traffic does not exceed the table’s total provisioned capacity or the partition’s maximum capacity.
  • It minimizes throttling due to throughput exceptions.
  • It also helps reduce costs by enabling the provisioning of only the needed throughput capacity.
  • Adaptive capacity is enabled automatically for every DynamoDB table, at no additional cost. You don’t need to explicitly enable or disable it.
  • Isolating Frequently Accessed Items:
    • Adaptive capacity rebalances partitions so that frequently accessed items don’t reside on the same partition.
    • If a single item drives consistently high traffic, adaptive capacity may isolate it on its own partition.
    • A single item can receive throughput up to the partition maximum of 3,000 RCUs and 1,000 WCUs.

Capacity Mode Comparison

Feature Provisioned Mode On-Demand Mode
Capacity Planning Required (specify RCU/WCU) Not required (automatic)
Pricing Model Pay for provisioned capacity (hourly) Pay per request (50% reduced Nov 2024)
Best For Predictable, steady traffic Unpredictable/spiky traffic (default)
Auto Scaling Supported (Application Auto Scaling) Automatic (built-in, scales to zero)
Warm Throughput Supported Supported
Configurable Max Throughput N/A (set explicit capacity) Supported (May 2024)
Reserved Capacity Supported Not supported
Initial Capacity (new tables) As specified 4,000 WPS / 12,000 RPS
Account-level Default Quota N/A 40,000 RRU/WRU per table (adjustable)
Switch to Other Mode Up to 4 times per 24hrs to on-demand Any time to provisioned

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. 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)
    4. 2778
  2. 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
  3. A company is building a system to collect sensor data from its 36000 trucks, which is stored in DynamoDB. The trucks emit 1KB of data once every hour. How much write throughput is required for the target table. Choose an answer from the options below
    1. 10
    2. 60
    3. 600
    4. 150
  4. A company is using DynamoDB to design storage for their IOT project to store sensor data. Which combination would give the highest throughput?
    1. 5 Eventual Consistent reads capacity with Item Size of 4KB (40KB/s)
    2. 15 Eventual Consistent reads capacity with Item Size of 1KB (30KB/s)
    3. 5 Strongly Consistent reads capacity with Item Size of 4KB (20KB/s)
    4. 15 Strongly Consistent reads capacity with Item Size of 1KB (15KB/s)
  5. If your table item’s size is 3KB and you want to have 90 strongly consistent reads per second, how many read capacity units will you need to provision on the table? Choose the correct answer from the options below
    1. 90
    2. 45
    3. 10
    4. 19
  6. A company is planning a major product launch that will generate 10x normal traffic for 2 hours. What feature should they use to ensure DynamoDB can handle the spike instantly?
    1. DynamoDB Auto Scaling
    2. Burst capacity
    3. Warm throughput with pre-warming
    4. Adaptive capacity
  7. When should you start pre-warming a DynamoDB table for an anticipated peak event?
    1. 1 hour before the event
    2. 6 hours before the event
    3. At least 24 hours before the event (pre-warming is asynchronous and completion time depends on the values set)
    4. 1 week before the event
  8. Which of the following statements about DynamoDB capacity modes are correct? (Select THREE)
    1. On-demand pricing was reduced by 50% in November 2024
    2. Provisioned mode does not support warm throughput
    3. New on-demand tables can sustain 4,000 writes and 12,000 reads per second initially
    4. On-demand mode supports reserved capacity
    5. Warm throughput values are available at no cost, but pre-warming incurs charges
  9. A development team wants to prevent a runaway application from generating excessive DynamoDB costs on their on-demand table. Which feature should they configure?
    1. DynamoDB Auto Scaling with max capacity
    2. Provisioned capacity with burst limits
    3. Configurable maximum throughput for on-demand tables
    4. Reserved capacity with cost alerts
  10. How many times can you switch a DynamoDB table from provisioned capacity mode to on-demand mode within a 24-hour period?
    1. Once
    2. Twice
    3. Four times
    4. Unlimited

References

AWS DynamoDB Security

~ Last updated on : ~ jayendrapatil ~ 2 Comments

DynamoDB Security

  • DynamoDB provides a highly durable storage infrastructure for mission-critical and primary data storage.
  • Data is redundantly stored on multiple devices across multiple facilities in a DynamoDB Region.
  • 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.
  • Fine-Grained Access Control (FGAC) gives a high degree of control over data in the table.
  • FGAC helps control who (caller) can access which items or attributes of the table and perform what actions (read/write capability).
  • FGAC is integrated with IAM, which manages the security credentials and the associated permissions.
  • VPC Endpoints allow private connectivity from within a VPC only to DynamoDB.

DynamoDB Resource-Based Policies – March 2024

  • DynamoDB now supports resource-based policies to simplify access control for DynamoDB resources.
  • Resource-based policies allow you to specify IAM principals that have access to a resource and what actions they can perform directly on the resource.
  • Simplifies cross-account access without requiring IAM role assumption.
  • Can be attached to:
    • DynamoDB tables
    • DynamoDB Streams
  • Resource-based policies work alongside IAM identity policies for comprehensive access control.
  • Enables fine-grained permissions at the resource level.
  • Useful for scenarios like:
    • Cross-account data sharing
    • Third-party integrations
    • Service-to-service access

DynamoDB Global Tables Multi-Account Replication – February 2026

  • DynamoDB global tables now support replication across multiple AWS accounts.
  • Enables improved resiliency and workload isolation at the account level.
  • Allows applying distinct security and governance controls per account.
  • Supports data perimeter guardrails using AWS Organizations.
  • DynamoDB automatically replicates tables across accounts and Regions.
  • Ideal for:
    • Multi-account strategies with AWS Organizations
    • Improved security isolation between workloads
    • Disaster recovery (DR) with account-level failover
    • Separating workloads by business unit
  • Available in all AWS Regions, billed per existing global tables pricing.

DynamoDB Encryption

  • DynamoDB Security supports both encryption at rest and in transit.

Encryption in Transit

  • DynamoDB Data in Transit encryption can be done by encrypting sensitive data on the client side or using encrypted connections (TLS).
  • DAX supports encryption in transit, ensuring that all requests and responses between the application and the cluster are encrypted by transport level security (TLS), and connections to the cluster can be authenticated by verification of a cluster x509 certificate.
  • All the data in DynamoDB is encrypted in transit.
  • Communications to and from DynamoDB use the HTTPS protocol, which protects network traffic using SSL/TLS encryption.
  • Data can also be protected using client-side encryption.

Encryption at Rest

  • Encryption at rest enables encryption for the data persisted (data at rest) in the DynamoDB tables.
  • Encryption at rest includes the base tables, primary key, local and global secondary indexes, streams, global tables, backups, and DynamoDB Accelerator (DAX) clusters.
  • Encryption at rest is enabled on all DynamoDB table data and cannot be disabled.
  • Encryption at rest automatically integrates with AWS KMS for managing the keys used for encrypting the tables.
  • Encryption at rest supports the following KMS keys:
    • AWS owned key – Default encryption type. The key is owned by DynamoDB (no additional charge).
    • AWS managed key – The key is stored in your account and is managed by AWS KMS (AWS KMS charges apply).
    • Customer managed key – The key is stored in your account and is created, owned, and managed by you. You have full control over the KMS key (AWS KMS charges apply).
  • Encryption at rest can be enabled only for a new table and encryption keys can be switched for an existing table.
  • DynamoDB streams can be used with encrypted tables and are always encrypted with a table-level encryption key.
  • On-Demand Backups of encrypted DynamoDB tables are encrypted using S3’s Server-Side Encryption.
  • Encryption at rest encrypts the data using 256-bit AES encryption.
  • DAX clusters do not support customer-managed KMS keys. DAX uses AWS owned keys only.

AWS Database Encryption SDK (formerly DynamoDB Encryption Client)

  • The AWS Database Encryption SDK (previously known as the DynamoDB Encryption Client, renamed June 2023) is a software library that helps protect table data before sending it to DynamoDB.
  • Encrypting sensitive data in transit and at rest helps ensure that the plaintext data isn’t available to any third party, including AWS.
  • Provides end-to-end data encryption with attribute-level control.
  • Encrypts attribute values that can be controlled but does not encrypt the entire table, attribute names, or primary key.
  • Supports searchable encryption, allowing encrypted attributes to be queried without decryption.
  • Compatible with the legacy DynamoDB Encryption Client — can decrypt items encrypted by the older library.

DynamoDB Deletion Protection

  • DynamoDB supports deletion protection to prevent tables from being accidentally deleted.
  • When enabled, any attempt to delete the table will fail until deletion protection is explicitly disabled.
  • Helps prevent disruption to business operations from accidental table deletion during regular management tasks.
  • AWS Security Hub control DynamoDB.6 checks that deletion protection is enabled on DynamoDB tables.
  • Recommended as a security best practice for all production tables.

VPC Endpoints

  • By default, communications to and from DynamoDB use the HTTPS protocol, which protects network traffic by using SSL/TLS encryption.
  • DynamoDB supports two types of VPC endpoints: Gateway Endpoints and Interface Endpoints (using AWS PrivateLink).

Gateway Endpoints

  • A VPC gateway endpoint for DynamoDB enables EC2 instances in the VPC to use their private IP addresses to access DynamoDB with no exposure to the public internet.
  • Traffic between the VPC and the AWS service does not leave the Amazon network.
  • EC2 instances do not require public IP addresses, an internet gateway, a NAT device, or a virtual private gateway in the VPC.
  • VPC Endpoint Policies to control access to DynamoDB.
  • No additional charge for using gateway endpoints.
  • Accessible only from within the VPC where they are created.

Interface Endpoints (AWS PrivateLink)

DynamoDB Interface Endpoints – March 2024

  • DynamoDB now supports AWS PrivateLink with interface VPC endpoints.
  • Interface endpoints are represented by elastic network interfaces (ENIs) with private IP addresses.
  • Accessible from:
    • Within the VPC
    • On-premises networks via AWS Direct Connect or Site-to-Site VPN
    • Other AWS Regions via VPC peering
  • Eliminates need for public IP addresses, proxy infrastructure, or firewall rules for on-premises access.
  • Supports private DNS names for simplified connectivity.
  • Standard AWS PrivateLink charges apply.

DynamoDB Streams Interface Endpoints – March 2025

  • DynamoDB Streams APIs now support AWS PrivateLink.
  • Enables private access to DynamoDB Streams APIs without traversing the public internet.
  • Supports GetRecords, GetShardIterator, and DescribeStream operations.
  • Only interface endpoints are supported for DynamoDB Streams (gateway endpoints not supported).

DynamoDB Streams FIPS Endpoints via PrivateLink – May 2026

  • DynamoDB Streams now supports AWS PrivateLink for FIPS endpoints in AWS GovCloud (US) Regions.
  • Allows government agencies to establish private connectivity to DynamoDB Streams FIPS endpoints without exposing traffic to the public internet.
  • Helps meet strict federal compliance and regulatory requirements.
  • Available in AWS GovCloud (US-East), GovCloud (US-West), US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Canada (Central), and Canada West (Calgary).
  • Enables compliant change data capture (CDC) solutions and event-driven architectures that adhere to federal security standards.

DAX Interface Endpoints – October 2025

  • DynamoDB Accelerator (DAX) now supports AWS PrivateLink.
  • Enables secure access to DAX management APIs over private IP addresses.
  • Supported APIs: CreateCluster, DescribeClusters, DeleteCluster.
  • Accessible using private DNS names.

DynamoDB VPC Endpoint

DynamoDB Security Best Practices

  • DynamoDB encrypts at rest all user data stored in tables, indexes, streams, and backups using encryption keys stored in KMS.
  • DynamoDB can be configured to use an AWS owned key (default encryption type), an AWS managed key, or a customer managed key to encrypt user data.
  • Use customer-managed KMS keys for enhanced control over encryption keys with rotation policies.
  • Use IAM Roles to authenticate access to DynamoDB.
  • Implement resource-based policies for simplified cross-account access control.
  • Use Fine-Grained Access Control (FGAC) to control access at item and attribute level.
  • Use VPC gateway endpoints for cost-effective private access from within VPC.
  • Use interface endpoints (AWS PrivateLink) for private access from on-premises or cross-region.
  • AWS Database Encryption SDK is a software library that helps in client-side encryption and protects the table data before you send it to DynamoDB.
  • Enable deletion protection on all production tables to prevent accidental deletion (Security Hub DynamoDB.6).
  • Enable AWS CloudTrail for auditing access to encryption keys and DynamoDB operations.
  • Apply principle of least privilege when defining IAM policies.
  • Regularly review and rotate access credentials and encryption keys.
  • Use multi-account global tables for enhanced security isolation and data perimeter enforcement.

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. What are the services supported by VPC endpoints, using the Gateway endpoint type?
    1. Amazon EFS
    2. Amazon DynamoDB
    3. Amazon Glacier
    4. Amazon SQS
  2. A company needs to provide cross-account access to a DynamoDB table without requiring IAM role assumption. Which feature should they use?
    1. IAM identity policies
    2. VPC endpoint policies
    3. Resource-based policies
    4. Fine-grained access control
  3. A company needs to access DynamoDB from their on-premises data center over AWS Direct Connect without traversing the public internet. Which solution should they use?
    1. VPC gateway endpoint
    2. VPC interface endpoint with AWS PrivateLink
    3. Internet gateway
    4. NAT gateway
  4. Which DynamoDB Streams access method supports AWS PrivateLink?
    1. Gateway endpoints
    2. Interface endpoints
    3. Both gateway and interface endpoints
    4. Neither gateway nor interface endpoints
  5. A company wants to minimize costs for private VPC access to DynamoDB from EC2 instances within the same VPC. Which endpoint type should they use?
    1. Interface endpoint
    2. Gateway endpoint
    3. Both are equally cost-effective
    4. Neither supports this use case
  6. Which of the following statements about DynamoDB security are correct? (Select THREE)
    1. Resource-based policies simplify cross-account access
    2. Gateway endpoints are accessible from on-premises networks
    3. DAX supports AWS PrivateLink for management APIs
    4. Encryption at rest can be disabled for tables
    5. DynamoDB Streams only supports interface endpoints, not gateway endpoints
  7. What encryption key type provides the most control over key management for DynamoDB?
    1. AWS owned key
    2. AWS managed key
    3. Customer managed key
    4. All provide equal control
  8. A government agency needs to privately access DynamoDB Streams using FIPS-compliant endpoints in GovCloud. Which connectivity option should they use?
    1. VPC gateway endpoint
    2. VPC interface endpoint with PrivateLink FIPS endpoints
    3. Public internet with TLS
    4. AWS Direct Connect public VIF
  9. An organization wants to replicate DynamoDB tables across multiple AWS accounts for improved security isolation and disaster recovery. Which feature supports this?
    1. DynamoDB Streams cross-account replication
    2. Resource-based policies with cross-account access
    3. DynamoDB global tables multi-account replication
    4. AWS Backup cross-account copy
  10. Which Security Hub control checks that DynamoDB tables have deletion protection enabled?
    1. DynamoDB.2
    2. DynamoDB.4
    3. DynamoDB.6
    4. DynamoDB.7

References

DynamoDB Secondary Indexes – GSI vs LSI

DynamoDB Secondary Indexes - GSI vs LSI
~ Last updated on : ~ jayendrapatil ~ 14 Comments

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

DynamoDB Advanced – DAX, Streams & Global Tables

~ Last updated on : ~ jayendrapatil ~ 7 Comments

AWS DynamoDB Advanced Features

  • 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 Global Tables is a fully managed, multi-active, cross-region replication capability of DynamoDB to support data access locality and regional fault tolerance for database workloads.
  • 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.
  • DynamoDB Zero-ETL Integrations provide seamless data replication to analytics services like Amazon Redshift, Amazon OpenSearch Service, and Amazon SageMaker Lakehouse without building ETL pipelines.
  • VPC Gateway Endpoints provide private access to DynamoDB from within a VPC without the need for an internet gateway or NAT gateway.
  • DynamoDB Warm Throughput provides visibility into the throughput your tables and indexes can instantly support and allows pre-warming for anticipated traffic spikes.

DynamoDB Secondary Indexes

  • DynamoDB Secondary indexes on a table allow efficient access to data with attributes other than the primary key.
  • 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 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 typically deletes expired items within a few days of their expiration. Items with valid, expired TTL attributes may still be updated, including changing or removing their TTL attributes, while pending deletion.
  • DynamoDB Stream tracks the delete operation as a system delete and not a regular delete.
  • TTL is useful if the stored items lose relevance after a specific time. for e.g.
    • Remove user or sensor data after a year of inactivity in an application
    • Archive expired items to an S3 data lake via DynamoDB Streams and AWS Lambda.
    • Retain sensitive data for a certain amount of time according to contractual or regulatory obligations.

DynamoDB Global Tables

  • DynamoDB Global Tables is a fully managed, serverless, multi-active, cross-region replication capability of DynamoDB to support data access locality and regional fault tolerance for database workloads.
  • Applications can 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 take advantage of data locality to reduce overall latency.
  • Global Tables provides up to 99.999% availability and increased application resiliency.
  • Global Tables uses the Last Write Wins approach for conflict resolution.
  • Global Tables requires DynamoDB streams enabled with New and Old image settings.
  • Global Tables supports both same-account and multi-account replication models (multi-account GA Feb 2026).

Global Tables – Multi-Region Strong Consistency (MRSC)

  • DynamoDB Global Tables now supports Multi-Region Strong Consistency (MRSC), generally available as of June 2025.
  • MRSC enables applications to always read the latest data from any Region, achieving zero Recovery Point Objective (RPO).
  • Provides the highest level of application resilience, removing the need to manage strongly consistent replication manually.
  • Ideal for global applications with strict consistency requirements such as user profile management, inventory tracking, and financial transaction processing.
  • Available in: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland, London, Paris, Frankfurt), Asia Pacific (Tokyo, Seoul, Osaka).
  • Note: Global tables configured for MRSC do not support the multi-account model.

Global Tables – Multi-Region Eventual Consistency (MREC)

  • Default replication mode providing eventual consistency for cross-region reads.
  • Supports strong consistency for same-region reads.
  • Supports both same-account and multi-account replication models.

Global Tables – Multi-Account Replication

  • DynamoDB Global Tables now supports replication across multiple AWS accounts (GA Feb 2026).
  • Adds account-level isolation for stronger resiliency and limits the impact of misconfigurations, security incidents, or account-level issues.
  • Multi-account global tables replicate data across AWS Regions and accounts, providing the same active-active functionality as same-account global tables.
  • Both models support multi-Region writes, asynchronous replication, last-writer-wins conflict resolution, and the same billing model.
  • They differ in how accounts, permissions, encryption, and table governance are managed.
  • Multi-account global tables support only Multi-Region Eventual Consistency (MREC), not MRSC.

Global Tables – Pricing (Nov 2024 Update)

  • Effective November 1, 2024, DynamoDB reduced global tables pricing by up to 67% for on-demand tables (replicated write pricing).
  • For provisioned capacity tables, replicated write pricing was reduced by 33%.
  • After the price reduction, replicated write cost (rWCU/rWRU) is now priced identically to standard single-region WCU/WRU.

Global Tables – AWS FIS Integration

  • DynamoDB supports an AWS Fault Injection Service (FIS) action to pause global table replication (April 2024).
  • Enables simulation and observation of application response to Regional replication pauses.
  • Helps fine-tune monitoring and recovery processes for improved resiliency and availability.

DynamoDB Streams

  • DynamoDB Streams provides a time-ordered sequence of item-level changes made to data in a table.
  • 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
  • DynamoDB Streams APIs help developers consume updates and receive the item-level data before and after items are changed.
  • DynamoDB Streams allow reads at up to twice the rate of the provisioned write capacity of the DynamoDB table.
  • DynamoDB Streams have to be enabled on a per-table basis.
  • DynamoDB streams support Encryption at rest to encrypt the data.
  • DynamoDB Streams is designed for No Duplicates so that every update made to the table will be represented exactly once in the stream.
  • DynamoDB Streams writes stream records in near-real time so that applications can consume these streams and take action based on the contents.
  • DynamoDB streams can be used for multi-region replication to keep other data stores up-to-date with the latest changes to DynamoDB or to take actions based on the changes made to the table
  • DynamoDB stream records can be processed using Kinesis Data Streams, Lambda, KCL application, or Amazon Managed Service for Apache Flink.
  • DynamoDB Streams now supports resource-based policies (March 2024), enabling cross-account stream access without complex IAM role configurations.
  • DynamoDB Streams supports AWS PrivateLink interface endpoints (December 2024), enabling private access to streams over private IP addresses within a VPC.

DynamoDB Streams vs Kinesis Data Streams for DynamoDB

  • DynamoDB offers two streaming models for change data capture (CDC):
    • DynamoDB Streams – Built-in, 24-hour retention, tightly integrated with DynamoDB, ideal for Lambda triggers and event-driven architectures.
    • Kinesis Data Streams for DynamoDB – More flexible retention (up to 365 days), higher throughput, supports multiple consumers, ideal for complex downstream processing pipelines.
  • Kinesis Data Streams captures item-level modifications and replicates them to a Kinesis data stream, allowing continuous capture and storage of terabytes of data per hour.
  • Choose DynamoDB Streams for simpler use cases (Lambda triggers, Global Tables). Choose Kinesis Data Streams for higher throughput, longer retention, or multiple consumers.

DynamoDB Triggers

  • 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 triggers can be used in scenarios like sending notifications, updating an aggregate table, and connecting DynamoDB tables to other data sources.
  • DynamoDB Trigger flow
    • Custom logic for a DynamoDB trigger is stored in an AWS Lambda function as code.
    • A trigger for a given table can be created by associating an AWS Lambda function to the stream (via DynamoDB Streams) on a table.
    • When the table is updated, the updates are published to DynamoDB Streams.
    • In turn, AWS Lambda reads the updates from the associated stream and executes the code in the function.

DynamoDB Backup and Restore

  • DynamoDB on-demand backup helps create full backups of the tables for long-term retention, and archiving for regulatory compliance needs.
  • Backup and restore actions run with no impact on table performance or availability.
  • Backups are preserved regardless of table deletion and retained until they are explicitly deleted.
  • On-demand backups are cataloged, and discoverable.
  • On-demand backups can be created using
    • DynamoDB
      • DynamoDB on-demand backups cannot be copied to a different account or Region.
    • AWS Backup (Recommended)
      • is a fully managed data protection service that makes it easy to centralize and automate backups across AWS services, in the cloud, and on-premises
      • provides enhanced backup features
      • can configure backup schedule, policies and monitor activity for the AWS resources and on-premises workloads in one place.
      • can copy the on-demand backups across AWS accounts and Regions,
      • encryption using an AWS KMS key that is independent of the DynamoDB table encryption key.
      • apply write-once-read-many (WORM) setting for the backups using the AWS Backup Vault Lock policy.
      • add cost allocation tags to on-demand backups, and
      • transition on-demand backups to cold storage for lower costs.

DynamoDB PITR – Point-In-Time Recovery

  • DynamoDB point-in-time recovery – PITR enables automatic, continuous, incremental backup of the table with per-second granularity.
  • PITR helps protect against accidental writes and deletes.
  • PITR can back up tables with hundreds of terabytes of data with no impact on the performance or availability of the production applications.
  • PITR-enabled tables that were deleted can be recovered in the preceding 35 days and restored to their state just before they were deleted.
  • Configurable Recovery Period (Jan 2025): PITR now supports configurable recovery periods. You can set the PITR period for each table between 1 to 35 days (default remains 35 days). This helps meet data compliance and regulatory requirements that need shorter retention periods.
  • Shortening the RecoveryPeriodInDays has no impact on PITR pricing because the price is based on the size of table and local secondary indexes.

DynamoDB Table Deletion Protection

  • DynamoDB supports table deletion protection (March 2023) to prevent accidental deletion during regular maintenance operations.
  • When deletion protection is enabled, the table cannot be deleted via the AWS Management Console, AWS CLI, or API calls unless the feature is explicitly disabled first.
  • Authorized administrators can set the deletion protection property when creating new tables or managing existing tables.
  • Complements other protection strategies like IAM policies, CloudFormation deletion policies, and PITR.

DynamoDB Import and Export

Export to S3

  • DynamoDB supports full and incremental exports to Amazon S3 from tables with PITR enabled.
  • Full Export: Exports the complete table data at any point in time within the PITR recovery window.
  • Incremental Export (Sep 2023): Exports only data that was inserted, updated, or deleted between two specified points in time. Enables efficient CDC pipelines without full table exports.
  • Exports do not affect the read capacity or availability of the table.
  • Data can be exported in DynamoDB JSON or Amazon Ion format.
  • Export per-second granularity for any point in the last 35 days (configurable with PITR recovery period).

Import from S3

  • DynamoDB Import allows importing data from an Amazon S3 bucket to a new DynamoDB table.
  • Supports up to 50,000 S3 objects in a single bulk import (increased from previous limits in March 2024).
  • Removes the need to consolidate S3 objects prior to running a bulk import.

DynamoDB Zero-ETL Integrations

  • DynamoDB offers zero-ETL integrations that seamlessly replicate data to analytics services without building or managing ETL pipelines.

Zero-ETL with Amazon Redshift (GA Oct 2024)

  • Automatically replicates DynamoDB tables into Amazon Redshift within minutes of data being written.
  • Enables SQL queries and analytics on DynamoDB data without complex ETL processes.
  • Supports Amazon Redshift Serverless workgroups or provisioned clusters using RA3 instance types.
  • Data replication begins within a few minutes of changes being written to DynamoDB.

Zero-ETL with Amazon OpenSearch Service (GA Jul 2024)

  • Provides near real-time data replication from DynamoDB to OpenSearch Service using the DynamoDB plugin for OpenSearch Ingestion.
  • Uses DynamoDB export to S3 for initial snapshot loading, then DynamoDB Streams for real-time change replication.
  • Enables powerful full-text search, vector search, and complex analytics on DynamoDB data.
  • Fully managed, code-free solution for seamless data synchronization.

Zero-ETL with Amazon SageMaker Lakehouse (Dec 2024)

  • Automates extracting and loading data from DynamoDB tables into SageMaker Lakehouse.
  • Enables analytics and ML workloads using integrated access control and Apache Iceberg for data interoperability.

Zero-ETL with Amazon S3 Tables (Jul 2025)

  • AWS Glue supports zero-ETL integrations from DynamoDB to S3 Table-backed data lakes.
  • Efficiently extracts and loads data for analysis in S3 Tables.

DynamoDB Warm Throughput

  • DynamoDB warm throughput (November 2024) provides visibility into the number of read and write operations your tables and indexes can readily handle.
  • Pre-warming allows proactively increasing the warm throughput value 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 your table’s throughput incurs a charge.
  • Warm throughput is not a maximum limit; it represents a minimum throughput the table can handle instantly.
  • DynamoDB dynamically increases warm throughput as applications grow, offering consistent performance at any scale.
  • Ideal for anticipated traffic spikes such as product launches, flash sales, or planned events.
  • Pre-warming is an asynchronous operation; you can carry out other table updates while pre-warming is in progress.

DynamoDB Configurable Maximum Throughput

  • DynamoDB supports configurable maximum throughput for on-demand tables (May 2024).
  • Allows optionally setting maximum read or write (or both) throughput for individual on-demand tables and associated secondary indexes.
  • Requests exceeding the maximum throughput are automatically throttled.
  • Provides predictable cost management and protection against accidental surging in consumed resources.
  • Safeguards downstream services with fixed capacity from potential overloading.
  • Maximum throughput values can be modified as needed based on application requirements.

DynamoDB Accelerator – DAX

  • DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for DynamoDB that delivers up to a 10x performance improvement – from milliseconds to microseconds – even at millions of requests per second.
  • DAX is intended for high-performance read applications. As a write-through cache, DAX writes directly so that the writes are immediately reflected in the item cache.
  • DAX as a managed service handles the cache invalidation, data population, or cluster management.
  • DAX provides API-compatible with DynamoDB. Therefore, it requires only minimal functional changes to use with an existing application.
  • DAX saves costs by reducing the read load (RCU) on DynamoDB.
  • DAX helps prevent hot partitions.
  • DAX only supports eventual consistency, and strong consistency requests are passed-through to DynamoDB.
  • DAX is fault-tolerant and scalable.
  • DAX cluster has a primary node and zero or more read-replica nodes. Upon a failure for a primary node, DAX will automatically failover and elect a new primary. For scaling, add or remove read replicas.
  • DAX supports server-side encryption.
  • DAX also supports encryption in transit, ensuring that all requests and responses between the application and the cluster are encrypted by TLS, and connections to the cluster can be authenticated by verification of a cluster x509 certificate.
  • DAX now supports R7i instances (April 2025), powered by 4th Gen Intel Xeon Scalable processors, with instance sizes up to 24xlarge and DDR5 memory.
  • DAX now supports AWS PrivateLink (October 2025), enabling secure access to DAX management APIs (CreateCluster, DescribeClusters, DeleteCluster) over private IP addresses within a VPC.
  • DAX SDK for JavaScript version 3 is now available (March 2025).

DynamoDB Accelerator - DAX

DynamoDB Security Features

Resource-Based Policies (March 2024)

  • DynamoDB supports resource-based policies for tables, indexes, and streams.
  • Allows specifying IAM principals and their permitted actions directly on DynamoDB resources.
  • Simplifies cross-account access control without requiring complex IAM role assumptions.
  • Integrates with AWS IAM Access Analyzer and Block Public Access capabilities.
  • Available in all AWS commercial Regions and GovCloud at no additional cost.

Attribute-Based Access Control – ABAC (Nov 2024 GA)

  • DynamoDB supports ABAC for tables and indexes.
  • ABAC defines access permissions based on tags attached to users, roles, and AWS resources.
  • Uses tag-based conditions in IAM policies to allow or deny specific actions.
  • Automatically applies tag-based permissions to new employees and changing resource structures without rewriting policies.

AWS PrivateLink (March 2024)

  • DynamoDB supports AWS PrivateLink (Interface VPC Endpoints) for private connectivity without public IP addresses.
  • Compatible with AWS Direct Connect and AWS VPN for end-to-end private network connectivity.
  • Eliminates the need for internet gateway or firewall rule configuration for DynamoDB access from on-premises.
  • Supports FIPS 140-3 compliant interface VPC endpoints and Streams endpoints (Dec 2024).

VPC Endpoints

  • DynamoDB supports both Gateway endpoints and Interface endpoints (PrivateLink):
    • Gateway Endpoints: Free, adds route table entries to direct traffic to DynamoDB. Ideal for VPC-to-DynamoDB access with no additional cost.
    • Interface Endpoints (PrivateLink): Creates an ENI with private IP. Supports Direct Connect and VPN. Has per-hour and per-GB costs. Ideal for on-premises-to-DynamoDB access.
  • VPC Gateway endpoints for DynamoDB improve privacy and security, especially those dealing with sensitive workloads with compliance and audit requirements, by enabling private access to DynamoDB from within a VPC without the need for an internet gateway or NAT gateway.
  • VPC endpoints for DynamoDB support IAM policies to simplify DynamoDB access control, where access can be restricted to a specific VPC endpoint.
  • VPC endpoints can be created only for Amazon DynamoDB tables in the same AWS Region as the VPC.
  • DynamoDB Streams can be accessed using Interface endpoints (PrivateLink) only, not Gateway endpoints.

VPC Gateway Endpoints

DynamoDB Pricing Updates (Nov 2024)

  • Effective November 1, 2024, DynamoDB reduced on-demand throughput pricing by 50%.
  • Global tables pricing reduced by up to 67% for on-demand and 33% for provisioned.
  • DynamoDB offers two table classes:
    • DynamoDB Standard: Default table class, optimized for balanced throughput and storage costs.
    • DynamoDB Standard-IA: Reduces storage costs by up to 60% ($0.10/GB vs $0.25/GB) for infrequently accessed data. Higher read/write costs (~25% higher).
  • Standard-IA is ideal when storage is the dominant cost and access patterns are infrequent.

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. What are the services supported by VPC endpoints, using Gateway endpoint type? Choose 2 answers
    1. Amazon S3
    2. Amazon EFS
    3. Amazon DynamoDB
    4. Amazon Glacier
    5. Amazon SQS
  2. A company has setup an application in AWS that interacts with DynamoDB. DynamoDB is currently responding in milliseconds, but the application response guidelines require it to respond within microseconds. How can the performance of DynamoDB be further improved? [SAA-C01]
    1. Use ElastiCache in front of DynamoDB
    2. Use DynamoDB inbuilt caching
    3. Use DynamoDB Accelerator
    4. Use RDS with ElastiCache instead
  3. A company runs a global application that requires strong consistency for reads across all regions. Which DynamoDB feature should be used?
    1. DynamoDB Streams with Lambda replication
    2. DynamoDB Global Tables with eventual consistency
    3. DynamoDB Global Tables with Multi-Region Strong Consistency (MRSC)
    4. DynamoDB with ElastiCache in each region
  4. A company needs to run analytics on DynamoDB data using SQL queries without building ETL pipelines. Which solution requires the least operational overhead?
    1. Export DynamoDB to S3 and query with Athena
    2. Use DynamoDB Streams to replicate to Aurora
    3. Use DynamoDB zero-ETL integration with Amazon Redshift
    4. Use AWS Glue to copy data to Redshift nightly
  5. A company anticipates a major traffic spike during a product launch and wants to ensure their DynamoDB on-demand table can handle the increased load immediately. What feature should they use?
    1. Switch to provisioned capacity mode
    2. Enable DynamoDB Auto Scaling
    3. Pre-warm the table using warm throughput
    4. Add a DAX cluster
  6. A company needs to grant a partner account access to specific DynamoDB tables without creating IAM roles in the partner account. What is the most efficient approach?
    1. Create a cross-account IAM role
    2. Use DynamoDB resource-based policies
    3. Share tables using AWS RAM
    4. Replicate data to the partner account
  7. A company wants to configure DynamoDB PITR with a 7-day recovery window to comply with data minimization regulations. Is this possible?
    1. No, PITR always retains 35 days of backups
    2. Yes, PITR now supports configurable recovery periods between 1-35 days
    3. No, you must use on-demand backups for shorter retention
    4. Yes, but only with AWS Backup
  8. Which DynamoDB streaming option provides retention of up to 365 days and supports multiple consumers? [SAA-C03]
    1. DynamoDB Streams
    2. Kinesis Data Streams for DynamoDB
    3. DynamoDB Triggers
    4. Amazon EventBridge

References

Aurora Global vs DynamoDB Global Tables

AWS Aurora Global Database vs DynamoDB Global Tables
~ Last updated on : ~ jayendrapatil

AWS Aurora Global Database vs. DynamoDB Global Tables vs. Aurora DSQL

Aurora Global Database

  • Aurora Global Database provides a relational database supporting MySQL and PostgreSQL.
  • Aurora Global Database consists of one primary AWS Region where the data is mastered, and up to five read-only, secondary AWS Regions.
  • Aurora cluster in the primary AWS Region performs both read and write operations. The clusters in the secondary Regions enable low-latency reads.
  • Aurora replicates data to the secondary AWS Regions with a typical latency of under a second.
  • Secondary clusters can be scaled independently by adding one or more DB instances (Aurora Replicas) to serve read-only workloads.
  • Aurora Global Database uses dedicated infrastructure to replicate the data, leaving database resources available entirely to serve applications.
  • Applications with a worldwide footprint can use reader instances in the secondary AWS Regions for low-latency reads.
  • Typical cross-region replication takes less than 1 second.
  • In case of a disaster or an outage, one of the clusters in a secondary AWS Region can be promoted to take full read/write workloads in under a minute.
  • However, the process is not automatic. If the primary region becomes unavailable, you must manually remove a secondary region from an Aurora Global Database and promote it to take full reads and writes. You will also need to point the application to the newly promoted region.
  • Architecture: Single-master, multi-reader (one primary region for writes, multiple secondary regions for reads).
  • Consistency: Eventual consistency for cross-region reads.
  • ARC Integration (June 2026): Amazon Application Recovery Controller (ARC) Region switch now supports Aurora serverless scaling and provisioned scaling execution blocks, automating database scaling during multi-Region failover orchestration.

DynamoDB Global Tables

  • DynamoDB Global tables provide NoSQL database.
  • DynamoDB Global tables provide a fully managed, multi-Region, and multi-active database that delivers fast, local, read and write performance for massively scaled, global applications.
  • Global tables replicate the DynamoDB tables automatically across the choice of AWS Regions and enable reads and writes on all instances.
  • DynamoDB global table consists of multiple replica tables (one per AWS Region). Every replica has the same table name and the same primary key schema. When an application writes data to a replica table in one Region, DynamoDB propagates the write to the other replica tables in the other AWS Regions automatically.
  • Global tables enable the read and write of data locally providing single-digit-millisecond latency for the globally distributed application at any scale.
  • DynamoDB Global tables are designed for 99.999% availability.
  • DynamoDB Global tables enable the applications to stay highly available even in the unlikely event of isolation or degradation of an entire Region. Applications can redirect to a different Region and perform reads and writes against a different replica table.
  • Cross-Account Replication (February 2026): DynamoDB Global Tables now support replication across multiple AWS accounts, providing account-level isolation for stronger governance, security, and blast-radius control. Currently supported for MREC tables only.

DynamoDB Global Tables Consistency Modes

  • DynamoDB Global Tables support two consistency modes:

Multi-Region Eventual Consistency (MREC) – Default

  • Provides asynchronous replication with approximately 1-second replication latency for tables between two or more Regions.
  • Multi-active: All replicas accept reads and writes.
  • Conflict Resolution: Last Write Wins based on internal timestamp.
  • RPO: Approximately 1 second (replication delay).
  • Best for applications that can tolerate eventual consistency.
  • Supports multi-account global tables for account-level isolation (February 2026).

Multi-Region Strong Consistency (MRSC) – January 2025

  • Announced at AWS re:Invent 2024 and generally available in January 2025.
  • Provides synchronous replication across Regions.
  • Strongly consistent reads always return the latest version of an item, irrespective of the Region.
  • Zero RPO: Enables Recovery Point Objective of zero.
  • Item changes are synchronously replicated to at least one other Region before write returns success.
  • Deployment: Must be deployed in exactly three Regions (3 replicas OR 2 replicas + 1 witness).
  • Regional Availability: Three Region sets (US, EU, AP) – cannot span Region sets.
  • Trade-off: Higher write latency compared to MREC due to synchronous replication.
  • Best for applications requiring global strong consistency and zero data loss.
  • AWS FIS Integration (January 2026): MRSC global tables now support application resiliency testing with AWS Fault Injection Service (FIS), enabling controlled fault injection experiments to validate failover behavior and regional resilience.
  • Does not support multi-account model (cross-account replication is MREC only).

Amazon Aurora DSQL (GA May 2025)

  • Amazon Aurora DSQL is a serverless distributed SQL database with active-active high availability, announced at re:Invent 2024 and generally available since May 27, 2025.
  • Provides PostgreSQL-compatible (based on PostgreSQL 16) distributed SQL with multi-Region strong consistency.
  • Active-active architecture: All database resources are peers capable of handling both read and write traffic, within a Region and across Regions. No leader, no failover lag.
  • Strong consistency: All reads and writes to any Regional endpoint are strongly consistent and durable — not eventually consistent.
  • Zero RPO: Synchronous data replication with automated zero data loss failover.
  • Serverless: No servers to provision, patch, or manage. Scales to zero when idle. Provisions in under 60 seconds.
  • Designed for 99.99% single-Region and 99.999% multi-Region availability.
  • Multi-Region deployment: Supports linked multi-Region clusters (currently two Regions).
  • Automatic failover: No manual intervention required. Applications use DNS-based routing (Route 53) for automatic Region redirection.
  • Independently scales reads, writes, compute, and storage with no manual intervention.
  • Supports SQL including secondary indexes, joins, and transactions — unlike DynamoDB’s NoSQL model.
  • Limitations: Based on PostgreSQL 16 but does not support all PostgreSQL features. Subset of commonly used queries and features supported.
  • Fills the gap between DynamoDB’s serverless economics and Aurora PostgreSQL’s SQL power with global consistency.

Comparison Table

Feature Aurora Global Database DynamoDB Global Tables (MREC) DynamoDB Global Tables (MRSC) Aurora DSQL
Database Type Relational (MySQL, PostgreSQL) NoSQL (Key-Value, Document) NoSQL (Key-Value, Document) Relational (PostgreSQL-compatible)
Architecture Single-master, multi-reader Multi-active (all replicas read/write) Multi-active (all replicas read/write) Active-active (all peers read/write)
Max Regions 1 primary + 5 secondary (6 total) Unlimited (any Region with DynamoDB) Exactly 3 Regions 2 linked Regions (multi-Region cluster)
Replication Type Asynchronous Asynchronous Synchronous Synchronous
Replication Latency < 1 second ~1 second Synchronous (no delay) Synchronous (no delay)
Cross-Region Writes No (primary region only) Yes (all replicas) Yes (all replicas) Yes (all peers)
Consistency Eventual (cross-region reads) Eventual (cross-region reads) Strong (all reads) Strong (all reads and writes)
RPO ~1 second ~1 second Zero (0) Zero (0)
RTO < 1 minute (manual failover) Seconds (automatic) Seconds (automatic) Automatic (no manual intervention)
Failover Manual promotion required Automatic (redirect to another replica) Automatic (redirect to another replica) Automatic (DNS-based routing)
Availability SLA 99.99% 99.999% 99.999% 99.999% (multi-Region)
Serverless No (instance-based, Serverless v2 option) Yes (on-demand or provisioned) Yes (on-demand or provisioned) Yes (fully serverless, scales to zero)
SQL Support Full SQL (MySQL/PostgreSQL) NoSQL API only NoSQL API only PostgreSQL-compatible SQL (subset)
Cross-Account No Yes (February 2026) No No
Use Cases Complex queries, joins, transactions, relational data High-scale, low-latency, eventual consistency acceptable Global strong consistency, zero data loss, financial apps Global SQL transactions, serverless, strong consistency

When to Choose Aurora Global Database

  • Relational Data Model: Need full SQL, complex queries, joins, and transactions.
  • MySQL/PostgreSQL Compatibility: Existing applications using these databases with full feature support.
  • Single-Master Writes: Write operations centralized in one region is acceptable.
  • Read-Heavy Workloads: Global read replicas for low-latency reads worldwide.
  • Complex Analytics: Need advanced SQL features and reporting.
  • More Than 2 Regions: Need up to 6 regions (vs. Aurora DSQL’s 2-region limit).
  • Disaster Recovery: Can tolerate manual failover process (under 1 minute).

When to Choose DynamoDB Global Tables (MREC)

  • NoSQL Data Model: Key-value or document data structure.
  • Multi-Active Writes: Need to write to multiple regions simultaneously.
  • Massive Scale: Require unlimited scalability with single-digit millisecond latency.
  • High Availability: Need 99.999% availability with automatic failover.
  • Eventual Consistency Acceptable: Can tolerate ~1 second replication delay.
  • Cross-Account Isolation: Need multi-account replication for governance and security.
  • Unlimited Regions: Need replication across many regions globally.

When to Choose DynamoDB Global Tables (MRSC)

  • Zero RPO Required: Cannot tolerate any data loss.
  • Global Strong Consistency: Need latest data across all regions immediately.
  • NoSQL Data Model: Key-value/document data with strong consistency needs.
  • Financial Applications: Banking, payments, trading systems.
  • Inventory Management: Global inventory with strict consistency.
  • Compliance Requirements: Regulations requiring zero data loss.
  • Three-Region Deployment: Can deploy in exactly three regions within same region set (US, EU, or AP).

When to Choose Aurora DSQL

  • Global SQL with Strong Consistency: Need SQL (joins, indexes, transactions) with multi-region strong consistency.
  • Active-Active SQL Writes: Need both regions to accept writes — unlike Aurora Global Database’s single-master.
  • Serverless with Scale-to-Zero: Want to avoid instance management entirely with pay-per-use pricing.
  • Zero RPO + SQL: Need zero data loss with relational database capabilities.
  • Financial Transactions: Global-scale financial apps requiring strong consistency and SQL.
  • Automatic Failover: Need automated zero-intervention failover (unlike Aurora Global Database’s manual process).
  • Two-Region Deployment: Workload fits within a two-region active-active topology.
  • Note: Does not support full PostgreSQL feature set — evaluate supported features for your use case.

AWS Aurora Global Database vs DynamoDB Global Tables

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 needs to implement a relational database with a multi-region disaster recovery Recovery Point Objective (RPO) of 1 second and a Recovery Time Objective (RTO) of 1 minute. Which AWS solution can achieve this?
    1. Amazon Aurora Global Database
    2. Amazon DynamoDB global tables
    3. Amazon RDS for MySQL with Multi-AZ enabled
    4. Amazon RDS for MySQL with a cross-Region snapshot copy
  2. A financial services company requires a globally distributed database with zero data loss (RPO = 0) and strong consistency across all regions. Which solution should they choose?
    1. Amazon Aurora Global Database
    2. Amazon DynamoDB Global Tables with MREC
    3. Amazon DynamoDB Global Tables with MRSC
    4. Amazon RDS with cross-region read replicas
  3. A company needs a multi-region database that supports writes in all regions simultaneously with automatic failover. Which solution provides this capability?
    1. Amazon Aurora Global Database
    2. Amazon DynamoDB Global Tables
    3. Amazon RDS Multi-AZ
    4. Amazon Aurora with read replicas
  4. What is the primary difference between Aurora Global Database and DynamoDB Global Tables in terms of write operations?
    1. Aurora supports writes in all regions, DynamoDB only in primary region
    2. Aurora supports writes only in primary region, DynamoDB supports writes in all regions
    3. Both support writes in all regions
    4. Both support writes only in primary region
  5. A company needs to deploy a DynamoDB Global Table with MRSC. How many regions must they deploy in?
    1. Minimum 2 regions
    2. Exactly 3 regions
    3. Up to 5 regions
    4. Unlimited regions
  6. Which of the following statements about Aurora Global Database and DynamoDB Global Tables are correct? (Select TWO)
    1. Aurora Global Database requires manual failover, DynamoDB Global Tables support automatic failover
    2. Aurora Global Database supports NoSQL, DynamoDB supports SQL
    3. DynamoDB Global Tables offer 99.999% availability, Aurora offers 99.99%
    4. Aurora Global Database supports multi-active writes
    5. DynamoDB MRSC has higher replication latency than Aurora
  7. A company needs a globally distributed relational database with active-active writes, serverless operations, and strong consistency. They require SQL support including joins and transactions. Which AWS service best meets these requirements?
    1. Amazon Aurora Global Database
    2. Amazon DynamoDB Global Tables with MRSC
    3. Amazon Aurora DSQL
    4. Amazon RDS with read replicas
  8. A company operates DynamoDB Global Tables and needs to replicate data across multiple AWS accounts for security isolation and governance. Which consistency mode supports this?
    1. Multi-Region Eventual Consistency (MREC)
    2. Multi-Region Strong Consistency (MRSC)
    3. Both MREC and MRSC
    4. Neither — cross-account replication is not supported
  9. Which of the following AWS database solutions provides BOTH zero RPO and active-active multi-region writes with SQL support? (Select TWO)
    1. Amazon Aurora Global Database
    2. Amazon DynamoDB Global Tables with MRSC
    3. Amazon Aurora DSQL
    4. Amazon RDS Multi-AZ
    5. Amazon ElastiCache Global Datastore

References

AWS DynamoDB Best Practices

~ Last updated on : ~ jayendrapatil

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

AWS Storage Options – RDS, DynamoDB & Database on EC2

~ Last updated on : ~ jayendrapatil ~ 17 Comments

AWS Storage Options Whitepaper with RDS, DynamoDB & Database on EC2 Cont.

Provides a brief summary for the Ideal Use cases, Anti-Patterns and other factors for Amazon RDS, DynamoDB & Databases on EC2 storage options

📝 Note: The original AWS Storage Services Overview whitepaper has been archived by AWS. This content is maintained and updated with current service capabilities for certification study reference. See the AWS Overview – Storage Services for the latest official guidance.

Amazon RDS

  • RDS is a fully managed relational database service supporting Amazon Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and Microsoft SQL Server database engines
  • RDS eliminates much of the administrative overhead associated with launching, managing, and scaling your own relational database on Amazon EC2 or in another computing environment.
  • RDS provides automated patching, backups, Multi-AZ high availability, read replicas, and monitoring out of the box.

Key Features (Updated 2024-2026)

  • Multi-AZ DB Cluster Deployments – deploys a primary and two readable standby instances across three AZs, providing faster failover (~35 seconds), improved commit latency via semisynchronous replication, and readable standbys (MySQL/PostgreSQL)
  • Blue/Green Deployments – creates a fully managed staging (green) environment that mirrors production (blue), allowing safe testing of major version upgrades and schema changes with minimal downtime switchover
  • RDS Proxy – a fully managed database proxy that pools and shares connections, improving application scalability, resilience to database failovers, and security via IAM/Secrets Manager authentication
  • RDS Data API – available for Aurora (Serverless v2 and provisioned), enables secure HTTP-based SQL execution without managing database drivers or connections
  • Aurora Serverless v2 – auto-scales database capacity in fine-grained increments based on application demand, scaling to hundreds of thousands of transactions per second
  • Aurora DSQL (launched Dec 2024) – a serverless, distributed SQL database with active-active multi-Region high availability, PostgreSQL-compatible, with strong consistency across all Regional endpoints
  • RDS Custom – provides OS and database access for Oracle and SQL Server when full administrative control is needed (Note: RDS Custom for Oracle reaches end of support March 31, 2027)
  • Graviton (ARM) Instances – M7g, R7g, M7i, R7i instance types offering better price-performance
  • gp3 Storage – baseline of 3,000 IOPS and 125 MiB/s, scalable up to 80,000 IOPS and 2,000 MiB/s per volume (up to 64 TiB per volume)
  • Extended Support – up to 3 additional years of critical security and bug fixes beyond community end-of-life for major engine versions

Ideal Usage Patterns

  • RDS is a great solution for cloud-based fully-managed relational database
  • RDS is also optimal for new applications with structured data that requires more sophisticated querying and joining capabilities than that provided by Amazon’s NoSQL database offering, DynamoDB.
  • RDS provides full compatibility with the databases supported and direct access to native database engines, code and libraries and is ideal for existing applications that rely on these databases
  • Applications requiring zero-downtime upgrades can leverage Blue/Green Deployments for safe major version changes
  • Serverless and event-driven applications benefit from RDS Proxy and Aurora Serverless v2 for connection management and auto-scaling

Anti-Patterns

  • Index and query-focused data
    • If the applications don’t require advanced features such as joins and complex transactions and is more oriented toward indexing and querying data, DynamoDB would be more appropriate for this needs
  • Numerous BLOBs
    • If the application makes heavy use of files (audio files, videos, images, etc), it is a better choice to use S3 to store the objects instead of database engines Blob feature and use RDS or DynamoDB only to save the metadata
  • Automated scalability
    • RDS provides vertical scaling (scale up) and limited horizontal scale-out via read replicas. For fully-automated serverless scaling, consider Aurora Serverless v2 or DynamoDB.
  • Complete control
    • RDS does not provide full OS-level admin access.
    • If the application requires complete OS-level control, consider RDS Custom (for Oracle/SQL Server) or a self-managed database on EC2.
  • Other database platforms
    • RDS supports Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server.
    • If any other database platform (such as IBM DB2, Informix, or Sybase) is needed, it should be deployed on a self-managed database on an EC2 instance.

Performance

  • RDS offers multiple storage types optimized for different workloads:
    • gp3 (General Purpose SSD) – baseline 3,000 IOPS, scalable up to 80,000 IOPS and 2,000 MiB/s throughput, up to 64 TiB per volume
    • io1/io2 (Provisioned IOPS SSD) – designed for I/O-intensive transactional workloads, up to 256,000 IOPS
  • Multi-AZ DB Cluster deployments provide improved write commit latency through optimized semisynchronous replication
  • Performance Insights provides a dashboard to monitor database load and identify bottlenecks
  • RDS Optimized Reads/Writes (Aurora) provide up to 2x faster query processing and 6x higher write throughput

Durability and Availability

  • RDS leverages Amazon EBS volumes as its data store
  • RDS provides database backups, for enhanced durability, which are replicated across multiple AZ’s
    • Automated backups
      • RDS automatically performs a full daily backup during the specified backup window, and captures DB transaction logs (up to 35-day retention)
    • User initiated backups (DB Snapshots)
      • User can initiate manual snapshots at any time; they are retained until explicitly deleted
  • Multi-AZ DB Instance – synchronously replicates data to a standby in another AZ with automatic failover (typically 60-120 seconds)
  • Multi-AZ DB Cluster – maintains a primary and two readable standbys across three AZs with faster failover (~35 seconds) and transaction log-based replication
  • RDS provides a DNS endpoint; in case of failure on the primary, it automatically fails over to the standby instance
  • RDS Read Replicas provide asynchronous replication for read scaling and can be promoted for disaster recovery (including cross-Region replicas)

Cost Model

  • RDS offers a tiered pricing structure based on instance size, deployment type (Single-AZ/Multi-AZ Instance/Multi-AZ Cluster), and AWS Region
  • Pricing components: DB instance hours, provisioned storage (per GB-month), I/O requests (for io1/io2), additional backup storage, and data transfer
  • Reserved Instances provide significant discounts (up to 69%) for 1-year or 3-year commitments
  • Aurora Serverless v2 charges per Aurora Capacity Unit (ACU) consumed per second

Scalability and Elasticity

  • RDS resources can be scaled in several dimensions: storage size, IOPS, instance compute capacity, and number of read replicas
  • Storage Auto Scaling automatically increases storage when approaching capacity limits
  • Aurora Auto Scaling automatically adjusts the number of Aurora Replicas based on demand
  • Aurora Serverless v2 scales compute capacity automatically in fine-grained increments (0.5 ACU) from minimum to maximum configured capacity
  • Read Replicas (up to 15 for Aurora, 5 for other engines) enable read scaling across AZs and Regions
  • Aurora Limitless Database provides horizontal write scaling by automatically sharding data across multiple writer instances

Interfaces

  • RDS APIs, AWS CLI, and the AWS Management Console provide management interfaces for creating, modifying, and managing DB instances
  • RDS Data API (Aurora) provides a secure HTTP endpoint for running SQL statements without managing database connections or drivers
  • Once a database is created, RDS provides a DNS endpoint for the database which can be used to connect using standard database drivers
  • Endpoint does not change over the lifetime of the instance, even during failover in Multi-AZ configurations
  • RDS Proxy endpoints provide connection pooling and improved failover handling for applications

Amazon DynamoDB

  • Amazon DynamoDB is a fully managed, serverless NoSQL database service that delivers single-digit millisecond performance at any scale.
  • DynamoDB offers zero infrastructure management, zero downtime maintenance, and automatic scaling to accommodate any workload demand.
  • DynamoDB provides both eventually-consistent reads (by default) and strongly-consistent reads (optional), as well as ACID transactions (TransactWriteItems, TransactGetItems) for coordinated operations across multiple items and tables.
  • Amazon DynamoDB handles data as follows:
    • DynamoDB stores structured data in tables, indexed by primary key, and allows low-latency read and write access to items.
    • DynamoDB supports rich data types: Scalar (String, Number, Binary, Boolean, Null), Document (List, Map), and Set (String Set, Number Set, Binary Set)
    • Tables do not have a fixed schema, so each data item can have a different number of attributes.
    • Primary key can either be a single-attribute partition key (hash key) or a composite partition key + sort key (hash-range key).
    • Local Secondary Indexes (LSI) – alternate sort key on the same partition key (defined at table creation)
    • Global Secondary Indexes (GSI) – alternate partition key and optional sort key, can be added/modified anytime

Key Features (Updated 2024-2026)

  • On-Demand Capacity Mode – pay-per-request pricing with no capacity planning; automatically scales to accommodate workload demand. 50% price reduction effective November 2024.
  • Global Tables – fully managed, multi-Region, multi-active replication with two consistency modes:
    • Multi-Region Eventual Consistency (MREC) – default mode, typically sub-second replication
    • Multi-Region Strong Consistency (MRSC) – GA 2025, provides zero RPO with strongly consistent reads/writes across all Regions
  • DynamoDB Accelerator (DAX) – fully managed, in-memory cache providing microsecond read latency for read-heavy workloads
  • Standard-IA Table Class – lower storage cost option (up to 60% cheaper storage) for infrequently accessed data
  • PartiQL – SQL-compatible query language for DynamoDB, enabling familiar SELECT, INSERT, UPDATE, DELETE syntax
  • Zero-ETL Integrations – seamless data replication to Amazon Redshift, OpenSearch Service, and SageMaker Lakehouse without building ETL pipelines
  • S3 Import/Export – bulk import data from S3 and export table data to S3 in DynamoDB JSON or Amazon Ion format
  • Point-in-Time Recovery (PITR) – continuous backups with per-second granularity, restorable to any point within a configurable 1-35 day window
  • Encryption at Rest – enabled by default using AWS owned keys, with options for AWS managed key or customer managed KMS key
  • DynamoDB Streams / Kinesis Data Streams – capture item-level changes for event-driven architectures, real-time analytics, and cross-Region replication

Ideal Usage Patterns

  • DynamoDB is ideal for applications that need a flexible NoSQL database with low read and write latencies, and the ability to scale storage and throughput up or down as needed without code changes or downtime.
  • Use cases requiring a highly available and scalable database e.g., mobile apps, gaming, digital ad serving, live voting, sensor networks, log ingestion, access control, metadata storage for S3 objects, e-commerce shopping carts, web session management, and serverless applications
  • Event-driven architectures leveraging DynamoDB Streams to trigger Lambda functions or downstream processing
  • Global applications requiring multi-Region active-active deployments with Global Tables

Anti-Patterns

  • Structured data with Join and/or Complex Transactions
    • If the application uses structured data and requires complex joins, multi-table transactions, or relationship infrastructure provided by traditional relational databases, RDS or Aurora would be a better choice. (Note: DynamoDB does support ACID transactions within and across tables, but not SQL-style joins.)
  • Large Blob data
    • DynamoDB has a maximum item size of 400 KB. For large media files, videos, etc., use S3 for storage and DynamoDB for metadata.
  • Large Objects with Low I/O rate
    • DynamoDB uses SSD drives and is optimized for high I/O workloads. If the application stores very large amounts of infrequently accessed data, S3 or the Standard-IA table class might be more cost-effective.
  • Complex ad-hoc analytics
    • For complex analytical queries across large datasets, use DynamoDB zero-ETL integration with Amazon Redshift or export to S3 for Athena queries.

Performance

  • SSDs and limited indexing on attributes provides single-digit millisecond latency at any scale.
  • Provisioned capacity mode – define exact read/write capacity units for predictable workloads with optional auto-scaling
  • On-demand capacity mode – automatically accommodates up to double previous peak traffic instantly, with further scaling within minutes
  • DAX (DynamoDB Accelerator) – in-memory cache providing microsecond response times for eventually consistent reads
  • DynamoDB automatically partitions data to maintain consistent performance as tables grow.

Durability and Availability

  • DynamoDB automatically and synchronously replicates data across three AZs in a Region for high availability and data protection against facility failures.
  • Global Tables provide multi-Region replication with 99.999% availability SLA (multi-Region)
  • PITR provides continuous backups for point-in-time restore capability
  • On-demand backups allow full table backups at any time without performance impact

Cost Model

  • DynamoDB offers two capacity modes:
    • On-Demand – pay per read/write request (no capacity planning). 50% price reduction since November 2024.
    • Provisioned – pay per hour for provisioned Read/Write Capacity Units (with optional auto-scaling and Reserved Capacity discounts)
  • Additional pricing components: data storage (per GB-month), Global Tables replication (per replicated write unit), backups, data export/import, DynamoDB Streams reads, and data transfer
  • Standard-IA table class reduces storage costs by up to 60% with higher per-request costs (ideal when storage dominates)
  • Global Tables pricing reduced by up to 67% (November 2024)

Scalability and Elasticity

  • DynamoDB is both highly-scalable and elastic with virtually unlimited storage and throughput capacity.
  • Data is automatically partitioned and re-partitioned as needed, while SSD storage provides predictable low-latency at any scale.
  • On-Demand mode provides truly serverless scaling with no capacity planning required
  • Provisioned mode with Auto Scaling automatically adjusts capacity based on utilization targets
  • DynamoDB can handle more than 10 trillion requests per day and support peaks of more than 100 million requests per second.

Interfaces

  • DynamoDB provides a low-level REST API, AWS SDKs in multiple languages, and the AWS CLI
  • PartiQL – SQL-compatible query language supported via Console, CLI, SDKs, and NoSQL Workbench
  • APIs provide both management and data interfaces: table management (create, list, delete, describe) and item operations (Get, Put, Update, Delete, Query, Scan, BatchWrite, BatchGet, TransactWrite, TransactGet)
  • DynamoDB Streams API – captures ordered sequence of item-level changes
  • NoSQL Workbench – visual tool for data modeling, visualization, and query development

Databases on EC2

  • EC2 with EBS volumes allows hosting a self-managed relational database with full OS and database administrative control
  • Ready-to-use, prebuilt AMIs are available from leading database vendors in AWS Marketplace
  • Note: With the introduction of RDS Custom (for Oracle and SQL Server), the need for self-managed databases on EC2 has decreased for these specific engines

Ideal Usage Patterns

  • Self-managed database on EC2 is ideal for applications that require a specific database platform not supported by Amazon RDS e.g., IBM DB2, Informix, Sybase, or specialized configurations
  • Applications requiring maximum level of administrative control and configurability including custom storage engines, specialized replication, or kernel-level tuning not available in RDS or RDS Custom
  • Database versions or configurations not yet supported by RDS

Anti-Patterns

  • Index and query-focused data
    • If the applications don’t require advanced features such as joins and complex transactions and is more oriented toward indexing and querying data, DynamoDB would be more appropriate
  • Numerous BLOBs
    • If the application makes heavy use of files (audio files, videos, images), use S3 for object storage and RDS or DynamoDB for metadata
  • Managed service available
    • If RDS supports the database engine and provides the needed features, RDS is preferred for reduced operational overhead. For Oracle/SQL Server requiring OS access, consider RDS Custom before self-managing on EC2.
  • Automated scalability
    • Self-managed databases require manual or scripted scaling operations. If fully-automated scaling is needed, DynamoDB, Aurora Serverless, or RDS with Auto Scaling may be better choices.

Performance

  • Performance depends on the EC2 instance type, number/configuration of EBS volumes, and database tuning
  • Scale up by choosing larger instance types (compute-optimized, memory-optimized) or Graviton-based instances for better price-performance
  • For storage: use gp3 or io2 Block Express EBS volumes. Use software RAID 0 (disk striping) across multiple EBS volumes for aggregated IOPS and bandwidth
  • Instance store (NVMe SSDs) can provide very high IOPS for temporary/cache workloads

Durability & Availability

  • Uses EBS for storage with same durability guarantees (99.999% availability for io2 Block Express)
  • Enhanced durability via EBS snapshots, cross-Region replication, or third-party backup tools (e.g., Oracle RMAN) to S3
  • High availability requires manual configuration: Multi-AZ replication, clustering solutions, or automated failover scripts

Cost Model

  • Cost determined by: EC2 instance size/type, EBS volume size and IOPS, data transfer, and any third-party database licensing costs
  • Savings Plans and Reserved Instances reduce EC2 compute costs for steady-state workloads
  • BYOL (Bring Your Own License) options available for Oracle, SQL Server, and other commercial databases

Scalability & Elasticity

  • Leverage EC2 scalability by creating AMIs for horizontal scaling, though database-specific clustering/sharding is required
  • Vertical scaling requires instance stop/start (brief downtime without clustering)
  • Auto Scaling groups can manage read replica fleets for read-heavy workloads

Comparison: RDS vs DynamoDB vs Database on EC2

Factor Amazon RDS DynamoDB Database on EC2
Type Managed Relational (SQL) Managed NoSQL (Key-Value/Document) Self-Managed Relational
Scaling Vertical + Read Replicas; Aurora Serverless for auto-scaling Fully automatic (on-demand) or provisioned with auto-scaling Manual vertical/horizontal
Availability Multi-AZ (2 or 3 AZs), automated failover Automatic across 3 AZs; Global Tables for multi-Region Manual HA configuration required
Admin Overhead Low (managed patching, backups) None (serverless) High (full responsibility)
Use Case Complex queries, joins, ACID transactions High-speed key-value access, flexible schema, massive scale Unsupported engines, full OS control

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. A client application requires operating system privileges on a relational database server. What is an appropriate configuration for highly available database architecture?
    1. A standalone Amazon EC2 instance
    2. Amazon RDS in a Multi-AZ configuration
    3. Amazon EC2 instances in a replication configuration utilizing a single Availability Zone
    4. Amazon EC2 instances in a replication configuration utilizing two different Availability Zones

    Note: With the introduction of RDS Custom, this question’s context has evolved. RDS Custom for SQL Server now supports Multi-AZ. However, for full OS-level control beyond what RDS Custom offers, EC2 remains the answer.

  3. You are developing a new mobile application and are considering storing user preferences in AWS, which would provide a more uniform cross-device experience to users using multiple mobile devices to access the application. The preference data for each user is estimated to be 50KB in size. Additionally 5 million customers are expected to use the application on a regular basis. The solution needs to be cost-effective, highly available, scalable and secure, how would you design a solution to meet the above requirements?
    1. Setup an RDS MySQL instance in 2 availability zones to store the user preference data. Deploy a public facing application on a server in front of the database to manage security and access credentials
    2. Setup a DynamoDB table with an item for each user having the necessary attributes to hold the user preferences. The mobile application will query the user preferences directly from the DynamoDB table. Utilize STS. Web Identity Federation, and DynamoDB Fine Grained Access Control to authenticate and authorize access (DynamoDB provides high availability as it synchronously replicates data across three facilities within an AWS Region and scalability as it is designed to scale its provisioned throughput up or down while still remaining available. Also suitable for storing user preference data)
    3. Setup an RDS MySQL instance with multiple read replicas in 2 availability zones to store the user preference data. The mobile application will query the user preferences from the read replicas. Leverage the MySQL user management and access privilege system to manage security and access credentials.
    4. Store the user preference data in S3 Setup a DynamoDB table with an item for each user and an item attribute pointing to the user’ S3 object. The mobile application will retrieve the S3 URL from DynamoDB and then access the S3 object directly utilize STS, Web identity Federation, and S3 ACLs to authenticate and authorize access.
  4. A customer is running an application in US-West (Northern California) region and wants to setup disaster recovery failover to the Asian Pacific (Singapore) region. The customer is interested in achieving a low Recovery Point Objective (RPO) for an Amazon RDS multi-AZ MySQL database instance. Which approach is best suited to this need?
    1. Synchronous replication
    2. Asynchronous replication (Cross-Region Read Replicas use asynchronous replication. Note: DynamoDB Global Tables with MRSC now offers zero RPO across Regions for NoSQL workloads.)
    3. Route53 health checks
    4. Copying of RDS incremental snapshots
  5. 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?
    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.
    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.
    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.
  6. Company ABCD has recently launched an online commerce site for bicycles on AWS. They have a “Product” DynamoDB table that stores details for each bicycle, such as, manufacturer, color, price, quantity and size to display in the online store. Due to customer demand, they want to include an image for each bicycle along with the existing details. Which approach below provides the least impact to provisioned throughput on the “Product” table?
    1. Serialize the image and store it in multiple DynamoDB tables
    2. Create an “Images” DynamoDB table to store the Image with a foreign key constraint to the “Product” table
    3. Add an image data type to the “Product” table to store the images in binary format
    4. Store the images in Amazon S3 and add an S3 URL pointer to the “Product” table item for each image
  7. A company needs to store IoT sensor data from thousands of devices. The data is small (under 1KB per reading), arrives at unpredictable rates, and must be queryable by device ID and timestamp with single-digit millisecond latency. Which database solution is most appropriate?
    1. Amazon RDS MySQL with Multi-AZ
    2. Self-managed Cassandra on EC2
    3. Amazon DynamoDB with on-demand capacity mode (DynamoDB with on-demand mode is ideal: handles unpredictable workloads without capacity planning, supports composite key (device ID as partition key, timestamp as sort key), and provides single-digit millisecond latency)
    4. Amazon Aurora Serverless
  8. A company wants to perform real-time analytics on data stored in their DynamoDB table without impacting production read/write performance. Which approach is the most operationally efficient?
    1. Create a read replica of the DynamoDB table
    2. Export data to S3 on a scheduled basis and query with Athena
    3. Use DynamoDB zero-ETL integration with Amazon Redshift (Zero-ETL integration provides near real-time data replication to Redshift without building custom pipelines or impacting DynamoDB performance)
    4. Use DynamoDB Streams with a Lambda function to copy data to RDS