Graduate @aws-cdk/aws-config to stable

We plan on graduating this module to stable.

What does it mean?

It means we will start providing semantic versioning guarantees on the existing API’s.

Use this issue to provide feedback about the current API and any changes you think are warranted.

Following are the tasks needed to complete before flipping the switch:

• Validate no p0 bugs in the last 4 weeks.
• Validate L2 coverage.
• Clear awslint exclusions (https://github.com/aws/aws-cdk/pull/6671)
• Conduct API review.

[iliapolo]

@jogold @MrArnoldPalmer @nija-at @ccfife

I’d like to kick-off a discussion on whether or not we should go ahead with graduating this module.

The problem is that in order to use the AWS config, one needs to first setup a ConfigurationRecorder and a DeliveryChannel. Before creating those resources, config rules cannot be created. The existing CDK constructs do not support creating them, and therefore, users have to either:

1. Create those resources using the L1 objects, as attempted here. This is a rather complex setup, and as the issue states, might be buggy and not fully supported.

2. Create those resources manually in the aws console prior to using CDK. This process is also quite complex and prone to user errors.

Neither of these methods provide a slick CDK experience that is in par with our other modules. When we graduate modules, we should consider the developer experience as a whole, not just with existing constructs.

I’d like your thoughts on this to decide if we push back on graduation until we provide support for ConfigurationRecorder and DeliveryChannel. My personal take is that we should put the breaks and invest our effort to adding those necessary L2 constructs.

[iliapolo]

@nija-at - The ConfigurationRecorder and DeliveryChannel are just enablers for the rules. You’re right that in order to create rules, one doesn’t need to refer to them, they just need to exist.

To clarify, the ConfigurationRecorder is just a specification of which resources will AWS even keep track of, and the DeliveryChannel is essentially which bucket to put the results in.

They are defined per account per region, but can be updated during their lifecycle. For example, I imagine you would normally start with minimum resource types to record (its charged per type), and as you add more rules, you might update the recorder with more resource types.

The current experience is that if you haven’t done the initial setup, creating the rules will simply fail. If you have done it, but are defining rules for unrecorded resource types, you just won’t have the data to actually employ those rules.

Im not entirely sure what the experience will look like because you don’t actually reference any resources when you configure a rule, its just a lambda function that uses the aws.ConfigService object.

Once a ConfigurationRecorder and a DeliveryChannel is set up, how would that fit into the rest of the CDK app, say in the case of, this app?

If they are already setup, you don’t strictly need them in the CDK app, unless you want to update them in the case i mentioned. Once we add support for those L2’s, they will be defined as free floating resources in the app, and will be changed when your rules require additional configuration tweaks.

Does this answer you questions?