SW BBANG K

Lambda 함수가 오류 없이 실행되는데 S3에서 403을 반환한다면, 대부분의 엔지니어는 즉시 실행 역할(Execution Role)을 의심한다. 맞는 방향이지만, S3의 403은 IAM 권한 하나만의 문제가 아니다. 버킷 정책, 퍼블릭 액세스 차단 설정, KMS 암호화, VPC 엔드포인트 정책까지 여러 레이어가 독립적으로 접근을 거부할 수 있고, 그 중 하나라도 Deny를 내리면 결과는 동일하게 403이다. TL;DR — Lambda S3 403 빠른 진단표 원인 레이어 증상 확인 방법 실행 역할 IAM 권한 누락 s3:GetObject 등 액션 없음 IAM 정책 시뮬레이터 또는 CLI 버킷 정책 명시적 Deny IAM 권한 있어도 거부 버킷 정책 직접 확인 S3 퍼블릭 액세스 차단 퍼블릭 ACL 기반 접근 차단 get-public-access-block KMS 키 권한 누락 SSE-KMS 버킷에서 403 KMS 키 정책 확인 VPC 엔드포인트 정책 VPC 내 Lambda에서만 403 엔드포인트 정책 확인 S3 객체 ACL 불일치 특정 객체만 403 get-object-acl Lambda S3 403 오류의 구조적 이해 S3의 접근 제어는 단일 정책이 아니라 여러 레이어의 평가 결과를 순서대로 합산한다. AWS는 이를 'Authorization Context'라고 부르며, 어느 레이어에서든 명시적 Deny가 발생하면 나머지 Allow는 무효화된다. Lambda 실행 역할에 s3:GetObject 를 추가했는데도 403이 계속 나온다면, 상위 레이어 중 하나가 여전히 Deny를 내리고 있는 것이다. graph TD A["Lambda 함수 실행"] --> B["IAM 정책 평가 (실행 역할 + SCP)"] B ...

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

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

Lambda 함수가 Private Subnet에 있는 RDS 인스턴스에 연결되지 않는 상황은 생각보다 자주 발생한다. 'Lambda에서 Private RDS 연결'을 처음 구성할 때 가장 많이 놓치는 부분이 Lambda 자체에 VPC 설정을 붙여야 한다는 사실이다 — Lambda는 기본적으로 AWS 관리 네트워크에서 실행되기 때문에, VPC 내부 리소스에는 아예 도달할 수 없다. TL;DR — Lambda에서 Private RDS 연결 핵심 요약 항목 설명 Lambda VPC 설정 필요 여부 필수. Subnet ID와 Security Group ID를 Lambda에 지정해야 함 Lambda용 Subnet 선택 RDS와 동일한 VPC 내 Private Subnet (가용 영역 2개 이상 권장) Security Group 규칙 Lambda SG → RDS SG 인바운드 허용 (포트 3306/5432) 인터넷 액세스 필요 시 NAT Gateway 경유 라우팅 필요 (IGW 직접 연결 불가) IAM 권한 Lambda 실행 역할에 VPC ENI 생성 권한 필요 연결 진단 순서 VPC 설정 → SG 규칙 → Subnet 라우팅 → IAM → RDS 상태 Lambda가 Private RDS에 연결되는 원리 Lambda 함수는 기본 실행 환경에서 AWS 관리 네트워크에 위치한다. 이 상태에서는 퍼블릭 엔드포인트(S3, DynamoDB 등)에는 접근할 수 있지만, 고객 VPC 내부의 RDS처럼 프라이빗 리소스에는 네트워크 경로 자체가 없다. Lambda에 VPC 설정을 추가하면, AWS는 Lambda 실행 환경과 고객 VPC 사이에 Hyperplane ENI(Elastic Network Interface) 를 생성한다. 이 ENI가 지정한 Subnet에 배치되고, 지정한 Security...

프론트엔드에서 API Gateway를 호출했을 때 CORS 오류 가 발생하면, 대부분의 엔지니어는 콘솔에서 'Enable CORS' 버튼 하나만 누르면 해결된다고 생각한다. 실제로는 그 버튼이 절반의 작업만 처리하고, 나머지 절반은 Lambda 함수 응답에서 직접 헤더를 반환해야 한다 — 이 사실을 모르면 콘솔 설정 후에도 동일한 오류가 반복된다. TL;DR — API Gateway CORS 오류 핵심 요약 구분 내용 문제 원인 브라우저 preflight OPTIONS 요청에 CORS 헤더 누락, 또는 실제 응답에 헤더 없음 콘솔 설정 역할 OPTIONS 메서드 Mock 응답에 CORS 헤더 추가 + 배포 필요 Lambda 역할 GET/POST 등 실제 메서드 응답에 직접 CORS 헤더 포함해야 함 필수 헤더 Access-Control-Allow-Origin, Access-Control-Allow-Headers, Access-Control-Allow-Methods 자주 놓치는 것 콘솔 설정 후 Stage 재배포 누락 CORS가 API Gateway에서 동작하는 방식 브라우저는 크로스 오리진 요청을 보내기 전에 먼저 preflight 요청 을 OPTIONS 메서드로 전송한다. 서버가 이 OPTIONS 요청에 올바른 CORS 헤더로 응답해야 브라우저가 실제 요청을 허용한다. API Gateway에서 이 흐름을 이해하지 못하면 설정이 반쪽짜리가 된다. API Gateway REST API에서 CORS는 두 개의 독립된 레이어에서 처리된다. 첫 번째는 OPTIONS preflight — API Gateway가 Lambda를 호출하지 않고 Mock 통합으로 직접 응답한다. 두 번째는 실제 메서드(GET, POST 등) 응답 — Lambda 함수가 응답 본문과 함께 CORS 헤더를 직접 ...

