Amazon DVA-C02: Amazon API Gateway 및 앱 통합 — 학습 가이드

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Developer Associate DVA-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

API Gateway(REST, HTTP, WebSocket)와 통합을 사용한 API 설계

설계는 올바른 API 유형을 선택하는 것에서 시작합니다. REST API(API Gateway REST)는 스테이지별 캐싱 및 정교한 매핑 템플릿과 같은 세분화된 스테이지 수준 기능을 제공합니다. HTTP API(API Gateway v2)는 일반적인 프록시 패턴과 네이티브 JWT/OIDC 권한 부여자에 대해 더 낮은 지연 시간과 비용을 제공합니다. WebSocket API는 라우팅 키($connect, $disconnect, $default)를 사용하여 영구적인 클라이언트-서버 채널을 제공하며, 메시지를 보내려면 API Gateway Management API(PostToConnection)가 필요합니다. 통합을 설계할 때는 간단한 요청/응답의 경우 AWS_PROXY/Lambda 프록시를 선호하고(aws apigateway put-integration --type AWS_PROXY 사용 또는 v2의 경우 ApiGatewayV2Client에서 CreateIntegration 사용), 프라이빗 HTTP 백엔드에는 HTTP 또는 VPC Link를 선택하십시오. 처리량이 높은 백엔드의 경우 NLB + VPC Link를 사용하십시오. Mock 통합(put-integration --type MOCK)과 통합 응답 템플릿을 사용하면 프런트엔드 팀이 백엔드 준비 없이도 개발을 시작할 수 있습니다. CloudFront를 API 앞에 배치할 때는 리전 API 엔드포인트를 오리진으로 사용하고 Origin Protocol Policy를 HTTPS-only로 설정하십시오. 엣지 최적화(edge-optimized) REST API는 이미 CloudFront 뒤에 위치합니다. 흔히 발생하는 문제로는 API와 Lambda 간의 페이로드 형식 버전 불일치(v1.0 vs 2.0), Lambda를 호출할 apigateway.amazonaws.com 권한 부여를 잊는 것(aws lambda add-permission --principal apigateway.amazonaws.com으로 권한 추가), 브라우저를 차단하는 CORS 설정 오류 등이 있습니다.

보안 및 권한 부여 패턴 (Cognito, IAM, 사용자 지정 권한 부여 모델)

보안 패턴은 클라이언트 유형 및 액세스 모델과 일치해야 합니다. Amazon Cognito User Pools 또는 외부 OIDC 공급자를 사용하고 이를 HTTP API용 JWT 권한 부여자로 연결하거나(apigatewayv2에서 CreateAuthorizer를 사용하고 identitySource를 $request.header.Authorization으로 설정), 세션 기반 사용자 액세스를 위해 REST API Cognito Authorizer를 사용하십시오. 서비스 간 또는 관리자용 API의 경우 IAM 권한 부여(SigV4)와 스테이지 및 메서드에 대한 범위가 엄격하게 지정된 IAM 리소스 정책을 선호하십시오. Lambda(사용자 지정) 권한 부여자는 맞춤형 인증 규칙을 구현하는 데 최고의 유연성을 제공하지만, 지연 시간과 장애 지점을 추가한다는 점을 기억해야 합니다. 콜드 스타트를 줄이고 클라이언트에 500 오류를 반환하는 것을 피하기 위해 TTL을 사용하여 권한 부여 응답을 캐시하십시오. 사용량 계획(usage plan)과 API 키(aws apigateway create-usage-plan 및 create-api-key)를 조절(throttling) 할당량과 결합하여 악용으로부터 보호하십시오. 올바른 IAM 권한을 보장하십시오. API Gateway에 Lambda 호출 권한을 부여하고(aws lambda add-permission), Lambda 실행 역할은 최소 권한으로 제한하십시오. 개발자가 겪는 함정으로는 JWT 권한 부여자를 위한 토큰 추출 활성화를 잊는 것, 권한 부여자 시간 초과가 전체 API 지연 시간에 영향을 미치는 것, CloudFront에 의한 헤더/쿠키 전달로 인해 의도치 않게 캐시를 우회하거나 사용자 데이터가 유출될 수 있는 것 등이 있습니다.

스테이지 관리, 버전 관리, 캐싱 및 카나리 배포

스테이지를 독립적인 런타임 환경으로 취급하십시오. 배포는 스냅샷(aws apigateway create-deployment 또는 apigatewayv2 create-deployment)이며, 스테이지는 해당 스냅샷에 매핑됩니다. 버전 간 트래픽을 라우팅하려면 스테이지 변수 또는 가급적 Lambda 별칭을 사용하십시오. 별칭을 원자적으로 전환(UpdateAlias)하거나 점진적 롤아웃을 위해 API Gateway 스테이지 카나리 설정을 사용하십시오. REST API의 경우, 스테이지에서 캐싱을 활성화하고(aws apigateway update-stage와 patch-operations를 사용하여 cacheClusterEnabled 및 cacheClusterSize 설정) 메서드 설정에서 TTL 및 캐시 키 파라미터를 제어하십시오. HTTP API는 현재 내장 캐싱 기능이 없으므로 CloudFront 또는 애플리케이션 수준 캐시를 사용하십시오. 배포 시 또는 기본 데이터가 변경될 때 캐시를 무효화하십시오. TTL에만 의존하면 오래된(stale) 데이터를 반환할 수 있습니다. 버전 관리 패턴: 경로에 시맨틱 API 버전 관리(/v1/…)를 사용하거나 블루/그린 흐름을 위해 스테이지 배포에 의존하십시오. 흔한 함정으로는 스테이지 변수가 안전하다고 가정하는 것(콘솔 액세스 권한이 있는 개발자에게 보임), 캐시 키를 잘못 구성하는 것(authorization 헤더 또는 쿼리 파라미터를 포함하는 것을 잊음), 스키마 변경 배포를 클라이언트 호환성과 조율하지 않는 것 등이 있습니다.

