This is extremely crucial for us too. We are racking up $1400 per month for cross-AZ transfer on both MongoDB Atlas as well as our EC2 instances. We'll be moving to Postgres on Amazon RDS soon since it'll help us to deploy it within the same AZ.

We too are also keen to see this functionality. Our application is hosted in the same AWS region as the MongoDB databases, but because they are in different AZs, we are getting increased data transfer costs. It would be helpful to either a) be able to set which AZs mongodb should spin up the clusters in, or b) be able to see which AZs mongodb has been spun up in so we can move our EC2 instances into the same AZ. This would help us cut $100s per month off our data transfer costs.

@Andrew Being able to choose the AZ can help avoid Data Transfer costs. For example in AWS, if you connect to Mongo Atlas over a peered VPC connection, and cross AZ traffic over a peered VPC connection is charged. Allowing users to control the AZ (just like other resources deployed in AWS) gives the user this choice. Somtimes (the cost savings are worth more than the redundancy in many situations). Please seriously consider adding this feature. See this link: https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-vpc-announces-pricing-change-for-vpc-peering/

Looking for the same feature. This will be also quite beneficial in order to significantly reduce the cross-zone traffic costs, since inner-zone traffic is typically free, like in GCP. Having the ability to define the allowed zones per region would be a plus, with a minimum of 2 or 3, depending on the specific region. And then define a preferred zone for the primary node whenever possible.

Hi Matthew, It would be helpful to understand what it is about your application that would benefit from. this. Noting that cross-AZ network hops are generally sub-2ms, single-AZ network affinity is usually reserved for the kinds of applications with more niche latency requirements (where latency trumps availability) like ad serving and high frequency trading. It would help to understand how you would take advantage of this, what it would mean for your applications, etc. Would you have other application tier instances running in the other AZ in the event of failure of the "preferred" AZ? Maintenance is another consideration--one key benefit of not thinking at the AZ level is you avoid pets and force yourself to be resilient for failures and maintenance. Thanks -Andrew