Homepage
A suite of utilities for AWS Lambda functions to ease adopting best practices such as tracing, structured logging, custom metrics, idempotency, batching, and more.
Tip: Looking for a quick read through how the core features are used?
Check out this detailed blog post with a practical example.
Install¶
Powertools is available in the following formats:
- Lambda Layer: arn:aws:lambda:{region}:017000801446:layer:AWSLambdaPowertoolsPython:21
- PyPi:
pip install aws-lambda-powertools
Support this project by using Lambda Layers
Lambda Layers allow us to understand who uses this library in a non-intrusive way. This helps us justify and gain future investments for other Lambda Powertools languages.
When using Layers, you can add Lambda Powertools as a dev dependency (or as part of your virtual env) to not impact the development process.
Lambda Layer¶
Lambda Layer is a .zip file archive that can contain additional code, pre-packaged dependencies, data, or configuration files. Layers promote code sharing and separation of responsibilities so that you can iterate faster on writing business logic.
You can include Lambda Powertools Lambda Layer using AWS Lambda Console, or your preferred deployment framework.
Note: Expand to copy any regional Lambda Layer ARN
Can't find our Lambda Layer for your preferred AWS region?
You can use Serverless Application Repository (SAR) method, our CDK Layer Construct, or PyPi like you normally would for any other library.
Please do file a feature request with the region you'd want us to prioritize making our Lambda Layer available.
1 2 3 4 5 |
|
1 2 3 4 5 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
Change {region} to your AWS region, e.g. eu-west-1
AWS CLI | |
---|---|
1 |
|
The pre-signed URL to download this Lambda Layer will be within Location
key.
Warning: Limitations
Container Image deployment (OCI) or inline Lambda functions do not support Lambda Layers.
Lambda Powertools Lambda Layer do not include pydantic
library - required dependency for the parser
utility. See SAR option instead.
SAR¶
Serverless Application Repository (SAR) App deploys a CloudFormation stack with a copy of our Lambda Layer in your AWS account and region.
Despite having more steps compared to the public Layer ARN option, the benefit is that you can specify a semantic version you want to use.
App | ARN | Description |
---|---|---|
aws-lambda-powertools-python-layer | arn:aws:serverlessrepo:eu-west-1:057560766410:applications/aws-lambda-powertools-python-layer | Core dependencies only; sufficient for nearly all utilities. |
aws-lambda-powertools-python-layer-extras | arn:aws:serverlessrepo:eu-west-1:057560766410:applications/aws-lambda-powertools-python-layer-extras | Core plus extra dependencies such as pydantic that is required by parser utility. |
Warning
Layer-extras does not support Python 3.6 runtime. This layer also includes all extra dependencies: 22.4MB zipped
, ~155MB unzipped
.
Tip
You can create a shared Lambda Layers stack and make this along with other account level layers stack.
If using SAM, you can include this SAR App as part of your shared Layers stack, and lock to a specific semantic version. Once deployed, it'll be available across the account this is deployed to.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
|
Credits to Dani Comnea for providing the Terraform equivalent.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
|
Example: Least-privileged IAM permissions to deploy Layer
Credits to mwarkentin for providing the scoped down IAM permissions.
The region and the account id for CloudFormationTransform
and GetCfnTemplate
are fixed.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
|
You can fetch available versions via SAR ListApplicationVersions API:
AWS CLI example | |
---|---|
1 2 |
|
Quick getting started¶
Hello world example using SAM CLI | |
---|---|
1 |
|
Features¶
Core utilities such as Tracing, Logging, Metrics, and Event Handler will be available across all Lambda Powertools 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 Metrics created asynchronously via CloudWatch Embedded Metric Format (EMF) |
Event handler: AppSync | AppSync event handler for Lambda Direct Resolver and Amplify GraphQL Transformer function |
Event handler: API Gateway and ALB | Amazon API Gateway REST/HTTP API and ALB event handler for Lambda functions invoked using Proxy integration |
Middleware factory | Decorator factory to create your own middleware to run logic before, and after each Lambda invocation |
Parameters | Retrieve parameter values from AWS Systems Manager Parameter Store, AWS Secrets Manager, or Amazon DynamoDB, and cache them for a specific amount of time |
Batch processing | Handle partial failures for AWS SQS batch processing |
Typing | Static typing classes to speedup development in your IDE |
Validation | JSON Schema validator for inbound events and responses |
Event source data classes | Data classes describing the schema of common Lambda event triggers |
Parser | Data parsing and deep validation using Pydantic |
Idempotency | Idempotent Lambda handler |
Feature Flags | A simple rule engine to evaluate when one or multiple features should be enabled depending on the input |
Environment variables¶
Info
Explicit parameters take precedence over environment variables
Environment variable | Description | Utility | Default |
---|---|---|---|
POWERTOOLS_SERVICE_NAME | Sets service name used for tracing namespace, metrics dimension and structured logging | All | "service_undefined" |
POWERTOOLS_METRICS_NAMESPACE | Sets namespace used for metrics | Metrics | None |
POWERTOOLS_TRACE_DISABLED | Explicitly disables tracing | Tracing | false |
POWERTOOLS_TRACER_CAPTURE_RESPONSE | Captures Lambda or method return as metadata. | Tracing | true |
POWERTOOLS_TRACER_CAPTURE_ERROR | Captures Lambda or method exception as metadata. | Tracing | true |
POWERTOOLS_TRACE_MIDDLEWARES | Creates sub-segment for each custom middleware | Middleware factory | false |
POWERTOOLS_LOGGER_LOG_EVENT | Logs incoming event | Logging | false |
POWERTOOLS_LOGGER_SAMPLE_RATE | Debug log sampling | Logging | 0 |
POWERTOOLS_LOG_DEDUPLICATION_DISABLED | Disables log deduplication filter protection to use Pytest Live Log feature | Logging | false |
POWERTOOLS_EVENT_HANDLER_DEBUG | Enables debugging mode for event handler | Event Handler | false |
LOG_LEVEL | Sets logging level | Logging | INFO |
Debug mode¶
As a best practice, AWS Lambda Powertools module logging statements are suppressed. If necessary, you can enable debugging using set_package_logger
for additional information on every internal operation:
Powertools debug mode example | |
---|---|
1 2 3 |
|
- this will configure our
aws_lambda_powertools
logger with debug.
Tenets¶
These are our core principles to guide our decision making.
- AWS Lambda only. We optimise 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)
- Progressive. Utilities are designed to be incrementally adoptable for customers at any stage of their Serverless journey. They follow language idioms and their communityβs common practices.