SW BBANG K

EC2 인스턴스를 새로 띄우고 나서 S3에 올려둔 설정 파일을 내려받으려는 순간, Unable to locate credentials 오류나 Access Denied 가 뜨면서 막히는 경험은 누구나 한 번쯤 겪는다. S3에서 EC2로 파일 복사 하는 작업은 명령어 자체는 단순하지만, IAM 인스턴스 프로파일이 제대로 붙어 있지 않으면 자격 증명 문제로 첫 단계부터 실패한다. TL;DR — 핵심 요약 항목 내용 복사 명령어 aws s3 cp s3://버킷명/경로/파일명 /로컬/경로/ 필수 IAM 액션 s3:GetObject (단일 파일), s3:ListBucket (경로 확인 시) 자격 증명 방식 EC2 인스턴스 프로파일 (IAM Role) — 권장 자격 증명 확인 aws sts get-caller-identity 가장 흔한 실패 원인 인스턴스 프로파일 미연결 또는 버킷 정책의 명시적 Deny 동작 원리: S3 파일 복사 흐름 aws s3 cp 는 내부적으로 S3 REST API의 GetObject 를 호출한다. EC2에서 이 호출이 성공하려면 두 가지 레이어가 모두 허용 상태여야 한다. 첫째는 IAM — 인스턴스에 연결된 Role이 해당 S3 액션을 허용해야 한다. 둘째는 S3 리소스 정책(버킷 정책) — 버킷 정책에 명시적 Deny가 있으면 IAM Allow를 덮어쓴다. sequenceDiagram participant CLI as AWS CLI (EC2 내부) participant IMDS as IMDS (169.254.169.254) participant STS as AWS STS participant S3 as Amazon S3 CLI->>IMDS: 임시 자격 증명 요청 IMDS->>STS: Role 기반 토큰 발...

Lambda 함수가 오류 없이 실행되는데 S3에서 403을 반환한다면, 대부분의 엔지니어는 즉시 실행 역할(Execution Role)을 의심한다. 맞는 방향이지만, S3의 403은 IAM 권한 하나만의 문제가 아니다. 버킷 정책, 퍼블릭 액세스 차단 설정, KMS 암호화, VPC 엔드포인트 정책까지 여러 레이어가 독립적으로 접근을 거부할 수 있고, 그 중 하나라도 Deny를 내리면 결과는 동일하게 403이다. TL;DR — Lambda S3 403 빠른 진단표 원인 레이어 증상 확인 방법 실행 역할 IAM 권한 누락 s3:GetObject 등 액션 없음 IAM 정책 시뮬레이터 또는 CLI 버킷 정책 명시적 Deny IAM 권한 있어도 거부 버킷 정책 직접 확인 S3 퍼블릭 액세스 차단 퍼블릭 ACL 기반 접근 차단 get-public-access-block KMS 키 권한 누락 SSE-KMS 버킷에서 403 KMS 키 정책 확인 VPC 엔드포인트 정책 VPC 내 Lambda에서만 403 엔드포인트 정책 확인 S3 객체 ACL 불일치 특정 객체만 403 get-object-acl Lambda S3 403 오류의 구조적 이해 S3의 접근 제어는 단일 정책이 아니라 여러 레이어의 평가 결과를 순서대로 합산한다. AWS는 이를 'Authorization Context'라고 부르며, 어느 레이어에서든 명시적 Deny가 발생하면 나머지 Allow는 무효화된다. Lambda 실행 역할에 s3:GetObject 를 추가했는데도 403이 계속 나온다면, 상위 레이어 중 하나가 여전히 Deny를 내리고 있는 것이다. graph TD A["Lambda 함수 실행"] --> B["IAM 정책 평가 (실행 역할 + SCP)"] B ...

간단한 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 연동은 별도로 다룬...

연간 감사(Audit)를 위해 딱 한 번만 꺼내볼 데이터를 S3 Standard에 그대로 두고 있다면, 매달 필요 이상의 비용을 지불하고 있는 것이다. S3 Glacier 계열 스토리지 클래스는 이런 장기 보관 시나리오를 위해 설계되었지만, 세 가지 Glacier 티어 중 어떤 것을 선택하느냐에 따라 복원 속도, 비용 구조, 운영 복잡도가 크게 달라진다. TL;DR — S3 Glacier 스토리지 클래스 비교 스토리지 클래스 최소 보관 기간 복원 소요 시간 주요 사용 사례 S3 Glacier Instant Retrieval 90일 밀리초 분기 1회 이하 접근, 즉시 복원 필요 S3 Glacier Flexible Retrieval 90일 1분~12시간 연 1~2회 접근, 수 시간 내 복원 허용 S3 Glacier Deep Archive 180일 12시간~48시간 연 1회 이하 접근, 최저 스토리지 단가 결론부터: 연 1회 감사 목적이라면 S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 가 최적 후보다. 복원 시점을 며칠 전에 예측할 수 있다면 Deep Archive가 스토리지 단가 측면에서 가장 저렴하다. 당일 복원이 필요하다면 Flexible Retrieval의 Bulk 또는 Standard 검색 옵션을 사용한다. S3 Glacier가 동작하는 방식 — 복원 메커니즘 이해 Glacier 계열 클래스에 저장된 객체는 즉시 읽을 수 없다. 복원(Restore) 요청을 제출하면 AWS가 내부적으로 객체를 준비하고, 지정한 보관 기간(days) 동안 S3 Standard 계층에 임시 사본 을 생성한다. 애플리케이션은 이 임시 사본을 통해 데이터에 접근한다. 임시 사본의 보관 기간이 만료되면 자동으로 삭제되며, 원본 Glacier 객체는 그대로 유지된다. 이 구...

