I have an AWS VPC with two public subnets. The route table has a public route 0.0.0.0/0 to the Internet gateway. Using CloudFormation I created a DocumentDB cluster with a single instance. I assigned it to both subnets, and I gave it a security group allowing ingress from 0.0.0.0/0 to port 27017, but no egress at all (i.e. 0.0.0.0/32). The instance is using the default.docdb4.0 parameter group, which appears to already have tls set to enabled.
Now I want to connect to this DocumentDB instance with mongosh just to do a sanity test. I'd prefer to use secure connections. If I need to open up some more ports/routes temporarily, that's fine. But I'm not sure what I'm lacking.
Each DocumentDB instance has a "Connection & Security" tab showing how to connect manually.
rds-combined-ca-bundle.pem as indicated.mongosh rather than mongo:mongosh --ssl --host ….docdb.amazonaws.com:27017 --sslCAFile rds-combined-ca-bundle.pem --username … --password …
I got:
MongoServerSelectionError: connect ETIMEDOUT x.x.x.x:27017
The IP address given is one in the VPC, not a publicly routable IP address. Does DocumentDB not have a publicly routable address? (I'm pretty sure ECS Fargate services have publicly routable addresses.) What am I missing to be able to connect directly via mongosh to my DocumentDB in my public subnet?
Update: After more research, especially the similar question problems connecting to AWS DocumentDB, it seems that a DocumentDB instance in a VPC is simply not visible directly, as it has an internal IP address. (Even this is confusing, because Working with a DB instance in a VPC seems to imply that I can get a public IP address to the instance somehow, and as already mentioned I can with ECS Fargate. Maybe none of that applies to DocumentDB. But why can't I set up something like a load balancer I wonder that forwards from external to internal IPs?) The solution seems to be SSH tunneling, but even that has to be done from an EC2 instance or Cloud9 from within my VPC. So I guess unless I want to create an EC2 instance, my only remaining option is to figure out why Cloud9 won't start up.
At this point I thought that maybe I needed some EC2 instance within the VPC itself to connect to the DocumentDB instance. So for the first time I attempted to create a Cloud9 environment. I used the defaults, except that I selected the VPC in which the DocumentDB cluster+instance is running. Cloud9 took a long time to set up the environment. (While it was being created, I received an email from AWS saying, "You recently requested an AWS Service that required additional validation. Your request has now been validated …." I have no idea what that meant.) Finally Cloud9 gave a status of "Error" with a lifecycle status of "Creation failed":
Cloud9 could not connect to the EC2 instance. Please check your VPC configuration and network settings to troubleshoot the issue.
I read VPC settings for AWS Cloud9 Development Environments, and it says that I need to have a route table with 0.0.0.0/0 to the Internet gateway (which I have). It also said I need a security group allowing SSH (port 22) connections. It wasn't clear what should have this security group, but I assume it means the Cloud9 EC2 instance (which I thought would be created automatically). Oddly I looked at the EC2 instance security group for the failed Cloud9 environment, and there were no inbound rules at all.
Admittedly there is a lot to read on the VPC settings page for Cloud9. I'll go back and try to wade through it all, but can anyone see right away what I'm missing just to spin up a Cloud9 environment to access my DocumentDB instance using mongosh?
Well at least I got it to create a Cloud9 environment. Using the console I had to select the "Secure Shell (SSH)" connection option. Every time I selected the "AWS Systems Manager (SSM)" connection option, it failed. I can't find any information on the difference between the two, or more to the point, why one would cause the creation of the Cloud9 environment to fail, even before I tried to connect to it.
Maybe someone can tell me what setting I need to add temporarily (preferably using CloudFormation) to access the DocumentDB instance from my local machine using mongosh?
Or is there some easier way to temporarily access my DocumentDB instance using mongosh for sanity testing?
I finally was able to connect to my DocumentDB cluster in my VPC. Here are some things of note:
I went the Cloud9 route. You can use the Cloud9 terminal to install the MongoDB shell and then use it to connect to your DocumentDB cluster in the same VPC. See Get Started with Amazon DocumentDB for an overview. Here are some tips from my experiences.
You can get the connection instructions from the console page for your DocumentDB cluster under "Connectivity & security". It assumes you've already installed the MongoDB shell, and assumes you're using the old version mongo. I preferred to use the newer mongosh, even though DocumentDB isn't compatible with the latest MongoDB versions, if nothing else than to ensure that the simple functionality I needed works with DocumentDB. So I followed the official MongoDB installation instructions, being sure to select "Amazon Linux".
Rather than typing some echo instructions, I typed sudo nano /etc/yum.repos.d/mongodb-org-6.0.repo and entered the following information to set up the latest (as of today) MongoDB Yum RPM repo:
[mongodb-org-6.0]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/6.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-6.0.asc
Then installed mongosh:
sudo yum install -y mongodb-mongosh
Then finally I followed the connections instructions for my DocumentDB cluster from the console.
wget https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem
mongosh --tls --host <cluster-info>.us-east-1.docdb.amazonaws.com:27017 --tlsCAFile rds-combined-ca-bundle.pem --username <username> --password <password>
Note that using the latest mongosh (v1.8.0), besides using mongo instead of mongosh it's best to also:
--tls instead of --ssl, and--tlsCAFile instead of --sslCAFile.