feat(custom-resource): AwsCustomResource supports AWS SDK for JavaScript v3

[WinterYukky]

What changes

Add support of AWS SDK for JavaScript v3 to AwsCustomResource. It also continues to works with runtimes that use the AWS SDK for JavaScript v2 (e.g Node.js 16.x).
⚠️ This PR only add support, doesn' change custom resource default runtime version

Why need this change?

Because AWS SDK for JavaScript v2 enters into maintenance mode in 2023.
At least, we must upgrade Node.js runtime to 18 or higher version that using AWS SDK for JavaScript v3 in 2023. If not upgrade, when customers possibly can't use new AWS Service's APIs.

※ reference from Document for AWS SDK for JavaScript v2

Version 2.x Support

We are formalizing our plans to enter AWS SDK for JavaScript v2 into maintenance mode in 2023.
AWS SDK for JavaScript v3 is the latest and recommended version, which has been GA since December 2020. Here is why and how you should use AWS SDK for JavaScript v3. You can try our experimental migration scripts in aws-sdk-js-codemod to migrate your application from v2 to v3.
To get help with your migration, please follow our general guidelines to open an issue and choose guidance. To give feedback on and report issues in the v3 repo, please refer to Giving feedback and contributing.
Watch this README and the AWS Developer Tools Blog for updates and announcements regarding the maintenance plans and timelines. Please refer to the AWS SDKs and Tools maintenance policy for further details.

Why don't change default runtime version?

AWS Lambda uses AWS SDK for JavaScript v3 since Node.js 18.x runtime. This is major update so I think it has breaking changes. This is reason. So I plan this.

1. Add experimentally support AWS SDK for JavaScript v3 (this PR)
2. Announce experimentally support Node.js 18.x runtime for customers who wish to update
3. Change AwsCustomResource's default runtime to Node.js 18.x in 2023 or Node.js 16.x EOL

This plan allows time for transition before changing the default runtime for AwsCustomResource.

Are there any changes to the props?

Yes. The specification method for the AWS SDK for JavaScript v3 will now be supported.
In AWS SDK for JavaScript v3, packages are installed for each service. Therefore, specify the package name for service. Also, action specifies the XxxClient operations provided in the package.

Example of SSM.getParameter:

new AwsCustomResource(this, 'GetParameter', {
  resourceType: 'Custom::SSMParameter',
  onUpdate: {
    service: '@aws-sdk/client-ssm', // 'SSM' in v2
    action: 'GetParameterCommand', // 'getParameter' in v2
    parameters: {
      Name: 'foo',
      WithDecryption: true,
    },
    physicalResourceId: PhysicalResourceId.fromResponse('Parameter.ARN'),
  },
});

What actions do customers need to take when migrating?

Nothing to do. To maintain backward compatibility, when customers provides AWS SDK for JavaScript v2 style parameters, then AwsCustomResource automatically convert the parameters to AWS SDK for JavaScript v3 style and handle it in lambda runtime code. Next example will be allowed.

new AwsCustomResource(this, 'CostUsageReportDefinitions', {
  resourceType: 'Custom::CostUsageReportDefinitions',
  onUpdate: {
    service: 'CUR', // will convert to '@aws-sdk/client-cost-and-usage-report-service'
    action: 'describeReportDefinitions', // will convert to 'DescribeReportDefinitionsCommand'
    parameters: {
      MaxResults: 5,
    },
    physicalResourceId: PhysicalResourceId.of('xxx'),
  },
});

How can I use it before the default runtime changes?

Overriding with regioninfo.Fact.register or rewriting it like addPropertyOverride by customers. There are currently no plans to provide dedicated functions.

This example is pattern of using regioninfo.Fact.register.
AwsCustomResource will experimentally supports AWS SDK for JavaScript v3 (NODEJS_18_X or higher) by this PR. In AWS SDK for JavaScript v3, packages are installed for each service. Therefore, specify the package name for service. Also, action specifies the XxxClient operations provided in the package. This example is the same as SSM.getParameter in v2.

import * as regionInfo from 'aws-cdk-lib/region-info';
// change custom resource default runtime
regionInfo.Fact.register({
  region: 'us-east-1', // your region
  name: regionInfo.FactName.DEFAULT_CR_NODE_VERSION,
  value: lambda.Runtime.NODEJS_18_X.name,
}, true);
new AwsCustomResource(this, 'GetParameter', {
  resourceType: 'Custom::SSMParameter',
  onUpdate: {
    service: '@aws-sdk/client-ssm', // 'SSM' in v2
    action: 'GetParameterCommand', // 'getParameter' in v2
    parameters: {
      Name: 'foo',
      WithDecryption: true,
    },
    physicalResourceId: PhysicalResourceId.fromResponse('Parameter.ARN'),
  },
});

Others

• I added 3 packages for testing
  • @aws-sdk/client-s3
  • @aws-sdk/credential-providers
  • aws-sdk-client-mock
• I'm referring to part of the code at aws-sdk-js-codemod. The license is from the same organization, so I don't think there's a problem, but I'll write it down for confirmation.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[TheRealAmazonKendra]

Oh wow! I was about to start working on migrating us over to V3 so I'm SO excited to see this contribution!

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[MrArnoldPalmer]

This is some great stuff!

I have been working on making the default custom resource runtime Node18 and AwsCustomResource is definitely the hard part. This solves my biggest concern in backwards compatibility. I have been investigating how to dynamically create the service list and map v2 to v3 service names, but we can do that in a follow up PR if we can figure out a way to do it reliably.

Since this allows for backwards compatibility, I think we should merge it (a couple of small changes requested), then enable Node 18 as the default CR runtime behind a feature flag separately.

Pull request has been modified.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: bcae03b
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).