Tips of distributing a static site created with Nuxt.js on AWS (CloudFront + S3)

ScrapboxからのReprinted from my Scrapbox.

Tips for delivering a static site built with Nuxt on AWS CloudFront + S3. This is mainly just the part I got into, but I hope it helps someone else.

Premise

I think SPA built with React or Vue or its related frameworks, the directory structure might be as follows.

 .
 ├── 200.html
 ├── _nuxt
 │   ├── LICENSES
 │   ├── 1234567890abcdef1234.js
 │   ├── abcdef1234567890abcd.js
 │   └── img
 │       ├── 1234567.svg
 │       └── abcdefg.png
 ├── dashboard
 │   └── index.html
 ├── favicon.ico
 └── index.html

When you open a SPA created by Nuxt with no settings in CloudFront, you can use the following problems.

• If the URL of the Root is opened without specifying the resource, it becomes Access Denied.
• If you specify index.html directly, Nuxt routing doesn't work well and causes an error becomes.

First, we need to set up a solution for this.

Configuring CloudFront's Default Root Object

When using CloudFront + S3, the web app will not work properly if the Default Root Object is not specified, as shown below.

foobar.com --> NG

foobar.com/index.html --> NG

Specify index.html as the default root object for CloudFront will allow access to https://foobar.com to be made available to index.html. Then, Nuxt's Routing will also work properly.

Error Page Setup

Accessing the root ( foobar.com ) is fixed by the Default Root Object setting, but If you go to a subpath in the SPA, such as foobar. com/dashboard, there is a problem.

In the above example, CloudFront has access to a directory of /dashboard and it returns 403 by default. But in order to make Router of Nuxt.js work properly, it should return /dashboard/index.html on access for /dashboard.

So, you can use CloudFront's Custom Error Response. Here's an example configuration.

This will ensure that access to /dashboard will work properly.

Adding Custom Header to your content

Web apps usually require some security measures. For example, to prevent clickjacking, the response header of the html should include an X- Frame-Options: Append DENY, etc.

You can use Lambda@Edge to achieve this. Settings are very easy. If you follow the tutorial, you can set it up without any problems.

The problem here is that the page delivered as an error page apparently has a Lambda@Edge doesn't work. So, in the above example, when you visit foobar.com/dashboard, Lambda@Edge function is not called and Custom Header is not given.

I found out that the CloudFront specification only runs Lambda@Edge for error pages in Origin Response. This means that in the Viewer Response when the cache is hit, the Lambda@Edge is not executed. In such case, you can set the TTL of the error page's cache to 0, as shown below. Performance is sacrificed, but it's inevitable.

That's it, the static site I wanted to deliver is now delivered without any problems. For now.