How do I set up private networking (VPC peering / PrivateLink) for MongoDB Atlas for a production environment?
Operational Databases (OLTP)

How do I set up private networking (VPC peering / PrivateLink) for MongoDB Atlas for a production environment?

10 min read

Designing a secure, production-ready MongoDB Atlas environment almost always includes private networking. Instead of exposing your database over the public internet, you connect your application VPC or VNet to Atlas over private links such as VPC Peering or AWS PrivateLink / Azure Private Link / GCP Private Service Connect. This reduces attack surface, helps meet compliance requirements, and aligns with zero-trust networking best practices.

Below is a practical, step-by-step guide to setting up private networking for MongoDB Atlas in a production environment, with a focus on AWS but including notes for Azure and GCP. The same principles apply whether you’re running microservices, a monolith, or a hybrid on-prem/cloud architecture.

1. Understand private networking options in MongoDB Atlas

MongoDB Atlas provides multiple private connectivity patterns so you can keep traffic off the public internet:

  • VPC Peering (AWS/GCP) / VNet Peering (Azure)

    • Directly connects your cloud VPC/VNet to the Atlas-managed VPC/VNet.
    • Uses private IPs only (no public internet routing).
    • Simple routing; good for single-region or simpler topologies.

  • PrivateLink (AWS) / Private Link (Azure) / Private Service Connect (GCP)

    • Exposes Atlas as a private endpoint inside your own VPC/VNet.
    • You connect to a private IP in your network, and the cloud provider handles the private connectivity to Atlas.
    • Strong isolation and more flexible multi-account / multi-VPC patterns.

  • Public access with IP Access Lists

    • Not recommended for strict production environments when private networking is possible, but can be used alongside private networking (e.g., for temporary external access, monitoring, or emergencies).

In production, teams typically:

  • Use PrivateLink-style endpoints for higher isolation, multi-account setups, or when using centralized networking/VPCs.
  • Use VPC peering for simpler, single-account, single-region deployments.

2. Prerequisites for production-grade private networking

Before creating any peering or PrivateLink connection, ensure:

  1. Atlas project and cluster are created

    • You can use a free tier or flex tier cluster to test, but for production you’ll usually use Dedicated Tier clusters. These offer fixed pricing and are designed for predictable, production-ready workloads with high availability.

  2. Cloud provider networking is in place

    • An AWS VPC / Azure VNet / GCP VPC for your application.
    • Subnets, route tables, and security groups/NSGs configured per your security standards.

  3. Region alignment

    • For best performance and simplest configuration, deploy your Atlas cluster in the same region as your application VPC/VNet (e.g., us-east-1 in AWS for both).

  4. Security and compliance requirements

    • Decide whether to restrict public network access entirely.
    • Align configuration with your organization’s requirements; Atlas helps meet stringent compliance needs with features like full-lifecycle encryption and enterprise-grade security out of the box.

3. Setting up VPC peering with MongoDB Atlas (AWS example)

3.1. Plan your IP ranges

  • Ensure no CIDR conflicts between:
    • Your application VPC (e.g., 10.0.0.0/16)
    • Atlas VPC (Atlas will display its CIDR, e.g., 192.168.248.0/21)
  • If there’s overlap, you must adjust your VPC CIDR or use a different connectivity method (PrivateLink) or a separate VPC.

3.2. Create a VPC peering connection in Atlas

  1. Log in to the Atlas UI.
  2. Go to Network Access → Private Endpoint / Peering (menu label may vary slightly by version).
  3. Choose VPC Peering and select:
    • Cloud provider: AWS.
    • Atlas project region: Region where your cluster is deployed.
  4. Enter details of your application VPC:
    • AWS Account ID.
    • VPC ID (e.g., vpc-0123456789abcdef0).
    • VPC CIDR block.
  5. Submit the request; Atlas will generate a VPC peering connection in pending acceptance state.

3.3. Accept the peering connection in AWS

  1. In the AWS Console, navigate to VPC → Peering connections.
  2. Locate the peering connection created by Atlas.
  3. Verify the details:
    • Requester: Atlas-owned VPC.
    • Accepter: your VPC.
  4. Click Accept request.

3.4. Update route tables in your VPC

To ensure traffic can flow between your VPC and the Atlas VPC:

  1. In AWS, open VPC → Route tables.
  2. For each route table associated with subnets running your application:
    • Add a route:
      • Destination: Atlas VPC CIDR (e.g., 192.168.248.0/21).
      • Target: the VPC peering connection.
  3. Save the changes.

