HAQM DocumentDB (with MongoDB compatibility) FAQs

When writing to storage, HAQM DocumentDB only persists a write-ahead logs, and does not need to write full buffer page syncs. As a result of this optimization, which does not compromise durability, HAQM DocumentDB writes are typically faster than traditional databases. HAQM DocumentDB clusters can scale out to millions of reads per second with up to 15-read replicas .

Please see the HAQM DocumentDB pricing page for current information on regions and prices.

Yes, you can try HAQM DocumentDB for free using the 1-month free trial. If you have not used HAQM DocumentDB before, you are eligible for a one month free trial. Your organization gets 750 hours per month of t3.medium instance usage, 30 million IOs, 5 GB of storage, and 5 GB of backup storage for free for 30 days. Once your one month free trial expires or your usage exceeds the free allowance, you can shut down your cluster to avoid any charges, or keep it running at our standard on-demand rates . To learn more, refer to the DocumentDB free trial page .

HAQM DocumentDB I/O-Optimized is the ideal choice when you need predictable costs or have I/O intensive applications. If you expect your I/O costs to exceed 25% of your total HAQM DocumentDB database costs, this option offers enhanced price performance. Refer to our HAQM DocumentDB I/O-Optimized documentation to learn more, including how to get started.

You can switch your existing database clusters once every 30 days to HAQM DocumentDB I/O-Optimized. You can switch back to HAQM DocumentDB standard storage configurations at any time.

Yes, the charges for the I/O operations required to replicate data across regions continue to apply. HAQM DocumentDB I/O-Optimized does not charge for read and write I/O operations, which is different from data replication. Refer to our HAQM DocumentDB I/O-Optimized documentation to learn more.

HAQM DocumentDB Elastic Clusters enables you to elastically scale your document database to handle millions of writes and reads, with petabytes of storage capacity. Elastic Clusters simplifies how customers interact with HAQM DocumentDB by automatically managing the underlying infrastructure and removing the need to create, remove, upgrade, or scale instances.

You can create an Elastic Clusters cluster using the HAQM DocumentDB API, SDK, CLI, CloudFormation (CFN), or the AWS console. When provisioning your cluster, you specify how many shards and the compute per shard that your workload needs. Once you have created your cluster, you are ready to start leveraging Elastic Clusters’ elastic scalability. Now, you can connect to the Elastic Clusters cluster and read or write data from your application. Elastic Clusters is elastic. Depending on your workload’s needs, you can add or remove compute by modifying your shard count and/or compute per shard using the AWS console, API, CLI, or SDK. Elastic Clusters will automatically provision/de-provision the underlying infrastructure and rebalance your data.

Elastic Clusters uses sharding to partition data across HAQM DocumentDB’s distributed storage system. Sharding, also known as partitioning, splits large data sets into small data sets across multiple nodes enabling customers to scale out their database beyond vertical scaling limits of a single database. Elastic Clusters utilizes the separation of compute and storage in HAQM DocumentDB. Rather than re-partitioning collections by moving small chunks of data between compute nodes, Elastic Clusters can copy data efficiently within the distributed storage system.

Elastic Clusters supports hash-based partitioning.

With Elastic Clusters, you can easily scale out or scale in your workload on HAQM DocumentDB typically with little to no application downtime or impact to performance regardless of data size. A similar operation on MongoDB would impact application performance and take hours, and in some cases days. Elastic Clusters also offers differentiated management capabilities such as no impact backups and rapid point in time restore enabling customers to focus more time on their applications rather than managing their database.

No. You do not need to make any changes to your application to use Elastic Clusters.

No, in the near-term, you can leverage AWS Database Migration service (DMS) to migrate data from an existing HAQM DocumentDB cluster to an Elastic Clusters cluster.

Choosing an optimal shard key for Elastic Clusters is no different than other databases. A great shard key has two characteristics - high frequency and high cardinality. For example, if your application stores user_orders in DocumentDB, then generally you have to retrieve the data by the user. Therefore, you want all orders related to a given user to be in one shard. In this case, user_id would be a good shard key. Read more information . 

• Elastic Clusters: An HAQM DocumentDB cluster that allows you to scale your workload’s throughput to millions of reads/writes per second and storage to petabytes. An Elastic Cluster cluster comprises of one or more shards for compute and a storage volume, and is highly available across multiple Availability Zones by default.
• Shard: A shard provides compute for an elastic cluster. It will have a single writer instance and 0–15 read replicas. By default, a shard will have two instances: a writer and a single read replica. You can configure a maximum of 32 shards and each shard instance can have a maximum of 64 vCPUs.
• Shard key: A shard key is a required field in your JSON documents in sharded collections that elastic clusters use to distribute read and write traffic to the matching shard.
• Sharded collection: A sharded collection is a collection whose data is distributed across an elastic cluster in data partitions.

