AWS S3 정적 웹사이트 호스팅과 CloudFront 연결하면서 겪은 문제와 해결법

AWS에서 S3 버킷을 이용해 정적 웹사이트를 호스팅하다가 CloudFront로 연결하는 과정에서 생각보다 여기저기 막히는 부분이 많았어요. 그래서 직접 해보면서 자주 겪는 문제와 그 해결책을 중심으로 정리해 봤습니다.

이번 글에서는 AWS 콘솔 설정부터 CLI 명령어까지 실제 세팅할 때 썼던 방법과, 특히 자주 질문하는 7~8개의 핵심 FAQ 형태로 풀어볼게요.

개발 환경 / 버전 정보

AWS CLI 2.11.13, AWS S3, CloudFront 최신 관리 콘솔, 그리고 macOS 터미널 사용했어요. AWS SDK는 이번에 사용하지 않고 오로지 CLI와 콘솔 UI만 활용했습니다.

AWS S3 정적 웹사이트 호스팅 CloudFront 연결 관련 정보

AWS S3 정적 웹사이트 세팅 이렇게 하면 됩니다

사실 S3에서 정적 웹사이트 설정은 간단한 편인데요, 버킷 생성부터 퍼블릭 액세스 설정과 정책 작성, 그리고 웹사이트 엔드포인트 활성화까지 차근차근 진행하는 게 중요합니다.

# 1. 버킷 생성 (리전은 us-east-1 예시)
aws s3api create-bucket --bucket my-static-site-example --region us-east-1

# 2. 버킷 퍼블릭 액세스 차단 해제
aws s3api put-public-access-block --bucket my-static-site-example --public-access-block-configuration BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false

# 3. 버킷 정책 설정 (모든 사용자에게 읽기 권한)
aws s3api put-bucket-policy --bucket my-static-site-example --policy '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":"*","Action":"s3:GetObject","Resource":"arn:aws:s3:::my-static-site-example/*"}]}'

# 4. 정적 웹 사이트 호스팅 활성화
aws s3 website s3://my-static-site-example/ --index-document index.html --error-document error.html

# 5. 파일 업로드
aws s3 cp ./dist/index.html s3://my-static-site-example/index.html
aws s3 cp ./dist/error.html s3://my-static-site-example/error.html

이렇게 세팅 후, 버킷 웹사이트 엔드포인트 URL을 통해 기본적으로 파일이 잘 보이는지 확인하세요.

CloudFront 배포는 이렇게 해야 문제 없어요

CloudFront를 S3 정적 사이트에 연결하려면 오리진 도메인 설정 때 S3 웹사이트 엔드포인트 주소를 꼭 써야 합니다. S3 REST API 엔드포인트 쓰면 403 에러 계속 떠서 한참 헤맸거든요.

# CloudFront 콘솔에서 다음 설정 참고
- Origin Domain Name: my-static-site-example.s3-website-us-east-1.amazonaws.com (웹사이트 엔드포인트 주소)
- Viewer Protocol Policy: Redirect HTTP to HTTPS
- Default Root Object: index.html

추가로 캐시 정책은 기본 캐시 정책 사용해도 되고 필요에 따라 TTL 조정하세요.

이렇게 배포 후 유효화(Invalidation) 작업도 해야 변경 사항이 바로 반영됩니다.

AWS S3 정적 웹사이트 호스팅 CloudFront 연결 관련 정보

여기서 많이 틀립니다: CloudFront와 S3 연결 FAQ

Q1. 버킷 정책을 이렇게 해야 CloudFront에서 접근 가능해요?

A. 네, 보통 모든 사용자(Principal: *)에게 s3:GetObject 권한을 주는 버킷 정책을 넣는데, 보안 이슈가 걱정된다면 오리진 액세스 아이덴티티(OAI)를 생성해서 CloudFront에 권한만 주는 방식을 쓰세요.

Q2. CloudFront Origin Domain은 S3 REST API 주소 말고 웹사이트 엔드포인트 주소가 맞나요?

A. 네, 꼭 그렇게 해야 해요. REST API 주소로 하면 403 권한 오류가 나더라고요. 예: my-bucket.s3.amazonaws.com 대신 my-bucket.s3-website-us-east-1.amazonaws.com 사용하세요.

Q3. HTTPS 적용하려고 ACM 인증서 어떻게 설정하나요?

A. ACM에서 미국 동부(버지니아) 리전(us-east-1)에서 인증서 발급해야 CloudFront에 연결할 수 있어요. 인증서 도메인 이름을 입력하고 DNS 검증 진행하면 됩니다.

Q4. S3 버킷 정책에서 CloudFront OAI(Origin Access Identity) 설정하면 어떻게 하나요?

A. 먼저 CloudFront에서 OAI를 생성한 후, S3 버킷 정책에 OAI에 읽기 권한을 주는 구문을 넣어야 합니다. 예시는 다음과 같아요.

