Navigation

Create a Cluster

Atlas-managed MongoDB deployments, or “clusters”, can be either a replica set or a sharded cluster. All Atlas clusters run using the WiredTiger storage engine. This tutorial covers creating and configuring a new Atlas cluster.

To learn how to modify an existing Atlas cluster, see Modify a Cluster.

Important

If this is the first M10+ dedicated paid cluster for the selected region or regions and you plan on creating one or more VPC peering connections, please review the documentation on VPC Peering Connections before continuing.

A. Open the Create New Cluster Dialog

Note

Before creating a cluster, check that you have the correct organization and project selected. Click the Context drop down in the top left corner to select a specific organization or project. For more information on creating and managing organizations and projects, see Organizations and Projects.

Each Atlas project supports up to 25 clusters. Please contact Atlas support for questions or assistance regarding the cluster limit. To contact support, select Support from the left-hand navigation bar of the Atlas UI.

Go to the Clusters view and click the Add New Cluster or Build a New Cluster button to display the Create New Cluster dialog. As you build your cluster, Atlas displays the associated costs at the bottom of the screen. You can hover over the displayed cost for additional estimates.

B. Configure the Cluster Cloud Provider & Region

Select your preferred cloud provider and region. The choice of cloud provider and region affects the configuration options for the available instance sizes, network latency for clients accessing your cluster, the geographic location of the nodes in your cluster, and the cost of running the cluster.

Atlas supports deploying M0 Free Tier and M2/M5 shared-tier clusters on all cloud providers but only a subset of each cloud provider’s regions. Regions marked as Free Tier Available support deploying M0 Free Tier clusters. For a list of regions that support M2/M5 clusters, see:

Regions marked as ★ are Recommended regions that provide higher availability compared to other regions. For more information, see:

The number of availability zones, zones, or fault domains in a region has no affect on the number of MongoDB nodes Atlas can deploy. MongoDB Atlas clusters are always made of replica sets with a minimum of three MongoDB nodes.

From the Cloud Provider & Region section, you can also Select Multi-Region, Workload Isolation, and Replication Options.

Select Multi-Region, Workload Isolation, and Replication Options

To configure additional cluster options, toggle Select Multi-Region, Workload Isolation, and Replication Options (M10+ clusters) to Yes. Use these options to add cluster nodes in different geographic regions with different workload priorities, and direct application queries to the appropriate cluster nodes.

AWS Only

If this is the first M10+ dedicated paid cluster for the selected region or regions and you plan on creating one or more VPC peering connections, please review the documentation on VPC Peering Connections before continuing.

The following options are available when configuring cross-region clusters:

Electable nodes for high availability

Having additional regions with electable nodes increases availability and helps better withstand data center outages.

The first row lists the Highest Priority region. Atlas prioritizes nodes in this region for primary eligibility. For more information on priority in replica set elections, see Member Priority.

Click Add a region to add a new row for region selection and select the region from the dropdown. Specify the desired number of Nodes for the region. The total number of electable nodes across all regions in the cluster must be 3, 5, or 7.

Backup Data Center Location

If this is the first cluster in the project and you intend to enable continuous snapshot backups, Atlas selects the backup data center location for the project based on the geographical location of the cluster’s Highest Priority region. To learn more about how Atlas creates the backup data center, see Fully Managed Backup Service.

When selecting a Region, regions marked as Recommended provide higher availability compared to other regions. For more information, see:

Each node in the selected regions can participate in replica set elections, and can become the primary as long as the majority of nodes in the replica set are available.

You can improve the replication factor of single-region clusters by increasing the number of Nodes for your Highest Priority region. You do not have to add additional regions to modify the replication factor of your Highest Priority region.

To remove a region, click the trash icon icon next to that region. You cannot remove the Highest Priority region.

Atlas provides checks for whether your selected cross-regional configuration provides availability during partial or whole regional outages. To ensure availability during a full region outage, you need at least one node in three different regions. To ensure availability during a partial region outage, you must have at least 3 electable nodes in a Recommended region or at least 3 electable nodes across at least 2 regions.

Read-only nodes for optimal local reads

Use read-only nodes to optimize local reads in the nodes’ respective service areas.

