MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Add new feedback Subscribe
Status Planned
Categories Atlas Monitoring, Alerts & Observability
Created by Guest
Created on Jun 16, 2021

RELATED FEEDBACK

Display replica set members' Availability Zone details

The AZ details (ideally including the AZ ID) for each replica set member would be helpful to display in the Atlas UI, mainly to easily verify nodes are distributed across AZs.
  • ADMIN RESPONSE
    Oct 18, 2025
    Thank you all for your feedback! We hear you loud and clear and are working on exposing these details in the next quarter.
  • Guest
    Sep 9, 2024
    Also want to know when this will be available.
    Reply
  • Guest
    Aug 16, 2024
    When will this feature be available?
    Reply
  • Guest
    Dec 13, 2023
    I think this is implied in the other comments but just to be sure, the az should be static for a given machine. Anotherwords, if I have 3 machines in my setup, machine 1 should always be in AZ with id 123XYZ and machine 2 should always be in 567ABC, etc. That way I can properly network and configure without having to create advanced rerouting mechanisms to prevent unwelcome data transfer fees from AWS in the event an AZ changes (changed != down).
    Reply
  • Guest
    Oct 25, 2023
    This is critically needed. I'm paying over $10k per month just in inter-AZ data transfer charges. So I'm always moving instances around to cluster app servers with database nodes in the same AZ. Having this tag would make it much easier to automate this.
    Reply
  • Guest
    Jan 30, 2023
    Yes. This is one feature badly looking forward to. @Atlas. Lock the primary in one specific AZ and provide us the AZ-ID, which will help us have a better architecture save on DT charges
    Reply
  • Guest
    Jan 12, 2023
    This feature would be great because we have design patterns where one instance imports lots of data into Atlas and our VPC is peered with the Atlas VPC. So by knowing the actual zoneId of the primary it would be possible to spawn an instance in the same az. By doing this, it would be possible to save a lot of money because there are no data transfer costs between vpc peerings communicating in the same az: https://aws.amazon.com/de/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/ Also it would be possible perhaps to configure instances to read against the atlas nodes in the same az first.
    Reply