Amazon DynamoDB FAQs

DynamoDB enables customers to offload the administrative burdens of operating and scaling distributed databases to AWS so that they don’t have to worry about hardware provisioning, setup and configuration, throughput capacity planning, replication, software patching, or cluster scaling. You can deploy a distributed, NoSQL database in a matter of minutes. DynamoDB automatically scales throughput capacity to meet workload demands, and partitions and repartitions your data as your table size grows. Also, DynamoDB synchronously replicates data across three Availability Zones (AZs) in an AWS Region, giving you high availability and data durability.

DynamoDB unique advantages include that it is a proven fully managed, scale-to-zero serverless database that provides single-digit millisecond performance and up to 99.999% availability. With its consistent performance at scale, DynamoDB also offers built-in security, durability, and the reliability required for global applications with the most stringent requirements. With its ease of use, DynamoDB is often chosen for both new data-driven and generative AI applications and established internet-scale applications seeking consistent fast performance with limitless scalability.

Yes. DynamoDB is a fully managed cloud service that you access via API. Applications running on any operating system (such as Linux, Windows, iOS, Android, Solaris, AIX, and HP-UX) can use DynamoDB. We recommend using the AWS SDKs to get started with DynamoDB.

DynamoDB table classes are performance and cost optimization options for DynamoDB tables. The two table classes available are DynamoDB Standard (default table class designed for workloads that require maximum performance and best suited for tables with unpredictable workloads), and DynamoDB Standard-Infrequent Access (table class optimized for tables where storage is the dominant cost and ideal for tables that store infrequently accessed data). Standard tables have lower costs for reads and writes but higher storage costs. Standard-IA tables have lower storage costs but higher costs for reads and writes. You can switch between these table classes twice in a 30-day period without downtime, allowing you to optimize your costs based on your table's usage patterns. The choice between these classes depends on the specific needs of your application and the access patterns of your data.

There are several factors to consider when choosing a table class in DynamoDB. The most common ones to consider are your data’s access patterns, cost considerations, and workload predictability. You can switch between table classes without any coding or downtime, so you can adjust your choice if your needs change over time.

DynamoDB Standard-IA (Infrequent Access) tables work seamlessly with existing DynamoDB features. They use the same APIs as regular DynamoDB tables, so you can use them with existing applications without code changes. They support Global Tables for multi-Region replication, point-in-time recovery (PITR), on-demand backups, encryption at rest using AWS Key Management Service (KMS), DynamoDB Streams, Time To Live to automatically delete items, and transactional read and write operations. Standard-IA tables are compatible with DynamoDB Accelerator (DAX).

Amazon DynamoDB stores data in partitions. A partition is an allocation of storage for a table, backed by solid state drives (SSDs) and automatically replicated across multiple Availability Zones within an AWS Region. Partition management is handled entirely by DynamoDB—you never have to manage partitions yourself.

The maximum size of an item that can be stored in a DynamoDB table is 400 KB. There are no predefined storage limits.

Yes, DynamoDB can store BLOB; however, it is not generally suited to storing documents or images. A better architectural pattern is to store pointers to Amazon S3 objects in a DynamoDB table.

There is no set expiration or deletion time for data stored in an Amazon DynamoDB table by default. Data will remain in the table indefinitely unless explicitly deleted by the customer or through Time to Live (TTL) deletes if TTL is enabled.

There is no predefined limit to the number of items that can be stored in a DynamoDB table. DynamoDB scales to hundreds of terabytes or more of data across any number of items.

While it's technically possible to store images in DynamoDB as binary data (base64-encoded), there are some limitations and drawbacks due to the 400KB item limit size. Instead of storing images directly in DynamoDB, a better practice is to store the images in Amazon S3 (Simple Storage Service) and then store the S3 object URL or key in DynamoDB.

