can I use internal AWS network for mms managed replica?

I just setup a replica set with mms using the website to manage it, and I realize you have assigned an external IP and DNS for it.  Can I connect to that replica set from my app servers using the internal aws network?

Yes, you can connect through the internal network. The Automation Agent needs to be able to reach the outside world. Check the following for more information about the network permissions and requirements:

• https://docs.mms.mongodb.com/reference/required-permissions-aws-user/
• https://docs.mms.mongodb.com/tutorial/configure-aws-settings/#security-group (you don't need SSH access if you provision yourself instead of using MMS to provision)
• https://docs.mms.mongodb.com/tutorial/configure-aws-settings/#vpc

Let me know if there's anything else I can do to help you with this.

Yes, definitely you can have your application talk to the replica set via the internal aws/private network as long as the mms agent (along with the munin-node) can talk to the outside world/MMS cloud. One of the issues I see is that I don't like to have an EIP for the database, I just do not like the idea of exposing the DB to the outside world.

We have several VPCs' that has an external and internal Network and all of our mission critical DBs' are in the internal Network. The problem I have with MMS is I cannot simply spin off a shard cluster or replica sets simply because MMS requires/assigns an EIP.

Yes, definitely you can have your application talk to the replica set via the internal aws/private network as long as the mms agent (along with the munin-node) can talk to the outside world/MMS cloud. One of the issues I see is that I don't like to have an EIP for the database, I just do not like the idea of exposing the DB to the outside world.

Hi Satish,

MMS does not require EIPs, and you definitely do not want to expose your DB to the outside world as part of general best practice. There's even a default MMS alert that warns you if your deployment appears to be exposed on the internet: https://docs.mms.mongodb.com/faq/#my-alert-email-says-my-host-s-are-exposed-to-the-public-internet-what-does-that-mean.

The MMS agents only require outbound connections to post information to the MMS server: https://docs.mms.mongodb.com/core/security/#required-ports-and-ip-addresses.

The only case where an (optional) inbound connection may be used is if you want to use MMS to directly provision new environments via ssh. You do not need any inbound ssh access if you provision environments yourself and install an automation agent for deployment.

Thanks for the reply.
 I recently ran in to a hurdle with respect to the deployment of the shards across multiples subnets/zones  in the VPC (AWS). Our VPC is logically divided in to two subnets: private(internal) and public (external).
The public subnet servers our Webserver and few other servers in the stack, where as the private subnet is exclusive to the Database  since it’s our corporate security policy not to have the DB talk to the world. This is where we ran into a problem with the MMS automated deployments.
If I choose the option to launch instances across subnets/zones, only the nodes that get allocated in the public subnet is able to be configured. Rest of them that get put in to the private subnet will timeout as the MMS agent cannot talk out, I.e. Elastic IPs’ assigned to instances in private subnet will not have Internet access (as per our Network architecture).

So, to effectively use MMS in our cloud infrastructure, we need to be presented with the option of ‘selecting’ the subnets of choice and not make use of Elastic IP addresses. Unless of course, this has been already addressed.

Thanks for the reply.
 I recently ran in to a hurdle with respect to the deployment of the shards across multiples subnets/zones  in the VPC (AWS). Our VPC is logically divided in to two subnets: private(internal) and public (external).
The public subnet servers our Webserver and few other servers in the stack, where as the private subnet is exclusive to the Database  since it’s our corporate security policy not to have the DB talk to the world. This is where we ran into a problem with the MMS automated deployments.
If I choose the option to launch instances across subnets/zones, only the nodes that get allocated in the public subnet is able to be configured. Rest of them that get put in to the private subnet will timeout as the MMS agent cannot talk out, I.e. Elastic IPs’ assigned to instances in private subnet will not have Internet access (as per our Network architecture).

So, to effectively use MMS in our cloud infrastructure, we need to be presented with the option of ‘selecting’ the subnets of choice and not make use of Elastic IP addresses. Unless of course, this has been already addressed.

Hi Satish,

Apologies for the late follow-up. As I mentioned in my previous response, the only time public IPs / inbound connection are required is for provisioning via MMS. If you provision the environments and install the MMS Automation agent, you may be able to use MMS to manage your deployments.

However, if your private subnet does not allow any connections to the outside world (i.e. you are unable to allow the required outbound connections for cloud-hosted MMS), you will need an alternative solution.

There is an On-Premise version of MMS available with a MongoDB Enterprise subscription (https://www.mongodb.com/products/mongodb-enterprise-advanced). Automation support is not included in the current On-Prem 1.5 release but is being prepared for a future release.