Lambda 함수가 3초 만에 끊기는데 실제 작업은 10초가 필요한 상황 — 처음 마주치면 당황스럽지만, 원인은 단순하다. Lambda의 기본 타임아웃이 3초로 설정되어 있고, 이 값을 명시적으로 늘리지 않으면 함수는 작업 완료 여부와 무관하게 강제 종료된다. 이 글에서는 Lambda 타임아웃 설정 위치, 최대 한도, 그리고 단순히 값을 올리는 것 이상으로 놓치기 쉬운 실전 주의사항을 정리한다. TL;DR — Lambda 타임아웃 핵심 요약 항목 내용 기본 타임아웃 3초 최대 타임아웃 900초 (15분) 설정 단위 함수 단위 (버전/별칭별 독립 설정 불가) 타임아웃 측정 범위 전체 호출 시간 — 콜드 스타트 init 단계 포함 설정 방법 콘솔, AWS CLI, IaC (SAM/CDK/Terraform) 연동 서비스 타임아웃 API Gateway(29초), ALB(60초) 등 별도 제한 존재 Lambda 타임아웃이 동작하는 방식 Lambda 타임아웃은 함수 호출이 시작된 시점부터 카운트된다. 중요한 점은 타임아웃이 핸들러 실행 시간만이 아닌 전체 호출 시간에 적용된다 는 것이다. 콜드 스타트가 발생하면 런타임 초기화(init) 단계도 이 시간에 포함된다. 즉, init에 2초가 걸리고 핸들러 로직에 9초가 필요한 함수라면, 타임아웃을 10초로 설정해도 강제 종료될 수 있다. 타임아웃이 초과되면 Lambda는 Task timed out after X.XX seconds 메시지와 함께 호출을 종료하고, 호출자에게 오류를 반환한다. 함수 내부에서 try/catch로 잡을 수 없다 — 런타임 레벨에서 강제 중단되기 때문이다. graph TD A["Lambda 호출 시작 타임아웃 카운터 시작"] --> B{"콜드 스타트?"}; B ...

SQS 큐에서 메시지가 두 개의 컨슈머에 의해 동시에 처리되는 현상을 프로덕션에서 처음 마주치면, 대부분 애플리케이션 코드나 멱등성 로직을 먼저 의심한다. 하지만 실제 원인은 대부분 더 단순한 곳에 있다 — Visibility Timeout 이 처리 시간보다 짧게 설정되어 있는 것이다. 이 설정 하나가 SQS 중복 처리 문제의 가장 흔한 원인이다. TL;DR — SQS Visibility Timeout 핵심 요약 항목 내용 Visibility Timeout 역할 메시지를 수신한 후 다른 컨슈머에게 보이지 않도록 숨기는 시간 기본값 30초 설정 범위 0초 ~ 12시간 중복 처리 발생 조건 처리 시간 > Visibility Timeout 권장 설정 최대 처리 시간의 6배 이상 (AWS 권장) 런타임 연장 방법 ChangeMessageVisibility API 호출 삭제 타이밍 처리 완료 후 반드시 DeleteMessage 호출 SQS Visibility Timeout 동작 원리 SQS는 메시지 브로커가 아니라 분산 큐다. 컨슈머가 메시지를 ReceiveMessage 로 가져가도 메시지는 큐에서 즉시 삭제되지 않는다. 대신 Visibility Timeout 동안 다른 컨슈머에게 보이지 않는 상태(invisible)로 전환된다. 컨슈머가 처리를 완료하고 DeleteMessage 를 호출해야 비로소 큐에서 제거된다. Visibility Timeout이 만료되기 전에 DeleteMessage 가 호출되지 않으면, SQS는 해당 메시지를 다시 visible 상태로 되돌린다. 이 순간 다른 컨슈머(또는 동일 컨슈머의 다른 인스턴스)가 동일 메시지를 다시 수신할 수 있게 된다. 이것이 중복 처리의 정확한 메커니즘이다. sequenceDiagram participant Q a...