Atlas manages the routes on its side, so you only need to update your own route tables.

3.5. Configure security groups and access lists

  • AWS Security Groups:
    • Allow outbound traffic from application instances to Atlas cluster ports (default MongoDB port is 27017, but check your Atlas configuration).
  • Atlas Network Access:
    • Add a CIDR access rule for your VPC’s CIDR (or specific subnets) if required by your network policy.
    • Optionally disable public access by:
      • Removing 0.0.0.0/0.
      • Restricting to private networking paths only.

4. Setting up PrivateLink for MongoDB Atlas (AWS)

VPC peering is straightforward, but AWS PrivateLink is often preferred for larger or more secure production environments because it:

  • Exposes Atlas as a private endpoint in your VPC.
  • Works well in multi-account and hub-and-spoke network architectures.
  • Avoids full VPC-to-VPC routing; only specific services are reachable.

4.1. Create a Private Endpoint in Atlas

  1. In the Atlas UI, go to Network Access → Private Endpoint.
  2. Select AWS and the region of your Atlas deployment.
  3. Click Add Private Endpoint and provide:
    • Your AWS VPC ID.
    • The subnets where the endpoint will be placed (these must be in the same region).
  4. Atlas generates:
    • An Endpoint Service Name (e.g., com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxxxxxxxxxxx).
    • Instructions for creating an Interface VPC Endpoint in AWS.

4.2. Create an Interface VPC Endpoint in AWS

  1. In the AWS Console, go to VPC → Endpoints → Create endpoint.
  2. Choose:
    • Service category: Other endpoint services.
    • Service name: Paste the Endpoint Service Name from Atlas.
  3. Select:
    • Your VPC.
    • One or more subnets (usually private subnets where your application runs).
  4. Configure:
    • Security groups: Allow outbound traffic to port 27017 (and any additional ports used by Atlas features like metrics or HTTP APIs if needed).
  5. Create the endpoint.

4.3. Approve the endpoint in Atlas

  1. Return to Atlas → Network Access → Private Endpoint.
  2. Locate the newly created endpoint; it should appear in Pending state.
  3. Click Approve to complete the association.

Once approved, AWS will provision a private IP address in your VPC for the endpoint. Your application will connect to Atlas using a special PrivateLink connection string provided by Atlas.

4.4. Use the PrivateLink connection string

  1. In Atlas, go to your cluster → Connect.
  2. Choose Private Endpoint as the connection type.
  3. Copy the connection string and configure it in:
    • Application configuration files.
    • Secret managers (AWS Secrets Manager, HashiCorp Vault, etc.).
  4. Redeploy your application so it uses the PrivateLink connection string instead of public DNS.

4.5. Lock down public access (optional but recommended)

For a production-grade posture:

  1. In Atlas → Network Access:
    • Remove broad IP entries like 0.0.0.0/0.
    • Ensure only Private Endpoint access is allowed, plus any explicitly required IPs (e.g., bastion hosts, monitoring tools).
  2. In AWS:
    • Ensure security groups do not allow unnecessary inbound access from the internet.
    • Use internal load balancers and NAT gateways where needed.

5. Azure Private Link and GCP Private Service Connect

The concepts are similar across providers:

5.1. Azure Private Link

  • Atlas side:

    • Create a Private Endpoint configuration in the Atlas UI, selecting Azure and region.
    • Atlas provides the Private Link service information.

  • Azure side:

    • In Azure Portal → Private endpoints → Create.
    • Choose Azure resource or resource by ID depending on instructions from Atlas.
    • Connect to the Atlas Private Link service.
    • Choose your VNet and subnet.
    • Configure Network Security Groups (NSGs).

  • Post-setup:

    • Approve the endpoint in Atlas.
    • Use the Private Link connection string for your cluster.
    • Restrict public access in Atlas and in Azure NSGs.

5.2. GCP Private Service Connect (PSC)

  • Atlas side:

    • Enable Private Service Connect for your project/cluster in the Atlas UI.
    • Obtain service attachment details.

  • GCP side:

    • In GCP Console → VPC network → Private Service Connect.
    • Create a PSC endpoint pointing to the Atlas service attachment.
    • Attach it to your VPC and relevant subnet.

  • Post-setup:

    • Approve the endpoint in Atlas.
    • Use PSC-specific connection string from Atlas.
    • Lock down public access.

6. Hardening and best practices for production

Once private networking is established, apply additional production hardening:

6.1. Combine private networking with Atlas security features

