[Low Priority] Investigate using CloudFront w/ custom domain

[deeheber]

Not necessary, but a nice to have bc we can use SSL certs to get rid of the insecure website errors that sometimes show up in certain browsers.

Ideally we'd set this up as an optional param passed as prop into the CDK app. If yes, deploy with CloudFront. If no, deploy as is with just the S3 bucket.

Some potential helpful resources (isitsnowinginhillsboro.com is not registered with Route 53 currently)
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/migrate-dns-domain-in-use.html

[deeheber]

Plan of action thinking

Add the following resources to the existing weather stack:

• hosted zone*
• certificate*
• bucket (done)
• OAI
• S3 origin
• distribution
• a record*

Allow for an optional env var to specify a custom domain name. If this is present, create the resources listed above with the * next to them. If env var is absent, don't create those resources or go with the CDK default.

Cloudfront certificates must be hosted in us-east-1. Could set this up using cross region references, but I think for now specifying in the README that this must be deployed in us-east-1 if you want a custom domain also makes sense to simplify a bit.

We'll also need to add a state to the Step Function to invalidate the Cloudfront cache on index.html after it is updated.

[deeheber]

I should also add a note to my blog post on this.

• https://danielleheberling.xyz/blog/serverless-weather-reporting/
• https://dev.to/aws-builders/serverless-weather-reporting-with-aws-step-functions-and-cdk-8c8