Deploying a .NET Lambda function — the real-world guide

Dave
2 min readMay 3, 2021

I’m mostly writing this for my future self, and all those people who, like my present self, are looking for this one, niche answer.

If you’re looking to deploy a trivial, “Hello world” Lambda function from scratch using the .NET Core CLI, don’t stop here, just Google it. There are about 50,000 results for you. But if you have an existing codebase with multiple functions and you use Terraform and Azure Pipelines to deploy it, then you’re in the right place.

Install the tools

First you need the tools. Assuming you’ve already got the .NET Core installed, the following three commands should set you up (I’m using Powershell, but should be basically the same in bash, etc.):

Next you just build/package it using the CLI with the lambda tools. The following snippet includes that, along with deploying the code:

Since this lambda is in a real dev environment with actual users testing against it, I’m not making it visible to them. They access it via API Gateway, which sends requests to a certain label (`stable`). When the code is deployed, that creates a new version of the function, but that doesn’t point the integration with API Gateway to that new version. I have to do that separately.

This is great, because I don’t really want other people testing my local code; they should be running against what is merged to the trunk and deployed by a CD pipeline. Instead I use our canary label. We have a second API Gateway integration pointing to that…but I don’t even need to use that! I can explicitly invoke the new version I created. In this case I am repointing the canary label because I do want to run some automated tests against my code through API Gateway.

Just to show that I don’t need API Gateway however, the last few lines of the script invokes the function directly through the AWS CLI, sending a basic request (JSON data) that lives in a file. It returns the log stream from the request and writes the output to a file.

--

--