[AWS][트러블슈팅] CloudFront Access Denied 에러 (This XML file does not appear to have any style information associated with it.)

문제 발생

구현한 웹페이지에서 뒤로가기 버튼 클릭시, 다음과 같은 오류가 자주 발생한다.

 

페이지를 처음 열고나서는 이런 오류가 잘 안생기는데, 몇분 뒤에 다시 사이트에 들어와서 뒤로가기 버튼을 누르면 아래와 같은 오류가 발생하는 현상이 있었다.

Access Denied
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
...
</Error>

 

오류의 내용을 살펴보니, S3 버킷쪽에서 Access Denied 오류가 발생하는것 같았다.

 

원인 분석

현재 내가 구현한 서비스는 프론트를 React로 구현하여, S3 버킷에 담고 이를 CloudFront가 접근하여 배포하는 방식이다.

 

이때, CloudFront가 S3 버킷에 접근하는 방법에는 2가지가 있다.

 

1. 객체 API 엔드포인트 (REST API) = 버킷 엔드포인트

 

• 형식: https://<bucket>.s3.<region>.amazonaws.com/<object-key>
• 의미: S3 서비스의 객체(오브젝트)를 API로 직접 읽고/쓰기(GET/PUT/HEAD/DELETE) 하는 전용 주소.
• 특징
  • 권한(ACL/버킷 정책/OAI·OAC, SigV4 서명) 을 엄격히 따름 → 비공개 버킷과 보안 연동에 적합.
  • 파일 단위로만 응답함. 요청한 키(<object-key>)가 실제로 있어야만 200을 줌.
  • 디렉터리 인덱스/라우팅 같은 웹서버 편의 기능 없음.
    → /page1 같은 “폴더/가상 경로” 요청이 들어오면, 그 이름의 객체가 없어 곧장 에러를 냄.
  • 존재/권한이 애매하면 403 AccessDenied (또는 404) 형태의 XML 에러를 반환.
  • CloudFront에서 원본(Origin)을 S3 버킷으로 선택하면 이 경로로 붙음.
    → OAI(Origin Access Identity) / OAC(Origin Access Control)로 서명된 요청을 날릴 수 있음

 

2. 정적 웹사이트 엔드포인트 (Static Website)

 

• 형식: http://<bucket>.s3-website-<region>.amazonaws.com
• 의미: S3를 간이 웹서버처럼 쓰게 해주는 모드의 주소.
• 특징
  • Index document / Error document 설정 지원 → 없는 경로라도 index.html로 폴백 가능.
  • 인증 서명(OAI/OAC) 미지원 → 버킷을 퍼블릭(또는 공개 가능한 수준)으로 열어야 함.
  • HTTPS 미지원(Origin) → CloudFront에서 원본 프로토콜을 HTTP only로 설정해야 함.
    (뷰어↔CloudFront는 HTTPS 유지 가능)
  • CloudFront 원본을 이 주소로 넣으면, S3의 “웹 호스팅 라우팅 규칙” 을 그대로 활용.

또한, 브라우저 주소창에 보이는 /page1 은 웹애플리케이션(SPA 라우터)가 만든 가짜 경로에 불과하다. 

 

예를 들어 React 앱의 경우에, 실제 버킷 안에는 index.html, bundle.js, style.css 같은 빌드 결과물만 있을 것이다. 

SPA 라우터는 처음에 index.html 하나만 받아온 뒤, JS로 원하는 주소 /page1, /page2, ... 로 화면을 바꾼다.

 

그러므로 /page1에 해당하는 물리적 파일은 존재하지 않고, 브라우저 안의 JS 라우터가 주소만 보고 화면을 그려준 것이다.

 

따라서 사용자가 브라우저에서 "뒤로가기"클릭 시, 브라우저는 

• 캐시가 있으면 캐시된 화면을 바로 부여준다.
• 캐시가 없거나 만료되면 서버에 해당 URL(/page1)을 직접 다시 요청한다.

그러나 S3 버킷에는 /page1이라는 정확한 파일이 존재하지 않으므로

• 객체 API 엔드포인트 → 403 Access Denied
• 웹사이트 엔드포인트 → index.html 반환 (ErrorDocument 규칙 적용) → SPA가 다시 실행돼서 /page1 반환

 

해결 방법

CloudFront의 현재 원본 규칙을 살펴보니, 정적 웹사이트 엔드포인트가 아닌 버킷 엔드포인트로 원본 도메인을 지정하고 있었다.

 

따라서 S3 버킷의 엔드포인트 주소를 복사한 뒤에, CloudFront의 원본으로 바꿔주면 된다. 

CloudFront의 원본(Origin)은 캐시에 없는 요청을 받았을 때, 실제 데이터를 가져오는 출처를 말한다.

 

S3 버킷 > 속성

맨 아래 버킷 웹사이트 엔드포인트 주소를 복사한다.

 

CloudFront > 원본 > 원본편집

원본으로 아래 S3 목록을 클릭하지 말고, 복사한 URL을 그대로 넣는다.

사진과 같이 복사한 주소에 S3-website라고 적혀있으면 버킷 웹사이트 엔드포인트를 잘 넣은것이다.

CloudFront > 무효화 > 무효화 생성

/* 로 캐시 무효화를 설정해준다.

 

이렇게 설정해주고 나면, 캐시가 만료된 뒤에도 index.html을 통해 다시 원하는 주소를 반환할 수 있게된다.