Our clusters keeps sending loads of alerts during maintenance times about host is down and similar - it's logical and I understand that those are rolling updates so the functionality of the cluster is not affected. However it's quite unfortunate that host are down for quite a while (20 - 30 mins sometimes) and as we don't want to create unnecessary noise from atlas monitoring we had to bump up our slack and pager duty notification to be fired 30+ minutes. This covers maintenance but out of maintenance this is ridiculously high and we would like to know there is possible issue way sooner than that.

As it's the atlas which is performing all the maintenance work it seems better solution would be to let atlas disable such alerts when entering the maintenance and enable them automatically again when maintenance is finished.

In Performance Advisor, I can see sample queries for each index suggestion.
They are formatted "nicely" for human viewing, but to actually investigate it, one would want to copy it as valid mongodb json, and run it with explain or analyze it in compass, or even just run it in a console to see how long it runs before and after the index addition.
However, there is no way of doing that, and I have multiple times "translated" the good looking ui to a mongo query so I could run it elsewhere.
This is a tedious and annoying thing (especially when you need to handle dates....).
Since you already have the data but chose to display/format it in a "nice" way, you also have the json behind it so please just let me copy it as json (with the proper ObjectId and ISODate or new Date() around ids and dates.

Thank you.

It is often practical to Live Migrate from one Atlas cluster to another Atlas cluster (e.g. to create another staging environment if backups are not enabled on the source, or migrate a production/staging environment to another dedicated project with minimal downtime).

Currently, the Live Migrate modal requires connection details from the source cluster, including the hostname of the primary, port, etc. Validation will fail if there are typos/errors in these inputs.

It would be easier to have a point-and-click option to "Migrate from another Atlas cluster" -- it could be a drop-down menu with names of other Atlas clusters in the project/organization that could be selected. The required connection parameters could then be automatically populated based on the particular cluster. A temporary user with the required permissions could even be created and then removed after the migration is complete.

This could make it easier to start Live Migrations between Atlas clusters, and avoid the need for the user to locate and confirm specific source connection requirements.

Currently, Atlas has a 15 minute interval where it checks access to remotely stored Customer Managed Encryption keys for the custom encryption at rest feature.

This value is not changeable, and it implies a problem: access to encryption keys can be lost for longer periods than 15 minutes without that implying that the key has been invalidated by the customer.

A perfect example of this was the recent Azure AD global outage that prevented all authentication to the Azure platform for about 3 hours (complete outage description: https://app.azure.com/h/SM79-F88/691d78). While the key used for one of our clusters was not invalidated nor the credentials rotated, the whole cluster went down just because the auth mechanism was failing. This impacted our customers and would have easily been mitigated if the time interval for key access checking would have been longer.

Currently Atlas only uses a single (flat) user group which only allows for 1 type of authentication per Organization.

However if Federated Authentication is enabled, the authentication mechanism in Atlas is bypassed for the IdP based on the domain name of the user and the configuration of Atlas Authentication.

This causes a problem if there are multiple groups of users who all share a domain name, some of whom are registered in an IdP, and some of whom are not registered in an IdP (for example users in 2 divisions of the same company).

In this scenario, users who are not registered in the IdP are not able to log in.

Proposed Solution:
Implement User Groups in Atlas with separate configuration settings, so that if 1 group enables Federated Authentication, they will not impact any other groups, even if they all share the same domain name in the user accounts.

There are use-cases where certain users or client IPs need to be given access restricted to only the Analytics node(s) . While it is possible to grant such users read-only permissions at the database/collection level, and have them use the ANALYTICS replica set tag in their connection string URI, it might still be possible for those users to connect to a Primary or a Secondary node (when not using the Analytics replica set tag) and run their query there.

Therefore, a feature that will either restrict specific users access to only the Analytics node(s) or a functionality that will restrict access from certain client IPs to only the Analytics node(s), will help in such use-cases.