Amazon DynamoDB FAQs

DynamoDB is a serverless, fully managed, distributed NoSQL database service with single-digit millisecond performance at any scale. 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 is fully managed, removing the heavy lifting of undifferentiated database management tasks such as backups, security, compliance, monitoring, and more. For globally distributed applications, DynamoDB global tables is a multi-Region, multi-active database with up to 99.999% availability and offers the highest database resilience. It supports multi-Region strong consistency ensuring your applications always stay available and always read the same data from any Region, enabling you to build zero RPO applications. DynamoDB has a broad set of security controls and compliance standards built to satisfy the requirements for governments, global banks, and other high-sensitivity organizations.

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 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. 

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.

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

There are two versions of DynamoDB global tables available: version 2019.11.21 (Current) and version 2017.11.29 (Legacy). Customers should use version 2019.11.21 (Current) for all new global tables, as this version is more efficient and consumes less write capacity. Anyone using version 2017.11.29 (Legacy) should upgrade their global tables to version 2019.11.21 (Current).

You can upgrade the version of a global table with just a few clicks in the AWS Management Console. Upgrading from version 2017.11.29 (Legacy) to version 2019.11.21 (Current) is a one-time action and cannot be reversed. Before upgrading, ensure that you have reviewed the differences in behavior between versions, and performed all necessary testing. For more information, see Upgrading global tables from version 2017.11.29 (Legacy) to version 2019.11.21 (Current).

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.

Yes, Amazon supports change data capture (CDC). In DynamoDB, CDC is implemented using a streaming model, which allows 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: Amazon DynamoDB Streams and Amazon 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 ecosystem (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.

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.

DynamoDB zero-ETL integration with OpenSearch Service abstracts away the operational complexity in orchestrating the replication of data from a transactional datastore to a search datastore. Data pipelines that are used to keep transactional and search datastores in sync can be challenging and costly to build and manage, and suffer from intermittent errors which are difficult to track. 

This integration enables Amazon DynamoDB customers to obtain near real-time search results from their transactional data by offering a fully managed solution for making transactional data from DynamoDB available in OpenSearch Service within seconds of being written. Customers simply choose the DynamoDB tables containing the data they want to analyze with OpenSearch Service, and this zero-ETL integration seamlessly replicates the schema and data into OpenSearch Service 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. 

Customers can get started by using the AWS Management Console for DynamoDB, OpenSearch Service, AWS CLI or AWS SDK or AWS CloudFormation. To enable an integration, customers first choose the DynamoDB table whose data needs to be replicated. Customers then choose either DynamoDB Streams for near real-time replication or DynamoDB Incremental Exports for delayed replication as the CDC mechanism to keep the data between the two systems in sync. 

This zero-ETL integration sets up an OpenSearch Ingestion pipeline in the customer’s account that takes care of replicating the data to an OpenSearch Service managed cluster or serverless collection. OpenSearch Ingestion understands the structure of the DynamoDB tables and then creates an equivalent OpenSearch Service managed domain or serverless collection and bootstraps the destination with the existing data from the DynamoDB tables. Optionally, customers can specify a schema for the indices that will be created in OpenSearch Service. 

This zero-ETL integration provides you a dashboard where you can monitor the state of your end-to-end integration with real time metrics and logs Amazon CloudWatch. You can set up alerting in case of breach of user defined thresholds. This integration also continually monitors the state of the DynamoDB tables and OpenSearch Service indices and immediately notifies users in case of regressions with any of these entities.

In order to ensure that OpenSearch Ingestion has the necessary permissions to replicate data across both these systems, DynamoDB zero-ETL integration with OpenSearch Service creates an IAM role with the necessary permissions to read data from DynamoDB tables and writes to an OpenSearch domain or collection. This role is then assumed by OpenSearch Ingestion pipelines to ensure that the right security posture is always maintained when moving the data from source to destination.

This zero-ETL integration uses the native data transformational capabilities of OpenSearch Ingestion pipelines to aggregate and filter the data while it is in motion. When moving the data from a DynamoDB table, customers may want to drop a few fields or create new fields based on aggregations across existing fields. 

Optionally, customers can also write custom logic for OpenSearch Ingestion to achieve bespoke transformational capability. For other users, who just want to move their entire data from source to sink, this zero-ETL integration will provide out-of-the box OpenSearch Ingestion blueprints so that they can perform the integrations with just a few button clicks.

This zero-ETL integration provides customers options to specify their custom data schema along with index mappings that is used to by OpenSearch Ingestion when writing data from DynamoDB to OpenSearch Service. This experience is added to the UI console within DynamoDB so that customers have full control on the format of indices that are created on OpenSearch Service.

There is no additional cost to use DynamoDB zero-ETL integration with OpenSearch Service apart from the cost of the existing underlying components. This zero-ETL integration uses Amazon OpenSearch Ingestion to read data in DynamoDB tables and replicates to OpenSearch Service. The cost involved in using DynamoDB zero-ETL integration with OpenSearch Service is the cost of OpenSearch Compute Units (OCUs) needed for OpenSearch Ingestion to replicate the data across the systems. Furthermore, customers have an option to choose either DynamoDB streams or incremental exports as the choice of CDC. For incremental exports, there is cost associated with writing data to S3 buckets. For DynamoDB streams, customers would be charged the standard charges for using DynamoDB streams.

DynamoDB zero-ETL integration with Amazon OpenSearch Service is available in all the regions that OpenSearch Ingestion is available in today.