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에 이미지를 업로드하고 객체 ACL을 'public-read'로 설정했는데도 URL로 접근하면 'Access Denied'가 반환되는 상황은 AWS를 처음 다루는 엔지니어뿐 아니라 경험 있는 팀에서도 자주 마주치는 문제다. 원인은 대부분 하나다 — 버킷 수준의 'Block Public Access' 설정이 객체 ACL보다 상위에서 동작하기 때문 이다. TL;DR — S3 퍼블릭 액세스 차단 문제 요약 확인 항목 예상 상태 실제 차단 원인 객체 ACL public-read 설정됨 Block Public Access가 ACL을 무시함 버킷 Block Public Access 기본값: 모두 활성화 4가지 설정 중 하나라도 켜져 있으면 퍼블릭 접근 차단 버킷 정책 없거나 Allow 없음 ACL 없이 정책만으로 퍼블릭 접근 허용 가능 계정 수준 Block Public Access 기본값: 모두 활성화 버킷 설정보다 상위에서 적용됨 S3 퍼블릭 액세스 제어 계층 구조 이해 S3의 접근 제어는 단일 설정이 아니라 여러 계층이 순서대로 평가되는 구조다. 객체 ACL을 'public-read'로 바꾸는 것은 가장 하위 계층을 건드리는 것이고, 그 위에 버킷 정책, 버킷 Block Public Access, 계정 수준 Block Public Access가 차례로 쌓여 있다. 상위 계층이 'Deny'를 내리면 하위 계층의 'Allow'는 효력이 없다. AWS는 2018년 이후 신규 버킷 생성 시 Block Public Access 4가지 옵션을 모두 활성화한다. 이 기본값은 의도치 않은 데이터 노출을 막기 위한 것이지만, 퍼블릭 접근이 필요한 정적 웹사이트 호스팅이나 공개 이미지 서빙 시나리오에서는 직접 해제해야 한다. gra...