Click Add a region to select a region in which to deploy read-only nodes. Specify the desired number of Nodes for the region.

Read-only nodes cannot provide high availability because they cannot participate in elections, or become the primary for their cluster. Read-only nodes have distinct replica set tags that allow you to direct queries to desired regions.

To remove a read-only region, click the trash icon icon next to that region.

Analytics nodes for workload isolation

Use analytics nodes to isolate queries which you do not wish to contend with your operational workload. Analytics nodes are useful for handling data analysis operations, such as reporting queries from BI Connector for Atlas. Analytics nodes have distinct replica set tags which allow you to direct queries to desired regions.

Click Add a region to select a region in which to deploy analytics nodes. Specify the desired number of Nodes for the region.

Analytics nodes cannot participate in elections or become the primary for their cluster.

To remove an analytics node, click the trash icon icon next to that region.

See also

For additional information on replica set tag sets, see Configure Replica Set Tag Sets in the MongoDB manual.

Note

Having a large number of regions or having nodes spread across long distances may lead to long election times or replication lag.

Important

For a given region in an Atlas project with multi-region clusters or clusters in multiple regions, you cannot have more than 40 MongoDB nodes on all other regions in that project. This limit applies across all cloud service providers. GCP regions communicating with each other do not count against that limit.

Example

If an Atlas project has 20 nodes in Region A and 20 nodes in Region B, you can deploy no more than 20 additional nodes in that project in any given region. This limit applies even if Region A and Region B are backed by different cloud service providers.

For Atlas projects where every cluster is deployed to a single region, you cannot create a multi-region cluster in that project if there are already 40 or more nodes in that single region.

C. Select the Cluster Tier

Select your preferred cluster instance size. The selected instance size dictates the memory, storage, and IOPS specification for each data-bearing server [2] in the cluster.

Atlas categorizes the instance sizes into tiers as follows:

Shared Clusters

Sandbox replica set clusters for getting started with MongoDB. These instances deploy to a shared environment with access to a subset of Atlas features and functionality. For complete documentation on shared cluster limits and restrictions, see Atlas M0 (Free Tier), M2, and M5 Limitations.

Atlas provides an option to deploy one M0 Free Tier replica set per project. You can upgrade an M0 Free Tier cluster to an M2+ paid cluster at any time.

M2 and M5 instances are low-cost shared starter clusters. These clusters provide the following additional features and functionality compared to M0 clusters:

Note

Atlas deploys MongoDB 4.0 for all instances in the Shared Clusters tier. However, Shared Clusters do not support all functionality in MongoDB 4.0. See Atlas M0 (Free Tier), M2, and M5 Limitations for details.

Atlas supports shared cluster deployment in a subset of Cloud Providers and Regions. Atlas greys out any shared cluster instance sizes not supported by the selected cloud service provider and region. For a complete list of regions that support shared cluster deployments, see:

Dedicated Clusters (for development and low-traffic applications)

Instances that support development environments and low-traffic applications.

These instances support replica set deployments only, but otherwise provide full access to Atlas features and functionality.

Dedicated Clusters (for production and high-traffic applications)

Instances that support production environments with high traffic applications and large datasets.

These instances support replica set and sharded cluster deployments with full access to Atlas features and functionality.

Some instances have variants, denoted by the ❯ character. When you select these instances, Atlas lists the variants and tags each instance to distinguish their key characteristics.

NVMe Storage on AWS

For applications which require low-latency and high-throughput IO, Atlas offers storage options on AWS which leverage locally attached ephemeral NVMe SSDs. The following instance sizes have an NVMe option, with the size fixed at the cluster tier:

  • M40
  • M50
  • M60
  • M80
  • M200
  • M400

Clusters with NVMe storage use Cloud Provider Snapshots for backup. Backup cannot be disabled for NVMe clusters.

NVMe clusters use a hidden secondary node consisting of a provisioned volume with high throughput and IOPS to facilitate backup.

The following table highlights key differences between an M0 Free Tier cluster, an M2 or M5 shared starter cluster, and an M10+ dedicated cluster.

  Free Tier Cluster (M0) Shared Starter Cluster (M2 and M5) Dedicated Cluster (M10 and larger)
