Connecting to SMTP server from AWS Lambda












1















On my AWS Lambda function, my javascript code times out whenever I try to use nodemailer to connect to my Amazon SES SMTP server (port 465). However, if I run the script locally, it works fine, which leads me to believe it's either a problem with the lambda dialing out to the SMTP server, or the SMTP server blocking the lambda from connecting -- I suspect the former is the issue.



I am using a firewall behind my Cloudfront distribution, but I don't think this is applied to incoming SES connections or outgoing lambda functions. In VPC, I can see there is an Internet Gateway attached to the instance. The outgoing connections for the Security Group allows all protocols to access 0.0.0.0/0, however, the ACL looks odd in that it's both allowing and rejecting all inbound/outbound connections:



enter image description here



enter image description here



In VPC, I see 6 subnets listed, where it's not very obvious to me what exactly these are doing in the grand scheme of things.



enter image description here



In the logs, I just see Task timed out after 6.01 seconds



Any idea how I can get more information on where the hangup is at?










share|improve this question





























    1















    On my AWS Lambda function, my javascript code times out whenever I try to use nodemailer to connect to my Amazon SES SMTP server (port 465). However, if I run the script locally, it works fine, which leads me to believe it's either a problem with the lambda dialing out to the SMTP server, or the SMTP server blocking the lambda from connecting -- I suspect the former is the issue.



    I am using a firewall behind my Cloudfront distribution, but I don't think this is applied to incoming SES connections or outgoing lambda functions. In VPC, I can see there is an Internet Gateway attached to the instance. The outgoing connections for the Security Group allows all protocols to access 0.0.0.0/0, however, the ACL looks odd in that it's both allowing and rejecting all inbound/outbound connections:



    enter image description here



    enter image description here



    In VPC, I see 6 subnets listed, where it's not very obvious to me what exactly these are doing in the grand scheme of things.



    enter image description here



    In the logs, I just see Task timed out after 6.01 seconds



    Any idea how I can get more information on where the hangup is at?










    share|improve this question



























      1












      1








      1








      On my AWS Lambda function, my javascript code times out whenever I try to use nodemailer to connect to my Amazon SES SMTP server (port 465). However, if I run the script locally, it works fine, which leads me to believe it's either a problem with the lambda dialing out to the SMTP server, or the SMTP server blocking the lambda from connecting -- I suspect the former is the issue.



      I am using a firewall behind my Cloudfront distribution, but I don't think this is applied to incoming SES connections or outgoing lambda functions. In VPC, I can see there is an Internet Gateway attached to the instance. The outgoing connections for the Security Group allows all protocols to access 0.0.0.0/0, however, the ACL looks odd in that it's both allowing and rejecting all inbound/outbound connections:



      enter image description here



      enter image description here



      In VPC, I see 6 subnets listed, where it's not very obvious to me what exactly these are doing in the grand scheme of things.



      enter image description here



      In the logs, I just see Task timed out after 6.01 seconds



      Any idea how I can get more information on where the hangup is at?










      share|improve this question
















      On my AWS Lambda function, my javascript code times out whenever I try to use nodemailer to connect to my Amazon SES SMTP server (port 465). However, if I run the script locally, it works fine, which leads me to believe it's either a problem with the lambda dialing out to the SMTP server, or the SMTP server blocking the lambda from connecting -- I suspect the former is the issue.



      I am using a firewall behind my Cloudfront distribution, but I don't think this is applied to incoming SES connections or outgoing lambda functions. In VPC, I can see there is an Internet Gateway attached to the instance. The outgoing connections for the Security Group allows all protocols to access 0.0.0.0/0, however, the ACL looks odd in that it's both allowing and rejecting all inbound/outbound connections:



      enter image description here



      enter image description here



      In VPC, I see 6 subnets listed, where it's not very obvious to me what exactly these are doing in the grand scheme of things.



      enter image description here



      In the logs, I just see Task timed out after 6.01 seconds



      Any idea how I can get more information on where the hangup is at?







      amazon-web-services amazon-vpc amazon-ses amazon-lambda






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 3 hours ago







      iRyanBell

















      asked 4 hours ago









      iRyanBelliRyanBell

      1511519




      1511519






















          1 Answer
          1






          active

          oldest

          votes


















          3














          This is expected.



          Lambda functions in a VPC can't communicate with the Internet (including the standard service APIs) using an Internet Gateway, because an Internet Gateway requires the internal devices to have associated public IP addresses. Being on a public subnet (where the default route is the Internet Gateway) isn't sufficient.




          Important



          If your Lambda function needs Internet access, do not attach it to a public subnet or to a private subnet without Internet access. Instead, attach it only to private subnets with Internet access through a NAT instance or an Amazon VPC NAT gateway.



          https://docs.aws.amazon.com/lambda/latest/dg/vpc.html




          A NAT device -- typically a NAT Gateway -- is required, unless the service in question supports VPC Endpoints (which SES currently does not).



          Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway.



          The NAT Gateway is the newer alternative to the NAT Instance, which is an EC2 instance dedicated to the same purpose. This was formerly the only way to privide the required NAT service. Unlike a NAT Gateway, which is managed by AWS and is fault-tolerant, a NAT Instance represents a potential single point of failure (but has a lower associated cost).



          Or, you can move the Lambda function out of the VPC if it requires no other VPC resources.



          The Network ACL both allowing all and denying all is normal, because rules are processed in order. That last rule is the default behavior that would apply if the Allow rule is removed. It's mostly a visual cue to remind you why the NACL doesn't work if you delete the other rules. Users might otherwise assume that since they didn't explicitly deny something, that it should be allowed.




          Each network ACL also includes a rule whose rule number is an asterisk. This rule ensures that if a packet doesn't match any of the other numbered rules, it's denied. You can't modify or remove this rule.



          https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html







          share|improve this answer


























          • Ok, I created an NAT Gateway. I'm not quite seeing how I get my lambda function to use this to connect to the outside internet. It looks like this is done through some sort of routing table route propagation (through an "internet gateway") based on subnet addressing? I suppose it's not as simple as attaching the subnet to the VPC and then attaching the NAT gateway to the subnet (do I need all of these subnets?) I'm feeling a little bit like the meme of the dog with the test tubes.

            – iRyanBell
            2 hours ago













          • Create the NAT Gateway on one of the existing subnets. It needs to be located on a subnet with the default route pointing to the Internet Gateway so it can access the Internet. Then, create a new route table, with the default route pointing to the NAT Gateway. Then, create two new subnets, in two availability zones, using this new route table for those subnets. Attach the Lambda function to the new subnets.

            – Michael - sqlbot
            1 hour ago











          • Hmm, now I get Task timed out after 6.01 seconds when my lambda tries to connect to Elasticache. The lambda, database, ACL, and NAT Gateway are all on the same subnet, and the route table has the internet gateway attached. Why would I need to create new subnets... and why different availability zones than my servers? (and what would I use for "IPv4 CIDR block") ?

            – iRyanBell
            1 hour ago













          • You need different subnets because, as I mentioned above, you have to "Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway." A NAT Gateway can't be on a the same subnet it serves. If all your resources are in a single AZ, you can just use one new subnet in that AZ. Based on your current subnets, it looks like you could use CIDR block 172.31.x.0/20 where x is 96, 112, 128, 144, any number up to 240 as long as it is divisible by 16.

            – Michael - sqlbot
            1 hour ago













          • I appreciate you taking the time to help me figure this out. Here's the setup, with the lambdas using both of the private subnets. My elasticache is back in business, but I'm still not getting the SMTP connectivity. I believe the Routing Table and its Subnet Associations needs a different configuration, but I'm not quite following what it should look like. i.imgur.com/LO6tkeJ.png

            – iRyanBell
            57 mins ago













          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "2"
          };
          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%2fserverfault.com%2fquestions%2f955461%2fconnecting-to-smtp-server-from-aws-lambda%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          3














          This is expected.



          Lambda functions in a VPC can't communicate with the Internet (including the standard service APIs) using an Internet Gateway, because an Internet Gateway requires the internal devices to have associated public IP addresses. Being on a public subnet (where the default route is the Internet Gateway) isn't sufficient.




          Important



          If your Lambda function needs Internet access, do not attach it to a public subnet or to a private subnet without Internet access. Instead, attach it only to private subnets with Internet access through a NAT instance or an Amazon VPC NAT gateway.



          https://docs.aws.amazon.com/lambda/latest/dg/vpc.html




          A NAT device -- typically a NAT Gateway -- is required, unless the service in question supports VPC Endpoints (which SES currently does not).



          Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway.



          The NAT Gateway is the newer alternative to the NAT Instance, which is an EC2 instance dedicated to the same purpose. This was formerly the only way to privide the required NAT service. Unlike a NAT Gateway, which is managed by AWS and is fault-tolerant, a NAT Instance represents a potential single point of failure (but has a lower associated cost).



          Or, you can move the Lambda function out of the VPC if it requires no other VPC resources.



          The Network ACL both allowing all and denying all is normal, because rules are processed in order. That last rule is the default behavior that would apply if the Allow rule is removed. It's mostly a visual cue to remind you why the NACL doesn't work if you delete the other rules. Users might otherwise assume that since they didn't explicitly deny something, that it should be allowed.




          Each network ACL also includes a rule whose rule number is an asterisk. This rule ensures that if a packet doesn't match any of the other numbered rules, it's denied. You can't modify or remove this rule.



          https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html







          share|improve this answer


























          • Ok, I created an NAT Gateway. I'm not quite seeing how I get my lambda function to use this to connect to the outside internet. It looks like this is done through some sort of routing table route propagation (through an "internet gateway") based on subnet addressing? I suppose it's not as simple as attaching the subnet to the VPC and then attaching the NAT gateway to the subnet (do I need all of these subnets?) I'm feeling a little bit like the meme of the dog with the test tubes.

            – iRyanBell
            2 hours ago













          • Create the NAT Gateway on one of the existing subnets. It needs to be located on a subnet with the default route pointing to the Internet Gateway so it can access the Internet. Then, create a new route table, with the default route pointing to the NAT Gateway. Then, create two new subnets, in two availability zones, using this new route table for those subnets. Attach the Lambda function to the new subnets.

            – Michael - sqlbot
            1 hour ago











          • Hmm, now I get Task timed out after 6.01 seconds when my lambda tries to connect to Elasticache. The lambda, database, ACL, and NAT Gateway are all on the same subnet, and the route table has the internet gateway attached. Why would I need to create new subnets... and why different availability zones than my servers? (and what would I use for "IPv4 CIDR block") ?

            – iRyanBell
            1 hour ago













          • You need different subnets because, as I mentioned above, you have to "Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway." A NAT Gateway can't be on a the same subnet it serves. If all your resources are in a single AZ, you can just use one new subnet in that AZ. Based on your current subnets, it looks like you could use CIDR block 172.31.x.0/20 where x is 96, 112, 128, 144, any number up to 240 as long as it is divisible by 16.

            – Michael - sqlbot
            1 hour ago













          • I appreciate you taking the time to help me figure this out. Here's the setup, with the lambdas using both of the private subnets. My elasticache is back in business, but I'm still not getting the SMTP connectivity. I believe the Routing Table and its Subnet Associations needs a different configuration, but I'm not quite following what it should look like. i.imgur.com/LO6tkeJ.png

            – iRyanBell
            57 mins ago


















          3














          This is expected.



          Lambda functions in a VPC can't communicate with the Internet (including the standard service APIs) using an Internet Gateway, because an Internet Gateway requires the internal devices to have associated public IP addresses. Being on a public subnet (where the default route is the Internet Gateway) isn't sufficient.




          Important



          If your Lambda function needs Internet access, do not attach it to a public subnet or to a private subnet without Internet access. Instead, attach it only to private subnets with Internet access through a NAT instance or an Amazon VPC NAT gateway.



          https://docs.aws.amazon.com/lambda/latest/dg/vpc.html




          A NAT device -- typically a NAT Gateway -- is required, unless the service in question supports VPC Endpoints (which SES currently does not).



          Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway.



          The NAT Gateway is the newer alternative to the NAT Instance, which is an EC2 instance dedicated to the same purpose. This was formerly the only way to privide the required NAT service. Unlike a NAT Gateway, which is managed by AWS and is fault-tolerant, a NAT Instance represents a potential single point of failure (but has a lower associated cost).



          Or, you can move the Lambda function out of the VPC if it requires no other VPC resources.



          The Network ACL both allowing all and denying all is normal, because rules are processed in order. That last rule is the default behavior that would apply if the Allow rule is removed. It's mostly a visual cue to remind you why the NACL doesn't work if you delete the other rules. Users might otherwise assume that since they didn't explicitly deny something, that it should be allowed.




          Each network ACL also includes a rule whose rule number is an asterisk. This rule ensures that if a packet doesn't match any of the other numbered rules, it's denied. You can't modify or remove this rule.



          https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html







          share|improve this answer


























          • Ok, I created an NAT Gateway. I'm not quite seeing how I get my lambda function to use this to connect to the outside internet. It looks like this is done through some sort of routing table route propagation (through an "internet gateway") based on subnet addressing? I suppose it's not as simple as attaching the subnet to the VPC and then attaching the NAT gateway to the subnet (do I need all of these subnets?) I'm feeling a little bit like the meme of the dog with the test tubes.

            – iRyanBell
            2 hours ago













          • Create the NAT Gateway on one of the existing subnets. It needs to be located on a subnet with the default route pointing to the Internet Gateway so it can access the Internet. Then, create a new route table, with the default route pointing to the NAT Gateway. Then, create two new subnets, in two availability zones, using this new route table for those subnets. Attach the Lambda function to the new subnets.

            – Michael - sqlbot
            1 hour ago











          • Hmm, now I get Task timed out after 6.01 seconds when my lambda tries to connect to Elasticache. The lambda, database, ACL, and NAT Gateway are all on the same subnet, and the route table has the internet gateway attached. Why would I need to create new subnets... and why different availability zones than my servers? (and what would I use for "IPv4 CIDR block") ?

            – iRyanBell
            1 hour ago













          • You need different subnets because, as I mentioned above, you have to "Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway." A NAT Gateway can't be on a the same subnet it serves. If all your resources are in a single AZ, you can just use one new subnet in that AZ. Based on your current subnets, it looks like you could use CIDR block 172.31.x.0/20 where x is 96, 112, 128, 144, any number up to 240 as long as it is divisible by 16.

            – Michael - sqlbot
            1 hour ago













          • I appreciate you taking the time to help me figure this out. Here's the setup, with the lambdas using both of the private subnets. My elasticache is back in business, but I'm still not getting the SMTP connectivity. I believe the Routing Table and its Subnet Associations needs a different configuration, but I'm not quite following what it should look like. i.imgur.com/LO6tkeJ.png

            – iRyanBell
            57 mins ago
















          3












          3








          3







          This is expected.



          Lambda functions in a VPC can't communicate with the Internet (including the standard service APIs) using an Internet Gateway, because an Internet Gateway requires the internal devices to have associated public IP addresses. Being on a public subnet (where the default route is the Internet Gateway) isn't sufficient.




          Important



          If your Lambda function needs Internet access, do not attach it to a public subnet or to a private subnet without Internet access. Instead, attach it only to private subnets with Internet access through a NAT instance or an Amazon VPC NAT gateway.



          https://docs.aws.amazon.com/lambda/latest/dg/vpc.html




          A NAT device -- typically a NAT Gateway -- is required, unless the service in question supports VPC Endpoints (which SES currently does not).



          Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway.



          The NAT Gateway is the newer alternative to the NAT Instance, which is an EC2 instance dedicated to the same purpose. This was formerly the only way to privide the required NAT service. Unlike a NAT Gateway, which is managed by AWS and is fault-tolerant, a NAT Instance represents a potential single point of failure (but has a lower associated cost).



          Or, you can move the Lambda function out of the VPC if it requires no other VPC resources.



          The Network ACL both allowing all and denying all is normal, because rules are processed in order. That last rule is the default behavior that would apply if the Allow rule is removed. It's mostly a visual cue to remind you why the NACL doesn't work if you delete the other rules. Users might otherwise assume that since they didn't explicitly deny something, that it should be allowed.




          Each network ACL also includes a rule whose rule number is an asterisk. This rule ensures that if a packet doesn't match any of the other numbered rules, it's denied. You can't modify or remove this rule.



          https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html







          share|improve this answer















          This is expected.



          Lambda functions in a VPC can't communicate with the Internet (including the standard service APIs) using an Internet Gateway, because an Internet Gateway requires the internal devices to have associated public IP addresses. Being on a public subnet (where the default route is the Internet Gateway) isn't sufficient.




          Important



          If your Lambda function needs Internet access, do not attach it to a public subnet or to a private subnet without Internet access. Instead, attach it only to private subnets with Internet access through a NAT instance or an Amazon VPC NAT gateway.



          https://docs.aws.amazon.com/lambda/latest/dg/vpc.html




          A NAT device -- typically a NAT Gateway -- is required, unless the service in question supports VPC Endpoints (which SES currently does not).



          Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway.



          The NAT Gateway is the newer alternative to the NAT Instance, which is an EC2 instance dedicated to the same purpose. This was formerly the only way to privide the required NAT service. Unlike a NAT Gateway, which is managed by AWS and is fault-tolerant, a NAT Instance represents a potential single point of failure (but has a lower associated cost).



          Or, you can move the Lambda function out of the VPC if it requires no other VPC resources.



          The Network ACL both allowing all and denying all is normal, because rules are processed in order. That last rule is the default behavior that would apply if the Allow rule is removed. It's mostly a visual cue to remind you why the NACL doesn't work if you delete the other rules. Users might otherwise assume that since they didn't explicitly deny something, that it should be allowed.




          Each network ACL also includes a rule whose rule number is an asterisk. This rule ensures that if a packet doesn't match any of the other numbered rules, it's denied. You can't modify or remove this rule.



          https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html








          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 1 hour ago

























          answered 3 hours ago









          Michael - sqlbotMichael - sqlbot

          15.5k3058




          15.5k3058













          • Ok, I created an NAT Gateway. I'm not quite seeing how I get my lambda function to use this to connect to the outside internet. It looks like this is done through some sort of routing table route propagation (through an "internet gateway") based on subnet addressing? I suppose it's not as simple as attaching the subnet to the VPC and then attaching the NAT gateway to the subnet (do I need all of these subnets?) I'm feeling a little bit like the meme of the dog with the test tubes.

            – iRyanBell
            2 hours ago













          • Create the NAT Gateway on one of the existing subnets. It needs to be located on a subnet with the default route pointing to the Internet Gateway so it can access the Internet. Then, create a new route table, with the default route pointing to the NAT Gateway. Then, create two new subnets, in two availability zones, using this new route table for those subnets. Attach the Lambda function to the new subnets.

            – Michael - sqlbot
            1 hour ago











          • Hmm, now I get Task timed out after 6.01 seconds when my lambda tries to connect to Elasticache. The lambda, database, ACL, and NAT Gateway are all on the same subnet, and the route table has the internet gateway attached. Why would I need to create new subnets... and why different availability zones than my servers? (and what would I use for "IPv4 CIDR block") ?

            – iRyanBell
            1 hour ago













          • You need different subnets because, as I mentioned above, you have to "Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway." A NAT Gateway can't be on a the same subnet it serves. If all your resources are in a single AZ, you can just use one new subnet in that AZ. Based on your current subnets, it looks like you could use CIDR block 172.31.x.0/20 where x is 96, 112, 128, 144, any number up to 240 as long as it is divisible by 16.

            – Michael - sqlbot
            1 hour ago













          • I appreciate you taking the time to help me figure this out. Here's the setup, with the lambdas using both of the private subnets. My elasticache is back in business, but I'm still not getting the SMTP connectivity. I believe the Routing Table and its Subnet Associations needs a different configuration, but I'm not quite following what it should look like. i.imgur.com/LO6tkeJ.png

            – iRyanBell
            57 mins ago





















          • Ok, I created an NAT Gateway. I'm not quite seeing how I get my lambda function to use this to connect to the outside internet. It looks like this is done through some sort of routing table route propagation (through an "internet gateway") based on subnet addressing? I suppose it's not as simple as attaching the subnet to the VPC and then attaching the NAT gateway to the subnet (do I need all of these subnets?) I'm feeling a little bit like the meme of the dog with the test tubes.

            – iRyanBell
            2 hours ago













          • Create the NAT Gateway on one of the existing subnets. It needs to be located on a subnet with the default route pointing to the Internet Gateway so it can access the Internet. Then, create a new route table, with the default route pointing to the NAT Gateway. Then, create two new subnets, in two availability zones, using this new route table for those subnets. Attach the Lambda function to the new subnets.

            – Michael - sqlbot
            1 hour ago











          • Hmm, now I get Task timed out after 6.01 seconds when my lambda tries to connect to Elasticache. The lambda, database, ACL, and NAT Gateway are all on the same subnet, and the route table has the internet gateway attached. Why would I need to create new subnets... and why different availability zones than my servers? (and what would I use for "IPv4 CIDR block") ?

            – iRyanBell
            1 hour ago













          • You need different subnets because, as I mentioned above, you have to "Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway." A NAT Gateway can't be on a the same subnet it serves. If all your resources are in a single AZ, you can just use one new subnet in that AZ. Based on your current subnets, it looks like you could use CIDR block 172.31.x.0/20 where x is 96, 112, 128, 144, any number up to 240 as long as it is divisible by 16.

            – Michael - sqlbot
            1 hour ago













          • I appreciate you taking the time to help me figure this out. Here's the setup, with the lambdas using both of the private subnets. My elasticache is back in business, but I'm still not getting the SMTP connectivity. I believe the Routing Table and its Subnet Associations needs a different configuration, but I'm not quite following what it should look like. i.imgur.com/LO6tkeJ.png

            – iRyanBell
            57 mins ago



















          Ok, I created an NAT Gateway. I'm not quite seeing how I get my lambda function to use this to connect to the outside internet. It looks like this is done through some sort of routing table route propagation (through an "internet gateway") based on subnet addressing? I suppose it's not as simple as attaching the subnet to the VPC and then attaching the NAT gateway to the subnet (do I need all of these subnets?) I'm feeling a little bit like the meme of the dog with the test tubes.

          – iRyanBell
          2 hours ago







          Ok, I created an NAT Gateway. I'm not quite seeing how I get my lambda function to use this to connect to the outside internet. It looks like this is done through some sort of routing table route propagation (through an "internet gateway") based on subnet addressing? I suppose it's not as simple as attaching the subnet to the VPC and then attaching the NAT gateway to the subnet (do I need all of these subnets?) I'm feeling a little bit like the meme of the dog with the test tubes.

          – iRyanBell
          2 hours ago















          Create the NAT Gateway on one of the existing subnets. It needs to be located on a subnet with the default route pointing to the Internet Gateway so it can access the Internet. Then, create a new route table, with the default route pointing to the NAT Gateway. Then, create two new subnets, in two availability zones, using this new route table for those subnets. Attach the Lambda function to the new subnets.

          – Michael - sqlbot
          1 hour ago





          Create the NAT Gateway on one of the existing subnets. It needs to be located on a subnet with the default route pointing to the Internet Gateway so it can access the Internet. Then, create a new route table, with the default route pointing to the NAT Gateway. Then, create two new subnets, in two availability zones, using this new route table for those subnets. Attach the Lambda function to the new subnets.

          – Michael - sqlbot
          1 hour ago













          Hmm, now I get Task timed out after 6.01 seconds when my lambda tries to connect to Elasticache. The lambda, database, ACL, and NAT Gateway are all on the same subnet, and the route table has the internet gateway attached. Why would I need to create new subnets... and why different availability zones than my servers? (and what would I use for "IPv4 CIDR block") ?

          – iRyanBell
          1 hour ago







          Hmm, now I get Task timed out after 6.01 seconds when my lambda tries to connect to Elasticache. The lambda, database, ACL, and NAT Gateway are all on the same subnet, and the route table has the internet gateway attached. Why would I need to create new subnets... and why different availability zones than my servers? (and what would I use for "IPv4 CIDR block") ?

          – iRyanBell
          1 hour ago















          You need different subnets because, as I mentioned above, you have to "Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway." A NAT Gateway can't be on a the same subnet it serves. If all your resources are in a single AZ, you can just use one new subnet in that AZ. Based on your current subnets, it looks like you could use CIDR block 172.31.x.0/20 where x is 96, 112, 128, 144, any number up to 240 as long as it is divisible by 16.

          – Michael - sqlbot
          1 hour ago







          You need different subnets because, as I mentioned above, you have to "Place the NAT Gateway on a public subnet (so that it can access the Internet using the Internet Gateway) and then create one or more private subnets, pointing their default route to the NAT Gateway." A NAT Gateway can't be on a the same subnet it serves. If all your resources are in a single AZ, you can just use one new subnet in that AZ. Based on your current subnets, it looks like you could use CIDR block 172.31.x.0/20 where x is 96, 112, 128, 144, any number up to 240 as long as it is divisible by 16.

          – Michael - sqlbot
          1 hour ago















          I appreciate you taking the time to help me figure this out. Here's the setup, with the lambdas using both of the private subnets. My elasticache is back in business, but I'm still not getting the SMTP connectivity. I believe the Routing Table and its Subnet Associations needs a different configuration, but I'm not quite following what it should look like. i.imgur.com/LO6tkeJ.png

          – iRyanBell
          57 mins ago







          I appreciate you taking the time to help me figure this out. Here's the setup, with the lambdas using both of the private subnets. My elasticache is back in business, but I'm still not getting the SMTP connectivity. I believe the Routing Table and its Subnet Associations needs a different configuration, but I'm not quite following what it should look like. i.imgur.com/LO6tkeJ.png

          – iRyanBell
          57 mins ago




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Server Fault!


          • 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%2fserverfault.com%2fquestions%2f955461%2fconnecting-to-smtp-server-from-aws-lambda%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







          Popular posts from this blog

          flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

          Mangá

          Eduardo VII do Reino Unido