이 기사를 읽고
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만 로드되므로,
테스트 환경에서는 오류 페이지의 403 설정이 제거되었습니다.
또는 테스트 환경에서 액세스 제한을 위해 Lambda@Edge를 사용합니다.

이전부터 이 설정을 해왔지만,
최근 AWS Amplify Hosting이 만든 CloudFront + s3의 hosting 환경의 동일한 설정이었습니다.
그래서, aws의 먹이 첨부 방법이라고 생각합니다.

배포

aws codebuild 설정 파일의 일부입니다.

buildspec.yml

      - 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을 모두 0으로 하고 있는 경우는 에러가 됩니다)

Nuxt로 빌드하면 js filename은 default 설정에서 hash가 되고 hash filename은 index.html에 기록됩니다.
그래서 file을 삭제하지 않으면 deploy중에서도 에러가 되거나 하지 않습니다.
또, index.html, js 모두 cloudfront에 의해 cache 되고 있으므로, 삭제했다고 해도 대부분의 경우는 괜찮습니다. (한 번도 호출되지 않은 파일을 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를 사용하지 않고 이용하고 있습니다.