Video Transcript (English)

Imagine connecting to your MongoDB Atlas cluster from the applications on your virtual private cloud with pinpoint precision—targeting only the exact cluster you need while keeping your data completely off the public internet.

That's the power of private endpoints. They provide the most secure way to access your data, creating a direct, private tunnel between your application and specific Atlas resources.

In this lesson, we'll explore what private endpoints are, how they work, and when to use them. We'll examine how they differ from other connection methods and walk through setting up a private endpoint using AWS. By the end, you'll have another useful tool in your security toolbox for protecting your MongoDB data.

When we look at a network peering setup, we see two virtual networks connected: your cloud provider's VPC and the MongoDB Atlas VPC. This connection allows resources in your VPC to communicate with your Atlas cluster since you've opened the necessary ports.

This approach works well, but it's connecting two entire networks just to access a single resource—your Atlas cluster. It's like building a bridge between two islands when you only need to visit one specific building.

Instead, what if we could create a direct, private connection specifically to the Atlas cluster and nothing else?

Private endpoints create a secure, resource-specific link to your Atlas cluster. Rather than connecting entire networks, private endpoints allow you to effectively isolate access to the cluster to your VPC without exposing it to other parts of your network or the internet.

Here's how they work: a private endpoint maps a specific resource (your Atlas cluster) to an IP address within your virtual private cloud, essentially making that resource appear as if it's part of your network. Traffic to the resource stays completely within your private network and the cloud provider's backbone infrastructure.

It's important to note that private endpoints are unidirectional—they allow your applications to connect to Atlas, but not the other way around. This adds another layer of security by limiting the direction of communication.

MongoDB Atlas supports private endpoints for all major cloud providers: AWS PrivateLink, Azure Private Link, and Google Cloud Private Service Connect. Each implementation has its own specific configuration, but they all achieve the same goal.

One limitation to be aware of: if you have a multi-region or multi-cloud cluster setup, it’s required to configure private endpoints for each region or cloud provider you're using. This ensures your applications can connect to the nearest cluster node without going over the public internet.

Let's walk through setting up a private endpoint using AWS. The process follows similar principles across other cloud providers, though the specific commands will vary.

First, we need to create a private endpoint service in Atlas using the Atlas CLI:

The privateEndpoints aws create command tells Atlas to create a new AWS private endpoint service. The region flag specifies us-west-1 as the AWS region where the Atlas cluster and VPC is located, and the projectId flag identifies the Atlas project.

When successful, Atlas responds with a simple confirmation that the endpoint service was created and that provides the unique ID we'll need in subsequent steps.

With that complete, we can move on to retrieving the endpoint service name from Atlas.

For this, we're using the privateEndpoints describe command to get details about our endpoint service. We provide the privateEndpointId we received earlier, the same projectId, and we specify json output format for easier reading.

Once the command has been successfully executed, the response will contain several useful fields.

The cloudProvider confirms we're using AWS. The status field showing "AVAILABLE" indicates the service is ready to use. Most importantly, the endpointServiceName is AWS's identifier for the Atlas service—we'll need this value for the next step. The interfaceEndpoints array is empty because we haven't connected any VPC endpoints yet.

Next, we need to create an interface endpoint in our AWS VPC to connect to Atlas.
The AWS ec2 create-vpc-endpoint command creates the connection point in our VPC.

For this we provide the vpc-id which identifies the VPC where the endpoint will be created. The VPC ID can be found in the AWS dashboard. The region must match the region we specified when creating the Atlas endpoint. For service-name, we use the endpointServiceName value from the previous step. We specify the vpc-endpoint-type as Interface, and provide the subnet-ids where the endpoint should be available.

After running the command, we receive a detailed JSON object with information about the new VPC endpoint. The most important part is the VpcEndpointId, which looks something like vpce-x. We'll need this ID for the next step.

With our AWS endpoint created, we now tell Atlas about it.

The atlas privateEndpoints aws interfaces create command associates our AWS VPC endpoint with the Atlas endpoint service. We provide the endpointServiceId from our first step, the privateEndpointId that AWS generated when we created the VPC endpoint, and our projectId again.

After running the command, we receive some information about our connection.

For instance, the connectionStatus initially shows "PENDING_ACCEPTANCE" because AWS and Atlas are establishing the connection.

It will take a moment for Atlas and AWS to get everything set up.

Once the connection is established, we can use the interfaces describe command to check the status of our interface.

For this, we provide the interfaceEndpointId , which is the same asthe AWS VPC endpoint ID, the endpointServiceId, and our projectId.

After running the command, the response shows the interface is now available.

The connectionStatus value of "AVAILABLE" confirms our private endpoint is fully set up and ready to use.

We can further confirm that our private endpoint is available by visiting the Atlas cluster dashboard.

Our private endpoint is up and running but you will need to configure a security group within your AWS VPC to allow inbound traffic to your Atlas Cluster. To learn more about configuring security groups visit the AWS documentation.

Once that is complete, applications in your VPC can connect to your Atlas cluster through this private endpoint, with all traffic staying within AWS's private network infrastructure.

Great work! Let’s take a moment to review what we learned in this lesson.

First, we learned how private endpoints provide resource-specific access to your Atlas clusters, creating a direct, private connection that keeps your data off the public internet. Unlike network peering, which connects entire networks, private endpoints give you precise control over which resources can be accessed.

After that, we set up our own private endpoint using AWS.

Finally, we confirmed that our private endpoint was operational on both Atlas and AWS.