Storage
512 MB
M2: 2 GB
M5: 5 GB
10 - 4000 GB
MongoDB Version Support 4.0 4.0 3.4, 3.6, 4.0, 4.2 (beta)
Metrics and Alerts Limited Limited Full metrics, including the Real Time Performance Tab, and full alert configuration options.
VPC Peering No No VPC Peering Connection wizard
Global Region Selection Atlas supports deploying M0 instances in a subset of regions in AWS, GCP, and Azure. Atlas supports deploying M2 and M5 clusters in a subset of regions in AWS, GCP, and Azure. Atlas supports deploying clusters globally on Amazon Web Services, Google Cloud Platform, and Microsoft Azure
Cross-Region Deployments No No Yes. Specify additional regions for high availability or local reads when creating or scaling a cluster.
Backups No Yes, daily backup snapshots Yes, including queryable backups
Sharding No No Yes, for clusters using an M30+ instance
Dedicated Instance No, M0 Free Tier clusters run in a shared environment No, M2 and M5 clusters run in a shared environment Yes, M10+ clusters deploy each mongod process to its own instance.
Performance Advisor No No Yes
BI Connector for Atlas No No Yes

For a complete list of M0 (Free Tier), M2, and M5 limitations, see Atlas M0 (Free Tier), M2, and M5 Limitations.

From the Cluster Tier section, you can also Customize Your Storage.

Customize Your Storage

Each cluster tier comes with a default set of resources. Clusters of size M10 and larger provide the ability to customize your storage capacity.

Atlas provides the following storage configuration options, depending on the selected cloud provider and instance size.

  • Cluster Class (AWS only)

    Clusters of size M40 and larger on AWS offer multiple options, including:

    • Low CPU

    • General

    • Local NVMe SSD

      Locally attached ephemeral NVMe SSDs offer the highest level of speed and performance.

    Select the Class box with your preferred speed. Changes to cluster class affect cost.

  • Storage Capacity

    The size of the server data volume. To change this, either:

    • Specify the exact disk size in the text box, or
    • Move the slide bar until the text box displays your preferred disk size.

    Changes to storage capacity affect cost.

    • Auto-Expand Storage: Available on clusters of size M10 and larger. When disk usage reaches 90%, automatically increase storage by an amount necessary to achieve 70% utilization. To enable this feature, check the box marked Auto-expand storage when disk usage reaches 90%.

      Changes to storage capacity affect cost.

      Contact Atlas support for guidance on oplog sizing for clusters with automatic storage expansion enabled. For details on how Atlas handles reaching database storage limits, refer to the FAQ page.

      Note

      AWS clusters with local NVMe SSDs cannot expand incrementally. When disk usage reaches 90%, NVMe clusters scale to the next available instance size, if any.

  • IOPS (configurable for AWS only)

    Atlas clusters on AWS of size M30 and greater allow you to customize the maximum IOPS rate of your cluster. To provision the IOPS rate of your cluster, check the box marked Provision IOPS and either:

    • Specify the exact IOPS rate in the text box, or
    • Move the slide bar until the text box displays your preferred IOPS rate.

    Note

    The available IOPS range for a cluster is tied to disk storage capacity. If you modify your cluster’s storage capacity, the range of available IOPS values changes as well.

    If you do not choose to provision IOPS, the default IOPS rate changes as the cluster’s storage capacity changes.

    Changes to IOPS provisioning affect cost.

    Important

    Atlas enforces the following minimum ratios by cluster tier to facilitate consistent network performance with large datasets.

    Disk Capacity to RAM:

    • -M40: 3:1
    • M40+: 50:1
    • M50+: 100 to 1

    For example, a cluster with 50 GB storage requires a value for IOPS of at least 150. To support 3 TB of disk capacity, you must select a cluster tier with at least 32 GB of RAM (M50 or higher).

    Atlas has a 4 TB disk capacity limit on all replica sets and shards, regardless of cluster tier. To expand total cluster storage beyond 4 TB, enable sharding.

    For clusters with Auto-Expand Storage enabled, Atlas respects the calculated maximum storage for the selected cluster tier. Users whose disk capacity reaches the allowable limit receive notification by email.

    For more information on the default resources and available configuration options for each cloud service provider, see:

