Using the latest Robo 3T and the command line provided by AWS
mongodb://<dbname>:<insertYourPassword>#example-db.cluster-c2e1234stuff0e.eu-west-2.docdb.amazonaws.com:27017
I get this Error:
Reason:
SSL tunnel failure: Network is unreachable or SSL connection rejected by server.
Reason: Connect failed
I have also tried following THIS walkthrough but had no joy.
I have read that it is possible to SSH to a EC2 instance on the same VPC and access documentdb this way but ideally I would like to access it directly and not pay for an extra EC2 instance. If I have that right?
I have tried via Mongo shell too and get the following response:
Error: couldn't connect to server example-db.cluster-c2eblahblaho0e.eu-west-2.docdb.amazonaws.com:27017, connection attempt failed: NetworkTimeout: Error connecting to example-db.cluster-c2eblahblaho0e.eu-west-2.docdb.amazonaws.com:27017 (<IP address>) :: caused by :: Socket operation timed out :
connect#src/mongo/shell/mongo.js:344:17
#(connect):2:6
exception: connect failed
What I suspect is happening is that either you do not have an EC2 instance in the same VPC as your DocumentDB cluster or that EC2 instance is not reachable from your laptop. I'd first connect to the EC2 instance with SSH to establish connectivity and then use that EC2 instance to SSH proxy from Robo3T.
For context, Amazon DocumentDB clusters deployed within a VPC can be accessed directly by EC2 instances or other AWS services that are deployed in the same VPC. Additionally, Amazon DocumentDB can be accessed by EC2 instances or other AWS services in different VPCs in the same region or other regions via VPC peering.
The advantage of deploying clusters within a VPC is that VPCs provide a strong network boundary to the Internet. A common way to connect to DocumentDB from your laptop is to create an EC2 instance within the same VPC as your DocumentDB cluster and SSH tunnel through that EC2 instance to your cluster: https://docs.aws.amazon.com/documentdb/latest/developerguide/connect-from-outside-a-vpc.html
To minimize costs for local development, start with the smallest EC2 instance size and utilize the start/stop functionality when not using the cluster.
The same can be done with DocumentDB. When you are developing, you can save on instance costs by stopping the cluster when it is no longer needed: https://docs.aws.amazon.com/documentdb/latest/developerguide/db-cluster-stop-start.html
An alternative is to utilize AWS Cloud9: https://docs.aws.amazon.com/documentdb/latest/developerguide/connect-with-cloud9.html. This solution still requires an EC2 instance in the same VPC as your Amazon Document. What is useful about this solution is that Cloud9 provides a mechanisms to automatically shutdown the EC2 instance if it has been idle for 30-minutes, for example, to help save costs.
Related
We have 2 separate VPC's and dont need to do any peering. one VPC has an openvpn software running for vpn purposes and a lambda in another vpc that needs access to the resource in the openvpn VPC. so how can this be done if we try to create a tunnel from an EC2 instance running in the Lambda's VPC that is connected to the other VPC via vpnclient? Would this work in this scenario or are there any other alternatives. The Lambda would like to reach the elasticsearch service running in the other VPC via VPN client running in the EC2 instance
Please create VPC peering between these 2 VPCs & configure route tables of both.
In case of need further help, please do let me know
I launched one RDS instance,s3 and EC2 in AWS and its is triggered properly using lambda. Now I wish to change the change the RDS and EC2 from AWS to local machine. My lambda is triggered from s3.
How do I connect the local database through lambda in AWS?
It appears that your requirement is:
You wish to run an AWS Lambda function
Within the function, you wish to connect to a database running on your own computer (outside of AWS)
Firstly, I would not recommend this strategy. To maintain good performance, you should always have an application as close as possible to the database. This means on the same network, in the same location and not going across remote network connections or the Internet.
However, if you wish to do this, then here's some things you would need to do:
Your database will need to be accessible on the Internet, so that you can connect to it remotely. To test this, try accessing it from an Amazon EC2 instance.
The AWS Lambda function should either be configured without VPC connectivity (which means that it is connected to the Internet) or, if you have configured it for VPC connectivity, it needs to be in a Private Subnet with a NAT Gateway enabling Internet access.
(Optional) For added security, you could lock-down your database to only accept connections from a known IP address. To achieve this, you would need to use the VPC + NAT Gateway so that all traffic is coming from the Elastic IP address assigned to the NAT Gateway.
I agree with John Rotenstein that connecting your local machine to a Lambda running on AWS is probably a bad idea.
If your intention is to develop or test locally, I recommend the serverless framework, and the serverless-offline plugin. It will allow you to simulate Lambda locally, and you can pass database config values through as environment variables.
See: Running AWS Lambda and API Gateway locally: serverless-offline
I have an instance of AWS RDS running in a private subnet of a VPC.
I would like my EC2 machine, which is running on a public subnet to have access to it via SSL (and not SSH like I saw people suggest. I want to access it directly from the code via SSL).
Is there a way to do so?
The EC2 instance should have direct access to the RDS instance as long as they are in the same VPC. You just need to open up the security group assigned to the RDS instance to allow ingress from the EC2 instance.
I think you have SSH tunneling (which isn't needed when both servers are in the same VPC) and SSL database connections confused. SSH and SSL would be completely unrelated in this case.
SSL connection support would be a function of the specific database engine you are using. If your database is configured to support SSL connections, then you should be able to configure your database client software running on your EC2 instance to use SSL when creating connections to the database.
I'm not able to connect to my Redshift cluster through ODBC from an EC2 instance. However, I'm able to connect to it from an outside computer (for eg My Macbook) using the ODBC connector. I have been trying and trying but in vain. How can I make my EC2 instance connect to Redshift? The Error I get is:
Is the Server running on host .................and accepting TCP/IP connections on port 5439?
I'm really confused as I can connect form outside but not from an EC2.
Thanks for the help.
Add the security group of your EC2 machine to the list of Ingress rules of the security group in your Redshift VPC.
Basically, you need to allow your EC2 machine to connect to the Redshift cluster.
If you have the instance in the same VPC, public hostname of redshift might not work.
Do I need to create an EC2 instance in order to remotely connect to my Amazon RDS instance?
I understand that setting up an Amazon RDS instance automagically creates an EC2 instance 'in the background'. But when looking into my EC2 console I don't see that hidden instance so I can't find the details for the public DNS or Elastic IP, neither the EC2 instance key that I need to connect through SSH.
Yes, an RDS instance creates an EC2 instance to run the database but you don't have direct access to it via ssh, which is kind of the point.
RDS is a service that is managed for you and the idea is to hide the implementation details and simply provide an endpoint to connect to from another EC2 instance. You can find the endpoint name in the EC2 console - just use this as the hostname to connect to from your application and you can treat RDS just like any other database.
Amazon need to maintain a level of control over the server in order to provide it as a service and ssh access would interfere with that. There are a few things you miss out on because of this (e.g. direct access to DB files) but these are far outweighed by having Amazon manage upgrades, backups and replication for you.