Implement Custom Resources in the AWS Construct Library as CFN Registry Resource Types

[eduardomourar]

PR	Champion
#170	@eladb

Description

A new CloudFormation CLI plugin for typescript is available and you can track progress here: aws-cloudformation/cloudformation-cli#397.

Even though it is in very initial phase, I believe migrating most of the custom resources to resource type provider would be beneficial to the CDK project in the future.

Here is good explanation of the difference between custom resource and resource type: https://aws.amazon.com/blogs/mt/managing-resources-using-aws-cloudformation-resource-types/

Progress

• Tracking Issue Created
• RFC PR Created
• Core Team Member Assigned
• Initial Approval / Final Comment Period
• Ready For Implementation
  • implementation issue 1
• Resolved

[richardhboyd]

Registering a Resource Provider has quite a bit of latency (10-20 seconds) and has to be done for each region in the account.

[eladb]

@eduardomourar this is interesting and I think definitely worth a deeper discussion. I am moving this to the RFC repo. Please check out our RFC process if you are interested to submit a proposal.

[eladb]

I think this is fairly related to #39

[eduardomourar]

@eladb I will probably be more helpful in the implementation phase, but I will try to prepare a RFC proposal. A few things we should consider as dependencies:

• As @richardhboyd mentioned, the resource provider needs to be added to the CloudFormation registry in each account and region. I am waiting on some improvements there to have it available using AWS Organizations. I don’t believe there a public issue to track that.
• Another important aspect is that we don’t yet have support to deploy resource providers using CloudFormation (only cfn CLI and SDK). There is a PR that we can track progress here.

[richardhboyd]

Once the RP is packaged, we can register it using the AWS CLI. The CFN CLI is just needed for init/generate. My understanding is that cfn submit is just a wrapper around aws cloudformation package

[eduardomourar]

@eladb and @richardhboyd, could you guys provide feedback in the PR aws/aws-cdk/pull/8424, please? You can find my first attempt to solve the part of the puzzle in regards to the actual registration of the resource types.

[richardhboyd]

Ryan Lohan is VERY close to delivering a CFN-native Resource Type. I would strongly prefer waiting for that feature than building a Custom Resource for it today.

[richardhboyd]

An area that is very close to this, though not exactly what you’re proposing, is a way to import 3p resources into the CDK L1 codegen utility space that people can build L2/L3s on top of Resource Types. I know this isn’t what you originally proposed in the RFC, but your familiarity with Resource Providers, CDK, and TypeScript tooling is ideally suited to this problem.

[eduardomourar]

Ryan Lohan is VERY close to delivering a CFN-native Resource Type. I would strongly prefer waiting for that feature than building a Custom Resource for it today.

I agree with you that native CloudFormation is better. Unfortunately, we will probably need a custom resource anyway because we will need a named alias (what I called semantic version) and also a way to cleanup older versions. Otherwise we will not be able to control the different versions used by the CDK.

[AlexCheema]

Ryan Lohan is VERY close to delivering a CFN-native Resource Type. I would strongly prefer waiting for that feature than building a Custom Resource for it today.

Is there an issue to track progress on this?

[eduardomourar]

There is a PR here: aws-cloudformation/aws-cloudformation-resource-providers-cloudformation#4

[eladb]

Dup #77

[eduardomourar]

You can now use CloudFormation to register your resource type. Also, it has been announced support for developing resource types with TypeScript: https://aws.amazon.com/about-aws/whats-new/2021/04/aws-cloudformation-command-line-interface-now-supports-typescript

[mrgrain]

Problem remains, but CFN Registry Resource Types won't be the solution as they require to be enabled per account.

Marking this RFCs as stale since there has been little recent activity and it is not currently close to getting accepted as-is. We appreciate the effort that has gone into this proposal. Marking an RFCs as stale is not a one-way door. If you have made substantial changes to the proposal, please open a new issue/RFC. You might also consider raising a PR to aws/aws-cdk directly or self-publishing to Construct Hub.