성능, 관찰 가능성 및 진단

API를 엔드투엔드로 계측합니다. API Gateway에서 실행 로그와 액세스 로그를 활성화하고 구조화된 JSON($context 변수)을 CloudWatch Logs로 생성합니다. API Gateway와 Lambda에서 X-Ray를 활성화하여(배포/스테이지에서 tracingEnabled를 설정하거나 SDK: PutFunctionConcurrency/UpdateFunctionConfiguration와 TracingConfig 사용) 추적을 상호 연관시킵니다. CloudWatch에서 API Gateway 지표(Latency, IntegrationLatency, 4XX/5XX, CacheHitCount)와 Lambda 지표(Duration, Throttles, ConcurrentExecutions)를 모니터링하고, 지표 수학(metric math)을 사용하여 지연 시간이 누적되는 위치를 식별합니다. WebSocket의 경우, 연결 수와 API Gateway 5XX 급증을 추적합니다. 문제 해결 단계에는 IntegrationLatency와 Latency를 비교하여 백엔드 또는 게이트웨이가 오버헤드를 추가하는지 확인하고, 콜드 스타트나 VPC ENI에 대해 X-Ray 세그먼트를 드릴다운하며, CloudWatch Logs에서 매핑 템플릿 오류를 확인하는 것이 포함됩니다. 비동기 Lambda 실패에 대해서는 DLQ와 대상을 사용하고, 중요한 함수에는 예약된 동시성 또는 프로비저닝된 동시성을 설정합니다. 개발자 함정: 민감한 PII를 추적에 로깅하는 것(소스에서 수정하거나 해당 흐름에 대해 X-Ray 샘플링 비활성화), 사용자 지정 도메인에 대한 공급자 인증서 누락(엣지용 us-east-1 대비 리전별 ACM), 퍼블릭 API에 대해 사용량 계획 없이 기본 계정 조절에 의존하는 것.

실제 문제: 사용 사례 시나리오

시나리오: BrightCart는 S3/CloudFront에서 호스팅되는 단일 페이지 애플리케이션으로 리전별 이커머스 프론트엔드를 운영하고 있으며, API Gateway(리전별 HTTP API)를 통해 체크아웃 API를 노출합니다. 이 API는 VPC 내의 Lambda 함수를 호출하고 주문을 DynamoDB에 기록합니다. 이 환경은 CI/CD 파이프라인을 사용하여 Lambda 버전을 프로덕션 별칭(alias)에 배포하고 프로덕션 스테이지에서 /checkout을 노출합니다.

과제: 최근 기능 출시 후 프로덕션 API 지연 시간이 증가했으며 일부 체크아웃 요청이 간헐적으로 502/504를 반환합니다. 개발자에게는 안전한 롤백 메커니즘과 즉각적인 진단이 필요합니다.

권장 접근 방식:

프로덕션 API 스테이지가 이전 배포를 가리키도록 하여 배포 롤백을 생성합니다.

undefined

를 사용한 다음

undefined

를 사용합니다. 2. Lambda 별칭을 사용하여 안전하게 트래픽을 전환합니다.

undefined

로 prod Lambda 별칭을 이전 버전으로 업데이트하고 동작을 확인합니다. 3. 진단 정보를 활성화하고 수집합니다. API와 Lambda에 대해 X-Ray 추적을 활성화하고(

undefined

및

undefined

) 상세 액세스 로그(

undefined

)를 켜서 CloudWatch Logs로 보냅니다. 4. 지표와 추적을 분석합니다. CloudWatch에서 API Gateway IntegrationLatency와 Latency를 비교하고, X-Ray 세그먼트를 검사하여 VPC ENI 콜드 스타트를 식별하며, Lambda 조절(throttle) 또는 DynamoDB 조건부 쓰기를 확인합니다. 만약 VPC ENI 지연 시간이 근본 원인이라면, 프로비저닝된 동시성(

undefined

)을 고려하거나 VPC 엔드포인트 최적화가 적용된 Lambda로 이전하는 것을 고려합니다.

근거: 원자적인 스테이지 재배포와 Lambda 별칭 전환은 코드 변경 없이 빠르고 위험이 적은 롤백을 제공합니다. X-Ray와 구조화된 액세스 로그를 활성화하면 개발자는 API Gateway, Lambda 콜드 스타트, VPC 네트워킹 또는 다운스트림 DynamoDB 호출 중 무엇이 오류를 유발하는지 정확히 찾아낼 수 있으며, 이를 통해 올바른 완화 조치(프로비저닝된 동시성, 처리량 증가 또는 구성 수정)를 안내받을 수 있습니다.

← 서버리스 및 AWS Lambda · 모든 도메인 · Amazon DynamoDB 및 NoSQL 설계 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →