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

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

EC2 인스턴스를 중지(Stop)했는데 다음 날 청구서를 확인하니 Elastic IP 요금이 그대로 붙어 있다. 인스턴스를 껐으니 당연히 IP도 멈출 거라 생각했지만, AWS는 그렇게 동작하지 않는다. Elastic IP 요금 청구 구조를 정확히 이해하지 못하면 아무것도 실행되지 않는 인스턴스에 매달 예상치 못한 비용이 쌓인다. TL;DR — Elastic IP 요금 청구 핵심 정리 상태 요금 발생 여부 이유 실행 중 인스턴스에 연결됨 ❌ 무료 정상 사용 중 중지된 인스턴스에 연결됨 ✅ 요금 발생 IP가 유휴 상태로 낭비됨 어떤 인스턴스에도 연결 안 됨 (미연결) ✅ 요금 발생 IP가 유휴 상태로 낭비됨 연결 해제(Disassociate) 후 릴리스(Release) 완료 ❌ 무료 IP가 AWS 풀로 반환됨 결론: 요금을 완전히 멈추려면 Disassociate(연결 해제) 와 Release(릴리스) 를 모두 수행해야 한다. Disassociate만 하면 IP가 계정에 남아 있어 여전히 과금된다. Elastic IP 요금 구조가 작동하는 방식 AWS가 Elastic IP에 요금을 부과하는 핵심 원칙은 단순하다. 퍼블릭 IPv4 주소는 희소 자원 이며, AWS는 계정이 해당 IP를 실제로 사용하지 않으면서 점유하고 있을 때 요금을 청구한다. '사용 중'의 정의는 실행 상태(running)의 인스턴스 또는 NAT 게이트웨이에 연결되어 있을 때 다. 인스턴스를 중지하면 그 인스턴스에 연결된 Elastic IP는 즉시 '유휴(idle)' 상태가 된다. AWS 입장에서는 이 IP를 다른 고객에게 할당할 수 없는데 계정이 붙잡고 있는 것이므로, 시간당 요금이 발생한다. 요금과 정확한 조건은 변동될 수 있으므로 항상 공식 AWS EC2 요금 페이지 에서 확인해야 한다. stateD...

DynamoDB 테이블을 처음 생성할 때 가장 먼저 마주치는 질문이 바로 용량 모드 선택이다. 트래픽 패턴이 불분명한 초기 단계에서 Provisioned를 잘못 설정하면 스로틀링으로 요청이 거부되고, On-Demand를 무심코 유지하다 보면 예상치 못한 청구서를 받게 된다. 이 글은 DynamoDB 용량 모드 의 내부 동작 원리부터 실전 전환 판단 기준까지, 운영 경험을 바탕으로 정리한다. TL;DR — 한눈에 보는 선택 기준 상황 권장 모드 핵심 이유 트래픽 패턴 미확인, 초기 서비스 On-Demand 스로틀링 없이 자동 스케일, 용량 예측 불필요 트래픽이 예측 가능하고 일정함 Provisioned + Auto Scaling 단위 비용이 낮고 비용 상한 제어 가능 급격한 스파이크 + 평시 트래픽 낮음 On-Demand 피크 대비 Provisioned 과잉 프로비저닝 방지 높은 베이스라인 + 예측 가능한 피크 Provisioned + Auto Scaling Reserved Capacity와 조합 시 비용 최적화 DynamoDB 용량 모드의 내부 동작 원리 두 모드를 단순히 '자동 vs 수동'으로 이해하면 운영 중 반드시 실수가 생긴다. 각 모드가 내부적으로 어떻게 처리량을 관리하는지 먼저 파악해야 한다. Provisioned 모드 Provisioned 모드에서는 RCU(Read Capacity Unit)와 WCU(Write Capacity Unit)를 명시적으로 설정한다. DynamoDB는 설정된 용량을 파티션 단위로 분배하며, 특정 파티션에 요청이 집중되면 해당 파티션의 할당량이 소진되어 ProvisionedThroughputExceededException 이 발생한다. Auto Scaling을 활성화하면 CloudWatch 지표를 기반으로 목표 사용률에 맞게 RCU/WCU를 자동 ...