Day 5 - Week 4 복습: API Gateway 종합 시나리오로 실전 감각 다지기

스타트업이 외부 파트너에게 API를 제공한다. 파트너 A는 월 10만 건, 파트너 B는 월 50만 건으로 API 호출을 제한해야 한다. 또한 파트너 B는 초당 100 요청, 파트너 A는 초당 20 요청으로 속도 제한이 필요하다. 가장 적절한 구성은?

• A파트너별로 별도 REST API와 스테이지를 생성하고 각 스테이지에 rate/burst 스로틀링을 설정한다 — 차등 속도는 되지만 월 할당량(quota)을 제공하지 못하고 API가 파트너 수만큼 중복돼 운영 복잡도가 큼
• B파트너별 사용량 플랜(Usage Plan)을 생성하고 각 파트너에게 API 키를 발급해 해당 플랜에 연결한다
• CLambda Authorizer에서 파트너 ID를 확인하고 호출 횟수를 DynamoDB 카운터에 원자적으로 기록해 월 한도·초당 한도를 직접 구현한다 — 동작은 하나 분산 카운터 원자성·비용 부담이 크고 매니지드 기능의 재발명
• DAPI Gateway 리소스 정책에서 파트너 IP별 aws:SourceIp 조건으로 요청 수를 제한한다 — 리소스 정책은 허용/거부 접근 제어일 뿐 rate limit·quota 기능이 없음

회사의 REST API Lambda 함수가 외부 결제 서비스에 의존한다. CloudWatch에서 5XXError가 증가하고 있으며, Latency는 29초에 가깝고 IntegrationLatency도 29초에 가깝다. 가장 가능성 높은 원인은?

• ALambda Authorizer가 느려 인증 단계에서 시간이 소요되고 있다 — 그렇다면 Latency가 IntegrationLatency보다 커야 하는데 둘이 거의 같아 병목은 백엔드
• BLambda 함수가 응답하기 전에 API Gateway 통합 타임아웃(29초)에 도달하고 있다
• C클라이언트가 한도를 초과해 요청을 보내 429 스로틀링이 발생하고 있다 — 스로틀링이면 5XX가 아니라 4XXError가 증가하고 Latency가 29초에 붙지도 않음
• DCloudWatch Logs 설정 오류로 Latency·IntegrationLatency 메트릭이 실제보다 부풀려 기록되고 있다 — 두 메트릭이 일관되게 29초에 수렴하는 패턴은 실제 백엔드 타임아웃의 전형적 신호

개발팀이 REST API에 DynamoDB 직접 통합(VTL)을 구현했다. API Gateway는 DynamoDB GetItem을 호출하고 응답을 클라이언트에 반환한다. 클라이언트 개발자가 응답이 {"Item": {"name": {"S": "홍길동"}, "age": {"N": "30"}}} 형식으로 오는 것에 불만을 제기했다. 어떻게 해결하는가?

• A통합 뒤에 Lambda 함수를 추가해 DynamoDB 응답을 파싱한 뒤 클린 JSON으로 반환한다 — 동작은 하나 Lambda 없는 직접 통합의 핵심 이점(비용·콜드스타트 제거)을 버리는 셈
• BDynamoDB 테이블의 속성 타입 설정을 모두 문자열(S)로 강제해 응답에서 타입 래퍼를 없앤다 — DynamoDB는 항목별 타입 래퍼를 항상 포함하므로 테이블 설정으로 제거 불가
• CIntegration Response의 VTL 매핑 템플릿을 작성해 DynamoDB 응답을 클린 JSON으로 변환한다
• DREST API를 HTTP API로 마이그레이션하면 DynamoDB 직접 통합이 타입 래퍼를 자동으로 제거해 준다 — HTTP API는 VTL·AWS 서비스 직접 통합을 지원하지 않아 이 시나리오 자체가 불가능

