Atlas network peering lets you create a private connection between your application network and the Atlas network for a dedicated cluster. This connection routes traffic over private IP addresses instead of the public Internet, which helps isolate application-to-database traffic. Atlas supports peering for dedicated clusters on AWS, Azure, and Google Cloud, and for sharded clusters that span multiple cloud providers. Compared to private endpoints, peering allows private network connectivity between Atlas and your cloud network, while private endpoints provide more narrowly scoped private access with less expansion of the network trust boundary.
正確な設定要件と制限はクラウドプロバイダーによって異なりますので、接続を構成する前にプロバイダー固有のガイダンスを検討する必要があります。
A key component of configuring network peering is defining the CIDR range in advance. Your Atlas CIDR must not overlap with any VPCs you plan to peer, and the CIDR size affects how many nodes and replica sets Atlas can support in that project or region. In Atlas, a network container is created automatically when you create a peering connection. In some cases, you might want to create or manage the container separately from the connection. To do this, follow the guide for managing network containers.
注意
The MongoDB Atlas Shared Responsibility Model defines the complementary duties of MongoDB and its customers in maintaining a secure and resilient data environment. Under this framework, MongoDB manages the security and operational integrity of the underlying platform, while customers are responsible for the configuration, management, and data policies of their specific deployments. For a detailed breakdown of ownership across security and operational excellence, see Shared Responsibility Model.
制限
Atlas does not support network peering between clusters deployed in a single region on different cloud providers. For example, you cannot set up network peering between an Atlas cluster hosted in a single region on AWS and an application hosted in a single region on Google Cloud.
無料クラスター (以前は
M0と呼ばれていました)と Flex クラスターは VPC ピアリングをサポートしていません。プライベートネットワークを使用するには、専有クラスターを使用する必要があります。
Atlas ピアリングのおすすめのベストプラクティス
Plan CIDR ranges early, ideally before deploying the first dedicated {+cluster} in a region. Your Atlas CIDR must not overlap with any VPCs you plan to peer, and the CIDR size affects how many nodes and replica sets Atlas can support in that project or region.
ピアリング ネットワークには RFC 1918 プライベート アドレスのみを使用します。
Atlas プロジェクトには、合計で最大 50 個のピアリング接続を設定できます。このうち、最大 25 個が保留できます。
Atlas へのプライベートネットワークパスが必要な場合は VPC または VNet ピアリングを使用しますが、ピアリングはプライベートエンドポイントよりもネットワークの信頼境界を拡張することに留意してください。信頼境界の拡張を最小限に抑えることが最優先の場合は、プライベートエンドポイントが一般的に適しています。
ピアリングを最小権限のネットワーク設計演習として扱います。セキュリティ グループとネットワーク ACL をロックダウンし、Atlas がアプリケーション ネットワークへ不要な受信アクセスを取得しないようにします。また、中間 VPC を使用して、Atlas アクセスが必要なコンポーネントのみを公開することを検討します。
Be explicit about connection string choice. In AWS, the standard connection string usually works over peering, and the
-pristring is optional unless you use custom DNS. In Azure and Google Cloud, use the Private IP for Peering connection string.For multi-region deployments, plan peering per cloud behavior: AWS and Azure require peering for each Atlas region involved, while Google Cloud uses global VPCs and needs only one peering connection.