Atlas network peering lets you create a private connection between your application network and the Atlas network for a dedicated cluster. This connection routes traffic over private IP addresses instead of the public internet, which helps isolate application-to-database traffic. Atlas supports peering for dedicated clusters on AWS, Azure, and Google Cloud, and for sharded clusters that span multiple cloud providers. Compared to private endpoints, peering allows private network connectivity between Atlas and your cloud network, while private endpoints provide more narrowly scoped private access with less expansion of the network trust boundary.
The exact setup requirements and limitations vary by cloud provider, so you should review the provider-specific guidance before you configure the connection.
A key component of configuring network peering is defining the CIDR range in advance. Your Atlas CIDR must not overlap with any VPCs you plan to peer, and the CIDR size affects how many nodes and replica sets Atlas can support in that project or region. In Atlas, a network container is created automatically when you create a peering connection. In some cases, you might want to create or manage the container separately from the connection. To do this, follow the guide for managing network containers.
Note
The MongoDB Atlas Shared Responsibility Model defines the complementary duties of MongoDB and its customers in maintaining a secure and resilient data environment. Under this framework, MongoDB manages the security and operational integrity of the underlying platform, while customers are responsible for the configuration, management, and data policies of their specific deployments. For a detailed breakdown of ownership across security and operational excellence, see Shared Responsibility Model.
Limitations
Atlas does not support network peering between clusters deployed in a single region on different cloud providers. For example, you cannot set up network peering between an Atlas cluster hosted in a single region on AWS and an application hosted in a single region on Google Cloud.
Free clusters (formerly known as
M0) and Flex clusters do not support VPC peering. To use private networking, you must use a dedicated cluster.
Recommended Best Practices for Atlas Peering
Plan CIDR ranges early, ideally before deploying the first dedicated {+cluster} in a region. Your Atlas CIDR must not overlap with any VPCs you plan to peer, and the CIDR size affects how many nodes and replica sets Atlas can support in that project or region.
Use only RFC 1918 private addresses for peering networks.
An Atlas project can have a maximum total of 50 peering connections, of which a maximum of 25 can be pending.
Use VPC or VNet peering when you want private network paths to Atlas, but remember that peering extends the network trust boundary more than private endpoints do. If minimizing trust-boundary extension is the top priority, private endpoints are generally the better fit.
Treat peering as a least-privilege network design exercise: lock down security groups and network ACLs so Atlas does not gain unnecessary inbound reach into your application network, and consider using an intermediate VPC so only the components that need Atlas access are exposed.
Add the peer CIDR to the Atlas IP access list and make sure the cloud-side network routing is configured as explained in the provider-specific peering procedure.
Be explicit about connection string choice. In AWS, the standard connection string usually works over peering, and the
-pristring is optional unless you use custom DNS. In Azure and Google Cloud, use the Private IP for Peering connection string.For multi-region deployments, plan peering per cloud behavior: AWS and Azure require peering for each Atlas region involved, while Google Cloud uses global VPCs and needs only one peering connection.