2

I can successfully connect to the cluster (1 instance for now) from the Cloud9 console using mongo shell, however wasted hours trying to connect to it from within a lambda function.

Setup:

  • Both cluster and lambda are in the same VPC (default)
  • TLS is ON
  • Cluster is in a security group called DemoDocDB which has inbound rules for 27017 for two security groups: cloud9 and DefaultSG
  • Lambda is in the default VPC and also in the DefaultSG security group

Code:

  • config.js
module.exports = {
    CONNECTION_STRING: 'mongodb://<user>:<pwd>@xxx.us-east-1.docdb.amazonaws.com:27017',
    SSL_CERTIFICATE: returnCerts(), // SSL Cert
    DB_NAME: 'documentdb', // Database name
    COLLECTION_NAME: 'events' // Tablename;
}

function returnCerts() {
    // Trick to avoid filesystem read of https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem
    return `-----BEGIN CERTIFICATE-----bla blah blah`
}
  • index.js
const {CONNECTION_STRING, SSL_CERTIFICATE, DB_NAME, COLLECTION_NAME} = require('./config');
const MongoClient = require('mongodb').MongoClient;

let client = null;

exports.handler = (event, context, callback) => {
    
    client = MongoClient.connect(CONNECTION_STRING, 
    { 
      sslValidate: true,
      sslCA:SSL_CERTIFICATE,
      useNewUrlParser: true
    },
    function(err, client) {
        console.log('connection callback invoked')
        
        if(err){
            console.log(err)
        }    })              
    //callback();
    return {
        statusCode: 200,
        body: JSON.stringify({"message":"hey"})
    };
};
  • Other: Nodejs 12.x, mongodb 3.6.2
  • Error:
START RequestId: 5e135853-063b-4d5a-8a21-9a29d15c8750 Version: $LATEST
2020-11-01T02:21:43.912Z    5e135853-063b-4d5a-8a21-9a29d15c8750    ERROR   (node:9) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.
2020-11-01T02:21:54.053Z    5e135853-063b-4d5a-8a21-9a29d15c8750    INFO    connection callback invoked
2020-11-01T02:21:54.091Z    5e135853-063b-4d5a-8a21-9a29d15c8750    INFO    MongoNetworkError: failed to connect to server [docdb-2020-10-31-23-57-52.cluster-cgzg3t2i3zpn.us-east-1.docdb.amazonaws.com:27017] on first connect [MongoNetworkTimeoutError: connection 0 to docdb-2020-10-31-23-57-52.cluster-cgzg3t2i3zpn.us-east-1.docdb.amazonaws.com:27017 timed out
    at Socket.<anonymous> (/var/task/LambdaDBTest/node_modules/mongodb/lib/core/connection/connection.js:421:7)
    at Object.onceWrapper (events.js:421:28)
    at Socket.emit (events.js:315:20)
    at Socket._onTimeout (net.js:482:8)
    at listOnTimeout (internal/timers.js:549:17)
    at processTimers (internal/timers.js:492:7) {
  [Symbol(beforeHandshake)]: true
}]
    at Pool.<anonymous> (/var/task/LambdaDBTest/node_modules/mongodb/lib/core/topologies/server.js:438:11)
    at Pool.emit (events.js:315:20)
    at /var/task/LambdaDBTest/node_modules/mongodb/lib/core/connection/pool.js:562:14
    at /var/task/LambdaDBTest/node_modules/mongodb/lib/core/connection/pool.js:995:11
    at callback (/var/task/LambdaDBTest/node_modules/mongodb/lib/core/connection/connect.js:75:5)
    at /var/task/LambdaDBTest/node_modules/mongodb/lib/core/connection/connect.js:101:9
    at _callback (/var/task/LambdaDBTest/node_modules/mongodb/lib/core/connection/connection.js:329:7)
    at Connection.errorHandler (/var/task/LambdaDBTest/node_modules/mongodb/lib/core/connection/connection.js:344:7)
    at Object.onceWrapper (events.js:422:26)
    at Connection.emit (events.js:315:20)
5
  • Are you connecting to a public endpoint of your cluster? If so, lambda in default VPC will not have any internet access, explaining your timeout. Commented Nov 1, 2020 at 3:50
  • Connecting to the only endpoint provided in the cluster details (guessing that's the public one?). Also, the DefaultSG has inbound permissions for the traffic from DemoDocDB Commented Nov 1, 2020 at 4:22
  • The issue is lambda specifiic? If you spin up an instance, with uses same SG as lambda, does connection work? Commented Nov 1, 2020 at 4:52
  • 2
    Well, I just tried to do the same with Python and it worked almost straight off the bat. I.e. my configuration seem to be correct and instead the problem might be in the MongoClient driver. So, going to ditch the javascript and switch to Python Commented Nov 2, 2020 at 4:28
  • Thanks for letting me know. You can answer your own question, for future reference for others:-) Commented Nov 2, 2020 at 4:31

1 Answer 1

4

I had a similar timeout issue connecting to a DocumentDB cluster with TLS enabled recently where I had omitted to tell the MongoClient to use SSL... I had the sslValidate and the sslCA option set but had not set the SSL option.

You have to either add ssl: true to your MongClient.connect options or add ssl=true to the connection URL query string. It doesn't look like (from the code snippets) that you're using either?

To clarify, the connection options from the question:

{ 
  sslValidate: true,
  sslCA:SSL_CERTIFICATE,
  useNewUrlParser: true
}

Should be:

{ 
  ssl: true,
  sslValidate: true,
  sslCA:SSL_CERTIFICATE,
  useNewUrlParser: true
}
Sign up to request clarification or add additional context in comments.

1 Comment

Oh wow, this was so helpful. I was trying to figure out in stackoverflow.com/q/75990980 why I could contact DocumentDb cluster from Cloud9 but not from my Spring Boot application, not realizing that in Cloud9 I was telling mongosh to use SSL/TLS but that Spring Boot by default apparently doesn't handle SSL/TLS. I had spent a whole day up against this roadblock until I found your answer here. Thank you!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.