SW BBANG K

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

S3에서 파일을 실수로 삭제했을 때, 버킷에 버전 관리(Versioning)가 활성화되어 있었다면 데이터는 실제로 사라진 게 아니다. AWS S3 버전 관리는 삭제 작업을 '삭제 마커(Delete Marker)' 삽입으로 처리하기 때문에, 이전 버전 객체는 여전히 스토리지에 남아 있다. 이 글은 그 버전을 찾아서 복원하는 정확한 절차를 다룬다. TL;DR — S3 삭제 복구 핵심 요약 단계 작업 핵심 포인트 1 버전 목록 조회 list-object-versions 로 삭제 마커와 이전 버전 확인 2 삭제 마커 제거 삭제 마커의 VersionId 를 지정해 delete-object 실행 3 복원 검증 head-object 로 객체 접근 가능 여부 확인 대안 특정 버전 복사 원하는 VersionId 를 copy-object 로 현재 버전으로 승격 S3 버전 관리가 삭제를 처리하는 방식 버전 관리가 활성화된 버킷에서 aws s3 rm 또는 DeleteObject API를 VersionId 없이 호출하면, S3는 해당 객체를 물리적으로 제거하지 않는다. 대신 동일한 키(Key)에 '삭제 마커'라는 특수 버전을 추가한다. 이후 일반적인 GetObject 요청은 405 Method Not Allowed 가 아닌 404 NoSuchKey 를 반환하는데, 이게 실제 삭제처럼 보이는 이유다. 삭제 마커 자체도 고유한 VersionId 를 가진다. 이 마커를 제거하면 이전 버전이 다시 '현재 버전'으로 노출된다. 즉, 복원의 핵심은 데이터를 되살리는 게 아니라 삭제 마커를 지우는 것이다. sequenceDiagram participant User as 사용자 participant S3 as S3 버킷 Note over S3: 버전 관리 활성화...

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시간이면 최대 하루 동안 구버전이 서빙될 ...

S3 버킷에 암호화를 적용하려고 콘솔을 열었을 때, 'AWS 관리형 키(aws/s3)'와 '고객 관리형 키(CMK)' 두 가지 선택지 앞에서 멈춰본 경험이 있을 것이다. 단순히 '암호화만 되면 되는 거 아닌가?'라고 생각했다가, 나중에 KMS API 호출 비용 청구서를 받고 당황하거나, 감사 요건을 충족하지 못해 다시 설계를 뒤집는 상황이 실제로 발생한다. AWS KMS 키 유형 선택은 보안 정책, 운영 복잡도, 비용 모두에 직접적인 영향을 미친다. TL;DR: AWS 관리형 키 vs 고객 관리형 키 (CMK) 핵심 비교 항목 AWS 관리형 키 (aws/s3) 고객 관리형 키 (CMK) 키 생성 주체 AWS가 자동 생성 사용자가 직접 생성 키 정책 제어 불가 (AWS 관리) 완전 제어 가능 키 로테이션 제어 AWS 자동 관리 (1년) 사용자 설정 가능 교차 계정 접근 불가 키 정책으로 허용 가능 월 키 관리 비용 무료 키당 월 $1 (대칭 키 기준) API 호출 비용 발생 (요청당 과금) 발생 (요청당 과금) CloudTrail 감사 제한적 모든 키 사용 이벤트 기록 Bucket Key 지원 지원 지원 AWS KMS가 S3 암호화에서 동작하는 방식 S3의 SSE-KMS 암호화는 봉투 암호화(envelope encr...

프라이빗 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 호출 ...