{
  "Version":"2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Principal": {
      "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EXAMPLEID"
    },
    "Action":"s3:GetObject",
    "Resource":"arn:aws:s3:::my-static-site-example/*"
  }]
}

이렇게 하면 외부에서는 직접 S3에 접근 불가하지만 CloudFront를 통해선 접근 가능해집니다.

Q5. CloudFront 캐시 무효화(Invalidation)는 언제 해야 하나요?

A. S3에 업로드한 정적 파일을 교체한 뒤, CloudFront 콘솔이나 CLI로 반드시 캐시 무효화를 해야 업데이트가 바로 반영돼요. CLI 예시는 아래와 같습니다.

aws cloudfront create-invalidation --distribution-id E1234567890ABCD --paths "/index.html" "/css/*"

배포 중인 파일이 많은 경우 캐시 갱신을 안 하면 오래된 파일이 보일 수 있으니 주의하세요.

Q6. 403 Forbidden 에러 뜰 때 주로 어디부터 확인해야 할까요?

A. 대부분 버킷 정책이 제대로 안 돼 있거나 CloudFront Origin이 REST API 주소로 설정되어 있을 때 문제가 발생해요. 이 두 부분을 꼭 다시 점검하세요. 버킷 퍼블릭 액세스 차단 설정도 확인해보시고요.

Q7. index 문서와 error 문서 설정은 어떻게 하나요?

A. S3 버킷 정적 웹사이트 설정에서 인덱스 문서 이름과 에러 문서 이름을 지정할 수 있어요. CloudFront에도 동일하게 'Default Root Object'를 index.html 등으로 지정해 주면 깔끔하게 작동합니다.

제가 직접 겪은 삽질과 해결법

처음에 CloudFront 연결할 때 깜빡하고 웹사이트 엔드포인트 대신 REST API 주소를 넣었다가 403 금지 오류만 떴어요. 왜 그런지 한참 헤매다가 AWS 공식 문서에서 다시 확인했는데, 웹사이트 엔드포인트를 써야 한다고 딱 나와 있더라고요.

또 버킷 정책은 다 열어둬도 무서워서 OAI 설정했는데, 이걸 버킷 정책에 안 넣으면 역시 접근 불가라서 시간이 좀 걸렸어요. 인증서도 ACM에서 us-east-1로 발급하지 않으면 CloudFront에 연결이 안 돼서 그 부분도 주의해야 합니다.

AWS S3 정적 웹사이트 호스팅 CloudFront 연결 관련 정보

심화: CloudFront 최적화 팁 알려드려요

CloudFront 캐시 정책을 기본 그대로 써도 되는데, 캐시 TTL(Time To Live) 값을 콘텐츠 변경 빈도에 맞게 조절하는 게 좋아요. 예를 들어 자주 바꾸는 스크립트 파일은 짧게, 거의 안 바뀌는 이미지 파일은 길게 설정하는 거죠.

그리고 CloudFront 로그 활성화해서 요청 패턴을 분석하면 트래픽 과부하를 미리 대비할 수 있답니다.

자주 물어보시는 것들

Q. S3 정적 웹사이트 주소로 바로 접속할 때와 CloudFront 도메인으로 접속할 때 차이가 있나요?

A. 네, S3 웹사이트 주소는 HTTPS를 지원하지 않기 때문에 보안 연결이 안 되고, 속도나 전 세계 배포 면에서도 CloudFront가 훨씬 유리합니다. 그래서 보통 프로덕션 환경에선 CloudFront 도메인 또는 커스텀 도메인으로 접속합니다.

Q. 커스텀 도메인 연결 시 DNS CNAME 설정은 어떻게 해야 하나요?

A. CloudFront 배포 도메인을 CNAME 레코드에 넣고, ACM에서 발급한 커스텀 도메인 인증서를 적용하면 됩니다. Route53을 쓰면 더 편하지만, 다른 DNS 서비스도 동일하게 처리 가능합니다.

Q. 매번 배포할 때마다 캐시 무효화하지 않으면 어떻게 되나요?

A. CloudFront가 이전 버전을 계속 보여서 사용자들이 예전 콘텐츠를 보게 돼요. 그래서 변경 파일이 많을땐 버전 관리나 파일명 변경 전략도 같이 하면 편해집니다.

이 글 하나로 AWS S3 정적 웹사이트 호스팅부터 CloudFront 연결까지 막히는 부분 대부분 해결할 수 있을 거예요. 직접 해보면서 계속 질문 정리해서 더 업데이트할 계획입니다.

📌 함께 보면 좋은 글

• AWS VPC 서브넷 처음 구성할 때 헷갈렸던 개념과 비용 차이 비교
• AWS EC2 프리티어 서버 처음 만들기, 단계별로 제가 겪은 이야기
• AWS SES로 이메일 발송 시작하며 겪은 삽질과 해결법 공유합니다