AWS Lambda timing out on MongoDB Atlas connection












0















I'm just trying to write a simple Lambda function to insert data into my MongoDB Atlas cluster. I've set the cluster to accept all incoming traffic (0.0.0.0/0) and confirmed that I can connect locally.



For AWS Lambda, I set up a VPC using the VPC wizard, and I gave my Lambda function a security role with full admin access. I set the timeout to 12 seconds, but I'm still getting the following error:



Response:
{
"errorMessage": "2018-11-19T15:17:23.200Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Task timed out after 11.01 seconds"
}

Request ID:
"3048e1fd-ec0e-11e8-a03d-fb79584484c5"

Function Logs:
START RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Version: $LATEST
2018-11-19T15:17:12.191Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Calling MongoDB Atlas from AWS Lambda with event: {"address":{"street":"2 Avenue","zipcode":"10075","building":"1480","coord":[-73.9557413,40.7720266]},"borough":"Manhattan","cuisine":"Italian","grades":[{"date":"2014-10-01T00:00:00Z","grade":"A","score":11},{"date":"2014-01-16T00:00:00Z","grade":"B","score":17}],"name":"Vella","restaurant_id":"41704620"}
2018-11-19T15:17:12.208Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 => connecting to database
2018-11-19T15:17:12.248Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 (node:1) DeprecationWarning: current URL string parser is deprecated, and will be removed in a future version. To use the new parser, pass option { useNewUrlParser: true } to MongoClient.connect.
END RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5
REPORT RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Duration: 11011.08 ms Billed Duration: 11000 ms Memory Size: 128 MB Max Memory Used: 29 MB
2018-11-19T15:17:23.200Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Task timed out after 11.01 seconds


The relevant part of my code for connecting is (with user and pass being the appropriate values):



const MongoClient = require('mongodb').MongoClient;
let atlas_connection_uri = "mongodb+srv://<user>:<pass>@restaurantcluster-2ylyf.gcp.mongodb.net/testdb"


let cachedDb = null;

exports.handler = (event, context, callback) => {
var uri = atlas_connection_uri

if (atlas_connection_uri != null) {
processEvent(event, context, callback);
}
else {
atlas_connection_uri = uri;
console.log('the Atlas connection string is ' + atlas_connection_uri);
processEvent(event, context, callback);
}
};

function processEvent(event, context, callback) {
console.log('Calling MongoDB Atlas from AWS Lambda with event: ' + JSON.stringify(event));
var jsonContents = JSON.parse(JSON.stringify(event));

//date conversion for grades array
if(jsonContents.grades != null) {
for(var i = 0, len=jsonContents.grades.length; i < len; i++) {

jsonContents.grades[i].date = new Date();
}
}

context.callbackWaitsForEmptyEventLoop = false;

try {
if (cachedDb == null) {
console.log('=> connecting to database');
MongoClient.connect(atlas_connection_uri, function (err, client) {
cachedDb = client.db('testdb');
return createDoc(cachedDb, jsonContents, callback);
});
}
else {
createDoc(cachedDb, jsonContents, callback);
}
}
catch (err) {
console.error('an error occurred', err);
}
}


I suspect that something is going on with my VPC firewall/permissions/security group considering the fact that I can connect from my local machine, but I have no idea how that could be the case when I'm granting full admins privileges in my security role and I've set all outgoing VPC traffic to my public subnet.



I would appreciate any advice/help in solving this!



edit to provide more info:



The function console.logs '=> connecting to database' and then immediately times out at MongoClient.connect (confirmed by attempting to console.log directly after that).










