Landing Zone Design
A landing zone is a framework for establishing a well-architected and pre-configured cloud environment. A MongoDB Atlas landing zone defines organization-specific requirements for operational efficiency, security, reliability, performance, and cost, as well as the tools, procedures, and Atlas configurations that teams must use to meet these requirements. We recommend that all enterprise customers design a landing zone before moving workloads to Atlas.
Designing and implementing a landing zone can help you avoid expensive efforts to redesign initial setups later down the line. For example, one enterprise customer worked with MongoDB's Professional Services in 2024 to set company-wide standards for security and cost-efficiency before moving their workload to Atlas. Peer financial services companies had published new reports of user data leaks and runaway cloud costs due to inconsistent encryption policies and redundant servers across business units. To avoid these risks, MongoDB's Professional Services helped our enterprise customer design a landing zone that aligns all of their teams and stakeholders on company requirements, including encryption at rest with BYOK and FinOps integrations to tag and track spending.
What Are Some Landing Zone Considerations?
As you create your landing zone, define requirements for the following considerations:
Consideration | Description |
|---|---|
System Hierarchy | Choose a deployment hierarchy that groups your Atlas organizations, projects, and clusters in order to isolate between business units, environments, and billable groups as needed. For example, you can group business units into individual organizations to ensure that sales credentials cannot authenticate to product resources. To get recommendations and learn more about this topic, see Guidance for Atlas Orgs, Projects, and Clusters. |
Security | By default, Atlas blocks all access to your clusters, enforces TLS/SSL encryption for all connections to your databases, and encrypts data at rest using cloud provider disk encryption. You must define the following security requirements to enable secure access to your clusters:
To get recommendations and learn more about this topic, see the following pages: |
Compliance | Consider how your deployment's data residency determines data sovereignty and therefore which laws apply to your data. Identify and account for any specific legal and regulatory requirements not clearly articulated within other categories of requirements. Your data residency depends on which regions and geographies you choose to deploy to in your deployment paradigm, and whether you choose to partition your data between geographies. To get recommendations and learn more about this topic, see the following pages: |
Disaster Recovery | Define and record a disaster recovery plan that meets the following criteria:
To get recommendations and learn more about this topic, see the following pages: |
High Availability | Set standards for high availability that ensure system operation during planned or unplanned outages. These requirements will partially determine the number of nodes, regions, and cloud providers in your deployment paradigm. To get recommendations and learn more about this topic, see the following pages: |
Billing | Identify any specific requirements for billing, such as integrations with FinOps tools for reporting and charge-back. You can build these requirements into the automation and provisioning process for Atlas clusters to facilitate this integration. To get recommendations and learn more about this topic, see Features for Atlas Billing Data. |
Data Retention | Identify and record your data retention policies. This may require creating a classification for automation, including creation of archive or purge automation. In some cases, data must be preserved for a certain duration, whereas in other cases data must be purged after some duration. Identify performance characteristics of retrieval of archived records. |
Monitoring and Observability | Set standards for observability that define which logs and metrics you will monitor and how you will monitor them. For example, set up external system integrations that ingest Atlas log files, audit logs, or activity feed data, or configure alerts and reporting guidelines for certain event types. To get recommendations and learn more about this topic, see the following pages: |
Auditing and Change Control | Define any auditing or change control requirements. This can include change approval processes and tools, along with reporting guidelines. To get recommendations and learn more about this topic, see Guidance for Atlas Auditing and Logging. |
Maintenance | Identify whether you have any specific requirements regarding Maintenance windows or upgrade deferments. |
Design Your Landing Zone
MongoDB's Professional Services team partners with enterprise customers to create custom landing zones for Atlas. If you're working with MongoDB's Professional Services, the resources on this page can also help you plan for those discussions.
Use the following resources as a starting point for your Atlas landing zone. Designing a landing zone is an iterative process that involves reviewing and realigning standards across teams. We recommend that you compile all diagrams, recommendations, and examples in a document and adjust them to meet your organization's requirements.
Example Landing Zone Diagram
The following example diagram unifies many of the architectural diagrams across the Atlas Architecture Center in one image to visualize your landing zone. You can adjust it as needed to customize it for your organization.
Information In The Atlas Architecture Center
To begin, copy the relevant guidance and examples in Guidance for Atlas Orgs, Projects, and Clusters, which helps you create your first foundational components in Atlas.
Then, review the guidance and examples for each of the pages nested under each Well-Architected Framework pillar in the Atlas Architecture Center. Copy the diagrams, recommendations, tools, and examples that are relevant for your organization.
The Atlas Architecture Center pages include:
Operational Efficiency
Security
Reliability
Performance
Cost Optimization
Your Organization's Requirements
Adjust the example landing zone diagram, recommendations, and examples that you copied from the Atlas Architecture Center to fit your organization's specific requirements. For example, if you use only Google Cloud as a cloud provider, your landing zone should specify that requirement and you should exclude any recommendations and examples applicable only to AWS and Azure.
To identify more considerations and requirements specific to your organization, see the previous section on Landing Zone Considerations.
Next Steps
See the Migration page to plan your migration to Atlas or use the left navigation to find features and best practices for each Well-Architected Framework pillar.