모바일 앱이 API Gateway REST API를 통해 데이터를 조회한다. Cognito User Pool로 인증한다. 같은 사용자가 동일한 데이터를 반복 조회할 때 Lambda 호출을 줄이고 싶다. 응답 캐싱을 설정했는데, 모든 사용자의 응답이 같은 캐시 값을 공유하는 문제가 발생했다. 원인과 해결책은?

• A캐싱이 Cognito 토큰을 자동으로 캐시 키에 포함하지 않으므로, Authorization 헤더를 캐시 키에 추가한다
• BAPI Gateway 캐싱은 사용자 단위 분리를 지원하지 않으므로 캐시를 끄고 Lambda 내부에서 사용자별 캐싱을 직접 구현한다 — 캐시 키에 헤더를 추가하면 분리가 되므로 자체 구현은 불필요
• CCognito Authorizer 대신 Lambda Authorizer로 바꾸면 principalId 기준으로 캐시가 자동 분리된다 — Authorizer 종류와 응답 캐시 키는 별개라 자동 분리되지 않음
• DREST API를 HTTP API로 전환하면 토큰별 캐시가 기본 적용된다 — HTTP API는 응답 캐싱 자체를 지원하지 않아 해결책이 될 수 없음

실시간 주식 거래 알림 시스템을 구축한다. 트레이더가 웹 브라우저에서 연결하면 서버가 가격 변동을 즉시 푸시해야 한다. 트레이더에서 서버로 메시지를 보낼 필요는 없다. 가장 적합한 아키텍처는?

• AWebSocket API + DynamoDB 연결 레지스트리 + Lambda 브로드캐스트로 양방향 채널을 구성한다 — 동작하나 단방향 푸시에는 연결 레지스트리·브로드캐스트 로직이라는 불필요한 복잡도·비용 추가
• BREST API에 클라이언트가 5초 간격으로 폴링하게 해 최신 가격을 가져온다 — 즉시성이 떨어지고 빈 응답에도 매번 호출이 발생해 비효율적
• CLambda Response Streaming + Function URL (SSE 패턴)
• DSNS + SQS + Lambda + REST API 롱 폴링으로 이벤트를 전달한다 — 구성 요소가 많아 과도하게 복잡하고 브라우저로의 실시간 푸시에는 부적합

회사가 REST API에 WAF를 설정해 SQL 인젝션을 차단하려 한다. 그런데 일부 합법적인 요청도 차단된다. 팀은 차단된 요청의 패턴을 분석하고 WAF 규칙을 세밀하게 조정하고 싶다. 어떤 WAF 설정을 활성화해야 하는가?

• AWAF Sampled Requests를 활성화해 매칭된 요청 샘플을 콘솔에서 확인한다 — 일부 샘플만 보여줘 분석엔 도움되나, 차단을 멈추지 않아 합법 요청이 계속 막힘
• BAPI Gateway Execution Logs를 INFO 레벨로 올려 차단 요청을 상세 로깅한다 — 실행 로그는 API GW 처리 내역일 뿐 WAF 규칙 매칭 원인을 보여주지 못함
• CX-Ray 추적을 활성화해 요청 경로별 지연과 차단 지점을 분석한다 — X-Ray는 성능 트레이싱 도구라 WAF 규칙 튜닝에 쓸 데이터를 제공하지 않음
• DWAF Web ACL을 count 모드로 전환하고 CloudWatch Logs를 활성화한다

스타트업이 Next.js 백엔드 API를 AWS에 배포하려 한다. 각 API 경로를 별도 Lambda로 분리했으며, 요구사항은: (1) 낮은 비용, (2) Cognito 기반 JWT 인증, (3) 자동 CORS 설정, (4) 커스텀 도메인. 가장 적합한 API 유형은?

