aws / aws-cdk-rfcs

RFCs for the AWS CDK

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool


This repo is a place to propose and track major upcoming changes to AWS CDK, jsii, and other related projects. It also is a great place to learn about the current and future state of the libraries and to discover projects for contribution.

Jump to: What is an RFC? | When to submit? | RFC Process | RFC Life Cycle

# Title Owner Status
52 Support resource import πŸ‘· implementing
77 CloudFormation Registry Support πŸ‘· implementing
340 Kinesis Data Firehose Delivery Stream L2 @BenChaimberg πŸ‘· implementing
431 SageMaker Model Hosting L2 Constructs πŸ‘· implementing
460 Reduce aws-cdk-lib package size πŸ‘· implementing
457 Create fluent-assertions library to improve consumer test readability πŸ“† planning
374 The jsii compiler to follow TypeScript versioning ⏰ final comments
8 Project Structure Guidelines @rix0rrr ✍️ review
175 AppSync Mapping Template Object Model @MrArnoldPalmer ✍️ review
317 CDK third-party dependencies management ✍️ review
362 Construct Library for Contributor Insights Rules ✍️ review
419 CDK environment setup for platform/system administrators ✍️ review
2 Support for CloudFormation Resource Imports πŸ’‘ proposed
4 CDK Testing Toolkit @nija-at πŸ’‘ proposed
5 Security-restricted environments πŸ’‘ proposed
9 Master developer guide sources in main repo πŸ’‘ proposed
10 New workshop modules πŸ’‘ proposed
13 Improvements to Reference docs πŸ’‘ proposed
14 Toolchain 2.0 πŸ’‘ proposed
15 Scaffolding πŸ’‘ proposed
17 CLI support for multiple-environments πŸ’‘ proposed
18 Open Context Providers @ddneilson πŸ’‘ proposed
19 Introspection API πŸ’‘ proposed
20 Security posture summary πŸ’‘ proposed
21 CDK Explorer Roadmap πŸ’‘ proposed
22 Cost calculator πŸ’‘ proposed
23 Stateful resource support πŸ’‘ proposed
24 Resource imports πŸ’‘ proposed
25 Defaults & configuration policy πŸ’‘ proposed
26 Monitoring packs πŸ’‘ proposed
27 200 resource limit tools & guidance πŸ’‘ proposed
30 Improve synthesized template output πŸ’‘ proposed
31 Integration tests πŸ’‘ proposed
32 App-centric operational experience πŸ’‘ proposed
39 Release public artifacts (lambda layers for custom resources, docker images) πŸ’‘ proposed
40 Stack traces across language boundaries πŸ’‘ proposed
48 Faster builds πŸ’‘ proposed
51 Standardize security groups πŸ’‘ proposed
58 Improved ergonomics for stack default environment πŸ’‘ proposed
63 CDK in Secure Environments πŸ’‘ proposed
64 Garbage Collection for Assets @kaizencc πŸ’‘ proposed
65 CDK Code Generation from AWS Console πŸ’‘ proposed
66 StackSets Support πŸ’‘ proposed
67 Monitoring Packs πŸ’‘ proposed
69 One-off "job" Stacks ("auto destruct") πŸ’‘ proposed
70 Cost Estimation Tools πŸ’‘ proposed
72 Stack Policy πŸ’‘ proposed
73 AWS Resource Model πŸ’‘ proposed
74 Common API for Resources with Web Addresses πŸ’‘ proposed
78 Feature proposal: Workspaces πŸ’‘ proposed
81 AWS Landing Zone CDK pattern request πŸ’‘ proposed
82 Weak references πŸ’‘ proposed
83 Global Name Prefix πŸ’‘ proposed
86 AWS Account Alias Resource πŸ’‘ proposed
127 CDK to directly reference/import/update an existing stack πŸ’‘ proposed
139 "fromLookup" for additional resources πŸ’‘ proposed
158 Implement Custom Resources in the AWS Construct Library as CFN Registry Resource Types πŸ’‘ proposed
159 Cross-App Resource Sharing πŸ’‘ proposed
161 Cross-Region/Account References πŸ’‘ proposed
162 CDK Refactoring Tools πŸ’‘ proposed
180 CustomResources: Allow usage across accounts πŸ’‘ proposed
193 Fixing of type unions @RomainMuller πŸ’‘ proposed
201 Construct scope relocation πŸ’‘ proposed
217 Alternative Infrastructure Providers @ccfife πŸ’‘ proposed
219 ECS Patterns Service Builder πŸ’‘ proposed
223 Improvements to Lambda Development Experience πŸ’‘ proposed
228 CDK CLI Triggers πŸ’‘ proposed
229 Construct library pattern for metrics πŸ’‘ proposed
230 Construct library pattern for grants πŸ’‘ proposed
231 Construct library pattern for resources that use a VPC πŸ’‘ proposed
232 Construct library pattern for resources that need IAM roles πŸ’‘ proposed
242 Bootstrap stacks as CDK apps πŸ’‘ proposed
244 Migration path for EKS Developer Preview πŸ’‘ proposed
247 CDK Common Stored Data Type Model πŸ’‘ proposed
248 Standardized context key for "cheap mode" πŸ’‘ proposed
256 ReactCDK: Add JSX/TSX Support πŸ’‘ proposed
272 CI/CD to Cloudfront Deploy πŸ’‘ proposed
275 route53-patterns for cross account DNS delegation πŸ’‘ proposed
277 cdk logs πŸ’‘ proposed
294 Policy Definition and Enforcement πŸ’‘ proposed
300 Programmatic Access of CDK CLI Capabilities πŸ’‘ proposed
305 support code signing of assets πŸ’‘ proposed
309 Parameter Store for cross stack references πŸ’‘ proposed
313 Questions on the Go Bindings RFC πŸ’‘ proposed
348 CloudFormationController - refactor CloudFormation stacks πŸ’‘ proposed
370 CLI deploy with change set review confirmation πŸ’‘ proposed
375 Support Encode Properties for CloudFormation CustomResource πŸ’‘ proposed
380 Remove Node.js as an installed pre-requisite for the jsii runtime πŸ’‘ proposed
394 WAF v2 L2 Construct πŸ’‘ proposed
399 SSM Document as Objects πŸ’‘ proposed
400 RUM AppMonitor L2 Construct πŸ’‘ proposed
402 Glue DataBrew L2 Construct πŸ’‘ proposed
418 CDK Operator CLI πŸ’‘ proposed
423 IoT Sitewise L2 Construct πŸ’‘ proposed
426 AppConfig L2 Construct πŸ’‘ proposed
428 Amazon CloudWatch Evidently L2 Constructs πŸ’‘ proposed
434 AWS Ground Station L2 Constructs πŸ’‘ proposed
437 CDK post-deployment experience πŸ’‘ proposed
441 Add Sagemaker endpoint L2 construct πŸ’‘ proposed
446 Network Firewall L2 Constructs πŸ’‘ proposed
448 AWS Compute Optimizer Constructs πŸ’‘ proposed
450 AWS CDK public roadmap πŸ’‘ proposed
456 L2 ElastiCache support πŸ’‘ proposed
458 Service Catalog ProductStack Asset Support πŸ’‘ proposed
463 Glue View L2 Construct πŸ’‘ proposed
465 AWS Organizations L2 Construct πŸ’‘ proposed
467 Add L2 constructs for Amaxon FSx Windows πŸ’‘ proposed
1 CDK Watch βœ… done
6 Monolithic Packaging βœ… done
7 Lambda Bundles βœ… done
16 RFC Process @MrArnoldPalmer βœ… done
34 Third-party construct ecosystem βœ… done
35 Publish construct library guidelines βœ… done
36 Constructs Programming Model βœ… done
37 Release from a "release" branch @MrArnoldPalmer βœ… done
49 CI/CD for CDK apps @rix0rrr βœ… done
55 Feature Flags βœ… done
71 Deployment Triggers βœ… done
79 CDK v2.0 βœ… done
92 CI/CD Asset Publishing @rix0rrr βœ… done
95 Cognito Construct Library @nija-at βœ… done
107 Publish a Construct Library Module Lifecycle document @ccfife βœ… done
110 CLI Compatibility Strategy @iliapolo βœ… done
116 Easier identification of experimental modules βœ… done
171 CloudFront Module Redesign βœ… done
192 Removal of the "constructs" compatibility layer (v2.0) @eladb βœ… done
204 JSII Go Support @MrArnoldPalmer βœ… done
249 Experimental Code in CDK v2 @ericzbeard βœ… done
253 CDK Metadata v2 βœ… done
282 CDK Pipelines security posture change approvals βœ… done
287 Deprecated API Warnings βœ… done
308 CLI notices βœ… done
322 CDK Pipelines Updated API βœ… done
324 Construct Hub @RomainMuller βœ… done
328 polyglot assert library @nija-at βœ… done
353 Constructs for all public CloudFormation resources and modules βœ… done
359 Construct Hub Deny List βœ… done
388 CLI Banners βœ… done
60 Bazel Build System πŸ‘Ž rejected
164 Construct Library Segments @nija-at πŸ‘Ž rejected
436 Amazon GameLift L2 Constructs ❓unknown

