AWS security group inbound rule. allow lambda function

I run a service on my EC2 instance and I want to setup an inbound rule that only allows my lambda function to access it. The security group allows me to restrict access by a specific IP, but I don't think that lambda functions have a specific IP assigned. Is there a way to do what I want?

Solution 1:

If you are enabling VPC access for your Lambda function, as per this blog post, then you will create a security group for your Lambda functions to use within your VPC. All you need to do at that point is go into the security group your EC2 instance is using and grant access to the security group the Lambda function is using. This is the method I recommend.

If you are not using VPC access then your EC2 instance would need to be publicly accessible and you would basically be going over the internet to access the EC2 instance from the Lambda function. If that's the case then there is no good way to restrict that in the security group. You could (with difficulty) open it up to only requests that originate within AWS, but that still leaves it open to all other users of AWS. If you must go over the internet to access your EC2 instance from Lambda then it would be best to send some sort of security token with each request Lambda sends, and ignore any requests on the EC2 server that don't contain that security token.

Solution 2:

What happens if we want our Lambda function to access resources in our VPC? This is a bit of a puzzlement because the Lambda function does not have a stable IP address that we can use as a source in our VPC security groups or in our subnet ACLs.

AWS has overcome these limitations by allowing you to specify a subnet and security group to associate with the Lambda function. You would think that this security group and subnet ACL would control traffic in and out of the Lambda function, but this is wrong. Firstly, Lambda functions do not listen for traffic on any port and so the concept of inbound traffic to a Lambda function is not applicable. Secondly, outbound connections from the Lambda function to VPC resources are not restricted in any way by the Lambda function’s security group. So, what is this mysterious Lambda function security group good for and how does it work?

It turns out that the Lambda function’s security group is just a naming placeholder that we can use in our other EC2 security groups. For example, a Lambda function can make a GET request to an EC2 instance on a private subnet in your VPC. We start out with two security groups. The first one is a normal security group that controls traffic to and from our EC2 instance that will be serving up the files on port 8080. It has a single inbound rule that allows port 8080 traffic with a source being the Lambda function’s security group. Recall that security group rules can specify source or destination as another security group which is a placeholder for all the hosts that are members of that source or destination security group.

The Lambda function’s security group has no rules whatsoever. None are required. It is merely a placeholder for the Lambda function that allows us to specify the Lambda function as source in our other EC2 security groups. Remember that the Lambda function has a random IP address that changes from day to day and hour to hour, so it is not possible to specify it as source for the inbound traffic to the EC2 instance. Security groups normally control traffic in and out of a network interface but in the case of an AWS Lambda function security group, there is no interface and no rules – it is merely a placeholder.

Solution 3:

A Lambda with no VPC association will be on the Internet and assigned with an arbitrary Public IP (obviously from Amazon Registered IPs) which will not be a fix address. So it is almost impossible to whitelist that IP in your EC2's SG since next time that Lambda spins up the IP could change and is not predictable.

However there is a way to Partially limit the Network Access only to the Resources Located in the VPC including Lambda's(since components will be assigned with Internal-IPs). Let's say you want that EC2 server only be accessible from Internal vpc network, therefor you place it in your Internal Subnet with no Public IP assigned to it. Now You can set SG on your EC2 to only accept IP from the Internal subnet CIDR range of your VPC. By Associating Lambda to that VPC and Placing it in the Private Subnet, Lambda will get arbitrary IP from Internal CIDR Range of your VPC which obviously falls in the SG range already configured for your EC2 (If you are going to have lots of Lambda in parallel just make sure you have enough amount of IPs within your defined CIDR range).

If you want your components to Communicate Internally meanwhile be able to access the Internet as well you can add a NAT Gateway Routable to IGW and then you will add Routing rule to the Internal Subnets to point to your NAT Gateway. Therefore all your component within the Internal subnet will be assigned with a Routing Tables pointing to NAT and subsequently the Internet.

Solution 4:

Your Lambda will have a temporary IP assigned to it when it runs. If you configure the IAM role attached to it so it can Allow/Revoke Security Group Ingress, you can make it "let himself in" to your sec group. Check out this article for an example on adding an IP or CIDR block to your inbound list. I would clean it up straight away when the function is done.