New Pattern: aws-route53-acm-cloudfront

[SureshkumarKV]

It is often necessary to use a custom domain with SSL certificate on a CloudFront distribution. While existing patterns like aws-s3-cloudfront can serve files, setting up custom domain for the CloudFront and attaching SSL certificates needs additional work. This is particularly hard for someone who is not familiar setting up certificates and DNS records. The proposed construct will make it easy to create CloudFront distributions that is ready for production with custom domain and SSL certificate.

Use Case

• The proposed construct can be used along with aws-s3-cloudfront construct to deploy static websites with custom domain and SSL certificate.
• The proposed construct can be used along with aws-cloudfront-apigateway to create custom, secure endpoints for user facing APIs.

Proposed Solution

The proposed construct has the following features:

• Automatically verify domain ownership and provision SSL certificate using ACM. (Fully automatic if Route53 is used as the DNS service.)
• Import an existing SSL certificate using its ARN.
• Configure cloudFront to use custom domain by adding alias configuration.
• Use incoming hosted zone or create one and then link it to CloudFront using Alias record.

Other

I have used this pattern in multiple prototypes and a solution construct of this pattern can made the CDK script shorter and elegant.

• [x] :wave: I may be able to implement this feature request
• [ ] :warning: This feature might incur a breaking change

---

This is a :rocket: Feature Request

[biffgaut]

Thanks - we will review this and get back to you shortly!

[SureshkumarKV]

Architecture diagram.

[biffgaut]

Great stuff - this looks good! When the team discussed it we had a couple of observations-

• The key services here are Route53 and CloudFront, so let's call it aws-route53-cloudfront. ACM is a property of the relationship between the two, so the construct props interface will include a flag whether or not to include ACM (if true, then the construct is exactly what you describe here, if false then no certificate is involve).
• This sets up a pattern for a number of other constructs - aws-route53-apigateway, aws-route53-applicationloadbalancer, etc. When designing and building this want to keep that in mind so that swapping out the Cloudfront service for a different service is straightforward.

Next step is for you to create a README.md file for the construct that defines the Props, properties, minimal use, etc.

[SureshkumarKV]

Thank you !

Please help me with a couple of clarifications about the 2 points before I proceed with the ReadMe.md file.

1. CloudFront with custom domain won't work without ACM. Therefore, we cannot give the option to enable/disable ACM. ACM will always be there when a custom domain is being used. The name aws-route53-cloudfront still sounds nice as ACM is implied for this construct. Please let me know if there is a way around this restriction.
2. Understood. I will prepare the code such that we can create the other constructs namely aws-route53-apigateway and aws-route53-applicationloadbalancer easily based on the code of this one. Please do let me know if I didn't get this right.

[biffgaut]

That's why we depend upon the community, because AWS is so vast that you often know more about the service areas you are proposing than we do! So a certificate is not optional.

My followup would be does it have to be an ACM certificate? If a client has a certificate from another authority can the client provide that certificate? If that is an order of magnitude more complex, could there be a path to support that in a a future non-breaking update?

[biffgaut]

BTW - exactly right on point 2.

[SureshkumarKV]

Thanks a lot @biffgaut !

We can support certificates from other parties once those have been imported into ACM. I will prepare the ReadMe.md including this feature.

[SureshkumarKV]

Hi, I have created a pull request with the README.md at: https://github.com/awslabs/aws-solutions-constructs/pull/135

Please review.