SW BBANG K

프라이빗 S3 버킷에 저장된 파일을 외부 사용자에게 일시적으로 공개해야 할 때, 버킷 정책을 건드리거나 퍼블릭 ACL을 열지 않고도 해결하는 방법이 바로 Presigned URL이다. 실제 운영 환경에서는 '이 파일 한 번만 다운로드할 수 있게 해줘'라는 요구가 생각보다 자주 온다 — 계약서 전달, 리포트 공유, 미디어 파일 배포 등. S3 Presigned URL은 서버 측에서 서명된 임시 접근 토큰을 URL에 포함시켜, 지정된 만료 시간 내에만 해당 객체에 접근할 수 있도록 제어한다. TL;DR — S3 Presigned URL 핵심 요약 항목 내용 목적 IAM 자격증명 없이 특정 S3 객체에 임시 접근 허용 서명 방식 SigV4 (AWS Signature Version 4) 기본 만료 범위 최소 1초 ~ 최대 7일 (IAM 역할 기반 서명 시 최대 12시간) SDK 메서드 Python: generate_presigned_url / JS: getSignedUrl (v2), getSignedUrl from @aws-sdk/s3-request-presigner (v3) 주요 주의사항 서명에 사용된 자격증명이 만료되면 URL도 즉시 무효화됨 S3 Presigned URL 동작 원리 Presigned URL은 S3 서비스가 생성하는 것이 아니다. SDK를 실행하는 서버(혹은 Lambda)가 로컬에서 서명을 계산해 URL에 포함 시킨다. S3는 요청이 들어왔을 때 URL에 포함된 서명 파라미터를 검증할 뿐이다. 이 차이가 중요한 이유는 — 서명을 생성한 자격증명(IAM 사용자 또는 역할)이 비활성화되거나 만료되면, URL 자체의 만료 시간이 남아 있어도 요청이 거부된다. sequenceDiagram participant App as 애플리케이션 서버 parti...

S3 버킷에 파일을 업로드하면 Lambda가 실행되고, Lambda가 처리 결과를 같은 버킷에 저장하면 또 Lambda가 실행된다. 이 Lambda S3 무한 루프 는 처음 설계할 때는 눈에 띄지 않다가, 프로덕션에서 갑자기 Lambda 동시 실행 한도를 소진하거나 S3 요청 비용이 폭발적으로 증가하면서 발견된다. TL;DR — Lambda S3 재귀 트리거 차단 방법 요약 방법 핵심 원리 적용 난이도 권장 여부 출력 접두사(Prefix) 분리 입력/출력 경로를 다르게 설정해 트리거 조건 자체를 제거 낮음 ✅ 1순위 출력 버킷 분리 처리 결과를 별도 버킷에 저장 낮음 ✅ 1순위 객체 메타데이터 확인 Lambda가 직접 처리 여부를 메타데이터로 판별 후 조기 종료 중간 ⚠️ 보조 수단 객체 태그 확인 처리 완료 태그가 있으면 즉시 반환 중간 ⚠️ 보조 수단 Lambda S3 재귀 트리거가 발생하는 구조 S3 이벤트 알림은 버킷 단위로 설정된다. 특정 접두사나 접미사 필터를 걸지 않으면, 버킷 내 모든 ObjectCreated 이벤트가 Lambda를 호출한다. Lambda가 처리 결과를 같은 버킷에 쓰는 순간 새로운 ObjectCreated 이벤트가 발생하고, 이 이벤트가 다시 Lambda를 호출한다. graph TD A["사용자: raw/input.csv 업로드"] --> B["S3: ObjectCreated 이벤트 발생"] B --> C["Lambda 호출 #1"] C --> D["처리 결과: processed/output.csv 저장"] D --> E["S3: ObjectCreated 이벤트 발생"] E --> F["Lambda 호출 ...

IAM User와 IAM Role의 차이를 명확히 이해하지 못하면, EC2 인스턴스에서 S3에 접근할 때 자격증명을 하드코딩하거나 불필요하게 장기 키를 발급하는 실수를 반복하게 된다. 이 글은 두 개념의 구조적 차이와, EC2 인스턴스가 S3에 접근하는 실제 운영 시나리오 에서 어떤 선택이 올바른지를 명확히 설명한다. TL;DR — IAM User vs IAM Role 핵심 비교 EC2 인스턴스에서 S3에 접근할 때는 IAM Role(인스턴스 프로파일)을 사용하는 것이 AWS 공식 권장 방식이다. IAM User의 액세스 키를 인스턴스에 직접 저장하는 방식은 키 노출 위험이 있고, 자격증명 교체 비용이 높다. 항목 IAM User IAM Role 자격증명 유형 장기 액세스 키 (Access Key ID + Secret) 임시 보안 토큰 (STS 발급) 주체(Principal) 사람 또는 애플리케이션 AWS 서비스, 계정, 사람 등 자격증명 수명 명시적으로 삭제하기 전까지 유효 기본 1시간, 최대 12시간 (설정에 따라 다름) EC2 사용 권장 여부 ❌ 비권장 (키 하드코딩 위험) ✅ 권장 (인스턴스 프로파일) 자격증명 자동 교체 수동 교체 필요 STS가 자동 갱신 멀티 계정 접근 제한적 Cross-account Role Assumption 지원 IAM User와 IAM Role의 작동 원리 IAM User는 AWS 계정 내에 영구적으로 존재하는 자격증명 주체다. 콘솔 로그인용 패스워드와 API 호출용 액세스 키를 가지며, 이 키는 명시적으로 비활성화하거나 삭제하지 않는 한 계속 유효하다. 사람이 직접 AWS 콘솔이나 CLI를 사용하는 경우에 적합하다. IAM Role은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...

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...