Editor’s note: This is the final post in our four-part series exploring how MongoDB Atlas Resource Policies help you strengthen database security and enforce consistent guardrails across your organization. Read the first post on IP access list management, the second on defense in depth strategies, and the third on blocking the wildcard IP address.
Maintaining control in a multi-cloud world
As organizations scale their database infrastructure, maintaining consistent security and compliance policies becomes increasingly complex. Development teams need agility, but security teams need control. One misconfigured cluster deployed in the wrong region or on an unapproved cloud hyperscaler can lead to:
Compliance violations with data residency requirements.
Security gaps from shadow IT deployments.
Cost overruns from unplanned multi-cloud sprawl.
Audit failures when infrastructure does not match documented policies.
Introducing MongoDB Atlas Resource Policies
MongoDB Atlas Resource Policies are organization-level controls that enable you to define and enforce infrastructure governance rules using policy as code. These policies act as intelligent guardrails, automatically constraining configuration options available to developers while maintaining the flexibility teams need to build and deploy.
Today, we’re diving deep into two of the most powerful policies for multi-cloud governance: Restrict Cloud Hyperscaler and Restrict Cloud Hyperscaler Region.
Policy #1: Restrict Cloud Hyperscaler
What it does
The Restrict Cloud Hyperscaler policy gives you fine-grained control over which cloud platforms—AWS, Google Cloud, or Azure—can be used for MongoDB Atlas cluster deployments within your organization.
Why it matters
Compliance and data sovereignty: Many industries have strict requirements about where data can be processed. If your compliance framework mandates AWS-only infrastructure, this policy ensures no clusters are accidentally deployed on Google Cloud Platform or Azure.
Cost optimization: Committed to an AWS Enterprise Discount Program? This policy prevents cost leakage to other hyperscalers and helps you maximize your cloud spend commitments.
Operational consistency: Standardizing on one or two cloud hyperscalers simplifies your operational model, reduces training overhead, and streamlines your disaster recovery procedures.
Security posture: Each cloud hyperscaler has unique security features and configurations. By restricting to approved hyperscalers, you ensure your security teams have deep expertise in the platforms you actually use.
Real-world examples
MongoDB Atlas Resource Policies are defined using the open-source Cedar policy language. Here are some examples of resource policies creating guardrails around which cloud providers can be used for MongoDB Atlas cluster deployments.
Example 1: Block a specific hyperscaler
Prevent any clusters from being deployed on Google Cloud:
Example 2: Allow only one hyperscaler
Your organization has standardized on Google Cloud. Ensure all clusters must be deployed there:
Example 3: Enforce Project-specific restrictions
Lock down a sensitive MongoDB Atlas Project so that only AWS can be used for cluster deployment:
Policy #2: Restrict Cloud Hyperscaler Region
What it does
The Restrict Cloud Hyperscaler Region policy enables you to control the specific geographic regions where MongoDB Atlas clusters can be deployed, down to the individual region level (e.g., aws:us-east-1, azure:westeurope).
Why it matters
Data residency compliance: GDPR, California Consumer Privacy Act (CCPA), and other regulations often mandate that data must remain within specific geographic boundaries. This policy streamlines compliance, making it automatic rather than manual.
Latency optimization: Restrict deployments to regions closest to your users for optimal performance. No more clusters accidentally deployed on the wrong continent.
Cost management: Some cloud regions are significantly more expensive than others. Control costs by preventing deployments to high-cost regions.
Disaster recovery planning: Define approved regions for production workloads and separate regions for disaster recovery, ensuring proper geographic distribution for business continuity.
Security compliance: Certain regions may not meet your security certification requirements. This policy ensures only approved, audited regions are used.
Real-world examples
Example 1: Block a specific region
Your compliance team has determined that aws:us-east-1 has unacceptable data residency risks for your use case, so clusters must not be deployed there:
Example 2: Block multiple regions
Prevent deployments across three regions that don’t meet your requirements:
Example 3: Allow approved regions
Take a zero-trust approach—only permit deployments in preapproved regions:
Exploring a real-world use case: Financial services compliance
A global financial services company needed to ensure all customer data remained within GDPR-compliant regions while maintaining its commitment to AWS as its primary cloud hyperscaler. Its challenge required addressing multiple dimensions simultaneously: preventing deployments to unapproved hyperscalers, restricting geographic regions for data residency, and blocking insecure network configurations.
It implemented a layered approach that combined hyperscaler and region policies with network security controls:
This single policy restricts all Google Cloud Platform deployments while also blocking specific AWS regions that didn’t meet its data residency requirements. The company complemented this with an IP access list policy preventing wildcard access to address network security.
The result? Zero compliance violations were reported in their subsequent audit. Consequently, developers maintained full self-service capabilities within established guardrails, and security teams gained confidence in infrastructure governance. The policies transformed compliance from a documentation exercise into an automated enforcement mechanism, rendering violations technically impossible.
Understanding the key benefits of using resource policies
1. Automated compliance
Stop relying on documentation, training, and manual reviews. Resource policies are enforced automatically at the Organization level.
2. Proactive, not reactive
Resource policies prevent noncompliant configurations before they are created, rather than detecting problems after deployment.
3. Developer velocity
Teams can self-service their infrastructure needs within approved guardrails without waiting for security reviews.
4. Audit trail
MongoDB Atlas generates activity feed events when policies are created, updated, or deleted, providing complete auditability.
5. Noncompliant resource visibility
Use the API endpoint /orgs/{ORG-ID}/nonCompliantResources to identify any existing resources that do not meet your policy requirements.
6. No service disruption
Existing noncompliant clusters continue running. Policies only restrict modifications or the creation of new resources that would keep them out of compliance.
Take the next step
Infrastructure governance doesn’t have to mean slowing down development. With MongoDB Atlas Resource Policies, you can enforce security and compliance requirements automatically while empowering your teams to move fast.
You can implement resource policies through the MongoDB Atlas UI with its visual policy editor, the Atlas Administration API for programmatic policy management, Terraform for infrastructure-as-code integration, or AWS CloudFormation for native AWS deployment. The policies are defined using Cedar, an open-source policy language designed for clarity and expressiveness. If you can read JSON, you can read Cedar policies.
Try resource policies today
Log into MongoDB Atlas with Organization Owner privileges.
Navigate to Organization Settings > Resource Policies.
Create your first policy using one of the examples above.
Monitor noncompliant resources and plan remediation.
Iterate and refine based on your organization’s needs.
Resource policies are included with all MongoDB Atlas deployments at no additional cost. There’s no reason not to start protecting your infrastructure today.
Additional Resources
Next Steps
Ready to implement infrastructure governance that doesn’t slow you down? Start your free MongoDB Atlas trial and configure your first resource policy in minutes.