What is an RFC?

An RFC is a document that proposes a change to one of the projects led by the CDK team at AWS. Request for Comments means a request for discussion and oversight about the future of the project from maintainers, contributors and users.

When should I write an RFC? The CDK team proactively decides to write RFCs on major features or complex changes that we feel require that extra vetting. However, the process is designed to be as lightweight as needed and can be used to request feedback on any change. Quite often, even changes that seem obvious and simple at first sight can be significantly improved once a wider group of interested and experienced people have a chance to weigh in.

Who should submit an RFC? An RFC can be submitted by anyone. In most cases, RFCs are authored by CDK maintainers, but contributors are more than welcome to submit RFCs.

If you are a contributor and you wish to write an RFC, please contact the core team at the #aws-cdk-rfcs to make sure someone from the core team can sponsor your work. Otherwise, there is a good chance we won't have bandwidth to help.

RFC Process

To start an RFC process, create a new tracking issue and follow the instructions in the issue template. It includes a checklist of the various stages an RFC goes through.

This section describes each stage in detail, so you can refer to it for guidance.

1. Tracking Issue

Each RFC has a GitHub issue which tracks it from start to finish. The issue is the hub for conversations, community signal (+1s) and the issue number is used as the unique identifier of this RFC.

Before creating a tracking issue, please search for similar or related ideas in the RFC table above or in the issue list of this repo. If there is a relevant RFC, collaborate on that existing RFC, based on its current stage.

