In this post we will cover how we make our microservices in Lambda available to API consumers via HTTP both internally and externally.
The first thing you need to understand is a Lambda is not accessible via HTTP by default, you have to configure some form of HTTP endpoint that will route to the Lambda. You can configure many different types of triggers from the console:
AWS API Gateway
When we first started designing our new architecture in late 2018 the API Gateway was the best option for providing an HTTP endpoint to a Lambda. API Gateway is especially useful if you need to secure and throttle access to your API. Its perfect for external users. These additional features come at a higher cost as you would expect.
To configure your ASP.NET Core service code for API Gateway in C#, you want to use the Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction base class for your Lambda entry point class and use the host builder to initialize the LambdaServer with your Startup class.
Then in your the Lambda console you can configure the Handler to point to the FunctionHandlerAsync method on your entry point class. This method is provided in the APIGatewayProxyFunction base class.
Lastly, add your API Gateway trigger:
I won’t dive into all they ways you can configure and use API Gateway in this post but you can learn more in the AWS documentation.
You can now hit your ASP.NET Core application via the HTTP endpoint configured in API Gateway.
AWS Application Load Balancer
ALB was later released to make adding HTTP endpoints for Lambda easier and cheaper. You can configure the endpoint for internal or external use cases.
You can also use the console to setup an ALB trigger:
From a code perspective you will want to use the Amazon.Lambda.AspNetCoreServer.ApplicationLoadBalancerFunction base class instead. You can create multiple entry point classes in you ASP.NET Core project if you want to trigger by API Gateway and ALB.
Our Usage
In our architecture, we leverage API Gateway for any services that need to be accessed over the internet by external users. This allows us to secure the endpoint so only the intended consumers can access it. There are multiple authentication options you can configure for you API.
We also throttle API usage in API Gateway so each customer has the appropriate number of calls to the API and no one consumer can use all available resources. This means we can charge consumers for more access.
As mentioned earlier we used API Gateway initially for all our HTTP triggering of Lambda. We quickly found this was going to get expensive. In addition, the vast majority of our service calls were performed inside our virtual network by internal services which didn’t need all the features of API Gateway. So we were very excited to try ALB for Lambda when it was released.
We have since migrated all our internal services to ALB which reduced our AWS bill and also make the network routing more efficient because the internal service calls stay inside our virtual network instead of routing out to the internet and back in through API Gateway.
Overall, we are very pleased with our final architecture leveraging both services to provide appropriate HTTP routing/access to our Lambdas.
If you found this post helpful and/or you have further questions please leave a comment below.
Happing HTTP Routing!