To store a list in DynamoDB, you need to use one of DynamoDB's list data types - either a List or a Set. When writing items to the table, the value for that attribute can be an array or collection of scalar (non-object) data types like strings, numbers etc. DynamoDB will automatically take care of serializing the list data and storing it in a way that maintains the list structure. You can then query the table attribute to retrieve the full list. Adding, updating or removing elements from the list works the same way as a regular write operation.

Yes, DynamoDB supports storing maps as an attribute data type. 

The Time to Live (TTL) feature automatically deletes expired items, thereby reducing storage usage and lowering costs. With TTL, you can define a per-item timestamp to determine when an item is no longer needed, and DynamoDB automatically deletes the item from your table without consuming any write throughput. Each time an item is created or updated, you can compute the expiration time and save it in the TTL attribute. TTL is useful if you store items that lose relevance after a specific time.

Yes, DynamoDB supports IAM permissions. IAM permissions can be defined in identity-based policies, resource-based policies, or other AWS policies to control access to DynamoDB resources. You can attach IAM policies to IAM users, groups, roles, and DynamoDB tables and streams, and control them as desired.

With AWS PrivateLink, you can simplify private network connectivity between virtual private clouds (VPCs), DynamoDB, and your on-premises data centers using interface VPC endpoints and private IP addresses. With PrivateLink, DynamoDB tables can be accessed from a private connection and requests do not leave the Amazon network. This enhances security as traffic does flow through any network gateways, and access can be controlled using IAM policies and security groups. PrivateLink is useful for applications that have data security requirements and require low latency. It also makes DynamoDB tables accessible from hybrid environments spanning on-premises networks and AWS.

Yes, DynamoDB supports resource-based policies for tables and streams. The resource-based policies for each table also cover the access permissions for the table's indexes (Global Secondary Indexes and Local Secondary Indexes). With resource-based policies, customers can define fine-grained access permissions for DynamoDB tables and other resources without having to grant full access at the AWS account level. These policies allow customers to control which users, roles, and federated users can perform actions like read, write, or delete on specific DynamoDB tables, indexes, and streams. The resource-based policies are attached and managed within each DynamoDB resource.

Resource-based policies support integrations with AWS Identity and Access Management (IAM) Access Analyzer and Block Public Access (BPA). IAM Access Analyzer helps customers refine permissions and conform to least privilege. BPA helps customers prevent public access to DynamoDB tables, indexes, and streams, and is always enabled with DynamoDB.
 

DynamoDB supports attribute-based access control which is generally available for DynamoDB tables and indexes.

Yes, you can use Amazon DynamoDB using VPC endpoints. DynamoDB supports two types of VPC endpoints - gateway endpoints and using AWS PrivateLink. With a gateway endpoint, you can access DynamoDB from your VPC, without requiring an internet gateway or NAT device for your VPC. However, gateway endpoints do not allow access from on-premises networks, from peered VPCs in other AWS Regions, or through a transit gateway. For those scenarios, you must use AWS PrivateLink which is available for an additional cost.

Fine-grained access control (FGAC) gives a DynamoDB table owner granular control over data in the table through AWS Identity and Access Management (IAM) policies and conditions. FGAC lets the owner provide permissions for access to items or attributes of the table, and associated actions. Fine-grained access control is used in concert with AWS IAM, which manages the security credentials and the associated permissions.

Yes, all user data in Amazon DynamoDB is fully encrypted in transit and at rest.

HTTPS protocol is used to protect network traffic by using Secure Sockets Layer encryption.

DynamoDB encryption at rest uses encryption keys stored in AWS Key Management Service (AWS KMS). Data at rest is encrypted using AES-256, the gold standard where the highest levels of security are required.

The following key types are available to encrypt data at rest:
1. AWS owned keys: These are managed entirely by AWS and are used by default if no other option is specified. They are free to use and require no additional setup.
2. AWS managed keys: These are customer master keys (CMKs) stored in AWS Key Management Service (KMS) that are created, managed, and used on the customer's behalf by AWS. They provide additional control and auditing capabilities compared to AWS owned keys.
3. Customer managed keys: These are CMKs that you create, own, and manage in AWS KMS. They offer the highest level of control over the encryption keys, including the ability to create, rotate, disable, and define access controls.