S3에 수백만 개의 로그 파일이 쌓여 있는데, 이걸 분석하려면 RDS나 Redshift에 적재해야 한다고 생각했다면 — 그 가정이 틀렸다. Amazon Athena는 S3에 저장된 파일을 그대로 두고 SQL로 직접 쿼리하는 서버리스 쿼리 엔진이다. 데이터 이동 없이, 별도 DB 프로비저닝 없이, 스캔한 데이터 양만큼만 비용을 낸다. TL;DR — S3 로그를 Athena로 쿼리하는 핵심 요약 단계 작업 핵심 포인트 1 S3 버킷 및 로그 구조 확인 파티션 키 설계가 쿼리 비용 직결 2 Glue Data Catalog에 테이블 정의 SerDe 선택이 파싱 성패를 결정 3 Athena 쿼리 결과 버킷 설정 결과 저장 위치 없으면 쿼리 실행 불가 4 파티션 등록 MSCK REPAIR 또는 파티션 프로젝션 사용 5 SQL 쿼리 실행 WHERE 절에 파티션 컬럼 반드시 포함 6 비용 최적화 Parquet 변환 + 압축으로 스캔 비용 절감 Athena가 S3 로그를 쿼리하는 방식 Athena는 Apache Hive 메타스토어 호환 카탈로그(AWS Glue Data Catalog)에 테이블 스키마와 S3 위치를 등록해 둔다. 쿼리를 실행하면 Athena가 카탈로그에서 해당 테이블의 S3 경로를 조회하고, 분산 쿼리 엔진(Presto/Trino 기반)이 S3에서 직접 파일을 읽어 처리한다. 데이터는 S3에 그대로 있고, Athena는 스캔만 한다. graph LR User["사용자 / 애플리케이션"] -->|"SQL 제출"| Athena["Amazon Athena (Presto/Trino 엔진)"] Athena -->|"스키마 및 S3 경로 조회"| Glue["Glue Data Catalog...

새벽 2시에 온콜 알림이 울렸다. EC2 인스턴스가 응답을 멈췄는데, DNS가 여전히 죽은 서버를 가리키고 있어서 사용자들은 그냥 타임아웃 화면만 보고 있었다. Route 53 DNS 페일오버를 미리 구성해뒀다면, 헬스 체크가 실패하는 순간 트래픽이 S3 정적 백업 사이트로 자동 전환됐을 것이다. 이 글은 그 설정을 처음부터 끝까지 다룬다. TL;DR — Route 53 DNS 페일오버 핵심 요약 단계 구성 요소 역할 1 Route 53 헬스 체크 EC2 엔드포인트 상태를 주기적으로 확인 2 Primary 레코드 (Failover) EC2를 가리키며 헬스 체크와 연결 3 Secondary 레코드 (Failover) S3 정적 웹사이트 엔드포인트를 가리킴 4 S3 버킷 정적 웹사이트 호스팅 백업 페이지 서빙 5 자동 전환 헬스 체크 실패 시 Secondary로 DNS 응답 변경 Route 53 DNS 페일오버 동작 원리 Route 53의 페일오버 라우팅 정책은 Active-Passive 구조다. Primary 레코드에 헬스 체크를 연결해두면, Route 53 헬스 체커가 전 세계 여러 위치에서 해당 엔드포인트를 주기적으로 폴링한다. 헬스 체크가 임계값 이상 실패하면 Route 53은 해당 레코드를 'Unhealthy'로 표시하고, 동일한 이름과 타입을 가진 Secondary 레코드로 DNS 응답을 전환한다. 중요한 점은 이것이 DNS 레벨의 전환이라는 것이다. 기존 TCP 연결은 끊기지 않으며, TTL이 만료된 이후 새로운 DNS 조회부터 Secondary 주소를 받게 된다. 따라서 TTL 값 설정이 실제 전환 속도에 직접적인 영향을 준다. sequenceDiagram participant Client as 클라이언트 participant R53 as Route...