share|improve this question

























  • Can you include the code for createDoc and insert a log in your MongoClient.connect callback to ensure that a) your createDoc is calling the callback argument and b) your MongoClient is connecting within the lambda.

    – thomasmichaelwallace
    Nov 19 '18 at 16:26











  • Hey Thomas, I can confirm that that connection is being attempted, as it times out at MongoClient.connect. The '=> connecting to database' fires and nothing after the connect function will fire. It's just timing out at MongoClient.connect without any given error.

    – yoursweater
    Nov 19 '18 at 16:28











  • MongoClient.connect will wait until connection timeout (typically 2 minutes in node) in cases of bad VPC configuration- so you're right to suspect that. Unfortunately at that point it's just a series of debugging steps. Can an EC2 machine configured with the same subnet/security-group as the lambda access that Mongo instance?

    – thomasmichaelwallace
    Nov 19 '18 at 16:35











  • Thomas - I just set up an ec2 instance to test this (actually, it was the first time I had ever done that, so that's kinda cool). Installed node and ran a script to connect... it connected without any problem, which makes me think my VPC setup HAS to be correct. So that must leave the security roles as the only culprit here, right? If not, then I'm at my wit's end!

    – yoursweater
    Nov 19 '18 at 17:24






  • 1





    If the Lambda function needs to run in a VPC, but access things outside the VPC, then it must be in a private subnet with a NAT Gateway. Lambda functions never get public IP addresses assigned to them, even inside a public subnet, so you have to use a private subnet + NAT in order to give them outside access. If your Lambda function doesn't actually need to access anything inside the VPC then configuring it to run inside the VPC has nothing but drawbacks. Unless you are doing something like Atlas VPC peering, then you probably shouldn't be placing the function in a VPC.

    – Mark B
    Nov 19 '18 at 18:35
















0















I'm just trying to write a simple Lambda function to insert data into my MongoDB Atlas cluster. I've set the cluster to accept all incoming traffic (0.0.0.0/0) and confirmed that I can connect locally.



For AWS Lambda, I set up a VPC using the VPC wizard, and I gave my Lambda function a security role with full admin access. I set the timeout to 12 seconds, but I'm still getting the following error:



Response:
{
"errorMessage": "2018-11-19T15:17:23.200Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Task timed out after 11.01 seconds"
}

Request ID:
"3048e1fd-ec0e-11e8-a03d-fb79584484c5"

Function Logs:
START RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Version: $LATEST
2018-11-19T15:17:12.191Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Calling MongoDB Atlas from AWS Lambda with event: {"address":{"street":"2 Avenue","zipcode":"10075","building":"1480","coord":[-73.9557413,40.7720266]},"borough":"Manhattan","cuisine":"Italian","grades":[{"date":"2014-10-01T00:00:00Z","grade":"A","score":11},{"date":"2014-01-16T00:00:00Z","grade":"B","score":17}],"name":"Vella","restaurant_id":"41704620"}
2018-11-19T15:17:12.208Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 => connecting to database
2018-11-19T15:17:12.248Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 (node:1) DeprecationWarning: current URL string parser is deprecated, and will be removed in a future version. To use the new parser, pass option { useNewUrlParser: true } to MongoClient.connect.
END RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5
REPORT RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Duration: 11011.08 ms Billed Duration: 11000 ms Memory Size: 128 MB Max Memory Used: 29 MB
2018-11-19T15:17:23.200Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Task timed out after 11.01 seconds


The relevant part of my code for connecting is (with user and pass being the appropriate values):



const MongoClient = require('mongodb').MongoClient;
let atlas_connection_uri = "mongodb+srv://<user>:<pass>@restaurantcluster-2ylyf.gcp.mongodb.net/testdb"


let cachedDb = null;

exports.handler = (event, context, callback) => {
var uri = atlas_connection_uri

if (atlas_connection_uri != null) {
processEvent(event, context, callback);
}
else {
atlas_connection_uri = uri;
console.log('the Atlas connection string is ' + atlas_connection_uri);
processEvent(event, context, callback);
}
};

function processEvent(event, context, callback) {
console.log('Calling MongoDB Atlas from AWS Lambda with event: ' + JSON.stringify(event));
var jsonContents = JSON.parse(JSON.stringify(event));

//date conversion for grades array
if(jsonContents.grades != null) {
for(var i = 0, len=jsonContents.grades.length; i < len; i++) {

jsonContents.grades[i].date = new Date();
}
}

context.callbackWaitsForEmptyEventLoop = false;

try {
if (cachedDb == null) {
console.log('=> connecting to database');
MongoClient.connect(atlas_connection_uri, function (err, client) {
cachedDb = client.db('testdb');
return createDoc(cachedDb, jsonContents, callback);
});
}
else {
createDoc(cachedDb, jsonContents, callback);
}
}
catch (err) {
console.error('an error occurred', err);
}
}


I suspect that something is going on with my VPC firewall/permissions/security group considering the fact that I can connect from my local machine, but I have no idea how that could be the case when I'm granting full admins privileges in my security role and I've set all outgoing VPC traffic to my public subnet.



I would appreciate any advice/help in solving this!



edit to provide more info:



The function console.logs '=> connecting to database' and then immediately times out at MongoClient.connect (confirmed by attempting to console.log directly after that).










share|improve this question

























  • Can you include the code for createDoc and insert a log in your MongoClient.connect callback to ensure that a) your createDoc is calling the callback argument and b) your MongoClient is connecting within the lambda.

    – thomasmichaelwallace
    Nov 19 '18 at 16:26











  • Hey Thomas, I can confirm that that connection is being attempted, as it times out at MongoClient.connect. The '=> connecting to database' fires and nothing after the connect function will fire. It's just timing out at MongoClient.connect without any given error.

    – yoursweater
    Nov 19 '18 at 16:28











  • MongoClient.connect will wait until connection timeout (typically 2 minutes in node) in cases of bad VPC configuration- so you're right to suspect that. Unfortunately at that point it's just a series of debugging steps. Can an EC2 machine configured with the same subnet/security-group as the lambda access that Mongo instance?

    – thomasmichaelwallace
    Nov 19 '18 at 16:35











  • Thomas - I just set up an ec2 instance to test this (actually, it was the first time I had ever done that, so that's kinda cool). Installed node and ran a script to connect... it connected without any problem, which makes me think my VPC setup HAS to be correct. So that must leave the security roles as the only culprit here, right? If not, then I'm at my wit's end!

    – yoursweater
    Nov 19 '18 at 17:24






  • 1





    If the Lambda function needs to run in a VPC, but access things outside the VPC, then it must be in a private subnet with a NAT Gateway. Lambda functions never get public IP addresses assigned to them, even inside a public subnet, so you have to use a private subnet + NAT in order to give them outside access. If your Lambda function doesn't actually need to access anything inside the VPC then configuring it to run inside the VPC has nothing but drawbacks. Unless you are doing something like Atlas VPC peering, then you probably shouldn't be placing the function in a VPC.

    – Mark B
    Nov 19 '18 at 18:35














0












0








0








I'm just trying to write a simple Lambda function to insert data into my MongoDB Atlas cluster. I've set the cluster to accept all incoming traffic (0.0.0.0/0) and confirmed that I can connect locally.



For AWS Lambda, I set up a VPC using the VPC wizard, and I gave my Lambda function a security role with full admin access. I set the timeout to 12 seconds, but I'm still getting the following error:



Response:
{
"errorMessage": "2018-11-19T15:17:23.200Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Task timed out after 11.01 seconds"
}

Request ID:
"3048e1fd-ec0e-11e8-a03d-fb79584484c5"

Function Logs:
START RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Version: $LATEST
2018-11-19T15:17:12.191Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Calling MongoDB Atlas from AWS Lambda with event: {"address":{"street":"2 Avenue","zipcode":"10075","building":"1480","coord":[-73.9557413,40.7720266]},"borough":"Manhattan","cuisine":"Italian","grades":[{"date":"2014-10-01T00:00:00Z","grade":"A","score":11},{"date":"2014-01-16T00:00:00Z","grade":"B","score":17}],"name":"Vella","restaurant_id":"41704620"}
2018-11-19T15:17:12.208Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 => connecting to database
2018-11-19T15:17:12.248Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 (node:1) DeprecationWarning: current URL string parser is deprecated, and will be removed in a future version. To use the new parser, pass option { useNewUrlParser: true } to MongoClient.connect.
END RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5
REPORT RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Duration: 11011.08 ms Billed Duration: 11000 ms Memory Size: 128 MB Max Memory Used: 29 MB
2018-11-19T15:17:23.200Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Task timed out after 11.01 seconds


The relevant part of my code for connecting is (with user and pass being the appropriate values):



const MongoClient = require('mongodb').MongoClient;
let atlas_connection_uri = "mongodb+srv://<user>:<pass>@restaurantcluster-2ylyf.gcp.mongodb.net/testdb"


let cachedDb = null;

exports.handler = (event, context, callback) => {
var uri = atlas_connection_uri

if (atlas_connection_uri != null) {
processEvent(event, context, callback);
}
else {
atlas_connection_uri = uri;
console.log('the Atlas connection string is ' + atlas_connection_uri);
processEvent(event, context, callback);
}
};

function processEvent(event, context, callback) {
console.log('Calling MongoDB Atlas from AWS Lambda with event: ' + JSON.stringify(event));
var jsonContents = JSON.parse(JSON.stringify(event));

//date conversion for grades array
if(jsonContents.grades != null) {
for(var i = 0, len=jsonContents.grades.length; i < len; i++) {

jsonContents.grades[i].date = new Date();
}
}

context.callbackWaitsForEmptyEventLoop = false;

try {
if (cachedDb == null) {
console.log('=> connecting to database');
MongoClient.connect(atlas_connection_uri, function (err, client) {
cachedDb = client.db('testdb');
return createDoc(cachedDb, jsonContents, callback);
});
}
else {
createDoc(cachedDb, jsonContents, callback);
}
}
catch (err) {
console.error('an error occurred', err);
}
}


I suspect that something is going on with my VPC firewall/permissions/security group considering the fact that I can connect from my local machine, but I have no idea how that could be the case when I'm granting full admins privileges in my security role and I've set all outgoing VPC traffic to my public subnet.



I would appreciate any advice/help in solving this!



edit to provide more info:



The function console.logs '=> connecting to database' and then immediately times out at MongoClient.connect (confirmed by attempting to console.log directly after that).










share|improve this question
















I'm just trying to write a simple Lambda function to insert data into my MongoDB Atlas cluster. I've set the cluster to accept all incoming traffic (0.0.0.0/0) and confirmed that I can connect locally.



For AWS Lambda, I set up a VPC using the VPC wizard, and I gave my Lambda function a security role with full admin access. I set the timeout to 12 seconds, but I'm still getting the following error:



Response:
{
"errorMessage": "2018-11-19T15:17:23.200Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Task timed out after 11.01 seconds"
}

Request ID:
"3048e1fd-ec0e-11e8-a03d-fb79584484c5"

Function Logs:
START RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Version: $LATEST
2018-11-19T15:17:12.191Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Calling MongoDB Atlas from AWS Lambda with event: {"address":{"street":"2 Avenue","zipcode":"10075","building":"1480","coord":[-73.9557413,40.7720266]},"borough":"Manhattan","cuisine":"Italian","grades":[{"date":"2014-10-01T00:00:00Z","grade":"A","score":11},{"date":"2014-01-16T00:00:00Z","grade":"B","score":17}],"name":"Vella","restaurant_id":"41704620"}
2018-11-19T15:17:12.208Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 => connecting to database
2018-11-19T15:17:12.248Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 (node:1) DeprecationWarning: current URL string parser is deprecated, and will be removed in a future version. To use the new parser, pass option { useNewUrlParser: true } to MongoClient.connect.
END RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5
REPORT RequestId: 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Duration: 11011.08 ms Billed Duration: 11000 ms Memory Size: 128 MB Max Memory Used: 29 MB
2018-11-19T15:17:23.200Z 3048e1fd-ec0e-11e8-a03d-fb79584484c5 Task timed out after 11.01 seconds


The relevant part of my code for connecting is (with user and pass being the appropriate values):



const MongoClient = require('mongodb').MongoClient;
let atlas_connection_uri = "mongodb+srv://<user>:<pass>@restaurantcluster-2ylyf.gcp.mongodb.net/testdb"


let cachedDb = null;

exports.handler = (event, context, callback) => {
var uri = atlas_connection_uri

if (atlas_connection_uri != null) {
processEvent(event, context, callback);
}
else {
atlas_connection_uri = uri;
console.log('the Atlas connection string is ' + atlas_connection_uri);
processEvent(event, context, callback);
}
};

function processEvent(event, context, callback) {
console.log('Calling MongoDB Atlas from AWS Lambda with event: ' + JSON.stringify(event));
var jsonContents = JSON.parse(JSON.stringify(event));

//date conversion for grades array
if(jsonContents.grades != null) {
for(var i = 0, len=jsonContents.grades.length; i < len; i++) {

jsonContents.grades[i].date = new Date();
}
}

context.callbackWaitsForEmptyEventLoop = false;

try {
if (cachedDb == null) {
console.log('=> connecting to database');
MongoClient.connect(atlas_connection_uri, function (err, client) {
cachedDb = client.db('testdb');
return createDoc(cachedDb, jsonContents, callback);
});
}
else {
createDoc(cachedDb, jsonContents, callback);
}
}
catch (err) {
console.error('an error occurred', err);
}
}


I suspect that something is going on with my VPC firewall/permissions/security group considering the fact that I can connect from my local machine, but I have no idea how that could be the case when I'm granting full admins privileges in my security role and I've set all outgoing VPC traffic to my public subnet.



I would appreciate any advice/help in solving this!



edit to provide more info:



The function console.logs '=> connecting to database' and then immediately times out at MongoClient.connect (confirmed by attempting to console.log directly after that).







mongodb amazon-web-services aws-lambda






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 19 '18 at 16:30







yoursweater

















asked Nov 19 '18 at 15:22









yoursweateryoursweater

346415




346415













  • Can you include the code for createDoc and insert a log in your MongoClient.connect callback to ensure that a) your createDoc is calling the callback argument and b) your MongoClient is connecting within the lambda.

    – thomasmichaelwallace
    Nov 19 '18 at 16:26











  • Hey Thomas, I can confirm that that connection is being attempted, as it times out at MongoClient.connect. The '=> connecting to database' fires and nothing after the connect function will fire. It's just timing out at MongoClient.connect without any given error.

    – yoursweater
    Nov 19 '18 at 16:28











  • MongoClient.connect will wait until connection timeout (typically 2 minutes in node) in cases of bad VPC configuration- so you're right to suspect that. Unfortunately at that point it's just a series of debugging steps. Can an EC2 machine configured with the same subnet/security-group as the lambda access that Mongo instance?

    – thomasmichaelwallace
    Nov 19 '18 at 16:35











  • Thomas - I just set up an ec2 instance to test this (actually, it was the first time I had ever done that, so that's kinda cool). Installed node and ran a script to connect... it connected without any problem, which makes me think my VPC setup HAS to be correct. So that must leave the security roles as the only culprit here, right? If not, then I'm at my wit's end!

    – yoursweater
    Nov 19 '18 at 17:24






  • 1





    If the Lambda function needs to run in a VPC, but access things outside the VPC, then it must be in a private subnet with a NAT Gateway. Lambda functions never get public IP addresses assigned to them, even inside a public subnet, so you have to use a private subnet + NAT in order to give them outside access. If your Lambda function doesn't actually need to access anything inside the VPC then configuring it to run inside the VPC has nothing but drawbacks. Unless you are doing something like Atlas VPC peering, then you probably shouldn't be placing the function in a VPC.

    – Mark B
    Nov 19 '18 at 18:35



















  • Can you include the code for createDoc and insert a log in your MongoClient.connect callback to ensure that a) your createDoc is calling the callback argument and b) your MongoClient is connecting within the lambda.

    – thomasmichaelwallace
    Nov 19 '18 at 16:26











  • Hey Thomas, I can confirm that that connection is being attempted, as it times out at MongoClient.connect. The '=> connecting to database' fires and nothing after the connect function will fire. It's just timing out at MongoClient.connect without any given error.

    – yoursweater
    Nov 19 '18 at 16:28











  • MongoClient.connect will wait until connection timeout (typically 2 minutes in node) in cases of bad VPC configuration- so you're right to suspect that. Unfortunately at that point it's just a series of debugging steps. Can an EC2 machine configured with the same subnet/security-group as the lambda access that Mongo instance?

    – thomasmichaelwallace
    Nov 19 '18 at 16:35











  • Thomas - I just set up an ec2 instance to test this (actually, it was the first time I had ever done that, so that's kinda cool). Installed node and ran a script to connect... it connected without any problem, which makes me think my VPC setup HAS to be correct. So that must leave the security roles as the only culprit here, right? If not, then I'm at my wit's end!

    – yoursweater
    Nov 19 '18 at 17:24






  • 1





    If the Lambda function needs to run in a VPC, but access things outside the VPC, then it must be in a private subnet with a NAT Gateway. Lambda functions never get public IP addresses assigned to them, even inside a public subnet, so you have to use a private subnet + NAT in order to give them outside access. If your Lambda function doesn't actually need to access anything inside the VPC then configuring it to run inside the VPC has nothing but drawbacks. Unless you are doing something like Atlas VPC peering, then you probably shouldn't be placing the function in a VPC.

    – Mark B
    Nov 19 '18 at 18:35

















Can you include the code for createDoc and insert a log in your MongoClient.connect callback to ensure that a) your createDoc is calling the callback argument and b) your MongoClient is connecting within the lambda.

