AWS Lambda: Unable to access SQS Queue from a Lambda function with VPC access

Question

I have a Lambda function that needs to read messages from an SQS queue using it\'s URL. Then it needs to insert that data to Cassandra running on a server inside a VPC.

Answer 1

I was unable to get either of the other two answers to this question to work. Perhaps this is due to one or more mistakes on my part. Regardless, I did find a workaround that I wanted to share, in case I'm not alone with this problem.

Solution: I created two Lambda functions. The first Lambda function runs inside my VPC and performs the desired work (in mandeep_m91's case, that's a data insertion to Cassandra; in my case is was accessing an RDS instance). The second Lambda function lives outside the VPC, so I could hook it up to the SQS queue. I then had the second Lambda function call the first, using the information found this this StackOverflow Q&A answer. Note, the linked question has both node.js and Python examples in the answers.

This will effectively double the cost of making a function call, since each call results in two function executions. However, for my situation, the volume is so low it won't make a real difference.

Answer 2

I ran into the same kind of problem when I was running lambda function with access to elasticache on the VPC. While the function was configured to run in the VPC, I wasnt able to talk to any other service (specifically codedeploy for me).

As @garnaat pointed out NAT seems to be the only way to go about solving this problem for services without VPC endpoints.

And like you pointed out, I also ran into the same trouble where I could'nt SSH into the machine(s) once I replaced the entry with the IGW in the route table. Seems like detaching the IGW starves the VPC of either the incoming traffic (mostly) or the outgoing traffic from or to the internet respectively. So here's what I did and it worked for me:

Create a new Subnet within the VPC Now, when lambda runs, make sure lambda operates from this subnet. You can do this by using aws-cli like so:

 aws lambda update-function-configuration --function-name your-function-name --vpc-config SubnetIds="subnet-id-of-created-subnet",SecurityGroupIds="sg-1","sg-2"

Make sure you add all the security groups whose inbound and outbound traffic rules apply for your lambda function.

Next, go to Route Tables in the VPC console and create a new route table.

Here is where you add the NAT gateway to the target.

finally go to the Subnet Associations tab in the new route table and add the newly created subnet there.

Thats all this should get it working . Mind you, please treat this as only a workaround. I haven't done much digging and I have a very limited idea on how things get resolved internally while doing this. This might not be an ideal solution.

The ideal solution seems to be to design the VPC before hand. Use subnets to isolate resources/instances that need internet access and that dont(private and public subnets) and place appropriate gateways where needed.( so that you may not have to create a seperate subnet for this purpose later). Thanks

Answer 3

Some services (e.g. S3) are offering VPC endpoints to solve this particular problem but SQS is not one of them. I think the only real solution to this problem is to run a NAT inside your VPC so the network traffic from the Lambda function can be routed to the outside world.

Answer 4

At the end of 2018, AWS announced support for SQS endpoints which provide

connectivity to Amazon SQS without requiring an internet gateway, network address translation (NAT) instance, or VPN connection.

There is a tutorial for Sending a Message to an Amazon SQS Queue from Amazon Virtual Private Cloud

See also the SQS VPC Endpoints Documentation for more information.

Its important to note that if you want to access SQS within the Lambda VPC there are a couple other things you need to do:

• Make sure to specify the SQS region in your code. For example, I had to set my endpoint_url to "https://sqs.us-west-2.amazonaws.com"
• Make sure that you have attached a "wide open" security group to the SQS VPC Interface, otherwise SQS will not work.
• Make sure that your subnets in your Lambda VPC match what you have set up for your SQS VPC Interface.

Answer 5

To clarify a point above about a "wide open" security group, the group set on the endpoint needs to allow inbound access to SQS from your lambda function.

I created a security group for my endpoint that only opened 443 to my lambda's security group.