Overview

Our public roadmap outlines the high level direction we are working towards. We update this document when our priorities change: security and stability are our top priority.

See our current iteration cycle for the most up-to-date information.

Key areas

Security and operational excellence take precedence above all else. This means bug fixing, stability, customer's support, and internal compliance may delay one or more key areas below.

Missing something or want us to prioritize an existing area?

You can help us prioritize by upvoting existing feature requests, leaving a comment on what use cases it could unblock for you, and by joining our discussions on Discord.

Observability providers

We want to extend Tracer, Metrics, and Logger to support any AWS Lambda certified observability partner, along with OpenTelemetry.

At launch, we will support Datadog since it's most requested observability provider. OpenTelemetry will be a fast follow-up as we need to decide on a stable solution to cold start penalty.

Help us identify which observability providers we should integrate next. Open feature request or by voting +1 in existing issues

Major updates

• Document how customers can use any provider with Logger
• Extend Metrics to add support for any Provider
• Extend Tracer to add support for any Provider
• Investigate alternative solution to OpenTelemetry cold start performance

Lambda Layer in GovCloud

We want to investigate security and scaling requirements for these special regions, so they're in sync for every release.

Help us prioritize it by reaching out to your AWS representatives or via email.

Major updates

• Gather agencies and customers name to prioritize it
• Investigate security requirements for special regions
• Create additional infrastructure for special regions
• AppSec review
• Update CDK Layer construct to include regions
• Distribution sign-off
• Distribute latest version
• Update Layer section with new AWS Accounts

V3

We are in the process of planning the roadmap for v3. As always, our approach includes providing sufficient advance notice, a comprehensive upgrade guide, and minimizing breaking changes to facilitate a smooth transition (e.g., it took ~7 months from v2 to surpass v1 downloads).

For example, these are on our mind but not settled yet until we have a public tracker to discuss what these means in detail.

• Parser: Drop Pydantic v1
• Parser: Deserialize Amazon DynamoDB data types automatically (like Event Source Data Classes)
• Parameters: Increase default max_age for get_secret
• Event Source Data Classes: Return sane defaults for any property that has Optional[<type>] returns
• Batch: Stop at first error for Amazon DynamoDB Streams and Amazon Kinesis Data Streams (e.g., stop_on_failure=True)

Major updates

• Create an issue to track breaking changes we consider making
• Create a v3 branch to allow early experimentation
• Create workflows to allow pre-releases
• Create a mechanism to keep ideas for breaking change somewhere regardless of v3

Revamp Event Handler

Event Handler provides lightweight routing for both REST: Amazon API Gateway, Amazon Elastic Load Balancer and AWS Lambda Function URL, and GraphQL: AWS AppSync.

Based on customers feedback, we want to provide middleware authoring support for cross-cutting concerns. For REST APIs, we are also looking into auto-generate OpenAPI Schemas and a SwaggerUI route. For GraphQL, we are working on supporting batch invocations (N+1 problem) along with partial failure support.

Major updates

• Agree on experience for middleware support
• RFC to outline initial thoughts on OpenAPI integration
• MVP for REST middleware
• MVP for OpenAPI and SwaggerUI
• MVP for AppSync Batch invoke and partial failure support

Authentication (SigV4)

During customers interview, we hear that signing requests using AWS SigV4 could be easier.

Since JWT is a close second, this new utility would cover higher level functions to sign and verify requests more easily.

Major updates

• Issue to outline challenges, alternative solutions and desired experience
• MVP for AWS SigV4

Office hours

We heard from customers that Powertools for AWS Lambda and its community can move faster than they are able to catch up. While documentation and release notes take these into account, they notice they don't always know advanced tricks, or what other customers tend to do in similar situations.

We want to run a monthly office hours to start addressing that, and learn from customers how they're using Powertools and whether or not they need a closer support.

Timezones being tricky, we plan to experiment with an afternoon slot in Central European that would also cover Middle East, US east coast, and South America. Depending on attendance, we plan to A/B test an Asia friendly one too.

Major updates

• Decide whether to use Amazon Chime or Zoom (we had audio setup issues on Discord)
• Experiment running monthly roadmap review as an open call
  • Settle on monthly roadmap review agenda
  • Invite Discord community
  • Update roadmap page with Discord event

Enhanced operational metrics

Through customers interview, Discord, and 1:1 customer enablement, we noticed customers often create the same set of custom operational metrics.

We want to make this easier by extending certain utilities to accept a metrics instance and metrics configuration (what metrics to create). It would be opt-in due to costs associated with creating metrics.

Got ideas for custom metrics? Open up a feature request

Major updates

• RFC to outline metrics for Batch (e.g., Failed items, Batch size)
• RFC to outline metrics for Feature flags (e.g., matched rules)
• RFC to outline metrics for Event Handler (e.g., validation errors )
• RFC to outline metrics for Idempotency (e.g., cache hit)

Roadmap status definition