D. Select any Additional Settings

Select the MongoDB Version of the Cluster

Select the new MongoDB version from the Select a version dropdown. Atlas always deploys the cluster with the latest stable release of the specified version.

Atlas supports creating M10+ paid tier clusters with the following MongoDB versions:

  • MongoDB 3.4
  • MongoDB 3.6
  • MongoDB 4.0
  • MongoDB 4.2 (beta)

M0 Free Tier and M2/M5 shared-tier clusters only support MongoDB 4.0.

As new maintenance releases become available, Atlas automatically upgrades to these releases via a rolling process to maintain cluster availability.

You can upgrade an existing Atlas cluster to a newer major MongoDB version, if available, when you scale a cluster. However, you cannot downgrade a cluster’s MongoDB version.

Important

If your project contains a custom role that uses actions introduced in a specific MongoDB version, you cannot create a cluster with a MongoDB version less than that version unless you delete the custom role.

Enable Backup for the Cluster

Backups are automatically enabled for M2 and M5 shared-tier clusters and cannot be disabled. For more information, see M2/M5 Snapshots.

To enable backups for an M10+ Atlas cluster, toggle Turn on Backup (M10 and up) to Yes. If enabled, Atlas takes snapshots of your databases at regular intervals and retains them according to your project’s retention policy.

Atlas provides the following backup options for M10+ clusters:

Backup Option Description
Continuous Backups

Atlas takes incremental snapshots of data in your cluster and allows you to restore from stored snapshots or from a selected point in time within the last 24 hours. You can also query a continuous backup snapshot.

Each project has one backup data center location dictated by the first backup-enabled cluster created in that project. See Snapshot Storage Location for more information.

Cloud Provider Snapshots Atlas takes either full copy snapshots (for Azure-backed clusters) or incremental snapshots (for AWS and GCP-backed clusters) of data in your cluster and allows you to restore from those snapshots. Atlas stores snapshots in the same cloud provider region as the replica set member targeted for snapshots.

Deploy a Sharded Cluster

Important

You cannot deploy a sharded cluster with MongoDB 4.2. Atlas only supports MongoDB 4.2 on replica sets.

To deploy your cluster as a sharded cluster, toggle Shard your cluster (M30 and up) to Yes.

Sharded clusters support horizontal scaling and consist of shards, config servers and mongos routers:

  • Atlas deploys each shard as a three-node replica set, where each node deploys using the configured Cloud Provider & Region, Cluster Tier, and Additional Settings. Atlas deploys one mongod per shard node.

    For cross-region clusters, the number of nodes per shard is equal to the total number of electable and read-only nodes across all configured regions. Atlas distributes the shard nodes across the selected regions.

  • Atlas deploys the config servers as a three-node replica set. The config servers run on M30 instances.

    For cross-region clusters, Atlas distributes the config server replia set nodes to ensure optimal availability. For example, Atlas might deploy the config servers across three distinct availability zones and three distinct regions if supported by the selected cloud service provider and region configuration.

  • Atlas deploys one mongos router for each node in each shard. For cross-region clusters, this allows clients using a MongoDB driver to connect to the geographically “nearest” mongos.

    To calculate the number of mongos routers in a cluster, multiply the number of shards by the number of replica set nodes per shard.

You cannot convert a sharded cluster deployment to a replica set deployment.

For details on how the number of server instances affect cost, see Number of Servers.

For more information on sharded clusters, see Sharding in the MongoDB manual.

Configure the Number of Shards

This field is visible only if the deployment is a sharded cluster.

You can set the number of shards to deploy with the sharded cluster. You can have no fewer than 2 shards and no more than 50 shards.

Enable BI Connector for Atlas

To enable BI Connector for Atlas for this cluster, toggle Enable Business Intelligence Connector (M10 and up) to Yes.

Note

BI Connector for Atlas is only available for M10+ clusters.

If enabled, select the node type from which BI Connector for Atlas should read.

The following table describes the available read preferences for BI Connector for Atlas and their corresponding readPreference and readPreferenceTag connection string options.

