Skip to content

Powertools for AWS Lambda (.NET)

Powertools for AWS Lambda (.NET) (which from here will be referred as Powertools) is a suite of utilities for AWS Lambda functions to ease adopting best practices such as tracing, structured logging, custom metrics, and more.

Info

Supports .NET 6 and .NET 8 runtimes

Tip

Powertools is also available for Python, Java, and TypeScript.

Support this project by becoming a reference customer or sharing your work ❤

You can choose to support us in three ways:

1) Become a reference customers. This gives us permission to list your company in our documentation.

2) Share your work. Blog posts, video, sample projects you used Powertools!

Features

Core utilities such as Tracing, Logging, and Metrics will be available across all Powertools for AWS Lambda languages. Additional utilities are subjective to each language ecosystem and customer demand.

Utility Description
Tracing Decorators and utilities to trace Lambda function handlers, and both synchronous and asynchronous functions
Logger Structured logging made easier, and decorator to enrich structured logging with key Lambda context details
Metrics Custom AWS metrics created asynchronously via CloudWatch Embedded Metric Format (EMF)
Parameters provides high-level functionality to retrieve one or multiple parameter values from AWS Systems Manager Parameter Store, AWS Secrets Manager, or Amazon DynamoDB. We also provide extensibility to bring your own providers.
Idempotency The idempotency utility provides a simple solution to convert your Lambda functions into idempotent operations which are safe to retry.
Batch Processing The batch processing utility handles partial failures when processing batches from Amazon SQS, Amazon Kinesis Data Streams, and Amazon DynamoDB Streams.

Install

Powertools for AWS Lambda (.NET) is available as NuGet packages. You can install the packages from NuGet gallery or from Visual Studio editor. Search AWS.Lambda.Powertools* to see various utilities available.

Using SAM CLI template

We have provided you with a custom template for the Serverless Application Model (AWS SAM) command-line interface (CLI). This generates a starter project that allows you to interactively choose the Powertools for AWS Lambda (.NET) features that enables you to include in your project.

To use the SAM CLI, you need the following tools.

Once you have SAM CLI installed, follow the these steps to initialize a .NET 6 project using Powertools for AWS (.NET)

  1. Run the following command in your command line 
    1
    sam init -r dotnet6

  2. Select option 1 as your template source

    1
2
3
    Which template source would you like to use?
    1 - AWS Quick Start Templates
    2 - Custom Template Location
    3. Select the Hello World Example with Powertools for AWS Lambda template

    1
2
3
4
5
6
7
8
9
    Choose an AWS Quick Start application template
    1 - Hello World Example
    2 - Data processing
    3 - Hello World Example with Powertools for AWS Lambda
    4 - Multi-step workflow
    5 - Scheduled task
    6 - Standalone function
    7 - Serverless API
Template: 3

  3. Follow the rest of the prompts and give your project a name

Viola! You now have a SAM application pre-configured with Powertools!

Examples

We have provided a few examples that should you how to use the each of the core Powertools for AWS Lambda (.NET) features.

Connect

  • Powertools for AWS Lambda (.NET) on Discord: #dotnet - Invite link
  • Email: aws-lambda-powertools-feedback@amazon.com

Tenets

These are our core principles to guide our decision making.

  • AWS Lambda only. We optimize for AWS Lambda function environments and supported runtimes only. Utilities might work with web frameworks and non-Lambda environments, though they are not officially supported.
  • Eases the adoption of best practices. The main priority of the utilities is to facilitate best practices adoption, as defined in the AWS Well-Architected Serverless Lens; all other functionality is optional.
  • Keep it lean. Additional dependencies are carefully considered for security and ease of maintenance, and prevent negatively impacting startup time.
  • We strive for backwards compatibility. New features and changes should keep backwards compatibility. If a breaking change cannot be avoided, the deprecation and migration process should be clearly defined.
  • We work backwards from the community. We aim to strike a balance of what would work best for 80% of customers. Emerging practices are considered and discussed via Requests for Comment (RFCs)
  • Idiomatic. Utilities follow programming language idioms and language-specific best practices.