[Compute] API Gateway 컨셉 노트
시험 빈출 api-gateway 컨셉 노트
Amazon API Gateway for SAA-C03
One-Line Summary
API Gateway는 외부 요청을 받아 인증·스로틀링·변환을 거쳐 백엔드(Lambda·ALB·ECS·EC2·AWS 서비스)로 안전하게 전달하는 관리형 API 관문이다. 시험에서는 대부분 REST API vs HTTP API 선택과 엔드포인트 타입(Edge/Regional/Private), 그리고 인증·스로틀링·캐싱 같은 부가 기능을 묻는다.
Why It Exists
백엔드(Lambda·EC2·컨테이너)를 인터넷에 직접 노출하면 인증, 요청 제한(과부하 방어), 로깅, 버전 관리, 변환을 애플리케이션마다 직접 구현해야 한다.
API Gateway는 이 공통 관문 기능을 대신한다.
클라이언트 -> API Gateway -> 백엔드(Lambda / ALB / ECS / EC2 / AWS 서비스)
- 인증/인가(Authorizer), 요청 검증
- 스로틀링(rate limiting)으로 백엔드 과부하 방어
- 캐싱으로 백엔드 호출·지연 감소
- 로깅/모니터링, 스테이지(버전) 관리
시험 감각:
"서버리스 REST API를 만들고 싶다" = API Gateway + Lambda. "백엔드 앞에 인증·스로틀링·API 관문이 필요" = API Gateway.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
API GW | Amazon API Gateway | 관리형 API 생성·게시·보안·운영 서비스 |
REST API | REST API | 기능이 풍부한 API Gateway 타입 |
HTTP API | HTTP API | 저렴·저지연·기능 축소형 API Gateway 타입 |
JWT | JSON Web Token | 토큰 기반 인증에 쓰는 표준 토큰 |
OIDC | OpenID Connect | JWT 기반 인증 프로토콜 |
WAF | Web Application Firewall | 웹 공격 필터링 방화벽 |
Authorizer | Authorizer | API Gateway의 인증·인가 처리 컴포넌트 |
Usage Plan | Usage Plan | API 키별 호출량·스로틀 한도를 정하는 요금/제한 계획 |
REST API vs HTTP API — 시험 핵심
| 구분 | REST API | HTTP API |
|---|---|---|
| 비용 | 비쌈 | 저렴(약 70% 저렴) |
| 지연 시간 | 보통 | 낮음 |
| 기능 | 많음(풀 기능) | 제한적(핵심만) |
| JWT/OIDC 인증 | 기본 제공 X (Cognito·Lambda authorizer로 처리) | 기본 제공 O (JWT authorizer 내장) |
| API 키 / Usage Plan | 지원 | 미지원 |
| 요청/응답 변환(매핑 템플릿) | 지원 | 미지원(단순 프록시 위주) |
| 요청 검증(Request validation) | 지원 | 미지원 |
| 캐싱 | 지원 | 미지원 |
| WAF 연결 | 지원 | 미지원 |
| 엔드포인트 타입 | Edge / Regional / Private | Regional만 |
| Cognito authorizer | 지원 | (JWT authorizer로 Cognito 포함 OIDC 처리) |
한 줄 요약:
기능이 많이 필요하면 REST API, 싸고 빠르고 단순하면 HTTP API. JWT(OIDC) 인증을 기본으로 쓰고 싶으면 HTTP API가 편하다.
언제 무엇을 쓰나 (실사례)
REST API를 쓰는 경우
기능이 필요할 때 고른다.
| 실사례 | 이유 |
|---|---|
| 외부 파트너에게 API를 요금제/등급별로 판매 | API 키 + Usage Plan으로 고객별 호출 한도·스로틀 |
| 잘못된 요청을 백엔드 전에 걸러야 함 | Request validation(스키마 검증) |
| 반복 조회를 백엔드까지 안 보내고 빠르게 응답 | API Gateway 캐싱 |
| 레거시 백엔드 포맷에 맞춰 요청/응답 형태 변환 | 매핑 템플릿(request/response transformation) |
| 웹 공격 필터링이 필요 | WAF 연결 |
| 사내에서만 접근 가능한 내부 API | Private 엔드포인트(VPC 내부만) |
HTTP API를 쓰는 경우
싸고 빠르고 단순하면 고른다.
| 실사례 | 이유 |
|---|---|
| Lambda/HTTP 백엔드에 단순 프록시하는 서버리스 API | 저비용·저지연, 복잡한 변환 불필요 |
| 모바일/SPA 백엔드를 JWT(OIDC)로 인증 (Cognito, Auth0 등) | JWT authorizer 기본 제공 |
| 비용·지연에 민감한 대량 트래픽 마이크로서비스 | REST 대비 저렴·저지연 |
엔드포인트 타입 (REST API)
| 타입 | 동작 | 언제 |
|---|---|---|
| Edge-optimized | CloudFront 엣지를 거쳐 라우팅 | 전 세계에 흩어진 사용자가 단일 리전 API를 호출할 때 응답 지연 감소 |
| Regional | 해당 리전으로 직접 | 클라이언트가 같은 리전에 있거나, 내가 직접 CloudFront/CDN을 붙일 때 |
| Private | VPC 인터페이스 엔드포인트로만 접근 | 인터넷 노출 없이 VPC/사내 내부에서만 호출 |
주의: Edge-optimized는 REST API에만 있다. HTTP API는 Regional만 지원하므로, HTTP API로 전 세계 가속이 필요하면 앞에 CloudFront를 직접 둔다.
VPC Link — 프라이빗 백엔드로 나가기 (빈출)
Private 엔드포인트와 헷갈리기 쉽다. 방향이 반대다.
| 구분 | Private 엔드포인트 | VPC Link |
|---|---|---|
| 다루는 것 | 누가 API를 호출하나 (인바운드) | API가 어떤 백엔드로 나가나 (아웃바운드) |
| 목적 | API를 VPC 내부에서만 호출 가능하게 | API Gateway가 VPC 안 프라이빗 리소스에 연결 |
| 대상 | 클라이언트(호출자) | 내부 ALB/NLB, 프라이빗 ECS 등 |
클라이언트 -> API Gateway -> [VPC Link] -> VPC 내부 프라이빗 백엔드
(internal NLB / ALB / ECS)
- 백엔드를 인터넷에 노출하지 않고 API Gateway와 연결할 때 사용
- REST API는 NLB 기반 VPC Link, HTTP API는 ALB/NLB/Cloud Map 기반 VPC Link
- 시험 키워드: "expose a private service in a VPC through API Gateway", "backend not exposed to the internet"
시험 감각:
"VPC 안의 프라이빗 백엔드를 API로 노출하되 인터넷 노출은 막아라" = VPC Link.
빈출 부가 개념
| 개념 | 설명 | 시험 감각 |
|---|---|---|
| Throttling(스로틀링) | 초당 요청 수를 제한해 백엔드 과부하/폭주 방어 | "protect backend from traffic spikes", "rate limiting" |
| Usage Plan + API Key | 고객/파트너별 호출 한도·과금 구간 | "per-client rate limit", "monetize/tiered API" (REST) |
| Caching | 응답을 캐싱해 백엔드 호출·지연 감소 | "reduce backend load / latency for repeated calls" (REST) |
| Authorizer 종류 | IAM, Cognito User Pools, Lambda(custom) authorizer, JWT(HTTP API) | 누가 인증하나로 구분 |
| WAF 연결 | SQLi/XSS 등 웹 공격 필터링 | "protect API from web exploits" (REST) |
| Stages / Canary | 스테이지별 배포, 카나리로 일부 트래픽만 신버전 | "safe/gradual API deployment" |
| WebSocket API | 실시간 양방향 통신(채팅 등) | "real-time two-way / WebSocket" |
| Private API + VPC endpoint | 인터넷 없이 VPC 내부 전용 | "internal only, no public access" |
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|---|
| 비용·지연이 중요한 단순 프록시에 REST API | 단순·저지연·저비용이면 HTTP API |
| JWT 인증이 필요한데 REST API가 기본 제공한다고 가정 | REST API는 JWT 기본 미제공(Cognito/Lambda authorizer), JWT 내장은 HTTP API |
| API 키·Usage Plan·캐싱·WAF를 HTTP API로 하려 함 | 이 기능들은 REST API 전용 |
| 전 세계 사용자 가속에 HTTP API의 엣지 최적화 선택 | Edge-optimized는 REST API 전용. HTTP API는 앞에 CloudFront를 직접 |
| 백엔드 과부하를 Auto Scaling으로만 방어 | 관문에서 막으려면 API Gateway Throttling |
| 같은 리전 클라이언트에 Edge-optimized 강제 | 같은 리전이면 Regional이 단순·적합 |
| 프라이빗 백엔드 연결을 Private 엔드포인트로 해결하려 함 | 호출자 제한(인바운드)일 뿐, 프라이빗 백엔드 연결(아웃바운드)은 VPC Link |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "build a serverless REST API" | API Gateway + Lambda |
| "low cost / low latency / simple proxy API" | HTTP API |
| "built-in JWT / OIDC (Cognito, Auth0) authentication" | HTTP API (JWT authorizer) |
| "API keys, usage plans, per-client rate limits" | REST API |
| "request validation / response mapping / transformation" | REST API |
| "cache API responses to reduce backend load" | REST API caching |
| "attach WAF to the API" | REST API + WAF |
| "throttle / rate limit to protect backend" | API Gateway Throttling |
| "globally distributed clients, reduce API latency" | Edge-optimized (REST) |
| "API accessible only inside the VPC" | Private 엔드포인트 |
| "real-time two-way communication" | WebSocket API |
Memory Sentence
API Gateway는 백엔드 앞단 관문(인증·스로틀·캐싱·변환). 기능 많이·API키/Usage Plan/캐싱/WAF/Private/Edge가 필요하면 REST API, 싸고 빠르고 JWT 기본 인증이면 HTTP API. 전 세계 사용자 가속은 Edge-optimized(REST 전용), 같은 리전은 Regional, 내부 전용은 Private.
References
댓글
아직 댓글이 없습니다.