1

I have a full AWS HTTPS web service, with all needed components i.e. a VPC containing:

  • private ec2 instances
  • autoscaling groups
  • a load balancer (with a public domain xxxxx.eu-west-1.elb.amazonaws.com , and even an official public domain xxxxx.com )
  • security groups

All of this works, and I can access from outside the Amazon cloud to xxxxx.com (using my Golang HTTP client code based on "net/http", for example), provided that I put my client IP address in the inbound rules of the security group of my load balancer (I filter IPs because it's a B2B service so I don't want to let anybody come in).

I have also a lambda function, and I would like to access this web service from that lambda function. The problem is, lambda functions don't have stable IP addresses. My request is similar to this one except that I don't want to access an EC2 instance directly (that would be unadvised since the service is scalable), simply access the public service like somebody from outside the Amazon cloud.

Currently, my lambda function can access any website on the Internet, except my HTTP web service. When I access my HTTP web service my Golang lambda client (the same code than above, so it's not a client issue) hangs in this function call, until the lambda timeouts (or my client timeouts if I configure a timeout in the client):

response, err = client.Do(req) // <--- hangs (client is a http.Client)

I tried to apply the recommended solution:

  • Allow all (0.0.0.0/0) in the inbound rules of the VPC security group. It works, but like I said, I want to eventually filter IPs to allow only specific clients (in addition of my lambda).
  • Add the lambda function in the VPC (the same VPC that the web service), create a security group for the lambda (with no inbounds rules, all/default outbounds rules), and allow that security group into in the inbound rules of the VPC security group. It doesn't work for some reason.

Is there a solution to do what I want?

Mark B
  • 183,023
  • 24
  • 297
  • 295
phrounz
  • 13
  • 3

1 Answers1

0

Add the lambda function in the VPC (the same VPC that the web service), create a security group for the lambda (with no inbounds rules, all/default outbounds rules), and allow that security group into in the inbound rules of the VPC security group. It doesn't work for some reason.

You are on the right track here, but unfortunately your public load balancer will be resolved by the Lambda function to its public IP address, which exists outside the VPC. So the Lambda then tries to reach out of the VPC to access the load balancer, at which point the traffic becomes disassociated with the Lambda function's security group.

You have two options:

  • Add an internal load balancer to your infrastructure, and a Route53 private hosted zone to resolve the domain name to the internal load balancer from within your VPC.

  • Deploy the Lambda function in VPC subnets that have a route to a NAT Gateway, and allow the NAT Gateway's Elastic IP address in the public load balancer's security group.

Mark B
  • 183,023
  • 24
  • 297
  • 295
  • Ok it works now, thanks! I did something which seems like the second option. I had a route table where I already had a network interface (or a NAT gateway?) giving me (I think) access to the Internet from the VPC (a line with destination=0.0.0.0/0 target=eni-xxxxxxxx). I just added the public IP address of this network interface eni-xxxxxxxx in the security group of the load balancer for HTTPS and it works. As I understand it I allow this way the traffic from the VPC to "reenter". – phrounz Mar 30 '22 at 10:51
  • You must have had a NAT Gateway already. A Lambda function can't use an Internet Gateway, it has to have a NAT Gateway. – Mark B Mar 30 '22 at 12:22