Our tracking issue template includes a checklist of all the steps an RFC goes through and it's the driver's responsibility to update the checklist and assign the correct label to on the RFC throughout the process.

When the issue is created, it is required to fill in the following information:

  1. Title: the name of the feature or change - think changelog entry.
  2. Description: a short description of feature, as if it was already implemented.
  3. Proposed by: fill in the GitHub alias of the person who proposed the idea under "Proposed by".

2. API Bar Raiser

Reach us via #aws-cdk-rfcs to get an "API Bar Raiser" assigned to your RFC.

For each RFC, CDK leadership will assign an API Bar Raiser who reviews and approves the public API of the feature. API Bar Raisers have veto rights on API-related design decisions, such as naming, structure, options, CLI commands and others.

The public API of a feature represents the surface through which users interact with it, and we want to make sure these APIs are consistent, ergonomic and designed based on the intent and the mental model of our users. Additionally, once we announce that a feature is "stable" (1.0, GA, etc) any breaking change to its public API will require releasing a new major version, so we like think of API decisions as "one way doors".

API Bar Raisers will be assigned using a tiering model which is generally based on the size of the user base that will likely get exposed to the feature. As a general rule, the more "significant" the feature is, we will assign a bar raiser with a wider and longer-term context of the project.

To merge an RFC, a sign-off from the bar raiser is required on the public API of the feature, so we encourage to engage with them early in the process to make sure you are aligned on how the API should be designed.

NOTE: The technical solution proposed in an RFC does not require approval beyond the normal pull request approval model (e.g. a core team member needs to approve the RFC PR and any subsequent changes to it).

3. Kick-off

Before diving into writing the RFC, it is highly recommended to organize a kick-off meeting that includes the API Bar Raiser and any stakeholders that might be interested in this RFC or can contribute ideas and direction. The goal of the meeting is to discuss the feature, its scope and general direction for implementation.

If you are not part of the CDK team at Amazon, reach out to us via #aws-cdk-rfcs and we will help to organize the kick-off meeting.

Our experience shows that such a meeting can save a lot of time and energy.

You can use the tracking issue to record some initial API and design ideas and collect early feedback and use cases as a preparation for the kick-off meeting and RFC document itself. You can start the meeting by letting participants obtaining context from the tracking issue.

At the end of the meeting, record any ideas and decisions in the tracking issue and update the checklist to indicate that the kick-off meeting has happened.

4. RFC Document

The next step is to write the first revision of the RFC document itself.

Create a file under text/ based off of the template under (where NNNN is your tracking issue number). Follow the template. It includes useful guidance and tips on how to write a good RFC.

