Atlas Data Processing
MongoDB Atlas offers customers the option to localize data processing by certain Atlas features to a particular region. The following sections provide additional details.
When creating a MongoDB Atlas cluster in an Atlas project, a customer must select a cloud provider and regions to deploy that cluster. The underlying cloud provider and region selected by a customer are referred to as Cluster Regions. The data that a customer stores in their Atlas clusters will be stored at rest in the specified region(s). This data includes any data records stored in the database as JSON documents and any data stored in database or audit logs. The data stored in clusters may also include Atlas database names, collection names, shard keys, index names, index definitions, Atlas database user names, and Atlas database roles.
MongoDB Atlas offers numerous features that provide increased observability into your database and proactive optimization suggestions, such as Performance Advisor, Query Profiler and Schema Advisor, and the Real Time Performance Panel. These features make use of database logs, which may contain snippets of data that customers store in MongoDB Atlas. Additionally, MongoDB Atlas offers Data Explorer, which allows a customer to query their data in Atlas clusters.
By default, each of these features run within the MongoDB Atlas control plane in the United States. Upon request and for a limited set of geographies, these features can also be configured to run in a specific region. The cloud provider regions where these services run are referred to as Project Services Regions.
Q: How are Project Services Regions Enabled?
The default Project Services Region is the MongoDB Atlas control plane in the United States.
Q: Can Atlas customers select the Project Services Regions?
No. Unlike cluster regions, the Project Services Regions are automatically selected by MongoDB Atlas. The automatic selection depends upon whether a customer has requested to enable non-US Project Services Regions.
Q: Which Atlas features support non-US Project Services Regions?
The following Atlas features support non-US Project Services Regions:
When the option is enabled, Atlas will limit processing of document field values and database logs that are processed through Performance Advisor, Query Profiler, Schema Advisor, Data Explorer, and Real Time Performance Panel so that those field values and database logs are processed in a specific Project Services Region.
Q: How does Atlas select the Project Services Region?
When a non-US Project Services Region is enabled, Atlas will set the data processing region for the Atlas project-- with respect to the features and data described above-- based on the first Dedicated Tier cluster created in the Atlas project, as follows:
If the first Dedicated Tier cluster is a single-region replica set or sharded cluster, Atlas will set the Project Services Region based on that single region;
If the first Dedicated Tier cluster is a multi-region replica set or sharded cluster, Atlas will set the Project Services Region based on the region that you designate as that cluster's highest priority region;
If the first Dedicated Tier cluster is a Global Writes sharded cluster, Atlas will set the Project Services Region based on the region that you designated as the first Zone's highest priority region.
All clusters within the same Atlas project will inherit the same data processing region as the first Dedicated Tier cluster. If all Dedicated Tier clusters are deleted in the Atlas project, Atlas will reset the Project Service Region of that Atlas project.
Q: What are the currently available Project Services Regions?
Using the above criteria, Atlas will map the first Dedicated Tier cluster's region or priority region to a specific Project Services Region as follows:
First cluster's region | Project Services Region |
|---|---|
AWS / Azure / GCP regions in France | AWS Paris ( |
AWS / Azure / GCP regions in the UK | AWS London ( |
AWS / Azure / GCP regions in the EU (except France) & Middle East & South Africa | AWS Ireland ( |
Q: Which Atlas services and data cannot be configured to use a non-US Project Services Region?
MongoDB does not regionalize processing for all Atlas services or all data processed by MongoDB Atlas. MongoDB will continue to transfer data to meet cloud service operational requirements and customer support needs for any Atlas services, features, and data types not included in the above list, as well as in response to any customer initiated data transfers.
Examples of services and features for which Atlas does not regionalize data processing include:
Queries for Atlas Data Lake, Online Archive, and Atlas Data Federation
Database log & audit log downloads if downloaded via the Atlas Administration API
If the Push Logs to AWS S3 bucket feature is configured, logs are pushed directly from Atlas clusters to the customer's S3 bucket without traversing the Atlas control plane
Data Explorer and Performance Advisor for Atlas Shared tiers and Serverless instances
Shared tier upgrades
Examples of data that are not covered by a non-US Project Services Region, i.e., that cannot be regionalized, include:
Atlas database names, collection names, shard keys, and indexes
Atlas login data used to log into the Atlas console
Atlas database access and network access metadata
Atlas support portal data used in customer support cases
Metadata from Atlas clusters (e.g., monitoring data)
Atlas application logs
MongoDB ensures that any data transfers are protected by appropriate security and legal safeguards detailed in our services agreements.
Q: What kinds of data may be in database logs?
The following gives an example of a JSON document and the data stored in the logs. The keys can be thought of as schema data while the values are the actual data.
{ "key1_string": "value1", "key2_number": 1234, "key3_array": ["a", "b" ], "key4_dict": { subkey1: "subkeyvalue" } }
Database log data. The log data contains both schema and actual data / literals:
2023-03-09T13:35:23.446-04:00 I COMMAND [conn1] command internal.clients appName: "MongoDB Shell" command: insert { insert: "clients", documents: [ { _id: ObjectId('593adc5b99001b7d119d0c97'), "key1_string": "value1", "key2_number": 1234, "key3_array": ["a", "b" ], "key4_dict": { subkey1: "subkeyvalue" } } ], ordered: true } ...