Video Transcript (English)

By now, you should know how to control access to your MongoDB clusters using IP access lists. These access lists are an important security layer that must always be implemented, regardless of whether you're connecting via public or private IP addresses. IP access lists serve as your first line of defense against unauthorized access. To strengthen your security posture further, you should implement additional complementary security measures alongside IP access lists.

In this video, we'll learn what network peering is and how it is beneficial when connecting our applications to Atlas. Let’s get started.

Let's review our current approach to MongoDB Atlas access. When you connect to your Atlas cluster, your traffic typically flows through the public internet. Your application or development machine, with its public IP address, must be added to the IP access list before it can establish a connection.

This setup works well for simple applications, but it creates potential security issue:
Routing database traffic through the public internet creates significant security risks: data interception, man-in-the-middle attacks, and DDoS threats that can compromise sensitive information or disrupt service availability.

These risks pose particular challenges for enterprises under HIPAA, PCI DSS, or GDPR compliance requirements, where security breaches can trigger regulatory penalties and reputational damage.

This is where network peering comes in. Network peering creates a direct, private connection between your Virtual Private Cloud (VPC) and your MongoDB Atlas cluster VPC. This connection bypasses the public internet entirely.

A Virtual Private Cloud (VPC) creates an isolated network within a cloud provider's infrastructure. This private section allows you to deploy and control your cloud resources—such as servers, databases, and storage—in a secure, contained environment that you define and manage.

Many organizations already run their applications on major cloud platforms like AWS, Azure, or Google Cloud. If your application infrastructure lives in one of these environments, Atlas can create a secure, private connection directly to that environment.

It's important to note that applications connecting to an Atlas cluster must run on the same cloud provider, and in many cases, they may need to be in the same region, as multi-region VPC peerings aren't universally supported across all providers.

Network peering works by connecting your Virtual Private Cloud VPC with the Atlas VPC in the same cloud provider's network. This creates a private highway for your data that only your resources can access. You'll still need to configure the IP access list. While adding entire CIDR blocks from your VPC simplifies management, it represents a security compromise. For stronger security, consider adding only the specific private IP addresses of resources that require database access, though this requires more maintenance.

The beauty of this approach is that it integrates with your existing cloud infrastructure. You can keep your access management centralized within your cloud environment and not worry about tracking individual IP addresses across multiple platforms. Your applications connect to Atlas using private IP addresses, and the traffic never leaves the cloud provider's network.

This is particularly valuable for organizations with complex network architectures or those who have already invested in cloud-based security controls.

Network peering offers four benefits beyond simplified access management.

First, enhanced security. By keeping database traffic off the public internet, you reduce your attack surface. Your data travels exclusively on private network infrastructure, protecting it from external threats.

Second, it can result in improved performance. Peering in most cases establishes direct connections between your networks within the Cloud provider infrastructure avoiding traffic over the public internet. This reduces latency and provides more consistent throughput for your database operations.

Third, simplified compliance. Many regulations require strict controls over data paths. Private connections make it easier to demonstrate that sensitive data never traverses public networks, satisfying auditors and security requirements.

Finally, potential cost benefits. Network peering typically reduces data transfer costs compared to routing through the public internet.

Setting up network peering in Atlas is straightforward, though it requires some preparation. Before you begin, you'll need an existing Virtual Private Cloud (VPC) in your cloud provider of choice.

Setting up a VPC beyond the scope of this video but we’ll cover the information you’ll need in order to set up network peering on the Atlas side.

The specific information you'll need varies by cloud provider:

For AWS, you'll need your AWS account ID, the VPC ID you want to peer with, VPC CIDR block, and the AWS region where your VPC is located.

For Azure, you'll need your Azure subscription ID, resource group name, virtual network name, and the Directory/Tenant ID.

For Google Cloud, you'll need your GCP project ID and the name of your VPC network.
Once we have all the necessary information from your VPC, we can begin setting up the network peering connection in Atlas.

We'll use the Atlas CLI with the command 'atlas networking peering create aws' to set this up. While we're using AWS here, you can substitute your own cloud provider, though the required information may vary - check the documentation for details.

First, you'll need your AWS account ID, which you can find in the AWS console.

Next, specify the Atlas CIDR block. This defaults to 192.168.248.0/21, but you can modify it through the Atlas API or user interface if needed.

Then, specify the cloud provider region where your VPC resides - the one you're peering with the Atlas VPC.

After that, provide the peer VPC CIDR block or subnet information, which is available in the AWS console.

Finally, enter the VPC ID to complete the peering setup.

After running the command, we should receive a confirmation message upon completion.
Keep in mind that after initiating the peering request from Atlas, you may need to accept the connection on your cloud provider's network console.

You'll also need to update your route tables by adding the Atlas CIDR block to the destination column and the AWS peering connection ID to the target column.

Additionally, configure your security groups or firewall rules to allow traffic between the peered networks.

When complete, your applications can connect to Atlas using private IP addresses, keeping all traffic within the cloud provider's network infrastructure rather than crossing the public internet.
Excellent work! Let's take a moment to recap what we've learned. We explored how network peering provides a more secure and efficient way to connect to MongoDB Atlas.

We learned that Network peering creates a direct, private connection between your Virtual Private Cloud (VPC) and your MongoDB Atlas cluster VPC that bypasses the public internet, offering enhanced security, improved performance, and simplified compliance.

By connecting your cloud infrastructure directly to Atlas, you can reduce management overhead while strengthening your security posture.