As AWS does support executing a Lambda function from an ALB, I thought I would try out executing one produced when deploying jets; unfortunately, to no avail.
Might I have missed something in the documentation or would this not be something that is supported at this time?
From what I could determine (thus far), it is simply that the response is not formatted how the ALB expects and thus results in a 502 with the access logs showing "LambdaInvalidResponse" where the CloudWatch logs show that it did execute successfully with a 200.
Following up on my question: it would appear that I am slightly mistaken regarding the response not being formatted how the ALB expects.
Running a test against the Lambda function using the event as sent by the ALB produces a response as the ALB expects with the exception of one detail: the statusCode is a string instead of an integer.
Thanks so much for the details in this post, it helped.
Played with ELBs a little bit this morning. Though not adding official ELB support, did adjust the response for requests coming from ELBs to help for those who are manually connecting ELBs: https://github.com/tongueroo/jets/pull/242
So think it should now be possible to execute lambda through ALBs now.
I had intended on getting a pull request submitted after diving into the code a bit further to determine if anything else should be done. Such as the response headers being strings; I had just removed them in my build but knew that was not the proper solution.
Semi-unrelated, but will just leave this here for anyone following this topic: calls coming from the ALB will not have event["pathParameters"] (nor event["resource"]) and thus, for example, a call of /posts/:id will not have params["id"]. We are currently working around this by just parsing it from the event["path"].