@aws-cdk/aws-certificatemanager.Certification to support Global certificate creation

[PhilKershaw]

• I'm submitting a ...

  • 🪲 bug report
  • 🚀 feature request
  • 📚 construct library gap
  • ☎️ security issue or vulnerability => Please see policy
  • ❓ support request => Please see note at the top of this template.

• What is the current behaviour?

When creating a certificate like:

const certificate = new certificatemanager.Certificate(this, `${domain}-cert`, {
  domainName: domain,
  validationMethod: certificatemanager.ValidationMethod.DNS,
  subjectAlternativeNames: [`www.${domain}`]
})

The certificate is created in the region specified in the profile.

• What is the expected behavior (or behavior of feature suggested)?

As is with the ability to specify whether the certificate should be global - i.e. for CloudFront - or adding the ability to customise the region, though this option seems overkill.

• What is the motivation / use case for changing the behaviour or adding this feature?

Would like to create an ACM Certificate for a domain not yet managed via Route53 - so not able to leverage DnsValidatedCertificate, where region can be specified - in order to provision CloudFront in front of an S3 bucket.

• Please tell us about your environment:

  • CDK CLI Version: 1.3.0
  • Module Version: 1.3.0
  • OS: OSX Mojave
  • Language: JavaScript

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. associated pull-request, stackoverflow, gitter, etc)

Related to #3464

[jkueh]

CloudFormation (and by extension the CDK) deploys resources into the region in which the CloudFormation stack lives (with the exception of StackSets).

Would this be considered a bit of an anti-pattern for CloudFormation, and therefore the CDK?

It almost sounds like the ACM certificate is being coupled to something else - Have you considered decoupling it, and using env props to specify a deploy region for the certificate stack?

Personally, I'd create a certificate stack in the 'global' region (aka us-east-1) - That way you're not coupling everything to an application stack if your application lives in another region.

A little something like this, perhaps?

Edit: I misread - You're asking for the ability to prevent the module from attempting to create the Route53 records, because the zone exists outside of the account?

[PhilKershaw]

@jordankueh You are quite right in your first read - though I do have another issue open regarding cross account deployments and Route53 #3470. I am essentially asking to be able to issue a certificate in a different region from the CloudFormation stack.

This isn't so much a design decision but how this particular part of AWS works. CloudFront (a global service) requires an ACM certificate (regional service) to be issued in us-east-1 but is configured with an origin which resides in eu-west-1. To avoid the problem the stack would have to be deployed entirely to us-east-1 which isn't the right fit for the solution. It's a pretty light stack and splitting in to multiple stacks doesn't seem sensible. Though, nested stacks are an option but would need to wait for nested stack support in CDK.

Maybe I do need to reconsider my approach here. However, while somewhat of an anti-pattern the president has already been set and the ability to deploy a stack in a specific region with a certificate in a different region is already there with DnsValidatedCertificate.

[jkueh]

@PhilKershaw I appreciate the clarification - And I'm familiar with the CloudFront conundrum™, so I empathise! 😄

I suspect what's happened here is when Certificate was initially written the idea was to reach feature parity with the Cloudformation resource (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-certificatemanager-certificate.html) - And DnsValidatedCertificate came along later with all the shiny new features 😂

Considering that there'd be a bit of ClickOps™ for validating the certificate anyway, you could justify it as a separate stack that way... Until they support the region parameter ;)

[rix0rrr]

We are unfortunately not able to create regular Certificates in a different region. The only reason we can in DnsValidatedCertificate is because that is a custom resource.

You could automate this by writing your own custom resource, and you could share your implementation with others via NPM, but I'm not sure the base construct library is a place for a resource that does this.

[mattiLeBlanc]

So I find this really weird, I do everything via CDK, in region AP-southeast-2, and now I noticed that creating the Certificate and linking it to my cloudfront doesnt work, because the CDK will create the certificate in the region of the profile used during deploy.
But it needs to be US-EAST-1.

 const hostedZone = HostedZone.fromLookup(this, `${this.props.rootName}HostedZone`, {
      domainName: hostedZoneUrl
    });

    const acmCertificate = new Certificate(this, 'Certificate', {
      domainName: certificateUrl,
     
      validation: CertificateValidation.fromDns(hostedZone),
    });

Since I do all this in CDK, it doesn't make sense to give this example in https://docs.aws.amazon.com/cdk/api/latest/docs/aws-certificatemanager-readme.html.
This would only for for customers working in US-EAST-1 region, not the rest of the world.

Is it an idea to add a region property to the new Certificate class so that we can automate it and create the certificate in the correct region?
I now have to manually issue the certificate :(