Each of these key types provides a different balance of convenience, control, and cost. AWS owned keys are the simplest to use, while customer managed keys offer the most control but require more management overhead.

Encryption at rest helps protect data by encrypting files containing sensitive information as they sit inactive. When data is encrypted at rest, unauthorized parties cannot access the plaintext content even if they are able to gain physical access to the devices storing the data. This provides an additional layer of security for data beyond just access controls and helps ensure confidential information stays private, even if the physical device is lost or stolen.

Yes, DynamoDB does support audit logging for item level changes on tables. DynamoDB is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in DynamoDB at the item level. Additional logging data captured includes creates, updates, deletes, and any conditional check failures. Customers can access these log records stored in CloudWatch Logs and build applications to analyze item level changes for auditing, monitoring, or other purposes. Audit logging provides visibility into data changes at a granular level without impacting normal read/write performance of the DynamoDB table.

Yes, you can use Amazon DynamoDB to build HIPAA-compliant applications and store healthcare-related information, including protected health information under an executed Business Associate Agreement (BAA) with AWS.

DynamoDB fulfills many compliance certifications including HIPAA eligible, FedRAMP, ISO 27001, SOC 1/SSAE 16/ISAE 3402 (formerly SAS 70), and SOC 2. For more information, see Compliance validation by industry for DynamoDB. AWS compliance reports are available for download in AWS Artifact.

Amazon DynamoDB global tables is a fully managed, serverless, multi-Region, and multi-active database. Global tables provides 99.999% availability, increased application resiliency, and improved business continuity. It replicates your DynamoDB tables automatically across your choice of AWS Regions, so you can achieve fast local read and write performance. Global tables use the same APIs as single Region DynamoDB tables, so you can easily make your DynamoDB tables globally available without application changes.

A global table is a collection of one or more replica tables, which can be owned by a single AWS account or multiple AWS accounts. A single Amazon DynamoDB global table can only have one replica table per AWS Region.

You should use global tables to improve your application's resiliency across multiple Regions and optionally across multiple AWS accounts. Global tables also enables applications to maintain high availability in the unlikely event of isolation or degradation of an entire Region.

DynamoDB global tables uses multi-active replication across Regions, where all replica tables in all Regions in a global table support read and write traffic. A global table has no primary Region, and thus no database failover is required when directing read and write traffic to a different Region. In the unlikely event that an AWS Region becomes isolated or degraded, your application can simply read and write from a replica table in an unaffected Region. For more information, see Best practices for DynamoDB global table design.

A replica table is a single DynamoDB table that is part of the global table replication group. Each replica table stores the same set of data items and uses the same primary key schema. In single account configurations, all replicas share the same table name. In multi-account configurations, replicas may use different table names, allowing you to reflect account, Region, or environment naming preferences. When an application writes data to a replica table in one Region, DynamoDB automatically replicates the writes to other replica tables in the other AWS Regions.

Yes, DynamoDB global tables bolsters business continuity as it increases an application’s resiliency and provides strong consistency for a single Region. With multi-Region strong consistency, you can build applications with zero RPO and the highest levels of resiliency. Additionally, with multi-account global tables you can achieve stronger isolation, better security and governance, and improved operational resiliency.

You can create a global table using DynamoDB console, AWS CLI, or AWS CloudFormation with this step-by-step guide.

Before adding a replica in a different region to an DynamoDB global tables, the table must have DynamoDB Streams enabled, have the same name as all other replicas, have the same partition key as all other replicas, and have the same write capacity settings specified.

For single account global tables, all replica tables must share the same name. For multi-account global tables, replicas can use different names, as long as they use the same primary key schema and meet the other prerequisites for global tables.