– thomasmichaelwallace
Nov 19 '18 at 16:26





Can you include the code for createDoc and insert a log in your MongoClient.connect callback to ensure that a) your createDoc is calling the callback argument and b) your MongoClient is connecting within the lambda.

– thomasmichaelwallace
Nov 19 '18 at 16:26













Hey Thomas, I can confirm that that connection is being attempted, as it times out at MongoClient.connect. The '=> connecting to database' fires and nothing after the connect function will fire. It's just timing out at MongoClient.connect without any given error.

– yoursweater
Nov 19 '18 at 16:28





Hey Thomas, I can confirm that that connection is being attempted, as it times out at MongoClient.connect. The '=> connecting to database' fires and nothing after the connect function will fire. It's just timing out at MongoClient.connect without any given error.

– yoursweater
Nov 19 '18 at 16:28













MongoClient.connect will wait until connection timeout (typically 2 minutes in node) in cases of bad VPC configuration- so you're right to suspect that. Unfortunately at that point it's just a series of debugging steps. Can an EC2 machine configured with the same subnet/security-group as the lambda access that Mongo instance?

– thomasmichaelwallace
Nov 19 '18 at 16:35





MongoClient.connect will wait until connection timeout (typically 2 minutes in node) in cases of bad VPC configuration- so you're right to suspect that. Unfortunately at that point it's just a series of debugging steps. Can an EC2 machine configured with the same subnet/security-group as the lambda access that Mongo instance?

