SW BBANG K

Lambda 함수를 매일 오전 8시에 실행해야 하는데, 처음에는 단순해 보였다. 그런데 막상 EventBridge 콘솔을 열면 Cron 문법이 일반적인 Unix Cron과 미묘하게 달라서 첫 번째 규칙을 잘못 설정하는 경우가 많다. 이 글은 EventBridge Cron 표현식으로 Lambda를 스케줄링 하는 전체 과정을 다루고, 실수하기 쉬운 타임존 문제와 권한 설정까지 정확하게 짚는다. TL;DR — EventBridge Lambda 스케줄링 핵심 요약 항목 내용 스케줄 방식 Rate 표현식 또는 Cron 표현식 매일 오전 8시 (UTC) Cron cron(0 8 * * ? *) EventBridge 기본 타임존 UTC (변경 불가, Scheduler는 타임존 지정 가능) 필수 IAM 권한 EventBridge → Lambda 호출용 리소스 기반 정책 필요 한국 시간 오전 8시 UTC 환산 전날 오후 11시 UTC → cron(0 23 * * ? *) 타임존 지정이 필요하면 EventBridge Scheduler 사용 권장 EventBridge 스케줄링이 동작하는 방식 EventBridge에는 두 가지 스케줄링 메커니즘이 있다. 하나는 EventBridge Rules (규칙 기반 스케줄) 이고, 다른 하나는 2022년 말에 출시된 EventBridge Scheduler 다. 이 둘은 같은 서비스처럼 보이지만 동작 모델이 다르다. graph LR A["EventBridge Rules (Schedule)"] -->|"직접 타겟 호출"| B["Lambda 함수"] C["EventBridge Scheduler"] -->|"실행 역할(IAM Role) 사용"| B A...

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

웹 앱에 회원가입과 로그인을 붙이려고 Cognito를 열었다가 'User Pools'와 'Identity Pools' 두 개가 보이는 순간 멈칫하게 된다. 이름도 비슷하고, 콘솔에서 나란히 있으니 같은 것처럼 보이지만 실제로는 완전히 다른 문제를 해결하는 서비스다. AWS Cognito User Pools로 사용자 데이터베이스를 관리하는 것이 일반적인 로그인 구현의 정답이다. TL;DR — AWS Cognito User Pools vs Identity Pools 항목 User Pools Identity Pools 핵심 역할 사용자 디렉터리 (회원가입/로그인) AWS 리소스 접근 권한 위임 발급 토큰 ID Token, Access Token, Refresh Token (JWT) 임시 AWS 자격증명 (STS) 사용 시나리오 앱 로그인, 사용자 프로필 관리 S3 직접 업로드, DynamoDB 직접 접근 사용자 DB 관리 ✅ 직접 관리 ❌ 관리하지 않음 소셜 로그인 연동 Google, Facebook, SAML 등 내장 지원 User Pools 포함 외부 IdP 결과를 AWS 권한으로 교환 AWS Cognito의 두 구성요소가 동작하는 방식 User Pools는 말 그대로 사용자 데이터베이스다. 이메일/비밀번호, 전화번호, 소셜 계정으로 가입한 사용자 레코드를 저장하고, 인증 성공 시 JWT 토큰 세 개(ID Token, Access Token, Refresh Token)를 발급한다. 앱 서버나 API Gateway는 이 JWT를 검증해서 요청을 인가한다. Identity Pools는 사용자를 저장하지 않는다. 대신 이미 인증된 사용자(User Pools JWT, Google OAuth 토큰, SAML Assertion 등)를 받아서 AWS STS로부터 임시 자격증명을 ...

API Gateway를 처음 설정할 때 'Lambda 프록시 통합' 체크박스 하나가 이벤트 객체 구조 전체를 바꾼다는 사실을 모르고 넘어가면, Lambda 핸들러에서 event.body 가 undefined 로 찍히는 상황을 마주하게 된다. 이 글은 두 통합 방식의 내부 동작 차이와 그로 인한 이벤트 포맷 변화를 실제 운영 관점에서 정리한다. TL;DR — Lambda 프록시 통합 핵심 요약 항목 Lambda 프록시 통합 Lambda 표준 통합 이벤트 구조 API Gateway가 고정 포맷으로 전달 매핑 템플릿으로 개발자가 직접 정의 요청 매핑 템플릿 불필요 (자동 처리) 필수 작성 응답 매핑 템플릿 불필요 (Lambda 반환값 그대로) 필수 작성 HTTP 상태코드 제어 Lambda 반환 객체 내 statusCode 필드 API Gateway 매핑 규칙 헤더 접근 event.headers 로 직접 접근 매핑 템플릿에서 명시적으로 추출 필요 설정 복잡도 낮음 높음 (VTL 템플릿 작성) 유연성 포맷 고정 완전한 변환 제어 가능 Lambda 프록시 통합이란 무엇인가 API Gateway에서 Lambda를 백엔드로 사용할 때 두 가지 통합 방식을 선택할 수 있다. Lambda 프록시 통합(Lambda Proxy Integration) 은 API Gateway가 HTTP 요청 전체 — 메서드, 경로, 쿼리스트링, 헤더, 바디 — 를 하나의 표준화된 JSON 이벤트 객체로 패키징해서 Lambda에 그대로 전달하는 방식이다. 반대로 Lambda 표준 통합(Lambda Non-Proxy Integration) 은 개발자가 Velocity Template Language(VTL)로 작성한 매핑 템플릿을 통해 요청과 응답을 변환하는 방식이다. 프록시 통합에서 'Pro...

5개의 EC2 인스턴스가 동일한 디렉토리를 읽고 써야 하는 상황이 생겼다. 처음엔 EBS 볼륨 하나를 여러 인스턴스에 붙이면 되지 않을까 생각했는데, 실제로 해보려고 하면 콘솔에서 막히거나 데이터가 꼬이는 경험을 하게 된다. 이 글은 여러 EC2 인스턴스 간 스토리지 공유 문제를 EBS와 EFS 관점에서 실제 운영 경험 기반으로 정리한다. TL;DR — EBS vs EFS 핵심 비교 항목 EBS (일반 볼륨) EBS Multi-Attach EFS 동시 다중 인스턴스 마운트 ❌ 불가 ⚠️ 제한적 가능 ✅ 기본 지원 파일시스템 공유 ❌ ❌ (클러스터 파일시스템 필요) ✅ NFS v4.1/4.2 AZ 제약 동일 AZ만 동일 AZ만 리전 전체 (멀티 AZ) 일반적 공유 폴더 용도 ❌ ❌ ✅ 운영 복잡도 낮음 높음 낮음 결론부터: 5개 EC2 인스턴스가 동일 폴더를 공유하려면 EFS를 사용 해야 한다. EBS는 구조적으로 단일 인스턴스 전용 블록 스토리지이며, Multi-Attach는 공유 파일시스템을 제공하지 않는다. EBS와 EFS의 동작 원리 — 왜 EBS는 공유가 안 되는가 EBS는 블록 스토리지다. 인스턴스에 마운트되면 해당 OS가 파일시스템(ext4, xfs 등)을 직접 관리한다. 두 인스턴스가 동시에 같은 EBS 볼륨을 마운트하면, 각 OS가 독립적으로 파일시스템 메타데이터를 쓰게 되어 데이터 손상이 발생한다. 이건 AWS 제약이 아니...