DynamoDB stores data in tables. A table is a collection of items, and each item is a collection of attributes. DynamoDB uses primary keys to uniquely identify each item in a table and has secondary indexes to provide more querying flexibility. With global tables you can automatically replicate your DynamoDB table data across AWS Regions without needing to build and maintain your own replication solution. Since data is replicated to AWS Regions across the world, globally scaled applications get faster local read and write performance as well as resiliency from regional failures. Learn more about DynamoDB global tables.

Yes, you can enable point-in-time recovery on each replica of a DynamoDB global table.

Yes, DynamoDB supports change data capture (CDC)., which is implemented using a streaming model allowing applications to capture item-level changes in a DynamoDB table in near real-time as a stream of data records. The CDC stream of data records enables applications to efficiently process and respond to the data modifications in the DynamoDB table. DynamoDB offers two streaming models for CDC: DynamoDB Streams and Kinesis Data Streams for DynamoDB. To help you choose the right solution for your application, see streaming options for change data capture.

A DynamoDB stream is an ordered flow of information about changes to items in a DynamoDB table. DynamoDB Streams captures a de-duplicated, time-ordered sequence of item-level modifications in a table and stores this information in a log for up to 24 hours. DynamoDB Streams scales capacity automatically, freeing you from provisioning and managing capacity. Based on your DynamoDB Streams configuration, you can view the data items as they appear before and after they were modified. You can build applications that consume these stream events and invoke workflows based on the contents of the event stream.

DynamoDB Streams is useful for when you want to respond to data changes with triggers using the native integration with AWS Lambda, track and analyze customer interactions or monitor application performance in near real time, capture ordered sequences of events, and improve application resiliency through replicating item-level transactional data.

Kinesis Data Streams captures item-level modifications in any DynamoDB table and replicates them to a Kinesis data stream. Your applications can access this stream and view item-level changes in near-real time. With Kinesis Data Streams, you can build custom applications that process or analyze streaming data for specialized needs. Unlike DynamoDB Streams, Kinesis Data Streams for DynamoDB does not provide record ordering nor deduplication guarantees. Record ordering and deduplication must be implemented by client applications, using the ApproximateCreationDateTime field in the item-level record.

Kinesis Data Streams for DynamoDB is useful if you need integration with the broader Kinesis capabilities (such as the Kinesis Client Library, Amazon Managed Service for Apache Flink, or Amazon Data Firehose), longer data retention and replayability (up to 365 days), and customized shard management for downstream consumption and streaming analytics.

When a DynamoDB stream or Kinesis data stream is enabled on a DynamoDB table, the table sends out a data record that captures any changes to that table’s data. This data record includes the specific time any item was recently created, updated, or deleted, that item’s primary key, an image of the item before the modification, and an image of the item after the modification

You can enable or disable streams on an existing DynamoDB table by using the AWS Management Console, the AWS SDK, the AWS Command Line Interface (AWS CLI), or Kinesis Client Library (KCL).

Choose DynamoDB Streams when you specifically need to track DynamoDB table changes. Choose Kinesis Data Streams for broader streaming needs, higher throughput requirements, or when you need longer data retention periods.

Amazon DynamoDB Time to Live (TTL) feature automatically deletes expired items that are no longer relevant from a table, thereby reducing storage usage and lowering costs. With TTL, you can define a per-item timestamp to determine when an item is no longer needed, and DynamoDB automatically deletes the item from your table without consuming any write throughput. Each time an item is created or updated, you can compute the expiration time and save it in the TTL attribute. TTL is useful if you store items that lose relevance after a specific time.

DynamoDB supports GET/PUT operations by using a user-defined primary key. The primary key is the only required attribute for items in a table. You specify the primary key when you create a table, and it uniquely identifies each item. DynamoDB also provides flexible querying by letting you query on nonprimary key attributes using global secondary indexes and local secondary indexes.

