Currently there is only a community supported Prometheus integration (exporter) available which polls db.serverStatus() and doesn't include as much metrics as the Atlas UI/API provides. A similar integration as with New Relic and Datadog would help many customers that are using Prometheus and Grafana for monitoring.

We have a single project set up for our application, and multiple clusters under that project. Right now, it's impossible to create database users who only have access to certain clusters - the only configurable option is "database name".

The issue is that some of the clusters have the same "database name" but I don't want them to be able to access a database in a specific cluster, though I do want them to access a database with the same name in a different cluster.

Any plans to implement this?

We would like the ability to configure an auto scaling cluster via Terraform. Currently we need to modify our cluster after its creation via terraform to setup auto scaling parameters.

We would like to be able to use Terraform to configure LDAP authentication/authorization on projects.

The functionality is available via the API:
https://docs.atlas.mongodb.com/reference/api/ldaps-configuration/

However, go-client-mongodb-atlas does not have these endpoints implemented, so that would need to be done before this functionality is included in the provider.

When an Atlas User logs in by a Federated Authentication (like Okta) there is only a "Default User Role" to control its permission, so all users get the same role. And after that, we must manually add to teams, or change their roles. It would be better to allow the IdP to set (and update) the groups/teams for each user automatically.

Add third-party service integration for Microsoft Teams, as we do for Slack.
Most likely the following can be leveraged to achieve the integration: https://docs.microsoft.com/en-us/graph/teams-proactive-messaging

The ability to pause Atlas clusters through terraform would help with being able to pause our non-prod environments when not in use. Currently this has to be managed directly with the Atlas API

Add a terraform resource for third party integrations (such as PagerDuty) to allow it to be set up.

At present the finest granularity of ATLAS metrics is 1 minute ,as the metrics are averaged by 1 minute , this would not provide info on spikes lasting less than few seconds
reducing the granularity to 1 second would give more insight

Currently a project is created with a set of default alerts. We need to customize these but we can only add new alerts via terraform. It would be helpful if there was a boolean flag in the mongodbatlas_project resource to disable default alert creation

Please add support for the newly announced and already generally available AWS EBS feature. [1]

The top capability is: "The new gp3 volumes deliver a baseline performance of 3,000 IOPS and 125 MB/s at any volume size. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MB/s for an additional fee." [2]

That basically means decoupling storage performance from storage size.
It would eliminate all our IOPS pain as 3000k is more than enough for our usecase. Currently, we are slightly overprovisioning storage size in order to guarantee minimal IOPS performance.

[1] https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-new-amazon-ebs-general-purpose-volumes-gp3/
[2] https://aws.amazon.com/ebs/general-purpose/

Allow creating alerts via terraform

Ability to create/update triggers using terraform

Please consider adding 2FA support for hardware keys (Yubikey). Our company started enforcing this in our compliance policy for accessing production environments.

I can create a Project in Terraform, but I cannot add a Team to it afterwards.

I am an Organization Member, so I cannot see Projects that I do not have explicit access to. This means that for any Project I create via Terraform, I need to ask someone with more permissions to add my Team to the Project.

The need to do two applies to completely configure the mongodbatlas_cloud_provider_access resource should have never seen the light of day. I would like to see an additional resource that could attach a role to a mongodbatlas_cloud_provider_access after it has been created. Then you could use the attributes in the mongodbatlas_cloud_provider_access resource to create the role, then attach the role to it using the access_role_attachment resource.