Aws-lambda-dotnet: Amazon.Lambda.AspNetCoreServer with Application Load Balancer

I was just taking a look at the new ALB integration. The JSON request that gets sent into the Lambda function is a different than API Gateway. It shouldn't be too hard to detect in APIGatewayProxyFunction the JSON format and do a different parse logic based on the source.

That would be great. We would probably use the ALB as our preferred method of integrating since we already make heavy use of ALB.

We are currently using APIGatewayProxyFunction, but the API Gateway only allows 30 seconds to finish transaction. A ELB would be a good work around for our larger data that needs processing. (Up to the limit on lambda functions 15min)

It would be amazing if we could just use the LambdaEntryPoint : Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction and have it not care if its APIGateway or a ELB.

I have been working on the ALB support on the alb-support branch. The next step in that branch is working on Amazon.Lambda.AspNetCoreServer

Wow that was quick! =) Thanks!
Cant wait!

This is great, thanks. Looking forward to using this for our dotnet core web app. Thanks!

Agreed, can't wait for this feature!

Status update I have pushed the branch alb-support-aspnetcore which contains the updates for Amazon.Lambda.AspNetCoreServer.

The changes ended up triggering a bigger refactor then I had hopped. I had definitely not anticipated when I originally wrote this library that there would be multiple HTTP frontends for Lambda functions.

If anybody is willing to clone the repo and give this a try while I finish with validation that would be great. You should just need to clone the repo, go into Amazon.Lambda.ApplicationLoadBalancerEvents and Amazon.Lambda.AspNetCoreServer and do a dotnet pack. Then add the created NuGet package to a local feed.

For most apps the only change you should have to do in LambdaEntryPoint or whatever you named it is change the base class from APIGatewayProxyFunction to ApplicationLoadBalancerFunction.

Funny thing is I re-deployed to a LAMBDA name using master, and I was able to use ELB with LambdaEntryPoint : Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction before your branch, and everything worked. (Just need to set the rules on the ELB Trigger to use path "api/*")

(Somehow setting up a ELB trigger on new lambda function works out the gate without your branches, maybe because the headers/responses are close to the same.)

If I have time I will test out your branch later today.

There is a fair amount of similarity between the API Gateway and ALB event which can allow you to get lucky. If you enabled multi value headers or had binary data from the request body it would fail.

Branch looks good.

This looks terrific! I'm eager to see how this functionality works in action. Do we have any estimated ETA on when this can be merged and packaged up?

Really looking forward to seeing this in the official package.
I think this is the best serverless offering that you have. We would migrate most of our APIs and even web sites to this if not for the two major drawbacks being; API Gateway and the (lambda) cold start delays. This fixes one of them, and ALB health checks should help to keep lambdas alive :-)

@normj, just curious if there is any ETA on when we can expect this to be available on Nuget?

I am eagerly waiting for this feature to be included in the Nuget too.

I have tested this on my already existing application and it appears to work without issue.

Version 3.0.0 of Amazon.Lambda.AspNetCoreServer was released today with ALB support. Check out the blog post for more information. https://aws.amazon.com/blogs/developer/updates-for-serverless-asp-net-core/

@normj Great post and excellent work! Thanks for all you do to integrate .NET into the AWS ecosystem.

@ryanpagel Your welcome 😄

Closing as the feature is released.