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](https://github.com/aws/aws-cdk-rfcs/issues/611).

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](https://github.com/aws/aws-cdk/pull/28366)

* 🔍 [CloudFront Origin Access Control L2](https://github.com/aws/aws-cdk-rfcs/issues/491)

* 🔍 [Rewrite EKS L2](https://github.com/aws/aws-cdk-rfcs/issues/605) - 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.

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](https://aws.amazon.com/blogs/devops/enhancing-resource-isolation-in-aws-cdk-with-the-app-staging-synthesizer/) - This feature enhances resource isolation and cleanup control by creating separate staging resources for each application

* 👂🏽 [CDK Refactoring](https://github.com/aws/aws-cdk-rfcs/issues/162) - We’re looking into providing built-in support for builder refactoring work.

* 🔍 [Garbage Collection for Assets](https://github.com/aws/aws-cdk-rfcs/issues/64) - Assets which are uploaded to the CDK's S3 bucket and ECR repository are never deleted.