Steps to deploy a React app on S3 with CloudFront while managing caching?

Question

I need to deploy a React App on AWS S3 using SSL and managing caching. What are the required steps, and what are some of the problems I might encounter?

Answer 1

Why do this?

It can be incredibly fast, "serverless" and very inexpensive. Through the CloudFront global endpoints (edge locations), an application can run very quickly with high reliability. By setting another source origin, CloudFront can act as a reverse proxy to an API, eliminating cross-region (CORS) issues and accelerating API calls in distant locations. Multiple deployments can be uploaded to a single S3 bucket.

Basic Concepts

There are a number of concepts to keep in mind when deploying a Create React App to S3/CloudFront:

• CloudFront front end - for a custom domain, SSL traffic will go through CloudFront and not S3 (which does not permit SSL with a custom domain)
• One to many - a single S3 bucket can hold many deployments (e.g. testing, production). I set up each deployment with a dedicated CloudFront distribution pointing to the same bucket but a different prefix (e.g. deployments/testing, deployments/production)
• Cross-domain API issues can be avoided - there is a way to use CloudFront for both static files in S3 and a dynamic API, all in the same domain (see below)
• Compression - compression should always be enabled on CloudFront
• Browser caching - CRA build will create chunk files with hash keys. These can be cached in the browser for long periods. But files without hash keys like index.html should be set for no-caching. These caching attributes can set through S3.

Cross-domain API issues (CORS) - how to avoid

Each CloudFront distribution can have multiple origins. One origin should be set to S3, while the other can be set to an API server or load balancer. If the API server is within the AWS system, CloudFront can safely use non-SSL (port 80) to communicate as a proxy server.

To use port 80, the API server must be configured to respond to the non-secure traffic (if traffic is only port 80, no SSL certificate is required). The Apache VirtualHost will use the hostname of CloudFront instance not the API server hostname (e.g. my.react-app.com not my.api.com) because the HTTP request Host value is not modified.

To enable the API with CloudFront:

1. Add your API server as an origin, HTTP only if within AWS
2. Add a new behavior, /api/* path pattern, HTTPS only viewer policy, all HTTP methods (unless you have GET only), ALL for Cache Based on Selected Request Headers, Compress Objects enabled, and Forward All for the query strings
3. Nothing should be cached by CloudFront (unless you can do this)

Copying to S3

A simple way to copy your build system to S3 would be:

aws s3 sync . s3://MY-S3-BUCKET/ --quiet

This is quite limited. It will not manage browser caching easily. Old files can be removed (--delete option) or maintained (default); of course this tool is agnostic to which CRA files should be maintained for older versions, so garbage collection will be complicated.

Python Tool for Deploying CRA to S3 / CloudFront

I built a python tool which will:

1. upload any new files to S3, validating the Etag to MD5
2. delete any old files
3. optionally maintain old files that were part of earlier builds (downloading and parsing older precache-manifest files)
4. set the HTTP cache parameters for different files (i.e. cache files with hash keys, no cache for common files)
5. clear the CloudFront distribution (i.e. invalidation request)

Even if you don't use this, it may help you out with your deployment system.

Enabling React Router in CloudFront

To enable different paths in React Router, set the the CloudFront error page to be /index.html (so that all failed requests will go there):

1. Go to CloudFront distributions in the AWS console
2. Click on the appropriate CloudFront distribution
3. Click on Error Pages tab
4. Add error responses for 403: Forbidden and 404: Not Found pointing /index.html with HTTP response of 200

Testing HTTP headers

You can view this HTTP header if your S3 bucket is set for static website hosting (note S3 website hosting is not required for CloudFront to work):

curl -I http://MY-S3-ENDPOINT/index.html

Likewise you can test the header from CloudFront:

curl -I https://CLOUDFRONT-URL/index.html

To test compression, add encoding acceptance to the request HTTP header, e.g.

curl -H "Accept-Encoding: gzip" -I https://CLOUDFRONT-URL/index.html

Answer 2

Great question and answer @charlie-hileman, thanks for sharing! In regards to "some of the problems I might encounter", I was exploring the associated costs of this approach, and I thought it might help someone else coming to this question.

CloudFront docs:

No additional charge for the first 1,000 paths requested for invalidation each month. Thereafter, $0.005 per path requested for invalidation.

Easy formula, but tricky to factor without a real-world project.

Formula:

0.005 * ((files * deployments) - 1000)

My fairly modest create-react-app generates 202 files (a lot of which are webpack chunks due to the default chunking strategy). I'll round it down to 200 for easy maths. That means I get roughly five invalidations per month for free:

0.005 * ((200 * 5) - 1000)      // $0.00

Beyond that, each deployment costs $1.

Let's scale that. Say I work roughly twenty days a month (five days a week, avg four weeks per month). At that rate, here's the cost if I deploy on average 1x day, 2x day, 3x...

0.005 * ((200 * 20 * 1) - 1000) // $15/mo
                   * 2          // $35/mo
                   * 3          // $55/mo
                   * 4          // $75/mo
                   * 5          // $95/mo

That's actually still relatively economical considering the benefits, now that I'm going into it understanding the costs. Plus, it might be an amortized cost if the project will stabilize and have fewer deployments over time. I would factor this against comparison operating costs of (for example) keeping a Node server up to host this project.