BI Connector Read Preference Description readPreference readPreferenceTags
Primary Read from the primary node. primary None
Secondary Read from secondary nodes. secondary nodeType:ELECTABLE,nodeType:READ_ONLY
Analytics BI Connector for Atlas reads from analytics nodes. secondary nodeType:ANALYTICS

The nodeType read preference tag dictates the type of node BI Connector for Atlas connects to. The possible values for this option are as follows:

  • ELECTABLE restricts BI Connector to the primary and electable secondary nodes.

  • READ-ONLY restricts BI Connector to connecting to non-electable secondary nodes.

  • ANALYTICS restricts BI Connector to connecting to analytics nodes.

    Tip

    When using a readPreference of "analytics", Atlas places BI Connector for Atlas on the same hardware as the analytics nodes from which BI Connector for Atlas reads.

    By isolating electable data-bearing nodes from the BI Connector for Atlas, electable nodes do not compete for resources with BI Connector for Atlas, thus improving cluster reliability and performance.

For high traffic production environments, connecting to the Secondary Node(s) or Analytics Node(s) may be preferable to connecting to the Primary Node.

For clusters with one or more analytics nodes, select Analytics Node to isolate BI Connector for Atlas queries from your operational workload and read from dedicated, read-only analytics nodes. With this option, electable nodes do not compete for resources with BI Connector for Atlas, thus improving cluster reliability and performance.

The BI Connector generates a relational schema by sampling data from MongoDB. The following sampling settings are configurable:

BI Connector Option Type Description
Schema Sample Size integer Optional. The number of documents that the BI Connector samples for each database when gathering schema information. For more information, see the BI Connector documentation.
Sample Refresh Interval integer Optional. The frequency, in seconds, at which the BI Connector re-samples data to recreate the schema. For more information, see the BI Connector documentation.

Enable Encryption at Rest

Configure Encryption at Rest using your Key Management for your Atlas Project

You must configure the Atlas project for Encryption at Rest using your Key Management before enabling the feature for your Atlas clusters. To learn more, see Encryption at Rest using Customer Key Management.

Atlas supports the following Encryption at Rest providers:

Important

If you want to switch from one Encryption at Rest provider on your cluster to another, you must first disable Encryption at Rest for your cluster, then re-enable it with your desired Encryption at Rest provider. See Encryption at Rest using Customer Key Management.

Atlas encrypts all cluster storage and snapshot volumes, ensuring the security of all cluster data at rest (Encryption at Rest). Atlas Project Owners can configure an additional layer of encryption on their data at rest using the MongoDB Encrypted Storage Engine and their Atlas-compatible Encryption at Rest provider.

To enable Atlas Encryption at Rest for this cluster, toggle Encryption At Rest with WiredTiger Encrypted Storage Engine (M10 and up) to Yes.

Atlas Encryption at Rest using your Key Management supports M10 or greater replica set clusters backed by AWS or Azure only. Support for clusters deployed on Google Cloud Platform (GCP) is in development. Atlas Encryption at Rest supports encrypting Cloud Provider Snapshots only. You cannot enable Encryption at Rest on a cluster using Continuous Backups.

Atlas clusters using Encryption at Rest using your Key Management incur an increase to their hourly run cost. For more information on Atlas billing for advanced security features, see Advanced Security.

Important

If Atlas cannot access the Atlas project key management provider or the encryption key used to encrypt a cluster, then that cluster becomes inaccessible and unrecoverable. Exercise extreme caution before modifying, deleting, or disabling an encryption key or key management provider credentials used by Atlas.

Configure Additional Configuration Options

You can configure the following mongod runtime options on M10+ paid tier clusters:

Set Oplog Size [1]

Modify the oplog size of the cluster. For sharded cluster deployments, this modifies the oplog size of each shard in the cluster. This option corresponds to modifying the replication.oplogSizeMB configuration file option for each mongod in the cluster.

To modify the oplog size:

  1. Log into Atlas.
  2. For your desired cluster, click Edit Configuration from the ellipsis h icon menu.
  3. Click Additional Settings.
  4. Set the oplog to the desired size.
  5. Click Apply Changes.

You can check the oplog size by connecting to your cluster via the mongo shell and authenticating as a user with the Atlas admin role. Run the rs.printReplicationInfo() method to view the current oplog size and time.