Elastic Clusters integrates with other AWS services in the same way DocumentDB does today. First, you can use AWS Database Migration Service (DMS) to migrate from MongoDB and other relational databases to Elastic Clusters. Second, you can monitor the health and performance of your Elastic Clusters cluster using HAQM CloudWatch. Third, you can set up authentication and authorization through AWS IAM users and roles and use AWS VPC for secure VPC-only connections. Last, you can use AWS Glue to import and export data from/to other AWS services such as S3, Redshift and OpenSearch.

Yes. You can migrate your existing MongoDB sharded workloads to Elastic Clusters. You can either use the AWS Database Migration Service or native MongoDB tools, such as mongodump and mongorestore, to migrate your MongoDB workload to Elastic Clusters. Elastic Clusters also supports MongoDB’s commonly used APIs, such as shardCollection(), giving you the flexibility to reuse existing tooling and scripts with HAQM DocumentDB.

The minimum storage is 10 GB. Based on your cluster usage, your HAQM DocumentDB storage will automatically grow, up to 128 TiB in 10 GB increments with no impact on performance. With HAQM DocumentDB Elastic Clusters, storage will automatically grow up to 4 PiB in 10 GB increments. For either case, there is no need to provision storage in advance.

HAQM DocumentDB scales in two dimensions: storage and compute. HAQM DocumentDB's storage automatically scales from 10 GB to 128 TiB in Instance-based Clusters, and up to 4 PiB for HAQM DocumentDB Elastic Clusters. HAQM DocumentDB's compute capacity can be scaled up by creating larger instances and horizontally (for greater read throughput) by adding additional replica instances to the cluster.

You can scale the compute resources allocated to your instance in the AWS Management Console by selecting the desired instance and clicking the “modify” button. Memory and CPU resources are modified by changing your instance class .

When you modify your instance class, your requested changes will be applied during your specified maintenance window. Alternatively, you can use the "Apply Immediately" flag to apply your scaling requests immediately. Both of these options will have an availability impact for a few minutes as the scaling operation is performed. Bear in mind that any other pending system changes will also be applied.

Automated backups are always enabled on HAQM DocumentDB clusters. HAQM DocumentDB’s simple database backup capability enables point-in-time recovery for your clusters. You can increase your backup window for point-in-time restores up to 35 days. Backups do not impact database performance.

Yes. Manual snapshots can be retained beyond the backup window and there is no performance impact when taking snapshots. Note that restoring data from cluster snapshots requires creating a new cluster.

HAQM DocumentDB automatically makes your data durable across three Availability Zones (AZs) within a Region and will automatically attempt to recover your instance in a healthy AZ with no data loss. In the unlikely event your data is unavailable within HAQM DocumentDB storage, you can restore from a cluster snapshot or perform a point-in-time restore operation to a new cluster. Note that the latest restorable time for a point-in-time restore operation can be up to five minutes in the past.

You can choose to create a final snapshot when deleting your instance . If you do, you can use this snapshot to restore the deleted instance at a later date. HAQM DocumentDB retains this final user-created snapshot along with all other manually created snapshots after the instance is deleted. Only snapshots are retained after the instance is deleted (i.e., automated backups created for point-in-time restore are not kept).

Deleting your AWS account will delete all automated backups and snapshot backups contained in the account.

Yes. HAQM DocumentDB gives you the ability to create snapshots of your cluster , which you can use later to restore a cluster. You can share a snapshot with a different AWS account, and the owner of the recipient account can use your snapshot to restore a cluster that contains your data. You can even choose to make your snapshots public – that is, anybody can restore a cluster containing your (public) data. You can use this feature to share data between your various environments (production, dev/test, staging, etc.) that have different AWS accounts, as well as keep backups of all your data secure in a separate account in case your main AWS account is ever compromised.

There is no charge for sharing snapshots between accounts. However, you may be charged for the snapshots themselves, as well as any clusters that you restore from shared snapshots.

We do not support sharing automatic cluster snapshots. To share an automatic snapshot, you must manually create a copy of the snapshot, and then share the copy.

No. Your shared HAQM DocumentDB snapshots will only be accessible by accounts in the same region as the account that shares them.

