SW BBANG K

간단한 HTML/CSS 포트폴리오나 랜딩 페이지를 만들었는데, 서버 없이 배포할 방법을 찾고 있다면 S3 정적 웹사이트 호스팅이 가장 현실적인 선택이다. EC2 인스턴스를 띄울 필요도 없고, Nginx 설정을 건드릴 필요도 없다. S3 버킷 하나로 수백만 요청을 처리할 수 있다. TL;DR — S3 정적 웹사이트 호스팅 핵심 요약 단계 작업 주의사항 1 S3 버킷 생성 (퍼블릭 액세스 차단 해제) 버킷 이름은 변경 불가 2 정적 웹사이트 호스팅 활성화 인덱스/에러 문서 지정 필수 3 버킷 정책으로 퍼블릭 읽기 허용 ACL 방식은 권장하지 않음 4 파일 업로드 Content-Type 자동 감지 확인 5 S3 웹사이트 엔드포인트로 접근 HTTPS는 CloudFront 필요 S3 정적 웹사이트 호스팅의 동작 원리 S3에는 두 가지 엔드포인트가 존재한다. 하나는 REST API 엔드포인트( s3.amazonaws.com ), 다른 하나는 웹사이트 엔드포인트( s3-website-{region}.amazonaws.com )다. 정적 웹사이트 호스팅을 활성화하면 웹사이트 엔드포인트가 활성화되고, 이 엔드포인트는 HTTP GET 요청에 대해 인덱스 문서를 반환하거나 404 시 커스텀 에러 페이지를 반환하는 웹 서버처럼 동작한다. REST 엔드포인트와 웹사이트 엔드포인트의 결정적 차이는 루트 경로 처리 방식이다. REST 엔드포인트에서 / 를 요청하면 버킷 목록 XML이 반환되거나 403이 뜬다. 웹사이트 엔드포인트는 설정된 인덱스 문서( index.html )를 자동으로 반환한다. 중요한 제약이 하나 있다. S3 웹사이트 엔드포인트는 HTTP만 지원한다. HTTPS가 필요하다면 CloudFront를 앞단에 배치해야 한다. 이 포스트에서는 S3 단독 설정에 집중하고, CloudFront 연동은 별도로 다룬...

S3 버킷에 파일을 덮어썼는데 CloudFront는 여전히 구버전을 서빙하고 있다. 배포 직후 사용자 신고가 들어오고, 콘솔을 열어보면 S3에는 분명 새 파일이 올라가 있다. 이 상황에서 필요한 것이 CloudFront 캐시 무효화(Invalidation) 다 — 엣지 로케이션에 남아있는 캐시 객체를 강제로 만료시켜 다음 요청 시 오리진에서 최신 버전을 가져오게 만드는 메커니즘이다. TL;DR — CloudFront 캐시 무효화 핵심 요약 상황 권장 방법 비용 특정 파일 1~수십 개 교체 경로 지정 Invalidation 월 1,000 경로 무료, 초과 시 유료 전체 캐시 일괄 초기화 /* 와일드카드 Invalidation 1개 경로로 카운트되나 모든 객체 무효화 배포 파이프라인 자동화 CLI / SDK Invalidation 호출 동일 과금 구조 근본적 캐시 충돌 방지 파일명 버전닝(캐시 버스팅) 무료 — Invalidation 불필요 정가 및 무료 한도는 변경될 수 있으므로 AWS CloudFront 공식 요금 페이지 에서 확인하라. CloudFront 캐시가 동작하는 방식 — 왜 S3를 바꿔도 즉시 반영되지 않는가 CloudFront는 전 세계 엣지 로케이션에 콘텐츠 사본을 저장한다. 사용자 요청이 들어오면 엣지가 먼저 로컬 캐시를 확인하고, 캐시 히트면 오리진(S3)에 전혀 접근하지 않고 응답한다. 캐시 항목은 TTL(Time To Live)이 만료되거나 명시적으로 무효화될 때까지 유지된다. S3에 파일을 덮어써도 엣지 캐시의 TTL이 남아있는 한 CloudFront는 오리진을 다시 조회하지 않는다. TTL은 오리진의 Cache-Control 헤더 또는 CloudFront 배포 설정의 'Default TTL'로 결정된다. 기본값이 24시간이면 최대 하루 동안 구버전이 서빙될 ...