Warning

Reducing the size of the oplog requires removing data from the oplog. Atlas cannot access or restore any oplog entries removed as a result of oplog reduction. Consider the ramifications of this data loss before reducing the oplog.

Enforce Index Key Limit
Enable or disable enforcement of the 1024-byte index key limit. Documents can only be updated or inserted if, for all indexed fields on the target collection, the corresponding index entries do not exceed 1024 bytes. If disabled, mongod writes documents that breach the limit but does not index them. This option corresponds to modifying the failIndexKeyTooLong parameter via the setParameter command for each mongod in the cluster.
Allow Server-Side JavaScript
Enable or disable execution of operations that perform server-side execution of JavaScript. This option corresponds to modifying the security.javascriptEnabled configuration file option for each mongod in the cluster.
Set Minimum TLS Protocol Version [1]

Sets the minimum TLS version the cluster accepts for incoming connections. This option corresponds to configuring the net.ssl.disabledProtocols configuration file option for each mongod in the cluster.

TLS 1.0 Deprecation

For users considering this option as a method for enabling the deprecated Transport Layer Security (TLS) 1.0 protocol version, please read What versions of TLS does Atlas support? before proceeding. Atlas deprecation of TLS 1.0 improves your security of data-in-transit and aligns with industry best practices. Enabling TLS 1.0 for any Atlas cluster carries security risks. Consider enabling TLS 1.0 only for as long as required to update your application stack to support TLS 1.1 or later.

Require Indexes for All Queries
Enable or disable the execution of queries that require a collection scan to return results. This option corresponds to modifying the notablescan parameter via the setParameter command for each mongod in the cluster.
[1](1, 2) Atlas performs uses a rolling deployment process to apply modifications to these options. For sharded clusters, this involves a rolling restart of all shards and the config server replica set. To learn more about how Atlas supports high availability during maintenance operations, see How does MongoDB Atlas deliver high availability?.

E. Enter the Cluster Name

This is the cluster name as it appears in Atlas. You cannot change the cluster name once Atlas deploys the cluster.

F. Enter your Payment Information and Deploy your Cluster

Click Create Cluster below the form to enter payment information. Atlas does not prompt you for payment information if you have already provided payment information for the organization within which you are deploying the cluster. For Atlas M0 Free Tier clusters, Atlas does not require payment information to deploy the cluster.

See Billing Overview for more information on Atlas billing and payments.

G. (Optional) Create a MongoDB Administrative User

Atlas only allows client connections to the cluster from entries in the project IP whitelist. Clients must also authenticate as a MongoDB database user associated to the project.

If you have not configured the project IP whitelist or MongoDB users, navigate to the Database Access and Network Access pages to configure basic project security.

When creating your first MongoDB database user, select the Atlas admin role from the user configuration dialog to create an administrative user. See MongoDB Database User Privileges for more information on MongoDB user privileges.

If you need to modify your existing project security settings navigate to the guilabel:Database Access, Network Access, and Advanced pages under the Security section in the navigation. See Security Features and Setup for complete documentation on Atlas project security settings.

H. Connect to your cluster

Once Atlas deploys your cluster, click Connect on the cluster to open the Connect dialog. To learn how to connect to your cluster, see Connect to a Cluster.

Open Ports 27015 to 27017 to Access Atlas Databases

If you use a whitelist on your firewall for network ports, open ports 27015 to 27017 to TCP and UDP traffic on Atlas hosts. This grants your applications access to databases stored on Atlas.

To configure your application-side networks to accept Atlas traffic, we recommend using the Atlas API Get All Clusters endpoint to retrieve mongoURI from the response elements. You can also use the Get All MongoDB Processes endpoint to retrieve cluster hostnames (mongo-shard-00-00.mongodb.net, mongo-shard-00-01.mongodb.net etc).

You can parse these hostname values and feed the IP addresses programatically into your application-tier orchestration automation to push firewall updates.

See also

View Clusters

[2]For replica sets, the data-bearing servers are the servers hosting the replica set nodes. For sharded clusters, the data-bearing servers are the servers hosting the shards. For sharded clusters, Atlas also deploys servers for the config servers; these are charged at a rate separate from the instance costs.