VPC peering creates a private network connection between an application VPC and an Atlas VPC, routing database traffic without exposing it to the public internet. It suits sensitive-data workloads, compliance requirements, and applications that benefit from private, low-latency access. section 20.6.2 section 20.6
Apply the following constraints when evaluating a peering design:
- Use network peering with dedicated Atlas clusters on AWS, GCP, or Azure, and with multicloud sharded clusters. section 20.6.2
- Do not select it for M0 or Flex clusters; those tiers do not support network peering. section 20.6.2
- Choose private IP-only access when traffic must remain private, or combine private and public access according to the IP access list. section 20.6.2
- Compare peering with IP access lists and private endpoints: peering enables private routing between VPCs, while private endpoints preserve a stricter boundary by preventing Atlas from initiating connections back to your VPC. section 20.6 section 20.8
Application VPC connected to Atlas
An AWS Customer VPC uses CIDR block 10.0.0.0/16 and hosts application servers behind an Elastic load balancer. It peers with an Atlas VPC using 172.31.248.0/21; Atlas cluster nodes span three availability zones, and traffic follows private routes between the two networks. section 20.6.2
Figure 20.4 Atlas VPC peered to an AWS VPC (Image © MongoDB 2024 CC BY-NC-SA 3.0)
Use the topology figure to inspect how application servers, load balancing, CIDR ranges, availability zones, and Atlas cluster nodes fit across the peered VPCs. section 20.6.2