MongoDB Atlas delivers enterprise-grade security out of the box. For production:

  • Enable encryption:
    • Atlas uses encryption at rest by default.
    • Consider using customer-managed keys (e.g., AWS KMS, Azure Key Vault, GCP KMS) for full-lifecycle encryption control.
  • Use strong authentication and authorization:
    • Enforce users with SCRAM or X.509 where appropriate.
    • Apply role-based access control (RBAC) with least privilege.
  • Enable auditing and monitoring:
    • Use Atlas monitoring and alerts.
    • Integrate logs with your SIEM for centralized visibility.

6.2. High availability and resiliency

  • Deploy your Atlas cluster as a replica set across multiple availability zones.
  • Rely on Atlas’s automated failovers and its 99.995% uptime SLA for production clusters.
  • For multi-region deployments:
    • Use multi-region clusters with appropriate read/write preferences.
    • Ensure PrivateLink/VPC peering is configured in each relevant region or use global routing strategies.

6.3. Network design tips

  • Prefer hub-and-spoke architecture:
    • Place common services (e.g., Atlas PrivateLink endpoints) in a central “hub” VPC/VNet.
    • Connect multiple “spoke” application VPCs/VNets via peering or transit gateways.
  • Standardize CIDR allocations to avoid IP conflicts with Atlas-managed VPCs.
  • Define internal DNS naming conventions to simplify routing and failover.

7. Automating private networking for MongoDB Atlas

For production at scale, avoid manual configuration and instead use automation:

  • MongoDB Atlas CLI

    • Install with: 
      brew install mongodb-atlas-cli
atlas setup
    • Use CLI commands to:
      • Create projects and clusters.
      • Configure VPC peering or Private Endpoints.
      • Manage network access and users.

  • Infrastructure-as-Code (IaC):

    • HashiCorp Terraform:
      • Use the official MongoDB Atlas Terraform provider to define:
        • Projects, clusters, VPC peering, Private Endpoints, IP access lists.
    • AWS CloudFormation:
      • Define VPCs, subnets, security groups, VPC endpoints, and route tables in templates.
    • Kubernetes Operator:
      • If your workloads run on Kubernetes, use the MongoDB Atlas Kubernetes Operator to provision clusters and networking alongside your app resources.

Automation ensures consistent, repeatable setups across environments (dev, staging, prod) and simplifies audits and change management.

8. Validating and troubleshooting your setup

Before going live:

  1. Connectivity tests:

    • From an instance/pod in your VPC/VNet, run: 
      nc -vz <atlas-host> 27017
    • Confirm successful TCP connection via Private Endpoint or peering.

  2. DNS resolution:

    • Ensure the Atlas hostnames in your connection string resolve to private IPs (for PrivateLink/Private Service Connect).
    • Check your DNS settings, especially if using custom resolvers or conditional forwarders.

  3. Failover tests:

    • Use Atlas’s test failover feature to ensure your application handles replica set member changes gracefully.

  4. Firewall and security group checks:

    • Confirm that only necessary ports are open.
    • Verify there’s no unintended public exposure of MongoDB ports.

9. Summary

To set up private networking for MongoDB Atlas in a production environment:

  1. Choose the right model:
    • VPC/VNet peering for simple, single-account deployments.
    • PrivateLink / Private Service Connect for higher isolation, multi-account, or hub-and-spoke architectures.
  2. Configure networking:
    • Align regions and IP ranges, create peering or Private Endpoints, update route tables, and security groups/NSGs.
  3. Harden security:
    • Lock down public access, enable encryption and RBAC, and rely on Atlas’s enterprise-grade security capabilities.
  4. Automate:
    • Use the Atlas CLI, Terraform, CloudFormation, or Kubernetes Operator for repeatable, auditable production setups.
  5. Validate:
    • Test connectivity, DNS, failover behavior, and monitoring before going live.

This approach leverages MongoDB Atlas’s secure-by-default design, high availability (99.995% uptime SLA for production clusters), and flexible connectivity options to deliver a robust, production-grade private networking configuration.

Back to Operational Databases (OLTP)

Keep Reading

More from Operational Databases (OLTP)

We’re standardizing on MongoDB Atlas—how do we start an enterprise trial/security review and get pricing via AWS/Azure/GCP marketplace?

Read more

How do I use MongoDB Atlas Data Federation and Online Archive to query hot + archived data in one place?

Read more

MongoDB Atlas: how do I set up org/projects, IP access or private endpoints, and production users/roles for a new production cluster?

Read more