cloudkj / scar Goto Github PK

Deploy static websites in seconds - with HTTPS, a global CDN, and custom domains.

License: MIT License

HTML 1.24% JavaScript 98.76%

static-site serverless aws s3 cloudfront route53 cloudformation

scar's Introduction

SCAR: 1-click static website deployment on AWS

Tired of reading outdated blog posts or combing through verbose AWS documentation just to figure out how to deploy your blog? Deploying static websites on AWS shouldn't be so scary.

SCAR is a deployment stack that make it easy for you to deploy a static website with a custom domain, SSL, and a CDN. All you need is an AWS account to get started in three simple steps:

Quick Start

1. Launch a new stack using the AWS console to create all the required resources

2. Update the settings at your domain registrar to use the Route 53 name servers

Find the name servers from your newly created Route 53 hosted zone, then update the name server settings at your registrar.

3. Validate the domain for your new ACM certificate

Find and expand the details of the certificate for your domain in the AWS console, then click the "Create record in Route 53" buttons in the two prompts for validation.

That's all, folks!

Use the CloudFormation console to check the status of the stack. Once it has been created, navigate to your given domain, and you should see the SCAR welcome page. You can now upload the contents of your website directly with the S3 console, or use the AWS CLI for programmatic control.

Stack

SCAR is a deployment stack for static websites running entirely on AWS, using S3, CloudFront, Amazon Certificate Manager, and Route 53. For a given domain such as example.com, the default SCAR stack will create the following:

Two S3 buckets, one for storing the contents of your static website (www.example.com) and another for redirecting requests for the apex domain (example.com) to the www subdomain.
Two CloudFront distributions, one for each S3 bucket.
One ACM public SSL/TLS certificate for both example.com and *.example.com
One Route 53 hosted zone, with an A record for each CloudFront distribution.

The behavior for the default SCAR stack is to redirect all requests for the apex domain to the www subdomain, and to redirect all http requests to https. All content will be stored in and served out of the www S3 bucket.

Additional stacks with slight variations from the default stack are also available:

Behavior	Default	WWW->Apex	Apex only
Apex domain requests	Redirect to `www`
`www` subdomain requests		Redirect to apex domain	N/A
`http` requests	Redirect to `https`	Redirect to `https`	Redirect to `https`
		(Coming Soon)	(Coming Soon)

Name Server Settings

FAQ

How much will this cost?

For most sites, it will likely cost less than $1 per month. The cost for a Route 53 hosted zone is fixed at $0.50/month; the remaining CloudFront and S3 costs depend on the levels of traffic, but typically amount to a few cents for small levels of traffic.

What tool did you use to draw the diagram above?

The AWS CloudFormation Designer tool allows drag-and-drop creation of templates, and also creates diagrams from existing JSON or YAML template files.

License

scar's People

Stargazers

Watchers

scar's Issues

Suggestion: Add estimated cost to README

I like the idea and am curious about what the monthly cost would be (or if it stays within the free tier) to run all these services.

Diagram Tool

What tool did you use to make this image? https://github.com/cloudkj/scar#stack

Delete the CNAME DNS record used for certificate validation in hosted zone

Attempting to delete a newly created SCAR stack in CloudFormation currently fails due to the CNAME DNS record that is created manually as part of the validation step. A custom resource could be added to the template to remove this record from the hosted zone so that the record is deleted after validation is successful.

Add template for apex domain only

Template for a stack with no www subdomain.

Add template for www->apex redirection

Template for a stack that is the same as the default stack, but redirects requests for the www subdomain to the apex domain.

Update docs to reflect us-east-1 limitation due to restriction on using ACM and CloudFront

As per https://docs.aws.amazon.com/acm/latest/userguide/acm-regions.html, ACM has a restriction that requires certificates to be created in the us-east-1 region in order to be used with CloudFront:

To use an ACM Certificate with Amazon CloudFront, you must request or import the certificate in the US East (N. Virginia) region. ACM Certificates in this region that are associated with a CloudFront distribution are distributed to all the geographic locations configured for that distribution.

The docs should be updated to reflect this limitation. It's possible that CloudFormation Stack Sets can offer a path forward by requesting only the ACM certificate in us-east-1 but other resources in the chosen region, but some work is needed to see if that's possible.

See #9 (comment)

Suggestion: Replace second bucket and CloudFront distribution with Lambda function

A Lambda@Edge deployment would, I think, be a more lightweight solution for redirection than another bucket and distribution.

Something like (written for !Sub):

exports.handler = async (event, context) => {
    
    const request = event.Records[0].cf.request;
    const headers = request.headers;
    const host = headers.host[0].value.toLowerCase();

    if (host == 'www.${APEX_DOMAIN}') {
        /*
         * Generate HTTP redirect response with 302 status code and Location header.
         */
        const response = {
            status: '302',
            statusDescription: 'Found',
            headers: {
                location: [{
                    key: 'Location',
                    value: 'https://${APEX_DOMAIN}',
                }],
            },
        };
        return response;
    } else {
        return request;
    }

};

ACM Pricing

$0.50 sounds nice, but doesn't ACM charge additional $400.00 for setup (after 30 days trial)?

https://aws.amazon.com/certificate-manager/pricing/

May be good to point out in the description?

Include certificate validation using CNAME DNS record as part of template

Adding this would remove the need for the third manual step in the quick start guide - to manually validate ownership of the domain by creating the CNAME records using the AWS ACM console.

Preliminary research seems to indicate that official CloudFormation support for template-driven certificate validation may be coming, but until then some potential solutions are: