Removing Public Access with Overlapping RFC1918 Space

Peering fails on three counts. VPC peering requires non-overlapping CIDRs on both sides; the on-prem 10.0.0.0/8 already overlaps production 10.0.0.0/16, and advertising Atlas routes would collide with the Direct Connect routes for that space. Peering is also non-transitive: on-premises systems cannot reach Atlas through the production VPC's peering connection without a transit gateway or proxy, so the on-prem consumers are not solved at all.

PrivateLink for production and shared services. An interface endpoint gives the consumer VPC ENIs inside its own address space. There is no route-table change and no new /8 route, which is exactly what the security mandate demands, and CIDR overlap is irrelevant because nothing is routed. On-premises consumers reach the endpoint through their existing Direct Connect path to the VPC that hosts the endpoint.

eu-west-1 needs a topology decision, not just an endpoint. PrivateLink is regional: an endpoint only reaches nodes in that region. Either add an eu-west-1 region to the cluster (multi-region), or accept inter-region peering to us-east-1, or proxy through us-east-1 - each with different latency and cost. Do not promise the EU team an endpoint before this is decided.

Vendor: remove 0.0.0.0/0 immediately, allow only the vendor's current egress ranges refreshed by an automated job against the Atlas API with a documented risk acceptance, and set a date to move them behind a fixed-IP egress proxy.

Sequence

1. Create the private endpoints in each consumer VPC and approve them; wait for AVAILABLE. Record the private connection strings (the -pri hostnames / SRV form).
2. Add the endpoint subnets' address ranges to the Atlas project IP access list - private endpoint traffic is still evaluated by the access list, and this is the most common cause of a mysterious timeout after cutover.
3. Verify from one host per VPC before touching any application: DNS resolution of the private hostname, TCP 27017 via the endpoint security group, and a mongosh connection with TLS.
4. Migrate services one at a time by changing only the connection string through configuration, canary a low-risk service first, then the rest. Atlas serves public and private paths concurrently, so there is a working rollback path.
5. Watch connections per hostname and connection-error rates during the dual run. Drivers cache DNS/SRV records, so restarts or a TTL-aware driver configuration are part of the change.

Gate for removal: no connections on the public hostnames for at least seven consecutive days of normal traffic (including month-end batch), every consumer owner signed off, and the vendor exception documented. Only then delete the 46 entries, starting with 0.0.0.0/0.

Most likely cause first: DNS. The private hostnames resolve through a private hosted zone associated with the consumer VPC. If the eu-west-1 VPC is not associated, queries return the public IPs, public access is now blocked, and the client reports a timeout rather than a refused connection. Run dig +short <cluster>-pri.<host> from an EU host and compare with what the US hosts see.

Then, in order

1. Security group on the interface endpoint: does it allow 27017 from the EU VPC CIDR? A newly created endpoint inherits a default SG that usually does not.
2. Endpoint state and subnets: is the endpoint AVAILABLE, and does it have subnets in enough AZs that the client's AZ is covered?
3. Region reachability: PrivateLink is regional. If the cluster has nodes only in us-east-1, there is no valid EU endpoint to attach - confirm what region the endpoint service actually lives in. This is a design gap, not a firewall bug.
4. NACLs and on-host firewalls on the EU side.

Diagnosis discipline: a timeout with no server-side connection log means traffic never reached Atlas - treat it as a network/DNS problem and do not start changing cluster settings or access lists, which only widens the blast radius.