A primary key can be either a single-attribute partition key or a composite partition-sort key. A single-attribute partition key could be, for example, UserID. Such a single attribute partition key would allow you to quickly read and write data for an item associated with a given user ID.

DynamoDB indexes a composite partition-sort key as a partition key element and a sort key element. This multipart key maintains a hierarchy between the first and second element values. For example, a composite partition-sort key could be a combination of UserID (partition) and Timestamp (sort). Holding the partition key element constant, you can search across the sort key element to retrieve items. Such searching would allow you to use the Query API to, for example, retrieve all items for a single UserID across a range of time stamps.

DynamoDB supports primary keys composed of up to eight attributes in global secondary indexes (GSIs), with up to four attributes each for the partition and sort keys.

After you have created a table using the DynamoDB console or CreateTable API, you can use the PutItem or BatchWriteItem APIs to insert items. Then, you can use the GetItem, BatchGetItem, or, if composite primary keys are enabled and in use in your table, the Query API to retrieve the items you added to the table.

Yes. DynamoDB is a fully managed cloud service that you access via API. Applications running on any operating system (such as Linux, Windows, iOS, Android, Solaris, AIX, and HP-UX) can use DynamoDB. We recommend using the AWS SDKs to get started with DynamoDB.

For use cases that require response times in microseconds, DynamoDB integrates with Amazon DynamoDB Accelerator (DAX), a fully managed, highly available caching service built for DynamoDB. DAX delivers up to a 10 times performance improvement—from milliseconds to microseconds—even at millions of requests per second.

ExtendDB is an open source project that implements the Amazon DynamoDB API with pluggable storage backends. It enables application developers, platform teams, and enterprise architects to use the DynamoDB programming model in environments where the DynamoDB managed service is not available, including on your laptop, on-premises data centers, and disconnected edge sites, without rewriting application code. To learn more, see the ExtendDB project page and the blog Introducing ExtendDB. To get started or contribute to the open source project, visit the GitHub repository.

LangGraph is a framework for building stateful, multi-agent AI applications with Large Language Models (LLMs). Agents built with LangGraph require persistent storage to maintain conversation state, enable human-in-the-loop workflows, support fault tolerance, and provide time-travel debugging capabilities. DynamoDB's serverless architecture, single-digit millisecond latency, and automatic scaling make it an ideal checkpoint store for production LangGraph deployments on AWS. To learn more, reference our documentation DynamoDB as a checkpoint store for LangGraph agents and read the blog Building durable AI agents with LangGraph and Amazon DynamoDB.

You can use zero-ETL integration to replicate data from DynamoDB tables to OpenSearch Service within seconds of being written using OpenSearch Ingestion pipelines. Customers can replicate data from multiple DynamoDB tables into a single OpenSearch Service managed domain or serverless collection to derive holistic insights across several applications, while also consolidating their core analytics assets, gaining significant cost savings and operational efficiencies.

Yes, you can purchase a Database Savings Plans for your Amazon DynamoDB usage and reduce your costs by up to 18% when you commit to a consistent amount of usage over a 1-year term. Additional information on eligible usage can be found on Database Savings Plans pricing page.

The DynamoDB free tier is enough for about 200M requests/month (depending on item size) and can be used for personal apps, prototypes, or learning/certification needs. It uses provisioned capacity and the DynamoDB Standard table class. In addition to the DynamoDB free tier, you can get up to $200 USD in credits with the AWS Free Tier to experience the full set of DynamoDB features for up to 6 months. To learn more, visit DynamoDB pricing or access your DynamoDB free tier.

DynamoDB is a fully serverless non-relational database. Compared to other databases that charge on various metrics, like storage, DynamoDB can scale-to-zero, meaning when customers utilize on-demand mode they only pay for active resources consumed.

Simply put, on-demand is better suited to customers who prefer to only pay for what they use or have unpredictable workloads. Provisioned capacity is popular with customers with applications that demonstrate consistent or predictable traffic and prefer to forecast capacity requirements to control costs.

