Serverless applications in .NET are growing in popularity thanks to AWS Lambda’s support for .NET 6, .NET 7, and now .NET 8. But building, testing, and deploying these applications manually can be time-consuming and error-prone. That’s where CI/CD pipelines come in. In this post, we’ll walk through how to set up a CI/CD pipeline using GitHub Actions to build, test, and deploy .NET AWS Lambda functions automatically.

Prerequisites To Follow

Along, You’ll Need A .NET Lambda project (for example, created with dotnet new lambda.EmptyFunction)

An AWS account with IAM credentials

AWS CLI installed locally (for initial setup)

An S3 bucket to store deployment artifacts (optional)

The AWS CLI and Amazon.Lambda.Tools installed: dotnet tool install -g Amazon.Lambda.Tools Project Structure Let’s Assume The Following Structure MyLambdaFunction/ ├── src/ │ └── MyLambdaFunction/ ├── tests/ │ └── MyLambdaFunction.Tests/ ├── .github/ │ └── workflows/ │ └── deploy.yml Step 1: Create a GitHub Actions Workflow Create The File .github/workflows/deploy.yml name: CI/CD for .NET Lambda on: push: branches:

- main jobs: build-test-deploy: runs-on: ubuntu-latest steps:
- name: Checkout code uses: actions/checkout@v4 - name: Setup .NET uses: actions/setup-dotnet@v4 with: dotnet-version: '8.x' - name: Restore dependencies run: dotnet restore - name: Build run: dotnet build --configuration Release --no-restore - name: Run tests run: dotnet test --no-build --verbosity normal - name: Get Lambda Role ARN from SSM id: ssm run: | ROLE_ARN=$(aws ssm get-parameter --name "/lambda/MyLambdaFunction/RoleArn" --query "Parameter.Value" --output text) echo "role_arn=$ROLE_ARN" >> $GITHUB_OUTPUT env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY:



${{ secrets.AWS_SECRET_ACCESS_KEY }} AWS_REGION: us-east-1 - name: Deploy to AWS Lambda env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} AWS_REGION: us-east-1 run: | cd src/MyLambdaFunction dotnet lambda deploy-function MyLambdaFunction --region $AWS_REGION --function-role ${{ steps.ssm.outputs.role_arn }} Step 2: Set Up AWS Credentials for GitHub Actions To securely authenticate your GitHub Actions workflow with AWS, you need to create an IAM user and store its access keys as GitHub secrets. Create an IAM User in AWS Sign in to the AWS Console

Go to IAM > Users > Add users

Choose a username (e.g., github-actions-deploy)

Enable Programmatic access

Attach the AWSLambdaFullAccess policy or a custom policy with only necessary permissions

Save the Access Key ID and Secret Access Key Add Secrets to GitHub In your GitHub repo, go to Settings > Secrets and variables > Actions

Add the following secrets

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

Step 3: Use SSM Parameters to Avoid Manual Setup You can avoid hardcoding values like the Lambda role ARN in your workflow by storing them in AWS Systems Manager (SSM) Parameter Store.

Store Required





Values in SSM Run This Command Locally To Store The Role ARN aws ssm put-parameter --name "/lambda/MyLambdaFunction/RoleArn" --type String --value "arn:aws:iam:::role/" Your GitHub Actions workflow can then retrieve this value dynamically before deployment. Step 4: Do You Still Need Manual Deployment? Yes, unless you ensure everything required for the deployment is pre-configured.

Here's why: The dotnet lambda deploy-function command creates the Lambda function if it doesn't exist, but requires details like the function role, memory size, etc.

If any required input is missing or the IAM role is misconfigured, the deployment will fail.

GitHub Actions is non-interactive, so any CLI prompts will break the pipeline.

When Manual

First-Time Deployment is Needed You Should Deploy Manually The First Time If The Lambda function does not yet exist

You haven't scripted or automated the full configuration cd src/MyLambdaFunction dotnet lambda deploy-function MyLambdaFunction This confirms that the function, role, region, and permissions are all set up correctly.

When You Can Skip Manual Deployment

You Can Skip It If The Lambda function and IAM role already exist

You’ve stored the function role in SSM and reference it in your workflow

You pass all required CLI arguments directly in the workflow This approach makes your pipeline truly hands-off from the beginning.

Conclusion With This Setup

Every push to the main branch triggers your CI/CD pipeline The pipeline builds, tests, and deploys your Lambda function

SSM parameters allow dynamic configuration without hardcoding

Manual setup can be avoided if resources are pre-provisioned This makes your Lambda deployments consistent, automated, and production-ready. References AWS Lambda Tools for .NET CLI

GitHub Actions Documentation

AWS CLI Configuration

AWS Systems Manager Parameter Store

Deploying Lambda with dotnet CLI

📌 CI/CD Pipeline for .NET Lambdas Using GitHub Actions (Jun)
🏢 Renato Gonçalves
📍 Jun