mjhjmtu

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:

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.

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?

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