AWS Lambda timing out on MongoDB Atlas connection
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
add a comment |
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
Can you include the code forcreateDoc
and insert a log in yourMongoClient.connect
callback to ensure that a) your createDoc is calling thecallback
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
add a comment |
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
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
mongodb amazon-web-services aws-lambda
edited Nov 19 '18 at 16:30
yoursweater
asked Nov 19 '18 at 15:22
yoursweateryoursweater
346415
346415
Can you include the code forcreateDoc
and insert a log in yourMongoClient.connect
callback to ensure that a) your createDoc is calling thecallback
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
add a comment |
Can you include the code forcreateDoc
and insert a log in yourMongoClient.connect
callback to ensure that a) your createDoc is calling thecallback
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Can you include the code for
createDoc
and insert a log in yourMongoClient.connect
callback to ensure that a) your createDoc is calling thecallback
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