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 complimentary security measures alongside IP access lists. In this video, we'll learn what network peering is and how beneficial it can be 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 a potential security issue. Routing database traffic through the public Internet creates significant security risks. Data interception, man in the middle attacks, and DDoS (Distributed Denial-of-Service) 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 MongoDB Atlas cluster's VPC. This connection bypasses the public Internet entirely. A virtual private cloud (VPC), creates an isolated network within your 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 and 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 to your VPC and 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 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 an organization with complex network architectures or those that 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, simplify compliance. Many regulations require strict controls over data paths. Private connections make it easier to demonstrate that sensitive data never traverses over public networks, satisfying auditors and security requirements. Finally, potential cost benefits. Network peering typically reduces data transfer costs compared to routing over the public Internet. Setting up network peering in Atlas is pretty straightforward, though it does require some preparation. Before you begin, you'll need an existing VPC in your cloud provider of choice. Setting up a VPC is 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 wanna peer with, the VPC CIDR block, and the AWS region where the VPC is located. For Azure, you'll need the Azure subscription ID, resource group name, virtual network name, and the directory or tenant ID. For GCP, you'll need the 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 network peering 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 out the documentation for more 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.0.0/24, 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 VPC CIDR block or subnet information, which is available in the AWS console. Finally, enter the VPC ID to complete 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 peered networks. When complete, your applications can connect to Atlas using the private IP addresses, keeping all traffic within the cloud provider's network infrastructure rather than traveling across the public Internet. Excellent work. Let's take a moment to recap what we learned. We explored how network peering provides a more secure and efficient way to connect to a MongoDB Atlas cluster. We learned that network peering creates a direct private connection between your virtual private cloud or 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.