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

웹 앱에 회원가입과 로그인을 붙이려고 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로부터 임시 자격증명을 ...

신규 개발자가 입사할 때마다 S3, CodeCommit, CloudWatch 정책을 한 명씩 붙이다 보면, 어느 순간 누군가의 계정에만 정책이 빠져 있거나 퇴사자 계정에 권한이 남아 있는 상황을 마주하게 된다. IAM 그룹은 이 문제를 구조적으로 해결하는 가장 기본적인 수단이다. TL;DR: IAM 그룹 vs 사용자 직접 연결 기준 사용자 직접 연결 IAM 그룹 연결 신규 사용자 온보딩 정책을 매번 수동 연결 그룹 추가만으로 완료 권한 변경 사용자 수만큼 반복 작업 그룹 정책 1회 수정으로 전파 퇴사자 처리 각 정책을 개별 분리 그룹 멤버십 제거로 권한 회수 감사(Audit) 사용자별 정책 목록 확인 필요 그룹 단위로 권한 범위 파악 가능 실수 가능성 높음 (누락, 중복 발생) 낮음 (그룹 정책이 단일 진실 공급원) IAM 그룹이 작동하는 방식 IAM 그룹은 사용자의 컨테이너다. 그룹 자체는 자격 증명이 아니므로 로그인하거나 임시 자격 증명을 발급받을 수 없다. 그룹에 연결된 정책은 그룹의 모든 멤버에게 적용된다. 사용자가 여러 그룹에 속하면 각 그룹의 정책이 합산되어 평가된다. 한 사용자에게 직접 연결된 정책과 그룹을 통해 상속된 정책은 IAM 평가 엔진에서 동일하게 처리된다. 단, Explicit Deny는 어떤 경로로 Allow가 부여되었든 항상 우선한다. graph LR G["Developers 그룹 정책 연결 지점"] --> P1["AmazonS3ReadOnlyAccess"] G --> P2["CloudWatchReadOnlyAccess"] U1["alice"] --> G U2["bob"] --> G U3["신규 사용자 추가 ...

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

레포지토리가 private이니까 괜찮다고 생각했던 DB 비밀번호가 GitHub 유출 사고의 주인공이 되는 건 순식간이다. Secrets Manager를 왜 써야 하는지, 자동 로테이션이 실제로 어떻게 동작하는지 운영 관점에서 정리한다. TL;DR: 핵심 비교 항목 하드코딩 / 환경변수 AWS Secrets Manager 비밀번호 노출 경로 코드, 로그, CI/CD 환경변수 API 호출 시점에만 메모리 접근 로테이션 수동 (배포 필요) 자동 (Lambda 기반, 무중단) 감사 추적 없음 CloudTrail로 모든 접근 기록 접근 제어 코드 접근 권한 = 비밀번호 접근 IAM 정책으로 세분화 비용 0원 (보안 사고 비용 제외) 시크릿당 월 과금 — AWS 공식 문서 확인 왜 Secrets Manager가 필요한가 — 하드코딩의 실제 위협 모델 'private 레포니까 괜찮다'는 가정이 깨지는 시나리오는 생각보다 많다. 팀원 계정 탈취, 실수로 public 전환, CI/CD 파이프라인 로그 노출, 컨테이너 이미지 레이어 분석 — 이 중 하나라도 발생하면 비밀번호가 코드에 있는 순간 게임 오버다. 환경변수도 완전한 해결책이 아니다. docker inspect , /proc/<pid>/environ , 애플리케이션 에러 로그에 환경변수가 그대로 출력되는 사례는 실제 운영 환경에서 반복적으로 발생한다. 비밀번호를 '어디에 두느냐'가 아니라 '누가, 언제, 어떤 경로로 접근하느냐'를 제어하는 것이 핵심이다. 하드코딩은 자물쇠 없는 금고다. 금고가 지하실에 있다고 안전한 게 아니다 — 지하실 문이 열리는 순간 모든 게 노출된다. Secrets Manager 동작 원리 Secrets Manager는 단순한 키-값 저장소가 아니다. 시크릿 값 자체...

어느 날 오전, 모니터링 알림이 울리고 확인해보니 운영 중이던 EC2 인스턴스가 없다. 콘솔에서 찾을 수 없고, Auto Scaling 그룹도 아니다. 누군가 TerminateInstances API를 직접 호출한 것이다. CloudTrail Event History는 이 상황에서 가장 먼저 열어야 할 도구다. TL;DR — 핵심 요약 단계 목적 핵심 확인 항목 1. Event History 필터 TerminateInstances 이벤트 검색 이벤트 이름, 리소스 ID 2. 이벤트 상세 확인 호출 주체 식별 userIdentity, sourceIPAddress 3. CLI로 정밀 조회 인스턴스 ID 기준 필터링 lookup-events 파라미터 4. 원인 분석 역할/사용자 권한 검토 assumedRole, sessionContext CloudTrail Event History가 동작하는 방식 CloudTrail은 AWS 계정 내 API 호출을 기록하는 감사 로그 서비스다. 리전별로 활성화되며, 별도 Trail을 구성하지 않아도 Event History 는 기본적으로 각 리전에서 최근 90일간의 관리 이벤트(Management Events)를 자동으로 보관한다. EC2 인스턴스 종료는 TerminateInstances API 호출로 기록되며, 이 이벤트에는 호출 주체, 시간, 소스 IP, 대상 리소스 정보가 포함된다. 중요한 점은 Event History가 기록하는 것은 관리 이벤트(Management Events) 뿐이라는 것이다. S3 객체 읽기 같은 데이터 이벤트는 별도 Trail 설정이 필요하다. EC2 종료는 관리 이벤트에 해당하므로 기본 Event History에서 조회 가능하다. sequenceDiagram participant U as IAM 사용자/역할 partic...

EC2 인스턴스를 운영하다 보면 CloudWatch 콘솔에서 CPU는 보이는데 메모리가 없다는 걸 처음 마주치는 순간이 있다. 알람을 걸려고 했더니 지표 자체가 없고, 인스턴스가 OOM으로 죽었는데 CloudWatch에는 아무 흔적이 없다. EC2 메모리 사용률 은 기본 CloudWatch 지표에 포함되지 않으며, 이를 수집하려면 CloudWatch Agent를 직접 설치해야 한다. TL;DR — EC2 메모리 모니터링 핵심 요약 항목 기본 CloudWatch CloudWatch Agent 설치 후 CPU 사용률 ✅ 자동 수집 ✅ 자동 수집 네트워크 I/O ✅ 자동 수집 ✅ 자동 수집 디스크 I/O (EBS 바이트) ✅ 자동 수집 ✅ 자동 수집 메모리 사용률 (RAM) ❌ 수집 불가 ✅ 수집 가능 디스크 공간 사용률 (파일시스템) ❌ 수집 불가 ✅ 수집 가능 프로세스별 메모리 ❌ 수집 불가 ✅ 수집 가능 (procstat 플러그인) 왜 EC2 메모리 사용률은 기본으로 보이지 않는가 CloudWatch가 기본으로 수집하는 지표는 AWS 하이퍼바이저 계층에서 관측 가능한 것들이다. CPU 사이클, 네트워크 패킷, EBS I/O 바이트 — 이것들은 인스턴스 외부에서 측정할 수 있다. 반면 OS 내부의 메모리 할당 상태, 파일시스템 사용량, 프로세스 목록은 게스트 OS 안에서만 볼 수 있다. AWS는 EC2 인스턴스 내부 OS에 직접 접근하지 않는다. 이건 보안 모델의 일부이기도 하고, 공유 책임 모델(Shared Responsibility Model)의 경계이기도 하다. 게스트 OS 레이어는 고객 책임 영역이고, AWS는 그 안을 들여다보지 않는다. 결과적으로 메모리 사용률을 수집하려면 인스턴스 안에서 직접 데이터를 밀어내는 에이전트가 필요하다. EBS 디스크 I/O 바이트는 하이퍼바이...