– thomasmichaelwallace
Nov 19 '18 at 16:35













Thomas - I just set up an ec2 instance to test this (actually, it was the first time I had ever done that, so that's kinda cool). Installed node and ran a script to connect... it connected without any problem, which makes me think my VPC setup HAS to be correct. So that must leave the security roles as the only culprit here, right? If not, then I'm at my wit's end!

– yoursweater
Nov 19 '18 at 17:24





Thomas - I just set up an ec2 instance to test this (actually, it was the first time I had ever done that, so that's kinda cool). Installed node and ran a script to connect... it connected without any problem, which makes me think my VPC setup HAS to be correct. So that must leave the security roles as the only culprit here, right? If not, then I'm at my wit's end!

– yoursweater
Nov 19 '18 at 17:24




1




1





If the Lambda function needs to run in a VPC, but access things outside the VPC, then it must be in a private subnet with a NAT Gateway. Lambda functions never get public IP addresses assigned to them, even inside a public subnet, so you have to use a private subnet + NAT in order to give them outside access. If your Lambda function doesn't actually need to access anything inside the VPC then configuring it to run inside the VPC has nothing but drawbacks. Unless you are doing something like Atlas VPC peering, then you probably shouldn't be placing the function in a VPC.

– Mark B
Nov 19 '18 at 18:35





If the Lambda function needs to run in a VPC, but access things outside the VPC, then it must be in a private subnet with a NAT Gateway. Lambda functions never get public IP addresses assigned to them, even inside a public subnet, so you have to use a private subnet + NAT in order to give them outside access. If your Lambda function doesn't actually need to access anything inside the VPC then configuring it to run inside the VPC has nothing but drawbacks. Unless you are doing something like Atlas VPC peering, then you probably shouldn't be placing the function in a VPC.

– Mark B
Nov 19 '18 at 18:35












0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53377725%2faws-lambda-timing-out-on-mongodb-atlas-connection%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53377725%2faws-lambda-timing-out-on-mongodb-atlas-connection%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







這個網誌中的熱門文章

Tangent Lines Diagram Along Smooth Curve

Yusuf al-Mu'taman ibn Hud

Zucchini