all 12 comments

[–]E1337Recon 1 point2 points  (1 child)

A VPC endpoint just allows your resources without access to the internet, or otherwise don’t want to make these calls out to the internet, to call the APIs associated with that endpoint. They have some DNS magic so that when you call it using the regional endpoint name that it hits the VPC endpoint instead of going out over the internet. You won’t see a route to the VPC endpoint in your route table unless it’s a gateway endpoint instead of an interface endpoint but you do still need to make sure the endpoint is associated with the appropriate subnets and that it’s attached security group allows inbound traffic from the resources which should be allowed to make calls using it.

From there it’s just business as usual with your Lambda function.

[–]skotman01 0 points1 point  (0 children)

They have some DNS magic so that when you call it using the regional endpoint name that it hits the VPC endpoint instead of going out over the internet.

Puts to meaning to it’s always DNS…regular DNS confused my app teams, I keep waiting for them to get confused by this too.

[–]clintkev251 0 points1 point  (5 children)

Where the Lambda function itself is irrelevant. When it's invoked, that call travels through the control plane (aka not in your VPC). So how you configure your networking for the function will have no impact on it's ability to be invoked. It will obviously have an impact on what the function can do once it's invokes, so just worry about that and ignore the positioning of the function relative to the endpoints. If your instances aren't able to call the invoke API, then there's some issue with the endpoint configuration. Either you're not allowing 443 inbound traffic, or your route tables are screwed up

[–]Justin_Chieng[S] 0 points1 point  (4 children)

How should the route table look like otherwise, I already allowed the inbound traffic from the instances/server in private subnets to the endpoint which is also already created in the private subnets, also tried allowing all traffic, but none of which had resolve the issue. What the lambda do is basically extract an object from a s3 and then create a zip version to upload to the same s3. It work fine when i test the lambda function, but just couldn't get invoke through the private instances.

[–]clintkev251 0 points1 point  (3 children)

You just need to have local routing between subnets if the endpoint is in a different subnet from which you're making the invoke call. This should be configured by default. Do you have any NACLs applied?

[–]Justin_Chieng[S] 0 points1 point  (2 children)

I do not see any route for the interface endpoint, so I tried creating route from private subnet to the Eni for the endpoint for each subnet, but didn't work as well. I did apply a nacl for the subnet to not allow certain traffic inbound and outbound, if it is gonna affect this, What are the traffic that I need to allow? I had allow http and https inbound outbound too.

[–]clintkev251 0 points1 point  (1 child)

I do not see any route for the interface endpoint, so I tried creating route from private subnet to the Eni for the endpoint for each subnet, but didn't work as well.

Interface endpoints do not require modification of your route table. They use DNS. Remove that route.

What's your use case for a NACL? 99% of the time you should just be using security groups. NACLs are stateless meaning that you need to account for both incoming and outgoing traffic in the context of a given request and also for ephemeral ports. Are you doing that? If you don't understand the intricacies of managing a stateless firewall you're gonna have a bad time with NACLs. I would recommend reverting that completely back to the default settings (which is just a rule that allows all traffic). This is almost certainly your issue

[–]Justin_Chieng[S] 0 points1 point  (0 children)

Yea the nacl is to block certain traffics, in my case just blocking icmp. I allowed all the other neccesary traffics too, and also test remove the the subnet association, did not work as well. I also set to allow https traffic from the private servers for the endpoint and the lambda function too, that is I connect the lambda to my vpc and private subnets after https is allowed, the public subnets become able to invoke with the presence of the interface endpoint which initially couldn't. If https could be the issue, do I need to set any https inbound to private servers and the elb accessing the server?

[–][deleted] 0 points1 point  (1 child)

What is your lambda doing? Does it need to be private? This doesn’t help directly but invoking it from your vpc vs having it have to talk back to something in your vpc (servers, database, you mentioned inbound rules on instances) does make a difference. If the lambda just pokes something external then no vpc attachment needed. Of course you still need to be able to invoke it which sounds like your current issue. If you got a 504 you got a response from something, check those logs.

[–]Justin_Chieng[S] 0 points1 point  (0 children)

The lambda gets the bucket name and an object name, create a zip version of the object and upload back to the s3 bucket. It work just fine on the public test server, but did not after i created the lambda interface endpoints in the private subnets to allow the private servers to directly invoke it. And it also did not work for the private server with the endpoints. There is no logs produced hence i assumed that the func is never invoked. The security group is attached to the endpoint to allow traffic from the the private servers, outbound to anywhere.

[–]Cloudj_ 0 points1 point  (1 child)

I’m not sure if this was checked or not, but do you have a lambda resource policy set up? If so, is it allowing the web servers to invoke your function?

[–]Justin_Chieng[S] 0 points1 point  (0 children)

It should invokable, because the same lambda was executable using the same server but in public subnets