Discover AWS DocumentDB: a MongoDB-compatible, AWS-managed database service. Learn how to optimize costs using Stratusphere™ by StratusGrid..
AWS DocumentDB is a managed service that deploys and manages MongoDB-compatible database engines. DocumentDB is built with the Amazon Relational Database Service (RDS) APIs.
Similar to RDS, you can set up DocumentDB clusters across multiple AWS Availability Zones within a region. You can select from a variety of different EC2 instance types for your DocumentDB cluster as well, including the t4g and r6g families that use the AWS Graviton ARM-based processor.
Because DocumentDB is a MongoDB compatible database engine, developed by AWS, you can use MongoDB tools to connect to it. For example, MongoDB Compass is a cross-platform, graphical tool that you can use to create documents and query them. You can use common MongoDB modules for various programming languages to connect your business applications to DocumentDB instances.
Querying for a list of DocumentDB instances, using the DescribeDBInstances API, also returns RDS instances. Similarly, querying the RDS service with the similarly named DescribeDBInstances API returns DocumentDB instances.
This can be confusing for anyone who’s new to the RDS & DocumentDB APIs. There is overlap between these services, even though they have separate APIs.
You can filter out the list of results for only DocumentDB instances by examining the Engine property on each result, and checking for the value of docdb.
In PowerShell, you could use the following command:
Install-Module -Name AWS.Tools.DocDB -Scope CurrentUser -Force
$DBList = Get-DocDBInstance | Where-Object -FilterScript { $PSItem.Engine -eq 'docdb' }
$DBList | Format-Table -AutoSize -Property DBInstanceIdentifier,DBInstanceStatus,Engine,EngineVersion
The first line simply installs the PowerShell module for the DocumentDB service. The second line retrieves a list of DocumentDB & RDS instances and filters them for only the DocumentDB instances, assigning the result to a variable. The third line pipes the contents of the variable into a Format-Table command, which displays a few key properties.
You can specify different properties to retrieve, by specifying any of them from the screenshot below, or by using an asterisk to select all properties. The default display format, shown in the screenshot, is a list view.
For Amazon DocumentDB clusters, there are a few ways to approach cost optimization.
First of all, you can monitor Amazon CloudWatch for the number of connections to the database server. Secondly, you can check CPU utilization of the server. Thirdly, you can temporarily stop your DocumentDB clusters so that you’re not charged for the compute costs.
Amazon DocumentDB exposes a snapshot of the current connection count every 60 seconds. Keep in mind that connections could be created and dropped in between the gathering of the metric data points.
Those connections would not be captured in the connection count, due to the way that DocumentDB gathers metric data points. Even if the connection count in CloudWatch shows 0 for a lengthy period of time, it’s still possible that short-lived connections, lasting for just a few seconds, are being created and then destroyed.
According to the documentation for DocumentDB, there are background maintenance tasks that run periodically against your database engine. These maintenance connections are not counted in the CloudWatch connection count metric.
Only connections made from customer applications are included in the CloudWatch metric. This could include Lambda functions, containers running on AWS Fargate, EC2 instances, graphical tools like MongoDB Compass, or other tools and services.
A graph of a completely idle DocumentDB instance, with no customer connections to it, should look something like the following example.
Using the CPU Utilization metric, you can determine if a DocumentDB instance is oversized. Generally speaking, a good utilization amount would be around 70-80%. Higher values than that would indicate that the instance is undersized, and may be impacting application performance. Values below that threshold would indicate potential oversizing and cost savings opportunity.
DocumentDB has a higher baseline CPU utilization than some other database engines. For example, see the following graph, which shows the baseline CPU utilization of a t3.medium instance type.
You can also stop a provisioned DocumentDB cluster for up to 7 days at a time. This is a useful capability for clusters that are used infrequently, such as those used for development or dedicated reporting purposes.
This stop and start process can be automated with the DocumentDB APIs, and scheduled to run at specific days and times. For example, you can stop clusters during nighttime hours and start them again in the morning when developers need access. You could also stop development and QA database clusters over weekend periods, when software teams are inactive.
The Amazon EventBridge service allows you to create Rules, based on a specific date and time, or an event triggered from another application. An EventBridge Rule can trigger the StopDBCluster API call for DocumentDB clusters as its Target configuration. For example, see the screenshot below.
If you’re using a different job scheduling solution, you can use the AWS CLI tool, AWS PowerShell module, or other supported AWS SDKs to call the same StopDBCluster API.
Another AWS service you can use to stop and start DocumentDB clusters, as part of a larger workflow, is the AWS Step Functions service. You can build out a workflow (aka. state machine) that calls various AWS APIs as well as business logic in Lambda functions, containers on AWS Fargate, or other services.
The workflow itself can be triggered from Amazon EventBridge, or any other application that incorporates the AWS SDK.
Here’s an example of a Step Functions state machine that will start a DocumentDB cluster, wait for 8 hours, and then stop the cluster again. You can trigger this state machine during weekdays, using an Amazon Event Bridge rule, so that your dev server is started in the morning, and automatically stopped during evening times when it’s not in use.
{
"Comment": "Automatically stop DocumentDB dev server during evening hours.",
"StartAt": "Start DocDB Dev Server",
"States": {
"Start DocDB Dev Server": {
"Type": "Task",
"Parameters": {
"DbClusterIdentifier": "MyData"
},
"Resource": "arn:aws:states:::aws-sdk:docdb:startDBCluster",
"Next": "Wait Until End of Day"
},
"Wait Until End of Day": {
"Type": "Wait",
"Seconds": 28800,
"Next": "Stop DocDB Dev Server"
},
"Stop DocDB Dev Server": {
"Type": "Task",
"Parameters": {
"DbClusterIdentifier": "MyData"
},
"Resource": "arn:aws:states:::aws-sdk:docdb:stopDBCluster",
"End": true
}
}
}
Remember that DocumentDB instances can only be stopped for up to 7 days at a time, until AWS automatically starts them. This is necessary to ensure that ongoing database engine maintenance is performed. To avoid RDS instances being restarted, and increasing your cloud spend, you can simply delete the DocumentDB clusters from your AWS account.
You can use any of the supported AWS SDKs, including the AWS CLI tool, to perform automated cleanup of unused DocumentDB clusters. Here’s an example of a command you could use to delete a DocumentDB cluster from your AWS account, using the AWS CLI.
If you’re deleting the cluster, using the DocumentDB APIs, then you’ll need to delete all of the DocumentDB instances that belong to a cluster before deleting the cluster itself. If you attempt to delete a cluster with active instances, you will receive an error message similar to:
An error occurred (InvalidDBClusterStateFault) when calling the DeleteDBCluster operation: Cluster cannot be deleted, it still contains DB instances in non-deleting state.
The following command will delete the named DocumentDB instance from a cluster.
aws docdb delete-db-instance --db-instance-identifier stratusgrid01
Once all of the DocumentDB instances have been removed from the cluster, you can delete the cluster itself.
aws docdb delete-db-cluster --db-cluster-identifier stratusgrid01 --skip-final-snapshot
According to the DocumentDB documentation, deleting the last instance in a cluster will also result in the cluster being deleted, so you may not need to issue the command to delete the cluster.
Amazon DocumentDB enables you to take snapshots of your databases, so that you can easily restore them for development / QA purposes, or for disaster recovery scenarios. Over a period of time, these snapshots may accumulate in your AWS account and increase your cloud spend.
Since AWS bills according to the size of storage, the largest costs will result from large databases. Even if you delete your DocumentDB clusters, the snapshots will be retained in your AWS account and incur cost.
You can list and delete snapshots from your AWS account using the following AWS CLI commands.
aws docdb describe-db-cluster-snapshots
aws docdb delete-db-cluster-snapshot --db-cluster-snapshot-identifier stratusgrid01
Stratusphere™ FinOps is a Software-as-a-Service (SaaS) solution developed and operated by StratusGrid, which helps you to identify cost savings opportunities across your entire organization. Stratusphere™ FinOps performs calculations based upon a variety of data sources, including Cost and Usage Reporting (CUR) data, and flags potential cost reductions as “findings.”
You can take action on these findings to reduce your cloud spend, with minimal or no impact to your line of business applications.
Unlock the full potential of your cloud operations with Stratusphere™ FinOps.
With Stratusphere™ FinOps, you gain access to powerful insights that help reduce your spending without impacting performance. Start your free trial now and experience firsthand how Stratusphere™ FinOps can transform your organization’s efficiency and cost-effectiveness.
Learn to reduce AWS costs with Stratusphere™ FinOps by efficiently remediating idle Amazon RDS instances, plus strategies to optimize your RDS...
Optimize your AWS Lambda functions by uncovering over-provisioning with Stratusphere™ FinOps by StratusGrid. Ensure cost efficiency and performance...
Discover how to efficiently backfill Cost and Usage Reports (CUR) from AWS into StratusGrid's cost optimization dashboard Stratusphere™ FinOps in our...