こちらの記事を読んで
Nuxt.jsとContentfulでモダンなブログを構築してみた
自分のケースを書いて置きたいと思いました。
CloudFront + S3構成について
自分はLambda@Edgeは設定していないです。
index.htmlとか、サブURLの処理のため、Lambda@Edgeの利用でなく、
CloudfrontのError Pagesに、400, 403, 404のResponse Page Path を /に、HTTP Response Codeを200に設定しています。
一つ短所としては、cloudfrontにWAFを連携しいる場合。
WAFによって403になってもindex.htmlだけ読み込まれるので、
テスト環境では Error Pagesの403設定は外しています。
もしくは、テスト環境でアクセス制限のために Lambda@Edgeを利用しています。
以前からこの設定をやっていましたが、
最近 AWS AmplifyのHostingの作ったCloudFront + s3のhosting環境の同じ設定でした。
なので、awsのお墨付き方法だと思います。
デプロイ
aws codebuildの設定fileの一部です。
- npm run generate
- aws s3 cp dist s3://$S3_BUCKETNAME --recursive
- aws cloudfront create-invalidation --distribution-id $CLOUDFRONT_DISTRIBUTION_ID --paths '/*'
これだけにしています。
これだけでも、デプロイ中にサイトがエラーになることはないかと思います。
なぜなら、CloudfrontでObject cacheをしていからです。
（もし、静的コンテンツをObject cacheをせずに TTLを全部０にしている場合はエラーになるでしょう）
Nuxtでbuildした場合、js filenameはdefault設定でhashになっていて、そのhash filenameはindex.htmlに記録されています。
なので、fileを削除しなければdeploy中でもエラーになったりはしないです。
また、index.html,jsともにcloudfrontによってcacheされているので、削除したとしても大抵の場合は大丈夫です。（一度も呼ばれてないfileをdeployタイミングで呼ばれたらエラーになる可能性はあります。）
また、このデプロイ方法も AWS AmplifyのHostingで amplify publishでやっている方法と同じです。
なので、awsのお墨付き方法だと思います。
デプロイでAmplify cliを使うのはだめなのか？
どのみち、cloudfront + s3を利用するなら、amplifyでしたくなります。
私もそうでしたので
やってみましたが、まだ現時点（2019/02/20）では、
amplify hostingを amplify cliはci/cdは完全ではない感じでした。
最近、amplify cliもupdateされて、multiple envとheadless optionができているが、
結局まだ足りない部分があったり、
むしろ上のbuildspec.ymlの3行より複雑になるので、ci/cdではamplify cliを使わずに利用しています。