• AREST API (Cognito User Pool Authorizer + 수동 CORS + us-east-1 ACM 커스텀 도메인) — 요구는 충족하나 호출당 비용이 약 3.5배 높고 CORS를 수동 구성해야 해 비용·자동화 요건에 불리
• BHTTP API (JWT Authorizer + 자동 CORS 설정 + 커스텀 도메인)
• CFunction URL (자동 CORS + IAM 인증)로 각 Lambda를 직접 노출 — 함수당 하나의 URL만 가능해 여러 경로 라우팅·통합 커스텀 도메인을 제공하지 못함
• DWebSocket API로 클라이언트와 지속 연결을 맺어 요청을 처리한다 — 요청-응답형 REST 백엔드에는 부적합한 양방향 프로토콜이며 JWT Authorizer·자동 CORS도 미지원

Lambda Authorizer(TOKEN 타입, TTL 300초)를 사용하는 API가 있다. 보안팀이 특정 사용자의 JWT 토큰을 즉시 무효화해야 한다는 요청을 했다. 토큰은 아직 만료되지 않았다. 가장 빠른 방법은?

• ACognito에서 해당 사용자 계정을 비활성화해 토큰을 무효화한다 — 새 토큰 발급은 막아도 이미 캐시된 Authorizer Allow 정책은 TTL 동안 그대로 유효해 즉시 차단되지 않음
• BLambda Authorizer 함수 코드에서 해당 토큰을 블랙리스트에 추가하고, Authorizer TTL을 0으로 임시 변경한다
• CAuthorizer 캐시 TTL 300초가 만료될 때까지 기다렸다가 자연 무효화되게 둔다 — 즉시 무효화 요구를 충족하지 못하고 그동안 접근이 허용됨
• DAPI Gateway 스테이지를 재배포해 Authorizer 캐시를 강제로 비운다 — 재배포는 Authorizer 결과 캐시를 비우지 않아 캐시된 토큰은 계속 통과

WebSocket API 기반 실시간 채팅에서 특정 채팅방에 있는 사용자들에게만 메시지를 브로드캐스트해야 한다. DynamoDB에 연결 레지스트리가 있다. 가장 효율적인 DynamoDB 조회 방법은?

• AScan + FilterExpression으로 전체 테이블을 읽은 뒤 해당 채팅방 연결만 필터링한다 — Scan은 전체 항목을 읽어 RCU·지연이 연결 수에 선형 증가해 비효율적
• B채팅방 ID를 GSI Partition Key로 설정하고 Query를 사용해 해당 채팅방의 연결만 조회한다
• C채팅방마다 별도 DynamoDB 테이블을 만들어 연결을 분리 저장한다 — 채팅방 수만큼 테이블이 늘어 관리·한도 부담이 크고 동적 채팅방 생성에 부적합
• DElastiCache Redis에 채팅방-연결 매핑을 두고 조회한다 — 빠르지만 ElastiCache 클러스터라는 추가 인프라·비용·운영이 필요해 본 요건엔 과함

팀이 API Gateway HTTP API와 Lambda 통합을 사용한다. 기존 Lambda 코드는 REST API에서 작동하던 코드로, event["requestContext"]["identity"]["sourceIp"]로 클라이언트 IP를 읽는다. HTTP API로 전환 후 해당 코드에서 오류가 발생한다. 근본 원인과 해결책은?

• AHTTP API는 클라이언트 IP를 이벤트로 제공하지 않으므로 REST API를 그대로 유지해야 한다 — HTTP API도 IP를 제공하며 위치가 바뀌었을 뿐이라 전환을 포기할 이유가 없음
• BHTTP API Payload v2.0에서 IP는 event["requestContext"]["http"]["sourceIp"]에 있다. 코드를 수정하거나 payloadFormatVersion을 "1.0"으로 설정한다
• CLambda 실행 역할에 execute-api 관련 권한이 빠져 IP 필드 접근이 거부되고 있다 — IAM 권한은 이벤트 페이로드 필드 가용성과 무관해 원인이 아님
• DsourceIp 대신 X-Forwarded-For 헤더를 직접 파싱해 첫 IP를 추출해야 한다 — 가능은 하나 v2.0이 sourceIp를 제공하므로 헤더 파싱은 불필요한 우회