DynamoDB is unique as it's a serverless database that provides customers with the option of only paying for the resources they consume—while scaling to zero when not in use with on-demand pricing. When the database is in-use, write request units and read request units are used to calculate charges.

DynamoDB includes a broad set of options that can be added to the service. A partial list includes:

• On-demand backup which takes snapshot backups at specified points in time
• Global tables for multi-region, multi-active replication
• DynamoDB Accelerator (DAX), an Amazon DynamoDB-compatible caching service, reduces latency through in-memory cache
• DynamoDB streams for time-ordered sequences of item-level changes to a table

Vector search in DynamoDB introduces a new index you create on the attribute that stores vector embeddings. This index is based on a proprietary approximate nearest neighbor (ANN) algorithm optimized for efficiency and horizontal scalability. It supports three distance metrics including Euclidean, cosine and dot product, and inline filtering. Vector embeddings stored in DynamoDB support up to 4096 dimensions. You generate vector embeddings using a model of your choice, such as Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI text embedding models, and store them as a list of floats in your table using a standard PutItem call. Vector search in DynamoDB works with DynamoDB global tables (both Multi-Region Eventual Consistency and Multi-Region Strong Consistency) and DynamoDB Streams. To learn more, visit vector search documentation for DynamoDB.

Choose DynamoDB vector search when you need single-digit millisecond vector search at any scale in a serverless database with zero infrastructure management. By using native vector search of DynamoDB, you also avoid adding a separate vector database and don’t need a data pipeline to synch operational data to it.

First, you ‘vectorize’ or generate vector embeddings for your data using a model of your choice such as Amazon Bedrock Titan Text Embeddings, Titan Multimodal Embeddings, Cohere Embed, OpenAI’s Text Embedding Models, or a custom model. You can vectorize data already existing in DynamoDB or bring your own embeddings. You can store these vector embeddings in DynamoDB as attributes using existing DynamoDB data types, such as an array of numbers (float). With just a few clicks on the AWS Management Console, or using the AWS SDK, AWS CLI, or AWS CloudFormation, you create a new vector index on the attributes that have the vector embeddings and optionally choose to specify attributes you want to filter by, so that you can reduce the search space for faster queries. Once the index is created, you can use the search API to perform similarity search on the index with predictable performance at scale. To perform search, you vectorize the search term using the same model you used to vectorize the data. You then query the vector index using the vectorized search term and the filter criteria, if applicable.

You can use existing data types to store vector embeddings in DynamoDB. For example, you can store vectors as an array of floats.

DynamoDB vector search supports three distance functions including Euclidean, cosine, and dot product. These quantify how far apart two vectors are in a given space. Euclidean measures straight-line distance between points and useful when magnitude matters (e.g., clustering items by purchase count). Cosine measures the angle between vectors and is used when direction matters more than magnitude (e.g., comparing a tweet to a document on the same topic). Dot product combines alignment and magnitude and is useful when both matter (e.g., recommendation systems considering interest alignment and frequency). Choosing the right distance function depends on your data, embedding model, and use case. In general, you must match the distance function to the one used to train your embedding model for the highest accuracy.

Yes. You can perform ENN search using the DynamoDB scan operation on the table. The exact nearest neighbor (ENN) search prioritizes accuracy over speed by looking for exact matches to a query vector. You can perform a repeated paginated scan to get exact matches to your search query.

If your data has changed since the creation of the index, you can create a new index to improve search query recall. Creating a new index may result in optimized indexing structure for your query patterns and provide better search query recall. You can cutover your application from the old index to use the new one. The new index will have a different ARN. Once the applications querying the vector index have cutover from the old index, you can choose to delete the old index.

Vectors with up to 4,096 dimensions are supported. Vector indexes are supported with on-demand tables only. Searches support up to 100 top k results. You can create up to five vector indexes per table. You can request an increase to the five vector index service quota by reaching out to AWS Support. For more detail, see our documentation about vector search limitations.