graph LR
    Ideas --> Backlog --> Work["Working on it"] --> Merged["Coming soon"] --> Shipped

Visual representation

Within our public board, you'll see the following values in the Status column:

• Ideas. Incoming and existing feature requests that are not being actively considered yet. These will be reviewed when bandwidth permits.
• Backlog. Accepted feature requests or enhancements that we want to work on.
• Working on it. Features or enhancements we're currently either researching or implementing it.
• Coming soon. Any feature, enhancement, or bug fixes that have been merged and are coming in the next release.
• Shipped. Features or enhancements that are now available in the most recent release.

Tasks or issues with empty Status will be categorized in upcoming review cycles.

Process

graph LR
    PFR[Feature request] --> Triage{Need RFC?}
    Triage --> |Complex/major change or new utility?| RFC[Ask or write RFC] --> Approval{Approved?}
    Triage --> |Minor feature or enhancement?| NoRFC[No RFC required] --> Approval
    Approval --> |Yes| Backlog
    Approval --> |No | Reject["Inform next steps"]
    Backlog --> |Prioritized| Implementation
    Backlog --> |Defer| WelcomeContributions["help-wanted label"]

Visual representation

Our end-to-end mechanism follows four major steps:

• Feature Request. Ideas start with a feature request to outline their use case at a high level. For complex use cases, maintainers might ask for/write a RFC.
  • Maintainers review requests based on project tenets, customers reaction (👍), and use cases.
• Request-for-comments (RFC). Design proposals use our RFC issue template to describe its implementation, challenges, developer experience, dependencies, and alternative solutions.
  • This helps refine the initial idea with community feedback before a decision is made.
• Decision. After carefully reviewing and discussing them, maintainers make a final decision on whether to start implementation, defer or reject it, and update everyone with the next steps.
• Implementation. For approved features, maintainers give priority to the original authors for implementation unless it is a sensitive task that is best handled by maintainers.

See Maintainers document to understand how we triage issues and pull requests, labels and governance.

Disclaimer

The Powertools for AWS Lambda (Python) team values feedback and guidance from its community of users, although final decisions on inclusion into the project will be made by AWS.

We determine the high-level direction for our open roadmap based on customer feedback and popularity (👍🏽 and comments), security and operational impacts, and business value. Where features don’t meet our goals and longer-term strategy, we will communicate that clearly and openly as quickly as possible with an explanation of why the decision was made.

FAQs

Q: Why did you build this?

A: We know that our customers are making decisions and plans based on what we are developing, and we want to provide our customers the insights they need to plan.

Q: Why are there no dates on your roadmap?

A: Because job zero is security and operational stability, we can't provide specific target dates for features. The roadmap is subject to change at any time, and roadmap issues in this repository do not guarantee a feature will be launched as proposed.

Q: How can I provide feedback or ask for more information?

A: For existing features, you can directly comment on issues. For anything else, please open an issue.

Launched

Setting Parameters and Secrets

Docs

As of today, the Parameters feature is used to retrieve data, not to create or update existing parameters. Based on community feedback, we plan to enhance Parameters to allow set operations.

Major updates

• RFC
• MVP

Amazon Bedrock Agent Event Handler

Docs

Based on customers at re:Invent 2023, we will add a new Event Handler resolver to improve authoring and maintenance of Amazon Bedrock Agents.

Major updates

• Event Source Data Classes support
• Pydantic model (Parser) support
• MVP Event Handler
• New feature documentation
• Video to walkthrough use cases for anyone new to LLM Agents
• Launch amplifier (e.g., What's New, Blog post)

Sensitive Data Masking

Docs

Data Masking will be a new utility to mask/unmask sensitive data using encryption providers. It's the second most voted feature request (behind Observability Providers).

Major updates

• RFC to agree on design and MVP
• POC with AWS KMS as the default provider
• User-guide documentation and include when not to use it (e.g., when to use SNS data policy, CloudWatch Logs data policy)
• Decide whether to use Encryption SDK to bring their own provider or a simply a contract (e.g., ItsDangerous)

Deprecate Python 3.7 support

AWS Lambda will officially block updates to Lambda functions using Python 3.7 support. We will drop support as soon as that is official.

Major updates

• Drop Python 3.7 support
• Add documentation banner
• Publish versioning policy docs

Dropped

Lambda Layer in release notes

Reason: We are looking at more accessible alternatives based on customer feedback (e.g., AWS System Manager public parameters)

We want to publish a JSON with a map of region and Lambda Layer ARN as a GitHub Release Note asset.

As of V2, we prioritize Lambda Layers being available before release notes are out. This is due to x86_64 and ARM64 compilation for smaller binaries and extra speed.

This means we have room to include a JSON map for Lambda Layers and facilitate automation for customers wanting the latest version as soon as it's available.

Major updates

• Create secure mechanism to upload signed assets to GitHub Release Notes
• Create feature request to agree on JSON structure and asset name