A developer toolkit to implement Serverless best practices and increase developer velocity.
This release adds the most requested feature ever: observability providers. You can now send custom metrics to Datadog using the same optimized development experience Powertools for AWS Lambda offers.
Also, you can now use our provided Lambda Layer in the new AWS Israel region (il-central-1).
⭐ ⭐ Huge thanks to Petar Lishov and Roger Zhang for your help!
Three years ago, we launched Powertools for AWS Lambda Python, making it easier to instrument your code with distributed tracing (Tracer), structured logging (Logger), and custom metrics (Metrics).
With the community, we’ve grown way past Observability and into several best practices, including 16 major features integrating with 15+ AWS services.
Today, we couldn’t be happier to share what we’ve been working with the community for the last 4 months. You can now switch back and forth between CloudWatch EMF and Datadog for creating custom metrics, with minimal friction.
We will continue to develop our main integration with Amazon CloudWatch EMF and AWS X-Ray. That said, this release opens up possibilities for integrating with other AWS Lambda observability partners within Powertools for AWS Lambda.
We would love to hear from you on which observability provider we should prioritize next!
33e28bd
to cd3a522
in /docs (#2859) by @dependabot33e28bd
to cd3a522
in /docs (#2859) by @dependabot@aal80, @barreeeiroo, @dependabot, @dependabot[bot], @duc00, @github-actions, @github-actions[bot], @heitorlessa, @ivica-k, @leandrodamascena, @roger-zhangg and @royassis
This release follows the newly announced Python 3.11 runtime in AWS Lambda 🚀. It also adds a revamped Batch Processing documentation, along with numerous bug fixes.
⭐ Huge thanks to new contributors: @94Sip and @duc00 for helping us improve Batch's documentation
This release adds a new error handling section, contextual information in key code snippets, and several new diagrams to improve understanding about Batch Processors and AWS Lambda Report Item Batch Failure feature.
@dependabot, @dependabot[bot], @github-actions, @github-actions[bot], @heitorlessa, @leandrodamascena, @ran-isenberg and @rubenfonseca
We are happy to announce the official support for Pydantic V2. 🚀🚀🚀🚀
This offers you the flexibility to choose between Pydantic v1 and v2 with no breaking changes. This 3-week significant effort wouldn’t be possible without many Pydantic experts from our community, and the Pydantic team for fixing a regression - thank you!!
New public reference. A big thank you to @ovahal at Jit Security.
⭐ Huge thanks to our new contributor: @tinti!
Pydantic recently released version 2, bringing a plethora of exciting improvements and enhancements.
We did an extensive research on breaking changes between v1 and v2 to provide a smooth transition, when using Powertools for AWS Lambda (Python) Parser models and envelopes.
a28ed81
to 33e28bd
in /docs (#2797) by @dependabota28ed81
to 33e28bd
in /docs (#2797) by @dependabot@dependabot, @dependabot[bot], @github-actions, @github-actions[bot], @heitorlessa, @leandrodamascena and @tinti
This release introduces signed and verifiable builds for PyPi, and a new documentation section to make our automation practices, maintainers playbook, and soon a re-imagined contributing guide more visible.
Love automation and CI/CD? We did an interview to walk through what's now documented under our new Automation section:
As of today's release, you can now publicly verify our builds came from a trusted source to further strengthen supply chain security. We created a new Security section in our documentation with steps you can take to verify releases.
You can skip this part if you're not interested in the supply chain security space
For the past few months, we've been working hard to improve our operational and security posture. The biggest chunk of work was introducing Open Source Security Foundation (OSSF) Scorecard project to generate security health metrics, proactive security alerts, and attest we've been following OSSF Best Practices.
We couldn't be happier with the results.
Through the research, we've learned about SLSA as a framework to produce verifiable reproducible builds within our release pipeline. This enables our more security conscious customers to guarantee our releases came from this repository and every step can be publicly traced back.
Provenance step within our release pipeline to attest its reproducibility and authenticity
3837c0f
to a28ed81
in /docs (#2669) by @dependabot3837c0f
to a28ed81
in /docs (#2669) by @dependabot@dependabot, @dependabot[bot], @github-actions, @github-actions[bot], @heitorlessa, @leandrodamascena, @roger-zhangg, @step-security-bot and @sthulb
In this new release we added:
⭐ Huge thanks to our new contributor: @rafaelgsr!
Docs: event handler, parser
Amazon VPC Lattice is a fully managed application networking service that you use to connect, secure, and monitor the services for your application across multiple accounts and virtual private clouds (VPC). You can register your Lambda functions as targets with a VPC Lattice target group, and configure a listener rule to forward requests to the target group for your Lambda function.
We have added support for handling events from Amazon VPC Lattice in the event handler, using the same API as existing event handlers. This includes important functionalities like CORS support and response header serialization.
In addition, we added the corresponding Pydantic Parser model for the VPC Lattice event:
SQS events can encapsulate events originated in other AWS resources, such as S3 and SNS. To improve the experience when creating Lambda functions to handle those events, we created a new method to decoded those nested events easily. For instance, this is how you access the nested S3 event from an SQS event:
@dependabot, @dependabot[bot], @github-actions, @github-actions[bot], @hjgraca, @leandrodamascena, @rafaelgsr, @ran-isenberg and @rubenfonseca
This release adds support for A/B testing in Feature Flags, and the ability to enable/disable compression for custom responses in Event Handler.
:star: Huge thanks to our new contributor: @ajwad-shaikh
You can now run experiments on a percentage of customers (e.g., A/B testing) with the new MODULE_RANGE
action.
You can now enable GZIP compression with custom responses. This is useful when you only want to compress certain responses, or override compression for non-200 HTTP status code.
@ajwad-shaikh, @dependabot, @dependabot[bot], @github-actions, @github-actions[bot], @heitorlessa, @hjgraca, @leandrodamascena and @sthulb
This release is full of new features and important bug fixes:
⭐ Huge thanks to new contributors: @abbasyadollahi @erikayao93 and @stephenbawks!
We now handle scenarios where the idempotency key might be optional by skipping the persistence storage layer operations (CRUD).
Here’s an example where uniqueness is dictated by X-Idempotency-Key
header, but it might be optional:
Imagine we have three disctinct requests, where the headers
key looks like this:
{"headers": {"X-Idempotency-Key": "7ca32179-f88f..."}}
{"headers": {}}
{"headers": {}}
With this fix, the first request will follow the current idempotency mechanism while the second and third request will not trigger any idempotency mechanism to prevent unwanted side effects (e.g., idempotency key of None is hashed).
We made a significant change in the way routes are matched on the event handler by giving priority to the most specific routes.
Consider the following code:
With this fix, a GET request to /studies/fetch
will now match the fetch_studies
handler, even though it was declared last.
We made it easier to work with events comming from Amazon VPC Lattice and AWS Config Rules.
@abbasyadollahi, @dependabot, @dependabot[bot], @erikayao93, @github-actions, @github-actions[bot], @heitorlessa, @leandrodamascena, @ran-isenberg, @rubenfonseca and @stephenbawks
This patch release primarily address a regression for custom builds that remove METADATA
directory from installations, e.g., Serverless Framework with python-requirements
plugin.
We have switched to bumping versions statically as of this release - SAM, CDK, Console, and Layer customers weren't affected.
Huge thanks to @bronzeson for reporting it, and @CJTurpie for reproducing it with Serverless framework plugin.
@dependabot, @dependabot[bot], @github-actions, @github-actions[bot], @heitorlessa and @leandrodamascena
We packed this release with a bunch of new features and performance improvements:
CodePipelineJobEvent
event source
⭐ Huge thanks to new contributors: @roger-zhangg and @darnley!!
Docs: Multiple CORS origins
We added support for multiple origins in CORS when defining an event handler. Supporting multiple CORS origins enables API calls from different domains and the integration of various sources. Your existing code will continue to work as it is.
SQS event notifications can sometimes be ingested into Lambda via an intermediary such as Kinesis Firehose (i.e. Lambda event source), for various architectural reasons - batching, retries, etc. However, from the Lambda function's perspective, the intermediary might not be too important; what's important is the SQS event notification itself. Now you can easily parse and access the inner payload for Kinesis Firehose-wrapped SQS events.
CodePipelineJobEvent
event sourceThanks to @darnley, we found out that using the CodePipelineJobEvent
came with a performance penalty, and we fixed it by optimizing the way we load dependencies.
We've completely revamped and fine-tuned all the samples and snippets for our Feature Flags and Batch Processing utilities! We took the time to bring the examples closer to real-world usage and fixed any syntax errors. We can't wait for you to try them out!
@darnley, @dependabot, @dependabot[bot], @github-actions, @github-actions[bot], @heitorlessa, @leandrodamascena, @roger-zhangg, @rubenfonseca, @sthulb and Release bot
This release is packed with a number of improvements:
And… a ton of documentation improvements.
⭐ Huge thanks to new contributors: @theipster (S3 events), @neilramsay (Data Class debug), @arjanschaaf (Batch docs) and @leif-ye (API Gateway Event Source)
Docs: Observability providers
You can now send logs to the observability provider of your choice via Lambda Extensions
. In most cases, you shouldn't need any custom Logger configuration, and logs will be shipped asynchronously with no performance impact.
Docs: Built-in envelopes, Parser
S3 event notifications can be sometimes be ingested into Lambda via an intermediary such as an SQS queue (i.e. Lambda event source), for various architectural reasons - batching, retries, etc. However, from the Lambda function's perspective, the intermediary might not be too important; what's important is the S3 event notification itself. Now you can easily parse and access the inner payload for SQS-wrapper S3 events.
Docs: Debugging
You can now print out the fields of a data class instance to obtain more information. All classes come with a __str__
method that generates a dictionary string which can be quite useful for debugging. Sensitive fields such as secret_access_key
and session_token
, are labeled as [SENSITIVE]
, to prevent any accidental disclosure of confidential information.
You can now manually flush the metrics at any time. This is useful when not running within a standard Lambda handler (e.g: Lambda Web Adapter), where the @log_metrics
decorator does not work as intended.
@arjanschaaf, @dependabot, @dependabot[bot], @heitorlessa, @leandrodamascena, @leif-ye, @neilramsay, @rubenfonseca, @theipster and Release bot