The roadmap priorities for the AWS CDK (Cloud Development Kit) are informed by what we hear from customers and interactions on Github, CDK.dev Slack, Stack Overflow, and Twitter. This document outlines the high level direction we are working towards, and for each project there is a tracking issue where you can leave feedback. We update this doc on a quarterly basis to reflect any changing priorities.
Follow CDK Live! and cdk.dev to learn what's new in AWS CDK.
Security and stability of the CDK is a top priority. If you think you’ve found a potential security issue, please do not post it as an issue or a discussion thread in this repository. Instead, please follow the instructions here or directly email AWS security.
- We empower CDK builders to innovate with confidence, without sacrificing security. The CDK provides customers with conviction by providing a clear and streamlined direction to building secure, modernized, industry leading innovations with AWS.
- Productivity through simplicity. The CDK measurably improves developer productivity in building with AWS. We make Infrastructure as Code simple to define, understand, change, and troubleshoot.
- Be transparent. The AWS CDK team’s current work should be easily visible.
- Listen to customers. Allow them to participate in design decisions and to vote on and propose new AWS CDK features. We will periodically reprioritize the roadmap based on customer feedback.
| Symbol | Description |
|---|---|
| 🔍 | Exploration |
| 👂🏽 | Waiting for feedback |
| 🚦 | Work ready to begin |
| 🛠️ | Work in progress |
| 🚀 | Released |
Over the course of the last few years, the CDK team has spent time speaking with and learning from its community. We've gathered that there were certain features that were greatly valued from the CDK and other features which would be beneficial to be added to its experience. We appreciate everyone sharing this feedback and we plan on addressing it through the targeted themes and RFCs listed below. Please be aware that the team will periodically work to add RFCs as we look to prioritize more work.
It’s clear that constructs are imperative to the CDK experience. We repeatedly hear from CDK builders that the most important improvement that the CDK can make for its construct experience would be to provide greater service coverage. Because of this, the CDK team intends to direct much of its focus towards investigating how we can provide more comprehensive AWS service coverage in the next year. In the past, the CDK has relied on community and in-house authored constructs to address construct demand. In the future, our goal is to bring CDK builders a complete and consistent construct model through largely autogenerated means. This model would provide builders with Day 1 support of AWS services--the moment services are launched--complete with the features that builders love in their L2s. We’ll be investigating this effort in the coming months, and it’s possible that there will be gradual rollouts for us to realize this goal. If you have feedback on what is most important to you while you work with CDK constructs today, we would highly appreciate you sharing this within our Complete Construct Model RFC.
The CDK team is committed to supporting our existing library of AWS L2 abstractions. We continue to solicit community feedback on where additional L2 coverage makes it simpler and more efficient to build with AWS. Current L2s that the team’s working on are listed below. Please be aware that this list will update throughout the year. If you have feedback on other L2s that should be prioritized by our team, feel free to submit a separate RFC.
- 🚀 Enabling IPv6 on Resources and VPCs
- 🔍 CloudFront Origin Access Control L2
- 🔍 Rewrite EKS L2 - drop the custom resource implementation in favor of the native L1.
We've also heard from many CDK builders that there's a desire to see more features which enable builders to iterate within their development loop faster. Over the next year, the team is also making it a goal to provide greater support for testing, debugging and deployment. Apart from the tickets listed below, if you have feedback have related to this goal, please submit it via and RFC and we will work to prioritize it towards this goal.
- 🚀 Enable CloudFormation builders to migrate existing infrastructure to CDK - CloudFormation builders can now generate a CDK application using an existing CloudFormation template in JSON or YAML format using cdk migrate!
- 🚀 Policy Validation at Synth - Builders can now check their policies immediately after synthesis using CloudFormation Guard or OPA!
- 👂🏽 Adding more resource support to Hotswap - Apart from Lambda, we are looking into expanding resource support for Hotswap. Please share your feedback in this linked ticket!
- 🔍 Local application testing - We are investigating how to improve CDK testing on builders’ locals. We would love to hear everyone’s feedback here on what they would like to see as part of this experience.
- 🔍 Upgrade deployment debugging experience - We also are looking into providing more debugging support at time of deployment. Please drop a note in this tagged ticket if you have any opinions related to this experience!
- 🚀 Secure CDK Deployments with IAM Permission Boundaries - CDK builders can now enact IAM permission boundaries, which help to ensure that all actions are within the overlap of the users permissions and the boundary, and ensure that any IAM entities that are created also have the same boundary applied!
- 👂🏽 CDK CLI Upgrade - We are looking into how to further improve the CLI experience. This includes allowing builders to automate necessary tasks and integrate the CDK into CI/CD pipelines if they desire to. Please share your feedback in this ticket if you have anything you would like noted!
- 👂🏽 CDK CLI Triggers - CLI enhancements are also being considered for post command hooks.
These are items that improve the user experience of the CDK. We strive to make the CDK as efficient and intuitive as possible. If you have other feedback around this area, please submit an RFC to detail your suggestion.
- 🚀 App Staging Synthesizer for Resource Isolation - This feature enhances resource isolation and cleanup control by creating separate staging resources for each application
- 👂🏽 CDK Refactoring - We’re looking into providing built-in support for builder refactoring work.
- 🛠️ Understand deployment progress within CloudFormation - This will help builders understand what CloudFormation is doing as deployments are in progress.
- 🔍 Garbage Collection for Assets - Assets which are uploaded to the CDK's S3 bucket and ECR repository are never deleted.
We would love to hear from you on how the CDK operates today and how it should grow in the future. To report a bug or create a small feature request, please create an issue here. If you are seeking to request a change in strategic direction or make a CDK core framework change, please create a Request for Comments (RFC) ticket here. If you are ever unsure about where your feature request should live, it is best to follow the first link within the aws-cdk repo.
Listening and working with the open source community is really important to us. If you would like to give us your feedback on how we are doing, feel free to reach out to our team via cdk.dev slack.
To make the CDK more accessible and easier to understand, we publish educational content like blog posts, videos and workshops. Here are some from AWS.
- [Workshop] The AWS CDK Workshop
- [Workshop] Extended CDK Workshop
- [Workshop] Automating your workload deployments in AWS Local Zones
- [Blogpost] Using AWS CloudFormation and AWS Cloud Development Kit to provision multicloud resources
- [Blogpost] CDK Pipelines: Continuous delivery for AWS CDK applications
- [Blogpost] Better together: AWS SAM and AWS CDK
- [Videos] CDK Live!
- [CDK Day] Track 1 (English) for CDK Day 2023
- [CDK Day] Track 2 (English) for CDK Day 2023
- [CDK Day] Track 3 (Spanish) for CDK Day 2023
- [re:Invent Content] Search through all content here
Stay tuned for more updates for 2024!
The AWS CDK 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.
Q: Why did you build an open roadmap? A: Your feedback and suggestions would help in ensuring that we are working on the most important and impactful issues. And if you are making decisions and plans based on what we are developing, this will provide insights on what is coming down the road for the CDK.
Q: Why are there no dates on your roadmap? A: Because security and operational stability are our highest priorities, the above new features cannot be provided specific target dates. 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: Is everything on the roadmap? A: We will publish high-level direction that is within the scope of the CDK. Minor features and performance improvement tasks are not on the roadmap currently, but we are constantly trying to improve the roadmap so please leave your suggestions here.
Q: How can I provide feedback or ask for more information? A: When in doubt, please create an issue! Issues will be reviewed and/or forwarded appropriately. A great time to provide feedback is when the project is in Exploration, RFC stage, or when the feature is in beta release. As always, we listen to your feedback and adapt our plans if needed.
Q: Can I 👍🏽 existing issues? A: We strongly encourage you to do so, as it helps us understand which issues will have the widest impact. You can navigate to the issue details page and add a reaction (👍🏽).
Q: How can I request a feature be added to the roadmap? A: We encourage you to open an issue, even if you’ve requested it before via other channels. Issues submitted will be reviewed by the roadmap maintainers. If you find an issue already created for the feature, please upvote it (👍🏽) and leave comments specific to your use case. To report a bug or create a small feature request, please create an issue here. If you are seeking to request a change in the CDK’s strategic direction or make a CDK core framework change, please create a Request for Comments (RFC) ticket here.
Please do not be discouraged if your ticket is closed—that may happen if it is not a priority during the quarter it was submitted. The CDK team closes tickets in an effort to display what is prioritized at a given moment. If this happens, we invite you to try submitting it again later in the year.