Cloudformation-coverage-roadmap: AWS::CertificateManager::Certificate - Region

[jk2l]

1. Title

AWS::CertificateManager::Certificate - Region

Add new parameter for EDGE or REGIONAL (default REGIONAL).

Samples:

  SslCertificate:
    Type: AWS::CertificateManager::Certificate
    Properties:
      DomainName: domain.com
      SubjectAlternativeNames:
        - *.domain.com
      ValidationMethod: DNS
      Region: GLOBAL
      DomainValidationOptions:
        - DomainName: domain.com
          HostedZoneId: 123456789ABC

2. Scope of request

When I want to create one single stack with Cognito custom domain, or CloudFront I need to create the certificate in us-east-1 manually first. But I would like to have my certificate to be deployed from within the same CloudFormation template with my Cognito/ApiGateway...etc

Current behaviour for Cognito custom domain even if I deploy the Cfn stack in other regions such as ap-southeast-1, it is actually deployed it into us-east-1 as it is global resource via Edge location (if I am not mistaken).

However, this will require me to deploy the one environment in two separate regions. Having a centralized Cfn will allow management part so much easier.

The biggest issue of no support multi-region properly is that if there is a bug happen in the template, it cannot fully rollback properly, also rolling out a new update of certs (e.g. add a new alternative name) will change the ARN. if I have a multi-account environment (I have 10 environments planned). manage all ACM Arn one by one can add a lot of overhead and issue

3. Expected behaviour

With the additional parameter mark it as global, the certificate can be used by CloudFront. Even if everything deploys in a different region

4. Suggest specific test cases

as mentioned in section 3.

5. Helpful Links to speed up research and evaluation

• Look for "Virginia" in the following docs

https://aws.amazon.com/premiumsupport/knowledge-center/custom-ssl-certificate-cloudfront/
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-add-custom-domain.html
https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html

Also for the sake of consistency, we can copy AWS::ApiGateway::RestApi EndpointConfiguration parameter format to use Edge, Regional as the option

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-restapi-endpointconfiguration.html

6. Category (required) - Will help with tagging and be easier to find by other users to +1

1. Compute
2. Networking & Content
3. Management
4. Security

[jk2l]

slightly updated the description to be inline and consistent with API gateway https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-restapi-endpointconfiguration.html

instead of calling them GLOBAL and LOCAL. it should be called EDGE and REGIONAL

[rrrix]

Great idea!! 👍

We also just ran into this today while trying to setup a Cognito Custom Domain Name in us-west-2. I can't think of an elegant solution that doesn't require me managing 2 additional stacks or writing a custom resource Lambda to do the necessary cross-region stack deployment coordination for me.

[jk2l]

Also suggested an alternative solution in #562

[max-allan-surevine]

See my answer to #630 . This is probably now possible with stacksets as cloudformation objects.

Your challenge is likely to be getting the properties of resources created in the sub-stacks.
I think your main stack would need to run in us-east-1 and create the ACM and then pass the ACM ID in to the nested stack, where the work happens in your other region. As long as you don't need to pass any information back from the region to us-east-1, I think you're OK. There is no "output" from the stackset.

[jk2l]

hm... this can be more difficult to deploy into us-east-1. as I have big infrastructure stack that also passing around parameters from other stack's output. it will be much easier to deploy ACM as sub stack into us-east-1 instead of the other way round.

[jk2l]

@max-allan-surevine how difficult will it be to introduce support for output references?

[max-allan-surevine]

I've just done it. It is pretty mind bending. I used some SSM params in the master region that a lambda in the sub-region can update. Then using the same concept and a custom resource type, that runs a lambda to update SSM.
If it is just one value you want to pass, shouldn't be too hard. If it is lots of values, I can imagine it getting very messy!! But for an ACM cert, it should be even easier than my example (that runs on 2 regions).
In this example, set reportValues.Input to whatever you want to "share" with the master (eg !Ref ACMCert)

example_region.txt

[aripalo]

Wanted to chime in and provide a use case for this feature request, since it would make things a lot easier for us.

Use case for Region: EDGE|REGIONAL

The challenge with multiple dynamic domains, AWS CloudFront, AWS Certificate Manager with infrastructure-as-code and other than us-east-1 as default region.

Background

DNS Setup

• We develop multiple projects - think of APIs & services - that live under a "official basedomain", for example example.dev|.com.
• We also utilize multiaccount strategy where each project/product/product-family (depends on the use case) has 2 AWS accounts:
  
  
  
  • dev
  
  
  • prod
  
  
• Each account type has their own basedomain:
  
  
  
  • <project>.example.dev (dev-account)
  
  
  • <project>.example.com (prod-account)
  
  

Environments (and CI/CD)

We use multiple environments (deployed via CI-service):

• Main ones being:
  
  
  
  • production
  
  
  • staging
  
  
• …but also dynamic _preview_ environments, so a developer can actually deploy a new feature to AWS for testing and sharing it with stakeholders.
• There's also - manually deployed - development environment which is mostly used for some random testing and during initial project setup.

The challange

Our main region is eu-west-1 (Ireland), since it's in the EU, it's the close to us (Finland) and it's a feature rich region (compared to Stockholm).

We use AWS Cloud Development Kit (CDK) for infrastructure as code (CDK is based on CloudFormation).

The setup described above (in the diagrams) with environment specific domains and CI-controlled environments works like a charm otherwise, BUT it can be challenging to work with CloudFront and ACM:

1. CloudFront requires that the certificate covers the alternate domain name on the same level as the CloudFront alias: So one can't use *.foo.example.dev in a CloudFront distribution with alias of api.my-cool-feature.preview.foo.example.dev.
2. ... which means that each environment must create their own certificate, since we cannot know ahead of time about all the possibile subdomains.
3. Creating _DNS-validated_ ACM certificates _in principle_ is easy with CloudFormation and CDK.
4. ... but since we're deploying to eu-west-1 and CloudFront requires the certificate to exists in us-east-1, we need to use some kind of _CloudFormation Custom Resource_ trickery.
5. Luckily CDK provides acm.DnsValidatedCertificate for exactly that use case.
6. ... unfortunately, since it may take 30 minutes for ACM to validate the certificate and the Lambda (that power Custom Resources) execution timeout is 15 minutes means that deployments often fail.
7. Redeploying the stack again results in acm.DnsValidatedCertificate creating a new certificate (instead of using the certificate from previous deploy that probably is already validated), so the problem persists.
8. One could use the acm.Certificate CDK construct, that will use native CloudFormation to create the certificate...
9. ... BUT it's not an option, since CloudFormation cannot currently create a certificate to another region, remember that our main region is eu-west-1 and CloudFront requires ACM certificate in us-east-1!

So we're kind of stuck in this situation where new environment deployments randomly fail. We could probably create a separate CDK stack with acm.Certificate and deploy it to us-east-1 and then pass around the certificate ARN via Systems Manager parameter store, but that gets quite complex quite fast.

The perfect solution for us would be CloudFormation supporting certificate deployments to other regions, as proposed in CloudFormation roadmap issue #523 via Region-property (either REGIONAL or EDGE).

Also wondering if anyone else has hit this limitation with similar environment/DNS setup and how've they worked around the issue.

[Dzhuneyt]

@aripalo we have exactly the same use case minus the Git tag based production environments, and we often encounter the random stack deployments that you mentioned. Currently we found no feasible workaround besides creating a dedicated ACM stack in the us-east-1 region as you mentioned.

[andrewnicolalde]

It is very, very surprising that this isn't already supported given the requirement to use us-east-1 for API Gateway..

[aripalo]

Yep. The most depressing fact is that this seems not to be even on the roadmap (since no milestones etc is not assigned).

My guess is that most US-based users & folks at AWS don't see this as a problem since they're most probably deploying their workloads into us-east-1 anyway 🤷‍♂️

[jpluscplusm]

It is very, very surprising that this isn't already supported given the requirement to use us-east-1 for API Gateway..

I was gobsmacked, given that same requirement for CloudFront! I really hope this gets picked up sometime soon ...

[Purushotam-Thakur]

I'm also facing the same with my CloudFront, ACM as the other resources are in the eu-central-1 region while there is no option in serverless(CloudFormation) to change region while creating ACM.. any resolution or update on this??

[ankon]

We hit this as well for a serverless API, and worked around the problem using a custom resource. This was a lot of work (and a lot more than expected), but seems to work reasonably well for now.

[jesusch]

why ain't ACM a global service since the very beginning...

[sirbully]

Experienced this problem too. Managed to come up with something based on @max-allan-surevine article. My issue now is how to get the output to show up from the stackset. I wanted to use the output to dynamically add it to my Cloudfront distribution but it's not showing up, neither is the export value that I tried to add. But it runs with no errors.

Certificate:
    Type: AWS::CloudFormation::StackSet
    Properties:
      Description: Request a certificate from ACM in N. Virginia
      PermissionModel: SELF_MANAGED
      StackInstancesGroup:
        - DeploymentTargets:
            Accounts:
              - !Ref AWS::AccountId
          Regions:
            - us-east-1
      StackSetName: !Sub ${AWS::StackName}-NorthVirginiaACM
      TemplateBody: |
        AWSTemplateFormatVersion: 2010-09-09
        Description: Request a certificate from ACM in N. Virginia
        Resources:
          USCertificate:
            Type: AWS::CertificateManager::Certificate
            Properties:
              DomainName: {redacted}
              SubjectAlternativeNames:
                - {redacted}
              DomainValidationOptions:
                - DomainName: {redacted}
                  HostedZoneId: {redacted}
              ValidationMethod: DNS
        Outputs:
          USCertificate:
            Value:
              Ref: USCertificate
            Export:
              Name: ami-Certificate

[lracicot]

I have the same issue. We have to deploy a stack that includes API Gateway with a custom domain using a CI/CD stack and we want to be able to freely deploy it in any region without manual intervention. We don't have capacity for developing/maintaining a custom solution. This is a huge pain point and the sole blocker for our current project.

[jk2l]

why ain't ACM a global service since the very beginning...

lately I am more keen toward with my suggestion for #562 as I recently need to deploy a WAFv2 rule on top of the CloudFormation stack that is already deployed in ap-southeast-2. and found we come across the issue mentioned in #546

as this "region" deployment issue cover quite a bit different service. probably much more ideally to allow child stack to be deployed from same region and then refrence it's output

p.s. Solution from #630 is not a solution. as it does not allow refrencing output. so we will need to deploy custom solution on top of it which mean it back to square one (To have a solution that do not require hack like custom resource)

[mkamioner]

I think that solution #521 could answer this as well since it would essentially allow creation of certificates in multiple regions more easily.

[jk2l]

I think that solution #521 could answer this as well since it would essentially allow creation of certificates in multiple regions more easily.

how is this related? what we want within this ticket is that the creation of ACM cert is in same region with resource that depends on it (e.g. if I create the CloudFront in with CloudFormation ap-southeast-2, I want to be able to create CloudFront's ACM from same stack as well).

but at the moment it is not possible to create ACM in us-east-1 from within ap-southeast-2 (but if you create global resource like CloudFront from ap-southeast-2, it is actually create us-east-1)