3 Ways to Leverage MongoDB Atlas for Data Transfer Cost Optimization

Business was going up and to the right when the macroeconomic impact hit. As a cloud center of excellence member, manager, or developer, you are now focused on analyzing and optimizing your cloud infrastructure spend. You made it your priority to ensure your applications remain available and uninterrupted in this new world of cost optimization.

Based on the report in the Atlas Billing Explorer, you have confirmed that your data transfer costs can add up to 20% of your monthly Atlas spend. This looks like a target ripe for optimization. You double click into the report and it reveals that a significant percentage of the spend is related to inter-availability-zone and inter-region data egress. Now, you are ready to start executing.

Atlas makes it a breeze to manage your cloud data infrastructure. Today, we will explore how it can help you achieve your cost optimization goals and get the recognition you deserve.

Caveat: We recommend testing the tips outlined in this guide on non-production clusters first. If you are unsure whether these suggestions are applicable to your cluster, reach out to support or to your MongoDB account team. We will be happy to guide you in the right direction.

Let’s take a look at three ways in which Atlas lets you optimize data transfer cost today, by making a small configuration change to your MongoDB driver.

1. Enable network compression

Compression in-transit, between the client (typically the MongoDB driver) and the server (the Atlas cluster), can achieve up to 50% reduction in network egress volume.

Atlas provides three compression modes: Snappy, Zlib, and Zstandard.

Let’s see the example below for how to specify Snappy compression in a Node driver:

const uri =
  "mongodb+srv://<username>:<password>@clustername.abcdef.mongodb.net";

const client = new MongoClient(uri,
  {
    compressors: ["snappy"]
  });

Check out our docs page for the Node driver, our simple guide for Python, and other drivers for more details. We recommend the Snappy compressor for minimum performance impact, if your application is latency-sensitive and requires significant resource headroom. Zstandard brings the best balance of resource utilization and compression capabilities and is the recommended choice for most applications. If you deploy applications across a variety of environments (e.g., Node, Java, Ruby), consider Zlib, which features the best compatibility across MongoDB drivers. Make sure to monitor CPU utilization when testing different configuration options.

2. Set up a cloud region read preference

If you take advantage of secondary reads, such as when using read-only and analytics nodes, you might be familiar with the concept of read preference. It is a configuration option that informs the driver which node to target for reads. It ensures better workload isolation and in turn, improves performance for mission-critical use cases.

Atlas multi-region clusters provide improved availability and disaster recovery during a cloud provider regional outage. But cross-region (and cross-cloud) data transfer traffic can sometimes rack up significant data transfer bills. You can mitigate this by specifically targeting nodes deployed in the same cloud provider region for secondary reads.

Let’s consider a cluster deployed in three AWS regions, one of them us-east-2. See below for how to specify your regional read preference for the us-east-2 region in the Node driver configuration:

const options = {
  readPreference: "secondaryPreferred",
  readPreferenceTags: [
    {provider : "AWS", region : "US_EAST_2"},
    {}
  ]
};
const client = new MongoClient(uri, options);

The secondaryPreferred read preference and the empty braces at the end of readPreferenceTags instruct the driver to fall back to targeting any cluster nodes in the event that no nodes deployed in us-east-2 are available for query.

3. Configure cloud availability zone read preference

Last year, Atlas introduced a new replica set tag specifying the availability zone (AZ) deployment for each of the cluster nodes. You can review these tags to confirm your high availability configuration across multiple AZs. Today, we will leverage them to reduce the impact of inter-AZ data transfer cost by up to 20%, depending on how heavily you rely on secondary reads.

First, let’s open mongosh, connect to the Atlas cluster, and run rs.conf(). This will return the replica set configuration document, including replica set tags. We can see the AZ assignment for each node under the members.tags array:

Atlas atlas-klmnop-shard-0 [primary] test> rs.conf()
{
      …
  members: [
    {
      _id: 0,
      host: "atlas-klmnop-shard-00-00.abcdef.mongodb.net:27017",
      …
      tags: {
        workloadType: "OPERATIONAL",
        availabilityZone: "use2-az1",
        diskState: "READY",
        nodeType: "ELECTABLE",
        provider: "AWS",
        region: "US_EAST_2"
      },
…
 ]
…
}

Lastly, specify the AZ tag in the Node driver read preference configuration:

const options = {
  readPreference: "secondaryPreferred",
  readPreferenceTags: [
    {availabilityZone : "use2-az1"},
    {}
  ]
};
const client = new MongoClient(uri, options);

You can combine the region and availability zone tag for maximum cost optimization:

const options = {
  readPreference: "secondaryPreferred",
  readPreferenceTags: [
    {availabilityZone : "use2-az1"},
    {provider : "AWS", region : "US_EAST_2"},
    {}
  ]
};
const client = new MongoClient(uri, options);

This configuration ensures the driver defaults to any node available in the region, if nodes deployed in the specified availability zone are not available for query.

Summary

Your Atlas deployments stand to benefit from significantly reduced data transfer cost, with the help of a few key, yet simple to set up, Atlas features.

If you enjoyed this guide, check out a recent MongoDB.local New York talk on Leveraging Atlas for Improved Cost Management, for a broader overview, including workload optimization and compute and storage cost considerations.