Yes. You can share encrypted HAQM DocumentDB snapshots . The recipient of the shared snapshot must have access to the KMS key that was used to encrypt the snapshot.

No. HAQM DocumentDB snapshots can only be used inside of the service.

You can choose to create a final snapshot when deleting your cluster . If you do, you can use this snapshot to restore the deleted cluster at a later date. HAQM DocumentDB retains this final user-created snapshot along with all other manually created snapshots after the cluster is deleted.

HAQM DocumentDB automatically divides your storage volume into 10 GB segments spread across many disks. Each 10 GB chunk of your storage volume is replicated six ways, across three Availability Zones (AZs). HAQM DocumentDB is designed to transparently handle the loss of up to two copies of data without affecting write availability and up to three copies without affecting read availability. HAQM DocumentDB’s storage volume is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically.

Unlike other databases, after a database crash , HAQM DocumentDB does not need to replay the redo log from the last database checkpoint (typically five minutes) and confirm that all changes have been applied, before making the database available for operations. This reduces database restart times to less than 60 seconds in most cases. HAQM DocumentDB moves the cache out of the database process and makes it available immediately at restart time. This prevents you from having to throttle access until the cache is repopulated to avoid brownouts.

HAQM DocumentDB supports read replicas , which share the same underlying storage volume as the primary instance. Updates made by the primary instance are visible to all HAQM DocumentDB replicas.

• Feature: HAQM DocumentDB read replicas
• Number of replicas: Up to 15
• Replication Type: Asynchronous (typically milliseconds)
• Performance impact on primary: Low
• Act as failover target: Yes (no data loss)
• Automated failover: Yes

Yes, you can replicate your data across regions using the Global Cluster feature . Global Clusters span across multiple AWS Regions. Global clusters replicate your data to clusters in up to five Regions with little to no impact on performance. Global clusters provide faster recovery from Region-wide outages and enable low-latency global reads. To learn more see our blog post .

Yes. You can assign a promotion priority tier to each instance on your cluster. If the primary instance fails, HAQM DocumentDB will promote the replica with the highest priority to primary. If there are inconsistencies between two or more replicas in the same priority tier, then HAQM DocumentDB will promote the replica that is the same size as the primary instance.

You can modify the priority tier for an instance at any time. Simply modifying priority tiers will not trigger a failover .

You can assign lower priority tiers to replicas that you do not want promoted to the primary instance. However, if the higher priority replicas on the cluster are unhealthy or unavailable for some reason, then HAQM DocumentDB will promote the lower priority replica.

HAQM DocumentDB can be deployed in a high-availability configuration by using replica instances in multiple AWS Availability Zones as failover targets. In the event of a primary instance failure, a replica instance is automatically promoted to be the new primary with minimal service interruption.

You can add additional HAQM DocumentDB replicas. HAQM DocumentDB replicas share the same underlying storage as the primary instance. Any HAQM DocumentDB replica can be promoted to become primary without any data loss and therefore can be used for enhancing fault tolerance in the event of a primary instance failure. To increase cluster availability, simply create one to 15 replicas, in multiple AZs, and HAQM DocumentDB will automatically include them in failover primary selection in the event of an instance outage.

Failover is automatically handled by HAQM DocumentDB so that your applications can resume database operations as quickly as possible without manual administrative intervention.

• If you have an HAQM DocumentDB replica instance in the same or a different Availability Zone, when failing over, HAQM DocumentDB flips the canonical name record (CNAME) for your instance to point at the healthy replica, which is in turn promoted to become the new primary. Start-to-finish, failover typically completes within 30 seconds. 
• If you do not have an HAQM DocumentDB replica instance (i.e. a single instance cluster), HAQM DocumentDB will attempt to create a new instance in the same Availability Zone as the original instance. This replacement of the original instance is done on a best-effort basis and may not succeed, for example, if there is an issue that is broadly affecting the Availability Zone. 

Your application should retry database connections in the event of connection loss.

HAQM DocumentDB will automatically detect a problem with your primary instance and begin routing your read/write traffic to an HAQM DocumentDB replica instance. On average, this failover will complete within 30 seconds. In addition, the read traffic that your HAQM DocumentDB replicas instances were serving will be briefly interrupted.

Since HAQM DocumentDB replicas share the same data volume as the primary instance, there is virtually no replication lag. We typically observe lag times in the 10s of milliseconds.

Yes. All HAQM DocumentDB clusters must be created in a VPC . With HAQM VPC, you can define a virtual network topology that closely resembles a traditional network that you might operate in your own datacenter. This gives you complete control over who can access your HAQM DocumentDB clusters.

