> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Single-Region Deployment Paradigm Single-region Atlas deployments set up cluster nodes within a single region of one cloud provider. All cluster tiers support single-region Atlas deployments. They provide the least expensive option for applications and are a good choice when cost is a factor. With nodes distributed across availability zones and the default `majority` [write concern](https://www.mongodb.com/docs/manual/reference/write-concern/), single-region deployments provide automatic failover protection against node and zone failures with zero data loss. However, a regional failure requires recovery from backups, which involves downtime and potential data loss that depends on your backup frequency. **Note:** Zero data loss during failover requires `majority` write concern. If you configure a lower write concern, automatic failover may result in data loss. All Atlas providers have regions that support availability zones within a region, which adds protection in the case of a single zone outage. The cloud provider automatically reroutes traffic to a node in another availability zone within the region to ensure availability. This is similar to multi-regional deployments but on a smaller scale. The following diagram shows a single-region Atlas deployment for a region that has 3 availability zones: ![An image showing a three-zone deployment in a single region.](/_includes/images/single-region.png) To learn how to configure a single-region deployment, see [Create a Cluster](https://www.mongodb.com/docs/atlas/tutorial/create-new-cluster/) in the Atlas documentation. ## Use Cases for Single-Region Deployments A single-region deployment may be best for you if you have the following requirements: - You want to use one cloud provider. - You don't need to deploy to more than one region. - Your application requires low latency *and* has a majority of users in one geographic location. For example, for an application deployed with AWS (Amazon Web Services) with users primarily located in the western US, you can deploy a single-region deployment to `us-west-2` (a region that supports availability zones). This ensures low latency since all nodes are within the western US, while offering availability if there's a zonal outage that affects the primary node. If your application requires low latency and cross-region or cross-provider high availability, consider a [Multi-Region Deployment Paradigm](https://www.mongodb.com/docs/atlas/architecture/current/deployment-paradigms/multi-region.md#std-label-arch-center-paradigms-multi-region) or [Multi-Cloud Deployment Paradigm](https://www.mongodb.com/docs/atlas/architecture/current/deployment-paradigms/multi-cloud.md#std-label-arch-center-paradigms-multi-cloud), respectively. ## Considerations for Single-Region Deployments Single-region deployments ensure a minimum level of availability. High availability depends on the deployment of nodes across regions as well as the number, distribution, and priority order of nodes. To learn more about recommended cluster topologies for high availability, see [Guidance for Atlas High Availability.](https://www.mongodb.com/docs/atlas/architecture/current/high-availability.md#std-label-arch-center-high-availability) For more considerations, see [Considerations](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution/#considerations) in the Atlas documentation. ## Recommendations for Single-Region Deployments If your application is deployed on one of the following cloud providers, MongoDB strongly recommends that you deploy your Atlas resources to that same provider and region. Doing so reduces latency for database operations executed by your application, and allows for enhanced security with private endpoints that connect your self-managed cloud resources with your Atlas resources. Moreover, this approach reduces latency and egress costs associated with cross-cloud data transfer while also reducing costs by reducing overall node counts and eliminating the need for multi-region networking components. To automate single-region deployment using Terraform, see the [MongoDB Atlas Cluster Terraform Module.](https://registry.terraform.io/modules/terraform-mongodbatlas-modules/cluster/mongodbatlas/latest) **Note:** Single-region deployments provide automatic failover protection against node and zone failures with zero data loss (RPO=0). However, a complete regional outage will require recovery from backups, which involves downtime and potential data loss (RPO>0) depending on backup frequency. For applications requiring automatic failover protection against regional failures, consider multi-region or multi-cloud deployments. ### Tab ![AWS Single-Region Deployment Diagram](/_includes/images/aws-single-region.png) To find recommendations for your Atlas cloud deployments, refer to the following resources: - [Recommendations for Atlas Orgs, Projects, and Clusters](https://www.mongodb.com/docs/atlas/architecture/current/hierarchy.md#std-label-arch-center-orgs-projects-clusters-recs) - Operational Efficiency - [Recommendations for Atlas Monitoring and Alerts](https://www.mongodb.com/docs/atlas/architecture/current/monitoring-alerts.md#std-label-arch-center-monitoring-alerts-recs) - Security - [Recommendations for Atlas Network Security](https://www.mongodb.com/docs/atlas/architecture/current/network-security.md#std-label-arch-center-network-security-recs) - [Guidance for Atlas Authentication](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-authentication-recs) - [Guidance for Atlas Authorization](https://www.mongodb.com/docs/atlas/architecture/current/auth/authorization.md#std-label-arch-center-authorization-recs) - [Recommendations for Atlas Data Encryption](https://www.mongodb.com/docs/atlas/architecture/current/data-encryption.md#std-label-arch-center-data-encryption-recs) - [Recommendations for Atlas Auditing](https://www.mongodb.com/docs/atlas/architecture/current/auditing.md#std-label-arch-center-auditing-recs) - [Recommendations for Atlas Logging](https://www.mongodb.com/docs/atlas/architecture/current/logging.md#std-label-arch-center-logging-recs) - Reliability - [Recommendations for Atlas High Availability](https://www.mongodb.com/docs/atlas/architecture/current/high-availability.md#std-label-arch-center-ha-recs) - [All Deployment Paradigm Recommendations](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-dr-recs) - Performance - [Recommendations for Atlas Scalability](https://www.mongodb.com/docs/atlas/architecture/current/scalability.md#std-label-arch-center-scalability-recs) - [Guidance for Atlas Latency Reduction](https://www.mongodb.com/docs/atlas/architecture/current/latency-strategies.md#std-label-arch-center-latency-strategies) - Cost Optimization - [Recommendations for Atlas Cost-Saving Configurations](https://www.mongodb.com/docs/atlas/architecture/current/cost-saving-config.md#std-label-arch-center-cost-saving-config)