{"id":13516197,"url":"https://github.com/aws/aws-cdk-rfcs","last_synced_at":"2025-05-15T07:06:10.961Z","repository":{"id":39741633,"uuid":"105809752","full_name":"aws/aws-cdk-rfcs","owner":"aws","description":"RFCs for the AWS CDK","archived":false,"fork":false,"pushed_at":"2025-05-06T15:38:18.000Z","size":5332,"stargazers_count":558,"open_issues_count":36,"forks_count":93,"subscribers_count":74,"default_branch":"main","last_synced_at":"2025-05-08T00:07:55.952Z","etag":null,"topics":["aws","cdk","cloud-infrastructure","infrastructure-as-code","rfc-process","rfcs"],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/aws.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2017-10-04T19:33:07.000Z","updated_at":"2025-05-06T15:38:21.000Z","dependencies_parsed_at":"2023-10-14T16:15:55.709Z","dependency_job_id":"b6b73b0d-1203-4c7e-8454-37c239e8cb5c","html_url":"https://github.com/aws/aws-cdk-rfcs","commit_stats":{"total_commits":414,"total_committers":53,"mean_commits":7.811320754716981,"dds":0.6256038647342995,"last_synced_commit":"2dff2a65963d9c3ea3d83661362df5fafe75c597"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aws%2Faws-cdk-rfcs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aws%2Faws-cdk-rfcs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aws%2Faws-cdk-rfcs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aws%2Faws-cdk-rfcs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/aws","download_url":"https://codeload.github.com/aws/aws-cdk-rfcs/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254292042,"owners_count":22046426,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aws","cdk","cloud-infrastructure","infrastructure-as-code","rfc-process","rfcs"],"created_at":"2024-08-01T05:01:20.160Z","updated_at":"2025-05-15T07:06:05.936Z","avatar_url":"https://github.com/aws.png","language":"JavaScript","readme":"# AWS CDK RFCs\n\nThis repo is a place to propose and track major upcoming changes to [AWS CDK], [jsii], and\nother related projects. It also is a great place to learn about the current and\nfuture state of the libraries and to discover projects for contribution.\n\n[AWS CDK]: https://github.com/aws/aws-cdk\n[jsii]: https://github.com/aws/jsii\n\n**Jump to**: [What is an RFC?](#what-is-an-rfc) |\n[RFC Process](#rfc-process) |\n[RFC State Diagram](#the-rfc-life-cycle)\n\n## Current RFCs\n\n**Jump to**:\n[Full list](./FULL_INDEX.md) |\n[Accepted](./ACCEPTED.md) |\n[Proposed](./PROPOSED.md) |\n[Closed](./CLOSED.md)\n\n\u003c!--BEGIN_TABLE--\u003e\n\\#|Title|Owner|Status\n---|-----|-----|------\n[300](https://github.com/aws/aws-cdk-rfcs/issues/300)|[Programmatic access of AWS CDK CLI](https://github.com/aws/aws-cdk-rfcs/blob/main/text/0300-programmatic-toolkit.md)|[@mrgrain](https://github.com/mrgrain)|👷 implementing\n[507](https://github.com/aws/aws-cdk-rfcs/issues/507)|[Full control over VPC and subnet configuration](https://github.com/aws/aws-cdk-rfcs/blob/main/text/0507-subnets)|[@otaviomacedo](https://github.com/otaviomacedo)|👷 implementing\n[605](https://github.com/aws/aws-cdk-rfcs/issues/605)|[Rewrite EKS L2 construct (EKSv2)](https://github.com/aws/aws-cdk-rfcs/blob/main/text/0605-eks-rewrite.md)||👷 implementing\n[670](https://github.com/aws/aws-cdk-rfcs/issues/670)|[AWS CloudWatch Application Signals L2 Constructs](https://github.com/aws/aws-cdk-rfcs/blob/main/text/0670-aws-applicationsignals-enablement-l2.md)||👷 implementing\n[673](https://github.com/aws/aws-cdk-rfcs/issues/673)|[RFC 670: AWS CloudWatch Application Signals L2 Constructs for SLO #673](https://github.com/aws/aws-cdk-rfcs/blob/main/text/0673-aws-applicationsignals-slo-l2.md)||👷 implementing\n[162](https://github.com/aws/aws-cdk-rfcs/issues/162)|[CDK Refactoring Tools](https://github.com/aws/aws-cdk-rfcs/issues/162)|[@otaviomacedo](https://github.com/otaviomacedo)|📆 planning\n[228](https://github.com/aws/aws-cdk-rfcs/issues/228)|[CDK CLI Triggers](https://github.com/aws/aws-cdk-rfcs/issues/228)||📆 planning\n[491](https://github.com/aws/aws-cdk-rfcs/issues/491)|[CloudFront Origin Access Control L2](https://github.com/aws/aws-cdk-rfcs/issues/491)||📆 planning\n[583](https://github.com/aws/aws-cdk-rfcs/issues/583)|[Deployment Debugging](https://github.com/aws/aws-cdk-rfcs/issues/583)||📆 planning\n[585](https://github.com/aws/aws-cdk-rfcs/issues/585)|[Local Application Testing](https://github.com/aws/aws-cdk-rfcs/issues/585)||📆 planning\n[586](https://github.com/aws/aws-cdk-rfcs/issues/586)|[Understand Deployment Progress](https://github.com/aws/aws-cdk-rfcs/issues/586)||📆 planning\n[502](https://github.com/aws/aws-cdk-rfcs/issues/502)|[Amazon VPC Lattice L2 Construct](https://github.com/aws/aws-cdk-rfcs/blob/main/text/0502_aws-vpclattice.md)|[@TheRealAmazonKendra](https://github.com/TheRealAmazonKendra)|👍 approved\n[686](https://github.com/aws/aws-cdk-rfcs/issues/686)|[L2 Constructs for Bedrock](https://github.com/aws/aws-cdk-rfcs/blob/main/text/0686-bedrock-l2-construct.md)||⏰ final comments\n\u003c!--END_TABLE--\u003e\n\n## What is an RFC?\n\nAn RFC is a document that proposes a change to one of the projects led by the\nCDK team at AWS. *Request for Comments* means a request for discussion and\noversight about the future of the project from maintainers, contributors and\nusers.\n\n**When should I write an RFC?** The CDK team proactively decides to write RFCs\non major features or complex changes that we feel require that extra vetting.\nHowever, the process is designed to be as lightweight as needed and can be used\nto request feedback on any change. Quite often, even changes that seem obvious\nand simple at first sight can be significantly improved once a wider group of\ninterested and experienced people have a chance to weigh in.\n\n**Who should submit an RFC?** An RFC can be submitted by anyone. In most cases,\nRFCs are authored by CDK maintainers, but contributors are more than welcome to\nsubmit RFCs.\n\nIf you are a **contributor** and you wish to write an RFC, please contact the\ncore team at the [#aws-cdk-rfcs] to make sure someone from the core team can\nsponsor your work. Otherwise, there is a good chance we won't have bandwidth to\nhelp.\n\n## RFC Process\n\nTo start an RFC process, create a [new tracking issue] and follow the\ninstructions in the issue template. It includes a checklist of the various\nstages an RFC goes through.\n\n[new tracking issue]: https://github.com/aws/aws-cdk-rfcs/issues/new?assignees=\u0026labels=management%2Ftracking%2C+status%2Fproposed\u0026template=tracking-issue.md\u0026title=proposal+title\n\nThis section describes each stage in detail, so you can refer to it for\nguidance.\n\n### 1. Tracking Issue\n\nEach RFC has a GitHub issue which tracks it from start to finish. The issue is\nthe hub for conversations, community signal (+1s) and the issue number is used\nas the unique identifier of this RFC.\n\n\u003e Before creating a tracking issue, please search for similar or related ideas in\nthe RFC table above or in the issue list of this repo. If there is a relevant\nRFC, collaborate on that existing RFC, based on its current stage.\n\nOur [tracking issue template] includes a checklist of all the steps an RFC goes\nthrough and it's the driver's responsibility to update the checklist and assign\nthe correct label to on the RFC throughout the process.\n\n[tracking issue template]: https://github.com/aws/aws-cdk-rfcs/blob/master/.github/ISSUE_TEMPLATE/tracking-issue.md\n\nWhen the issue is created, it is required to fill in the following information:\n\n1. **Title**: the name of the feature or change - think changelog entry.\n2. **Description**: a _short_ description of feature, as if it was already implemented.\n3. **Proposed by**: fill in the GitHub alias of the person who proposed the idea\n   under \"Proposed by\".\n\n### 2. API Bar Raiser\n\nReach us via [#aws-cdk-rfcs] to get an \"API Bar Raiser\" assigned to your RFC.\n\nFor each RFC, CDK leadership will assign an **API Bar Raiser** who reviews and\napproves the public API of the feature. API Bar Raisers have veto rights on\nAPI-related design decisions, such as naming, structure, options, CLI commands\nand others.\n\nThe public API of a feature represents the surface through which users interact\nwith it, and we want to make sure these APIs are consistent, ergonomic and\ndesigned based on the intent and the mental model of our users. Additionally,\nonce we announce that a feature is \"stable\" (1.0, GA, etc) any breaking change\nto its public API will require releasing a new major version, so we like think\nof API decisions as \"one way doors\".\n\nAPI Bar Raisers will be assigned using a tiering model which is generally based\non the size of the user base that will likely get exposed to the feature. As a\ngeneral rule, the more \"significant\" the feature is, we will assign a bar raiser\nwith a wider and longer-term context of the project.\n\nTo merge an RFC, a [sign-off](#6-api-sign-off) from the bar raiser is required\non the public API of the feature, so we encourage to engage with them early in\nthe process to make sure you are aligned on how the API should be designed.\n\n\u003e NOTE: The technical solution proposed in an RFC *does not* require approval\n\u003e beyond the normal pull request approval model (e.g. a core team member needs\n\u003e to approve the RFC PR and any subsequent changes to it).\n\n### 3. Kick-off\n\nBefore diving into writing the RFC, it is highly recommended to organize a\nkick-off meeting that includes the API Bar Raiser and any stakeholders that\nmight be interested in this RFC or can contribute ideas and direction. The goal\nof the meeting is to discuss the feature, its scope and general direction for\nimplementation.\n\nIf you are not part of the CDK team at Amazon, reach out to us via [#aws-cdk-rfcs]\nand we will help to organize the kick-off meeting.\n\nOur experience shows that such a meeting can save a lot of time and energy.\n\nYou can use the tracking issue to record some initial API and design ideas and\ncollect early feedback and use cases as a preparation for the kick-off meeting\nand RFC document itself. You can start the meeting by letting participants\nobtaining context from the tracking issue.\n\nAt the end of the meeting, record any ideas and decisions in the tracking issue\nand update the checklist to indicate that the kick-off meeting has happened.\n\n### 4. RFC Document\n\nThe next step is to write the first revision of the RFC document itself.\n\nCreate a file under `text/NNNN-name.md` based off of the template under\n[`0000-template.md`](./0000-template.md) (where `NNNN` is your tracking issue\nnumber). Follow the template. It includes useful guidance and tips on how to\nwrite a good RFC.\n\n**What should be included in an RFC?** The purpose of an RFC is to reduce\nambiguity and risk and get approval for public-facing interfaces (APIs), which\nare \"one-way doors\" after the feature is released. Another way to think about it\nis that the goal and contents of the document should allow us to create a\n*high-confidence* implementation plan for a feature or a change.\n\nIn many cases, it is useful to develop a **prototype** or even start coding the\nactual implementation while you are writing the RFC document. Take into account\nthat you may need to throw your code away or refactor it substantially, but our\nexperience shows that good RFCs are the ones who dive into the details. A\nprototype is great way to make sure your design \"holds water\".\n\n\u003e [!NOTE]\n\u003e To ensure consistency, the Markdown you write will be checked for common \u003e\nmistakes using a linter. To get early feedback while you are writing, use the\n[VSCode \u003e markdownlint\nextensions](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint),\n\u003e or run the `./lint.sh` script in the root of the repository.\n\u003e Run `./lint.sh --fix` auto fix all fixable violations.\n\n### 5. Feedback\n\nOnce you have an initial version of your RFC document (it is completely fine to\nsubmit an unfinished RFC to get initial feedback), submit it as a pull request\nagainst this repo and start collecting feedback.\n\nContact the CDK core team at [#aws-cdk-rfcs] (or via email/Slack if you are part\nof the core team) and reach out to the public and Amazon internal communities\nvia various Slack channels in [cdk.dev](https://cdk.dev), Twitter and any other\nrelevant forum.\n\nThis is the likely going to be the longest part of your RFC process, and where\nmost of the feedback is collected. Some RFCs resolve quickly and some can take\nmonths (!!). *Take into account at least 1-2 weeks to allow community and\nstakeholders to provide their feedback.*\n\nA few tips:\n\n- If you decide to resolve a comment without addressing it, take the time to\n  explain.\n- Try to understand where people are coming from. If a comment seems off, ask\n  folks to elaborate and describe their use case or provide concrete examples.\n- Work with your API bar raiser: if there are disagreements, @mention them in a\n  comment and ask them to provide their opinion.\n- Be patient: it sometimes takes time for an RFC to converge. Our experience\n  shows that some ideas need to \"bake\" and solutions oftentimes emerge via a\n  healthy debate. We've had RFCs that took months to resolve.\n- Not everything must be resolved in the first revision. It is okay to leave\n  some things to resolve later. Make sure to capture them clearly and have an\n  agreement about that. We oftentimes update an RFC doc a few times during the\n  implementation.\n\n### 6. API Sign-off\n\nBefore you can merge your RFC, you will need the API Bar Raiser to sign-off on\nthe public API of your feature. This is will normally be described under the\n**Working Backwards** section of your RFC.\n\nTo sign-off, the API bar raiser will add the **status/api-approved** label to the RFC\npull request.\n\nOnce the API was signed-off, update your RFC document and add a `[x]` the\nrelevant location in the RFC document. For example:\n\n```\n[x] Signed-off by API Bar Raiser @foobar\n```\n\n### 7. Final Comments Period\n\nAt some point, you've reached consensus about most issues that were brought up\nduring the review period, and you are ready to merge. To allow \"last call\" on\nfeedback, the author can announce that the RFC enters \"final comments period\",\nwhich means that within a ~week, if no major concerns are raised, the RFC will\nbe approved and merged.\n\nAdd a comment on the RFC pull request, tracking issue (and possibly slack/email\nif relevant) that the RFC entered this stage so that all relevant stakeholders\nwill be notified.\n\nOnce the final comments period is over, seek an approval of one of the core team\nmembers, and you can merge your PR to the main branch. This will move your RFC\nto the \"approved\" state.\n\n### 8. Implementation\n\nFor large changes, we highly recommend creating an implementation plan which\nlists all the tasks required. In many cases, large implementation  should be\nbroken down and released via multiple iterations. Devising a concrete plan to\nbreak down the break can be very helpful.\n\nThe implementation plan should be submitted through a PR that adds an addendum\nto the RFC document and seeks the approval of any relevant stakeholders.\n\nThroughout this process, update the tracking issue:\n\n- Add the alias of the \"implementation lead\"\n- Execution plan submitted (label: `status/planning`)\n- Plan approved and merged (label: `status/implementing`)\n- Implementation complete (label: `status/done`)\n\n## The RFC Life Cycle\n\nThe following state diagram describes the RFC process:\n\n![rfc-states](./images/lifecycle.png)\n\n\u003c!--\ndigraph states {\n    node [shape=ellipse];\n    edge [color=gray, fontsize=12]\n\n    idea [label = \"Idea\", shape = plaintext]\n    proposed [label = \"Proposed\"];\n    review [label = \"In Review\"];\n    fcp [label = \"Final Comment Period\"];\n    approved [label = \"Approved\"];\n    planning [label = \"Planning\"];\n    implementing [label = \"Implementing\"];\n    done [label = \"Done\"];\n    rejected [label = \"Rejected\"];\n\n    idea -\u003e proposed [label = \"github issue created\"]\n    proposed -\u003e review [label = \"pull request with rfc doc created\"];\n    review -\u003e review [label = \"doc revisions\"];\n    review -\u003e fcp [label = \"shepherd approved\"];\n    review -\u003e rejected [label = \"rejected\"];\n    fcp -\u003e review [label = \"revision requested\"];\n    fcp -\u003e approved [label = \"pull request approved and merged\"];\n    fcp -\u003e rejected [label = \"rfc rejected\"];\n    approved -\u003e planning [label = \"pull request with implementation plan created\"];\n    planning -\u003e implementing [label = \"rfc with implementation plan approved and merged\"];\n    implementing -\u003e done [label = \"implementation completed\"];\n}\n--\u003e\n\n1. **Proposed** - A tracking issue has been created with a basic outline of the\n   proposal.\n2. **Review** - An RFC document has been written with a detailed design and a PR is\n   under review. At this point the PR will be assigned a **shepherd** from the core\n   team.\n3. **Final Comment Period** - The shepherd has approved the RFC PR, and announces\n   that the RFC enters a period for final comments before it will be approved (~1wk).\n   At this stage, if major issues are raised, the RFC may return to **Review**.\n4. **Approved** - The RFC PR is approved and merged to `master`, and the RFC is now\n   ready to be implemented.\n5. **Planning** - A PR is created with the **Implementation Plan** section of the RFC.\n6. **Implementing** - Implementation plan is approved and merged and the RFC is actively\n   being implemented.\n7. **Done** - Implementation is complete and merged across appropriate\n   repositories.\n8. **Rejected** - During the review period, the RFC may be rejected and then it will\n   be marked as such.\n9. **Stale** - The RFC did not get any significant enough progress or tracking and has become stale.\n   We welcome a re-submission with substantial enough changes to overcome the original issues.\n\n---\n\nAWS CDK's RFC process owes its inspiration to the [Yarn RFC process], [Rust\nRFC process], [React RFC process], and [Ember RFC process]\n\n[yarn rfc process]: https://github.com/yarnpkg/rfcs\n[rust rfc process]: https://github.com/rust-lang/rfcs\n[react rfc process]: https://github.com/reactjs/rfcs\n[ember rfc process]: https://github.com/emberjs/rfcs\n\n[#aws-cdk-rfcs]: https://cdk-dev.slack.com/archives/C025ZFGMUCD\n","funding_links":[],"categories":["JavaScript","aws"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faws%2Faws-cdk-rfcs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Faws%2Faws-cdk-rfcs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faws%2Faws-cdk-rfcs/lists"}