HAQM DocumentDB supports RBAC with built-in roles. RBAC enables you to enforce least privilege as a best practice by restricting the actions that users are authorized to perform. For more information, see HAQM DocumentDB role-based access control .

HAQM DocumentDB utilizes VPC’s strict network and authorization boundary. Authentication and authorization for HAQM DocumentDB management APIs is provided by IAM users , roles, and policies. Authentication to an HAQM DocumentDB database are done via standard MongoDB tools and drivers with Salted Challenge Response Authentication Mechanism (SCRAM), the default authentication mechanism for MongoDB.

Yes. HAQM DocumentDB allows you to encrypt your clusters using keys you manage through AWS Key Management Service (KMS) . On a cluster running with HAQM DocumentDB encryption, data stored at rest in the underlying storage is encrypted, as are its automated backups, snapshots, and replicas in the same cluster. Encryption and decryption are handled seamlessly. For more information about the use of KMS with HAQM DocumentDB, see the Encrypting HAQM DocumentDB Data at Rest .

Currently, encrypting an existing unencrypted HAQM DocumentDB cluster is not supported. To use HAQM DocumentDB encryption for an existing unencrypted cluster, create a new cluster with encryption enabled and migrate your data into it.

HAQM DocumentDB was designed to meet the highest security standards and to make it easy for you to verify our security and meet your own regulatory and compliance obligations. HAQM DocumentDB has been assessed to comply with PCI DSS , ISO 9001 , 27001 , 27017 , and 27018 , SOC 1, 2 and 3 , and Health Information Trust Alliance (HITRUST) Common Security Framework (CSF) certification , in addition to being HIPAA eligible . AWS compliance reports are available for download in AWS Artifact .

In-place major version upgrade (MVU) lets you upgrade HAQM DocumentDB 3.6 or 4.0 clusters to HAQM DocumentDB 5.0 using the AWS Console, Software Development Kit (SDK), or Command Line Interface (CLI). With in-place MVU, there is no need to create new clusters or change your end points. In-place MVU is available in all regions where HAQM DocumentDB 5.0 is available. To get started with in-place MVU, please review in-place MVU documentation.

In-place MVU lets you seamlessly upgrade your HAQM DocumentDB 3.6 or 4.0 clusters to version 5.0 without the need to perform backup and restore to another cluster and without using other data migration tools. In doing so, it reduces the time and effort associated with usual upgrade process which entail configuring the source and target end points, migrating indexes and data, changing application code, and more.

You won't need to change your endpoint in your applications post upgrade. Since the data stays in the same cluster, there is no additional cost to upgrade using feature.

Downtime can vary from cluster to cluster depending on number of collections, indexes, databases, and instances. Before running in-place major version upgrade on your production cluster, we strongly recommend running it in a lower environment to test downtime, performance, and also verify that your applications work as expected post upgrade.

You can also utilize HAQM DocumentDB’s fast clone feature to clone your cluster data for testing. Depending on the complexity of your HAQM DocumentDB implementation, you can engage our database solutions architect for additional help.

In-place MVU is only supported with HAQM DocumentDB 3.6 or 4.0 as a source and version 5.0 as target. It is not supported for HAQM DocumentDB Global Clusters or Elastic Clusters or with DocumentDB 4.0 as target.

HAQM DocumentDB integrates with HAQM SageMaker Canvas, making it easy to build machine learning (ML) models and customize foundation models using data stored in HAQM DocumentDB without writing a single line of code. You no longer need to develop custom data and ML pipelines between HAQM DocumentDB and SageMaker Canvas. You can launch SageMaker Canvas from within the HAQM DocumentDB console and add existing HAQM DocumentDB databases as a data source to start building your machine learning models. You can use your data in DocumentDB in SageMaker Canvas to build models to predict customer churn, detect fraud, predict maintenance failures, forecast financial metrics and sales, optimize inventory, summarize content, and generate content.

HAQM SageMaker Canvas offers a no-code interface to build machine learning models using data from various data sources including HAQM DocumentDB. You are charged for your use of SageMaker Canvas and for the resulting I/Os when SageMaker Canvas reads data from your HAQM DocumentDB instance. There is no additional charge to use DocumentDB as a data source in HAQM SageMaker Canvas. Visit the HAQM DocumentDB pricing page and SageMaker Canvas pricing page to learn more.

Vector search is a method used in machine learning (ML) to find similar data points to a given data point by comparing their vector representations using distance or similarity metrics. The closer the two vectors are in the vector space, the more similar the underlying items are considered to be. This technique helps capture the meaning or semantics of the data. This approach is useful in various applications, such as recommendation systems, natural language processing, and image recognition.

