AWS Certified Developer - Associate (DVA-C02) #3 Domain 1-2 AWS 서비스로 개발: API Gateway

2026년 5월 22일 금요일

5 분 소요

#2 Lambda 깊이에서 백엔드 로직을 정리했으니, 이번에는 그 앞에서 HTTP 요청을 받는 관문인 API Gateway입니다. 서버리스 API는 거의 항상 클라이언트 → API Gateway → Lambda → DynamoDB 구조이므로, 시험은 이 관문에서 인증,스로틀링,캐싱을 어떻게 다루는지 묻습니다.

REST API vs HTTP API #

API Gateway에는 두 종류가 있습니다. 시험은 “어느 것을 골라야 하는가"를 비용,기능 트레이드오프로 묻습니다.

구분	REST API	HTTP API
비용	더 비쌈	약 70% 저렴
지연	보통	더 낮음
인증	IAM, Cognito, Lambda 오서라이저	IAM, JWT(Cognito/OIDC), Lambda 오서라이저
기능	API 키,사용량 계획, 캐싱, 요청 검증, WAF	핵심 기능 위주(캐싱,API 키 없음)
권장	풍부한 기능이 필요할 때	단순 Lambda/HTTP 프록시, 비용,지연 우선

핵심 한 줄: 기능이 더 필요하면 REST, 저렴하고 빠른 게 우선이면 HTTP API입니다. API 키,사용량 계획,캐싱,요청 검증이 필요하면 REST API여야 합니다.

Lambda 통합: 프록시 vs 비프록시 #

API Gateway가 Lambda를 호출하는 방식은 두 가지입니다.

Lambda 프록시 통합. 요청 전체(헤더,쿼리,바디,경로)를 정해진 형식의 이벤트로 Lambda에 그대로 넘기고, Lambda는 statusCode,headers,body를 담은 정해진 형식으로 응답합니다. 매핑 설정이 거의 없어 간단하며 가장 흔합니다.
비프록시(사용자 정의) 통합. 매핑 템플릿(VTL)으로 요청,응답을 변형합니다. 세밀한 제어가 가능하지만 복잡합니다.

프록시 통합에서 Lambda가 정해진 응답 형식(statusCode/body)을 지키지 않으면 502 Bad Gateway가 납니다. 시험 단골 오류입니다.

인증: 세 가지 방식 #

API Gateway에서 누가 호출할 수 있는지 통제하는 방법은 세 가지입니다. 이 구분은 보안 도메인과도 연결되는 핵심입니다.

방식	적합한 경우
IAM 인증(SigV4)	호출자가 AWS 자격 증명을 가진 경우(다른 AWS 서비스, 내부 시스템). 요청에 SigV4 서명
Cognito User Pool 오서라이저	사용자가 로그인하는 앱. Cognito가 발급한 JWT를 검증
Lambda 오서라이저(커스텀)	자체 토큰,서드파티 OIDC 등 커스텀 인증 로직. 토큰 기반 또는 요청 파라미터 기반

Lambda 오서라이저는 인증 함수가 IAM 정책 문서를 반환해 허용/거부를 결정하며, 결과를 캐싱해 매 요청 호출을 줄일 수 있습니다. “외부 OAuth 토큰을 검증해야 한다” 같은 커스텀 요구는 Lambda 오서라이저가 답입니다. “Cognito로 로그인한 사용자” 라면 Cognito 오서라이저입니다.

스로틀링과 사용량 계획 #

API Gateway는 요청 속도를 제한해 백엔드를 보호합니다.

계정,스테이지 레벨 스로틀링. 기본 초당 요청(rate)과 버스트(토큰 버킷) 한도.
사용량 계획(Usage Plan) + API 키. 고객,티어별로 호출 한도와 할당량(quota)을 다르게 적용. REST API 전용 기능입니다.

한도를 초과하면 클라이언트는 429 Too Many Requests를 받습니다. “특정 고객 등급에 월 호출 횟수를 제한하려면?“의 답은 사용량 계획 + API 키입니다. API 키 자체는 인증 수단이 아니라 식별,계량 수단이라는 점이 함정입니다.