What should be included in an RFC? The purpose of an RFC is to reduce ambiguity and risk and get approval for public-facing interfaces (APIs), which are "one-way doors" after the feature is released. Another way to think about it is that the goal and contents of the document should allow us to create a high-confidence implementation plan for a feature or a change.

In many cases, it is useful to develop a prototype or even start coding the actual implementation while you are writing the RFC document. Take into account that you may need to throw your code away or refactor it substantially, but our experience shows that good RFCs are the ones who dive into the details. A prototype is great way to make sure your design "holds water".

5. Feedback

Once you have an initial version of your RFC document (it is completely fine to submit an unfinished RFC to get initial feedback), submit it as a pull request against this repo and start collecting feedback.

Contact the CDK core team at #aws-cdk-rfcs (or via email/Slack if you are part of the core team) and reach out to the public and Amazon internal communities via various Slack channels in, Twitter and any other relevant forum.

This is the likely going to be the longest part of your RFC process, and where most of the feedback is collected. Some RFCs resolve quickly and some can take months (!!). Take into account at least 1-2 weeks to allow community and stakeholders to provide their feedback.

A few tips:

  • If you decide to resolve a comment without addressing it, take the time to explain.
  • Try to understand where people are coming from. If a comment seems off, ask folks to elaborate and describe their use case or provide concrete examples.
  • Work with your API bar raiser: if there are disagreements, @mention them in a comment and ask them to provide their opinion.
  • Be patient: it sometimes takes time for an RFC to converge. Our experience shows that some ideas need to "bake" and solutions oftentimes emerge via a healthy debate. We've had RFCs that took months to resolve.
  • Not everything must be resolved in the first revision. It is okay to leave some things to resolve later. Make sure to capture them clearly and have an agreement about that. We oftentimes update an RFC doc a few times during the implementation.

6. API Sign-off

Before you can merge your RFC, you will need the API Bar Raiser to sign-off on the public API of your feature. This is will normally be described under the Working Backwards section of your RFC.

To sign-off, the API bar raiser will add the api-approved label to the RFC pull request.

Once the API was signed-off, update your RFC document and add a [x] the relevant location in the RFC document. For example:

[x] Signed-off by API Bar Raiser @foobar

7. Final Comments Period

At some point, you've reached consensus about most issues that were brought up during the review period, and you are ready to merge. To allow "last call" on feedback, the author can announce that the RFC enters "final comments period", which means that within a ~week, if no major concerns are raised, the RFC will be approved and merged.

Add a comment on the RFC pull request, tracking issue (and possibly slack/email if relevant) that the RFC entered this stage so that all relevant stakeholders will be notified.

Once the final comments period is over, seek an approval of one of the core team members, and you can merge your PR to the main branch. This will move your RFC to the "approved" state.

8. Implementation

For large changes, we highly recommend creating an implementation plan which lists all the tasks required. In many cases, large implementation should be broken down and released via multiple iterations. Devising a concrete plan to break down the break can be very helpful.

The implementation plan should be submitted through a PR that adds an addendum to the RFC document and seeks the approval of any relevant stakeholders.

Throughout this process, update the tracking issue:

  • Add the alias of the "implementation lead"
  • Execution plan submitted (label: status/planning)
  • Plan approved and merged (label: status/implementing)
  • Implementation complete (label: status/done)

State Diagram

The following state diagram describes the RFC process:


  1. Proposed - A tracking issue has been created with a basic outline of the proposal.
  2. Review - An RFC document has been written with a detailed design and a PR is under review. At this point the PR will be assigned a shepherd from the core team.
  3. Final Comment Period - The shepherd has approved the RFC PR, and announces that the RFC enters a period for final comments before it will be approved (~1wk). At this stage, if major issues are raised, the RFC may return to Review.
  4. Approved - The RFC PR is approved and merged to master, and the RFC is now ready to be implemented.
  5. Planning - A PR is created with the Implementation Plan section of the RFC.
  6. Implementing - Implemetation plan is approved and merged and the RFC is actively being implemented.
  7. Done - Implementation is complete and merged across appropriate repositories.
  8. Rejected - During the review period, the RFC may be rejected and then it will be marked as such.

AWS CDK's RFC process owes its inspiration to the Yarn RFC process, Rust RFC process, React RFC process, and Ember RFC process


RFCs for the AWS CDK

License:Apache License 2.0


Language:JavaScript 91.9%Language:Shell 8.1%