Vector search for HAQM DocumentDB combines the flexibility and rich querying capability of a JSON-based document database with the power of vector search. You can use your existing HAQM DocumentDB data, or a flexible document data structure, to build machine learning and generative AI use cases such as semantic search experiences, product recommendations, personalization, chatbots, fraud detection, and anomaly detection. Visit the vector search for HAQM DocumentDB documentation to learn more.

Vector search for HAQM DocumentDB is available on HAQM DocumentDB 5.0 instance-based clusters.

Vector search for HAQM DocumentDB enables the use of semantic search so you can capture the meaning, context, and intent behind your data. Keyword search finds the document based on the actual text or pre-defined synonym mappings. For example, in a traditional e-commerce application, a red dress might return products that have the words “red” and “dress” in their descriptions. Semantic search will retrieve results with dresses in different shades of red which can improve the user experience.  

There is no additional cost to use vector search for HAQM DocumentDB. Standard compute, I/O, storage, and backup charges will apply as you store, index, and search vectors in HAQM DocumentDB. Visit the HAQM DocumentDB pricing page to learn more.

HAQM DocumentDB integrates with HAQM SageMaker Canvas making it easy to build generative artificial intelligence (AI) and machine learning (ML) applications using data stored in HAQM DocumentDB. You no longer need to develop custom data and ML pipelines between HAQM DocumentDB and SageMaker Canvas. The in-console integration removes the undifferentiated heavy lifting to connect and access data to accelerate ML development with a low code no code (LCNC) experience. You can launch SageMaker Canvas from within the HAQM DocumentDB console and add existing HAQM DocumentDB databases as a data source.

This zero-ETL integration with HAQM OpenSearch Service abstracts away the operational complexity in extracting, transforming, loading of data from an HAQM DocumentDB collection to HAQM OpenSearch managed cluster or serverless collection. With this integration, you no longer have to build or manage data pipelines nor transform data.

If you want to use MongoDB APIs, you should use the native database capabilities in HAQM DocumentDB to perform vector search on your documents. The HAQM DocumentDB zero-ETL integration with HAQM OpenSearch Service is well suited for searching across collections and for storing and indexing vectors with more than 2,000 dimensions.

The zero-ETL integration of HAQM DocumentDB with HAQM OpenSearch Service uses HAQM OpenSearch Ingestion to seamlessly move operational data from HAQM DocumentDB to HAQM OpenSearch Service. To get started, you enable change stream functionality on the HAQM DocumentDB collection that needs to be replicated. The zero-ETL integration feature sets up an HAQM OpenSearch Ingestion pipeline in the your account that automatically replicates the data to an HAQM OpenSearch Service managed cluster or serverless collection.

HAQM OpenSearch Ingestion automatically understands the format of the data in HAQM DocumentDB collections and maps the data to HAQM OpenSearch Service to yield the most performant search results. You can synchronize data from multiple HAQM DocumentDB collections via multiple pipelines into one HAQM OpenSearch managed cluster or serverless collection to offer holistic insights across several applications. Optionally, you can specify custom data processors when defining the ingestion configuration in HAQM OpenSearch Service. Subsequent updates to the DocumentDB collections are also replicated to HAQM OpenSearch Service without any manual intervention.

This zero-ETL leverages the native data transformational capabilities of HAQM OpenSearch Ingestion pipelines to aggregate and filter the data while it is in motion.

You can also write custom transformation logic if you want bespoke transformational capability, and HAQM OpenSearch Ingestion will manage the transformation process. Alternatively, if want to move entire data from source to sink without customization, HAQM OpenSearch Ingestion provides out-of-the box blueprints so that youcan perform the integrations with just a few button clicks.

In order to ensure that HAQM OpenSearch Ingestion has the necessary permissions to replicate data from HAQM DocumentDB, the zero-ETL integration feature creates an IAM role with the necessary permissions to read data from HAQM DocumentDB collection and write to an HAQM OpenSearch domain or collection. This role is then assumed by HAQM OpenSearch Ingestion pipelines to ensure that the right security posture is always maintained when moving the data from source to destination.

You can view all the metrics related to your zero-ETL integration with HAQM DocumentDB on the console dashboards provided by HAQM DocumentDB and OpenSearch Ingestion pipeline. You can also query real-time logs in HAQM CloudWatch and set up custom alerting using HAQM CloudWatch that are triggered when user-defined thresholds are breached.