NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
PyPI · #975 most downloaded on PyPI
Powertools for AWS Lambda (Python) is a developer toolkit to implement Serverless best practices and increase developer velocity.
Last release 19 days ago
15 Sep 2026
Ships fairly regularly
a new release about every 3 weeks
Nearly every release is documented
notes for 58 of the last 60 stable releases
3 versions withdrawn
withdrawn after publishing
7 years old
530 releases · first in 2019
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
One column per quarter.
This release improves the OpenAPI utility, letting customers distinguish between request and response validation errors. It also adds support for API
This release improves the OpenAPI utility, letting customers distinguish between request and response validation errors. It also adds support for API Gateway WebSocket in the Event Source Data Class utility.
Thanks to @ericbn, we simplified the Event Source Data Class utility code, making it more readable and easier to maintain.
⭐ A huge thanks to our new contributor: @amin-farjadi.
Customers can now customize response validation errors to be clearly identified.
Previously, both request and response validation failures triggered the same RequestValidationError, making debugging difficult. Response validation now raises a specific ResponseValidationError, helping you quickly identify validation issues. This is useful to both detect and handle these types of errors more easily.
You can now use the APIGatewayWebSocketEvent data class when working with WebSocket API events. This simplifies handling of API Gateway WebSocket events by providing better type completion in IDEs and easy access to event properties.
DD_FLUSH_TO_LOG env var (#6280) by @leandrodamascenaDD_FLUSH_TO_LOG env var (#6280) by @leandrodamascena479a06a to f226a2d in /docs (#6279) by @dependabot[bot]047452c to 479a06a in /docs (#6261) by @dependabot[bot]@ChristophrK, @amin-farjadi, @basvandriel, @dependabot[bot], @ericbn, @github-actions[bot], @leandrodamascena, dependabot[bot] and github-actions[bot]
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
We are excited to announce a new feature in Logger: Logger buffering. This new feature allows you to buffer logs for a specific invocation, and flush
We are excited to announce a new feature in Logger: Logger buffering. This new feature allows you to buffer logs for a specific invocation, and flush them automatically on error or manually as needed.
A special thanks to Ollie Saul and James Saull from Dotelastic for their instrumental input on this new feature!
⭐ Also, huge thanks to our new contributors: @tiagohconte and @speshak.
You can now enable log buffering by passing buffer_config when initializing a new Logger instance. This feature allows you to:
WARNING, INFO, and DEBUG levels| Option | Description | Default |
|---|---|---|
max_bytes |
Maximum size of the buffer in bytes | 20480 |
buffer_at_verbosity |
Minimum log level to buffer (more verbose levels are also buffered) | DEBUG |
flush_on_error_log |
Whether to flush buffer when an error is logged | True |
When log buffering is enabled, you can now pass a new opt-in flush_buffer_on_uncaught_error flag to the inject_lambda_context() decorator. When enabled, 1/ we'll intercept any raised exception, 2/ flush the buffer, and 3/ re-raise your original exception. This enables you to have detailed logs from your application when you need them the most.
For detailed explanations with diagrams, please refer to our comprehensive documentation.
Q: Does the buffer persist across Lambda invocations? A: No, each Lambda invocation has its own buffer. The buffer is initialized when the Lambda function is invoked and is cleared after the function execution completes or when flushed manually.
Q: Are my logs buffered during cold starts? A: No. We never buffer logs during cold starts to ensure all logs from this phase are immediately available for debugging.
Q: How can I prevent log buffering from consuming excessive memory?
A: You can limit the size of the buffer by setting the max_bytes option in the LoggerBufferConfig constructor parameter. This will ensure that the buffer does not grow indefinitely and consume excessive memory.
Q: What happens if the log buffer reaches its maximum size? A: Older logs are removed from the buffer to make room for new logs. This means that if the buffer is full, you may lose some logs if they are not flushed before the buffer reaches its maximum size. When this happens, we emit a warning when flushing the buffer to indicate that some logs have been dropped.
Q: What timestamp is used when I flush the logs? A: The timestamp preserves the original time when the log record was created. If you create a log record at 11:00:10 and flush it at 11:00:25, the log line will retain its original timestamp of 11:00:10.
Q: What happens if I try to add a log line that is bigger than max buffer size? A: The log will be emitted directly to standard output and not buffered. When this happens, we emit a warning to indicate that the log line was too big to be buffered.
Q: What happens if Lambda times out without flushing the buffer?
A: Logs that are still in the buffer will be lost. If you are using the log buffer to log asynchronously, you should ensure that the buffer is flushed before the Lambda function times out. You can do this by calling the logger.flush_buffer() method at the end of your Lambda function.
Q: Do child loggers inherit the buffer? A: No, child loggers do not inherit the buffer from their parent logger but only the buffer configuration. This means that if you create a child logger, it will have its own buffer and will not share the buffer with the parent logger.
2615302 to 047452c in /docs (#6210) by @dependabot[bot]@dependabot[bot], @github-actions[bot], @leandrodamascena, @speshak, @tiagohconte, dependabot[bot] and github-actions[bot]
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
IoTCoreThingTypeEvent - For Thing Type Created/Updated/Deprecated/Deleted events
In this release, we are thrilled to announce new features and improvements:
We also fixed a bug in the Logger utility's custom handlers and expanded Lambda layer support to Thailand (ap-southeast-7) and Mexico Central (mx-central-1) regions.
⭐ Huge thanks to our new contributors: @basvandriel and @DKurilo
We have improved the Parser utility by adding support for events from IoT Core Registry Events
Here are all the models we have added for IoT Core Registry Events:
You can now include specific examples of parameter values directly in the schema objects. These examples are rendered in API documentation tools like SwaggerUI and provide a better experience when reading the OpenAPI schema.
Customers can now rely on a correct logger handler selection in compute environments or custom setups where a standard logging logger shares the same name as a Powertools logger.
sourceIPAddress and sequencer fields in S3RecordModel Model (#6154) by @DKurilof5bcec4 to 2615302 in /docs (#6135) by @dependabot[bot]c62453b to f5bcec4 in /docs (#6087) by @dependabot[bot]@DKurilo, @anafalcao, @basvandriel, @dependabot[bot], @github-actions[bot], @hjgraca, @leandrodamascena, dependabot[bot] and github-actions[bot]
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
In this release, we are thrilled to announce new features and improvements:
In this release, we are thrilled to announce new features and improvements:
Special thanks to @philiptzou, for improving type annotations in our OpenAPI utility! ⭐
You can now configure advanced masking options when using erase method in the Data Masking utility. This feature provides granular control to protect sensitive information while maintaining data readability and structure.
The new options to use with erase :
*You can now set the POWERTOOLS_METRICS_DISABLES environment variable to control the metrics output. This is useful when you want to silent metrics in a non-production environment. When POWERTOOLS_DEV is enabled, the metrics are also suppressed, but you can always override it by setting POWERTOOLS_METRICS_DISABLED=false when you want to continue emitting metrics while in dev mode.
You can now use the new APIGatewayAuthorizerResponseWebSocket class to handle authorization policies for WebSocket APIs.
clear_state() methodWe have added a new clear_state() to Logger to easily remove any temporary keys you have added. This is useful when you add multiple custom keys conditionally or when you emit canonical or wide logs.
7e841df to c62453b in /docs (#6052) by @dependabot[bot]471695f to 7e841df in /docs (#6012) by @dependabot[bot]41942f7 to 471695f in /docs (#5979) by @dependabot[bot]@anafalcao, @dependabot[bot], @dreamorosi, @github-actions[bot], @leandrodamascena, @philiptzou, dependabot[bot] and github-actions[bot]
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
We're excited to introduce new features and improvements in this release:
We're excited to introduce new features and improvements in this release:
We also revamped the Data Source event class documentation and now we have more complete examples.
Thanks to @xdxindustries for helping us resolve a bug with OpenAPI and Pydantic Models' forward references.
⭐ Huge thanks to our new contributors: @kattakaha and @AlphaWong!
We've introduced new Event Source Data Classes to simplify custom identity provider authorizations in AWS Transfer Family, streamlining the process of constructing authorization responses for Lambda-based custom authorizers.
TransferFamilyAuthorizer: Converts incoming events into structured objectsTransferFamilyAuthorizerResponse: Facilitates building standardized authorization responsesThe @idempotent_function and @idempotent decorators now support an optional key_prefix parameter, allowing you to define custom prefixes for idempotency keys. With this feature, you can implement cross-function idempotency, group related operations under a common prefix, and ensure your idempotency records remain stable during code refactoring or Lambda function renaming.
It allows you to override the default idempotency key prefix, which is typically a combination of Lambda function, module, and decorated function names. By specifying a custom prefix, you gain more control over the idempotency key structure.
The Logger utility now includes an append_context_keys context manager, allowing temporary addition of keys to the logger’s context within a with statement. This simplifies the process of adding contextual information to logs in specific code blocks.
fronzen_openapi_extensions (#5929) by @kattakahapyproject.toml fully compatible with Poetryv2 (#5902) by @leandrodamascenaba73db5 to 41942f7 in /docs (#5890) by @dependabot@AlphaWong, @anafalcao, @dependabot, @dependabot[bot], @github-actions, @github-actions[bot], @kattakaha, @leandrodamascena and @xdxindustries
Nothing published for this version
Nothing published for this version
In this release we fixed a bug in the Idempotency utility when using Optional types in output serialization.
In this release we fixed a bug in the Idempotency utility when using Optional types in output serialization.
🌟 ⭐ Thanks for @TonySherman for reporting this issue.
Customers can now use Optional type when serializing Idempotency response. Previously, using Optional types in Idempotency serialization with Pydantic or Dataclasses caused serialization exception.
And last but not least, thanks to @aminalaee for reporting a bug in the resolver field naming in AppSync!
@anafalcao, @dependabot, @dependabot[bot], @github-actions, @github-actions[bot], @heitorlessa and @leandrodamascena
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →