When would you choose an Atlas private endpoint over VPC peering, and what changes for clients?

## The problem both solve By default an Atlas cluster is reached over the public internet, protected by TLS, database authentication, and the project's IP access list. That is defensible, but many organizations require that database traffic never traverse the public internet at all. Atlas offers two private paths, and the interview question is which one and why. ## VPC peering Peering creates a routing relationship between your VPC (or Azure VNet, or GCP VPC) and the VPC Atlas runs the project's clusters in. Once routes and rules are in place, your instances address the cluster over private addressing. Properties that decide the choice: - **Bidirectional.** Peering is a network join, not a service exposure. Both sides can, in principle, route to each other, which some security teams reject on principle. - **CIDR coordination.** Peered networks must not have overlapping address ranges. In a large organization with historically allocated RFC 1918 space, this is frequently the blocker — and it is not fixable without renumbering. - **Non-transitive.** If your application lives in VPC A, which peers with VPC B, which peers with Atlas, A cannot reach Atlas. Every VPC that needs access needs its own peering connection. - **Same cloud provider.** You peer AWS to AWS, Azure to Azure, GCP to GCP. - **Access list still applies.** Peering changes the path, not the admission control. You add the peer VPC's CIDR — or, on AWS, the peer security group, which is the more maintainable form because membership follows the group rather than an address range. ## Private endpoints A private endpoint uses the cloud provider's service-exposure primitive: AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. Atlas publishes the cluster as a service; you create an interface endpoint in your own VPC and Atlas approves it. Your clients then resolve a private address inside your own network. What this changes: - **Unidirectional.** The endpoint exposes Atlas to you. Atlas cannot initiate connections back into your VPC, which is a materially smaller blast radius and the argument that usually wins with a security reviewer. - **No CIDR coordination.** Because nothing is routed between networks, overlapping address space is irrelevant. This alone decides the question in many enterprises. - **Endpoint approval is the control.** The path is admitted by virtue of the approved endpoint, so you are not maintaining public IP access-list entries for application traffic. In practice the access list then shrinks to whatever administrative tooling still comes over the public path. - **A different connection string.** This is the operational gotcha. Atlas issues a distinct private-endpoint SRV hostname; the public string will not resolve to the endpoint. Applications must be redeployed with the new URI, and a migration therefore has a cutover, not a silent switch. - **Regional and per-provider.** An endpoint serves one region. A multi-region replica set — or a multi-cloud cluster — needs an endpoint in each region where you want private connectivity, and each is configured separately. - **Cost.** Provider charges apply per endpoint-hour and per gigabyte processed. At high volume this is a real line item and worth modelling before committing. ## Choosing Reach for a **private endpoint** when: CIDRs overlap or you cannot coordinate address space; the security requirement is one-way exposure; clients are spread across accounts and VPCs (each gets its own endpoint without a mesh of peerings); or you want to stop maintaining public IP entries entirely. Reach for **peering** when: you already operate a peered topology and want private addressing with minimal new machinery; you need the cluster reachable from a network where creating endpoints is awkward; or the per-gigabyte endpoint charge is unattractive at your volume and the CIDR space is clean. Many production deployments end with private endpoints for application traffic, a tiny access list for operators and CI, no public application path at all, and separate Atlas projects per environment so none of this configuration leaks between staging and production. ## What neither does Private connectivity is not authentication and not authorization. Anyone who reaches the endpoint still needs a database user with roles, and TLS still protects the session. A frequent review finding is a cluster with a beautiful private path and a `readWriteAnyDatabase` credential shared by six services — the network work was the easy half.