SW BBANG K

웹 앱에 회원가입과 로그인을 붙이려고 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...

프론트엔드에서 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 ...