캐싱 #

REST API는 스테이지 레벨에서 응답 캐시를 켤 수 있습니다. 같은 요청에 대한 백엔드 호출을 줄여 지연과 비용을 낮춥니다. TTL을 설정하고, 클라이언트가 Cache-Control 헤더로 캐시를 무시하도록 허용할 수도 있습니다. HTTP API에는 캐싱이 없습니다.

스테이지와 스테이지 변수 #

스테이지(Stage). dev, prod 같은 배포 환경입니다. 배포는 항상 특정 스테이지로 이뤄집니다.
스테이지 변수(Stage Variable). 스테이지마다 다른 값을 주입하는 키-값입니다. 예를 들어 dev 스테이지는 Lambda의 dev 별칭을, prod는 prod 별칭을 가리키게 해 하나의 API 정의로 환경별 백엔드를 분기합니다.

스테이지 변수를 Lambda 별칭과 묶으면, API 정의를 바꾸지 않고도 환경별로 다른 함수 버전을 호출할 수 있습니다.

CORS #

브라우저에서 다른 오리진의 API를 호출하면 CORS가 적용됩니다. 브라우저는 본 요청 전에 OPTIONS 프리플라이트를 보내고, API Gateway는 Access-Control-Allow-Origin 등 헤더로 응답해야 합니다.

시험 함정: 프런트엔드에서 “CORS 오류"가 난다면 코드가 아니라 API Gateway(또는 프록시 통합 시 Lambda 응답 헤더)에서 CORS를 활성화해야 합니다. 프록시 통합에서는 Lambda 응답에 CORS 헤더를 직접 넣어야 하는 경우가 많습니다.

그 외 시험 포인트 #

요청 검증(Request Validation). REST API는 모델(JSON Schema)로 요청 바디,파라미터를 검증해 잘못된 요청을 Lambda 전에 거를 수 있습니다.
WAF 연결. REST API에 WAF를 붙여 L7 공격을 차단합니다.
타임아웃. API Gateway 통합 타임아웃은 최대 29초입니다. 더 긴 작업은 비동기 패턴(202 응답 + 폴링/이벤트)으로 바꿔야 합니다.
엔드포인트 유형. Edge-optimized(CloudFront 경유), Regional, Private(VPC 내부).

시험 출제 패턴 #

“비용과 지연이 가장 중요하고 단순 Lambda 프록시만 필요하다.” → HTTP API.
“API 키로 고객별 월 할당량을 두고 싶다.” → REST API + 사용량 계획 + API 키.
“Cognito로 로그인한 사용자만 호출 허용.” → Cognito User Pool 오서라이저.
“서드파티 OAuth 토큰을 자체 로직으로 검증.” → Lambda 오서라이저.
“프록시 통합 Lambda가 502를 반환.” → Lambda 응답 형식(statusCode/body) 불일치.
“동일 요청이 백엔드를 반복 호출해 느리다.” → API Gateway 캐싱.
“브라우저에서 CORS 오류.” → API Gateway/Lambda에서 CORS 활성화.

정리 #

이번 글에서 잡은 것:

REST API(기능 풍부,API 키,캐싱,요청 검증) vs HTTP API(저렴,저지연)
Lambda 프록시 통합이 기본. 응답 형식 어기면 502
인증. IAM(SigV4),Cognito 오서라이저,Lambda 오서라이저 세 갈래
사용량 계획 + API 키로 고객별 한도. 초과 시 429. API 키는 인증이 아니라 계량
캐싱,요청 검증,WAF는 REST API 기능
스테이지 변수 + Lambda 별칭으로 환경별 백엔드 분기
CORS,29초 타임아웃은 단골 함정

다음: Domain 1-3 DynamoDB 개발 #

API의 뒤에는 데이터가 있습니다. 서버리스에서 가장 많이 쓰이는 데이터베이스는 DynamoDB입니다. #4 DynamoDB 개발에서는 파티션 키 설계, LSI와 GSI의 차이, 읽기 일관성, 조건부 쓰기와 낙관적 잠금, DynamoDB Streams, 그리고 DAX 캐싱까지 정리하겠습니다.