이번에 기존 서비스의 도메인을 변경하면서 AWS CloudFront, Router53 등 배포 세팅을 하게되었다.
마주했던 이슈와 ChatGPT로 문제 핸들링을 함께한 경험을 회고하며, 추후에는 동일한 문제가 발생하지 않도록 기록을 남겨본다.

Why(왜 이 작업을 했는가?)

기존에는 브라우저에서 A라는 도메인명을 통해 자사 서비스가 접근했었다.
이번에 서비스명이 재정립되면서 브라우저에 노출되는 도메인명도 B로 변경하기로 하였다.

How(어떻게 했는가?)

Amazon S3의 정적 파일을 CloudFront를 통해 도메인과 연결하여 작업했다.

1. S3에 새로운 버킷 example을 생성하고, 해당 버킷 안에 빌드한 정적 파일을 넣는다.
   • pipeline을 통해 code commit으로 push했을 때, 자동으로 해당 버킷에 code build, code deploy되도록 구축했다.
2. CloudFront에서 배포 생성을 클릭한다.
   a. origin 을 설정한다.
   b. 우리는 OAI가 아닌 OAC설정을 하여, 만들어진 버킷의 정책에 권한을 설정하였다.
   c. 대체 도메인을 추가하고, 인증서로 연결한다.
3. Router 53에 인증한 인증서에 레코드를 추가한다.
   • 별칭으로 CloudFront에서 설정한 배포를 선택하고, 대체 도메인 이름에 맞게 호스트 이름을 설정한다.

OAI(Origin Access ID) : ID를 CloudFront 배포와 연결하여 S3 버킷에 대한 보안 액세스를 가능하게 하는 기능이다.
OAC(Origin Access Control) : OAI를 개선한 기능으로, 단기 보안 인증과 더불어, 자주 보안 인증 정보를 교체하여 보안 태세를 강화한다. (AWS에서도 OAC 사용을 권장)

OAI와 OAC에 대한 자세한 내용들은 다음 AWS페이지를 참고

What(무엇을 도출했는가?)

바뀐 도메인 B로 서비스 접근이 가능해졌다.

Issue

버킷 정책을 적용했는데, 정적 파일 내 일부 폴더에서 cors 이슈 발생

Access to font at '요청 url' from origin 'null' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

새로 배포한 도메인 이름으로 요청을 보냈을 시, js 와 css 파일은 잘 받아와 서비스를 호출하는데, 다른 폴더에 있는 폰트로 접근시, cors 이슈가 발생하였다.
ex) B/static/main.js로는 접근이 가능하나, B/static/media/font로 접근시에는 cors 이슈 발생

chatGPT에게 설정한 AWS 버킷의 CORS configuration을 보여주며, 다음 에러가 발생하는 이유가 무엇일까?물어보니, 다음과 답변을 받았다.

Your CORS configuration seems to be allowing all origins (*), all headers (*), and only GET and HEAD methods. This should allow cross-origin requests to be made to your CloudFront distribution without encountering any CORS-related errors.

However, if the issue persists, you may want to try the following troubleshooting steps:

1. Double-check that your CloudFront distribution is actually using the CORS configuration that you have set. You can verify this by checking the distribution's settings in the AWS Management Console.
2. Check that your font files are being served with the correct MIME type. If the font files are being served with an incorrect MIME type, this can cause some browsers to block them. Make sure that your server or CDN is serving the font files with a Content-Type header that corresponds to the font's file type (e.g. application/font-woff for WOFF files).
3. Check that your font files are accessible and have the correct permissions. Make sure that the font files are located in a directory that is accessible to the web server or CDN, and that they have the correct permissions set so that they can be served.
4. If the font files are being loaded using a relative URL (e.g. ../fonts/myfont.woff), try using an absolute URL instead (e.g. /fonts/myfont.woff). Some browsers may interpret relative URLs differently and cause CORS issues.
5. If none of the above steps work, you may want to try using a tool like Fiddler or the Chrome DevTools to inspect the network traffic and see if there are any specific errors or warnings related to CORS. This can help you narrow down the issue and find a solution.

I hope this helps you resolve the CORS issue with your font files.

문제 해결을 위한 시도들

1번째 방법 : 배포 설정 더블 체크 (이미 함)

2번째 방법 : header에 content-type을 넣었는지 확인 (이미 함)

3번째 방법 : 파일에 대한 권한 확인 → 동일 디렉토리 다른 폴더로는 접근 가능하니, 파일 권한 문제는 아닌것으로 판단
s
✅ 4번째 방법 : 일부 브라우저에서는 상대 URL을 다르게 해석하여 CORS이슈가 날 수 있으니, 절대 경로로 바꿀 것

5번째 방법 : 네트워크 트래픽 검사해서 오류 확인

내가 적용한 해결책은 4번 방법이었다.

해당 방법을 택한 이유는 동일한 요청을 safari로 보냈을 때는 cors이슈가 안나고, chrome에서 발생했기 때문이다!

그래서 폰트 파일 경로를 절대 경로로 수정하여 미리 구성한 파이프라인을 통해 재배포하였다.

… 문제는 그래도 동일한 cors 이슈가 나는 것 🥲

최종적인 원인은 cloudfront 무효화 작업이 안되어, 기존 캐싱된 파일을 가지고 왔었던 것이다.

cloudfront > 배포 > ID 클릭 > 무효화 탭 클릭하여 생성

무효화 처리를 다음과 같이 해줌으로써, S3의 해당 버킷 내 모든 파일들 중 변경사항 발생 시, cloudfront도 재배포되도록 처리하여 최신화 작업을 진행할 수 있었다!

참고 자료
ChatGPT
Amazon CloudFront, 오리진 액세스 제어(OAC) 시작