AWS Section 23-2. AWS 서버리스 : API 게이트웨이

API Gateway – Usage Plans & API Keys

API를 제공하고 이를 유료화하려면 사용량 계획(Usage Plan)과 API 키(API Key)를 설정해야 한다.

• Usage Plan (사용량 계획)
  • API에 접근할 고객들의 속도와 요청 한도를 관리하는 기능이다. 누가 어떤 API의 단계와 메서드에 접근할 수 있는지, 얼마나 자주 접속할 수 있는지 등을 설정한다.
• API Keys (API 키)
  • 고객 식별을 위한 고유한 문자열이다. 고객에게 제공할 문자열로, API Gateway와 상호작용할 때 사용된다.
  • API 키는 사용량 계획과 함께 사용하여 고객이 API를 안전하게 사용하고 요청을 인증하는 데 사용된다.
  • 조절 한도는 API 키 수준에서 적용되어, 고객마다 사용 한도를 다르게 설정할 수 있고 최대 요청 수를 제한한다.
    • 조절 한도: API를 호출할 수 있는 최대 속도를 설정하여 API의 과도한 사용을 방지한다.
    • 할당량(Quota limits): 정해진 기간 동안 고객이 사용할 수 있는 최대 요청 횟수이다. 예를 들어, 기본 할당량을 설정해 한 달에 10,000개 요청만 가능하도록 할 수 있다.
•  

API Gateway – Correct Order for API Keys

[API 키와 사용량 계획을 구성하기 위한 순서]

1. 하나 이상의 API를 만들고, 특정 메서드가 API 키를 필요로 하도록 설정한 후, 해당 API를 단계에 배포한다.
2. 고객에게 제공할 API 키를 생성하거나 가져온다.
3. 원하는 조절 한도와 할당량을 지정하여 사용량 계획을 만든다.
4. API 단계와 API 키를 사용량 계획에 연결하여 적용한다.
5. API 호출 시, 클라이언트는 x-api-key 헤더에 할당된 API 키를 포함해야 한다. 이를 누락하면 요청이 인증되지 않는다.

 

API Gateway – Logging & Tracing

API Gateway는 CloudWatch Logs와 X-Ray를 통해 요청과 응답을 추적하고 로깅할 수 있다.

• CloudWatch Logs
  • API Gateway와 통합해 요청과 응답 정보를 기록한다.
  • 요청 및 응답의 세부 내용을 기록하며, 단계(Stage)별로 설정할 수 있다.
  • 로그 수준(예: ERROR, DEBUG, INFO)을 선택해 필요한 정보를 남길 수 있으며, API별로 설정을 재정의할 수 있다.
  • 로그를 남기면 요청과 응답의 모든 세부 정보가 기록되지만, 민감 정보가 포함될 수 있으므로 주의가 필요하다.
• X-Ray
  • 요청의 추적 정보를 제공해 API의 흐름을 시각적으로 확인할 수 있다.
  • 특히 API Gateway와 Lambda의 통합 추적에 유용하다.

사용자의 요청이 API Gateway를 통해 백엔드로 전달되고, 응답이 다시 CloudWatch Logs와 X-Ray를 통해 기록되어 사용자에게 전달된다.

 

API Gateway – CloudWatch Metrics

 

CloudWatch Metrics는 API Gateway의 성능 및 상태를 모니터링하는 데 유용한 다양한 메트릭을 제공한다.

• 주요 메트릭
  • CacheHitCount & CacheMissCount: 캐시 효율성을 보여준다. 캐시 적중률이 높을수록 백엔드 부하가 줄어든다.
  • Count: 주어진 기간의 API 요청 수를 나타낸다.
  • IntegrationLatency: API Gateway가 백엔드에서 응답을 받을 때까지 걸리는 시간이다.
  • Latency: 클라이언트 요청 수신부터 응답 반환까지 걸리는 전체 시간으로, IntegrationLatency보다 크다.
  • 4XXError & 5XXError: 클라이언트 측(4xx) 및 서버 측(5xx) 오류의 발생 횟수를 나타낸다.

 

API Gateway Throttling

 

API Gateway는 요청이 과도할 때 Throttling을 통해 서비스 안정성을 유지한다.

• 기본 한도
  
  • 모든 API에 대해 초당 10,000건의 요청으로 조절되며, 필요에 따라 상향 가능하다.
• 429 오류
  • 요청이 과도할 경우 클라이언트는 "429 Too Many Requests" 오류를 받으며, 재시도할 수 있지만 백오프 전략이 필요하다.
• 단계 및 메서드별 제한
  • 성능 향상을 위해 각 단계와 메서드별로 조절 한도를 설정할 수 있다. 사용량 계획을 통해 고객별 조절도 가능하다.

 

API Gateway – Errors

 

API Gateway에서 발생하는 주요 오류 코드에는 클라이언트 오류(4xx)와 서버 오류(5xx)가 있다.

• 4xx 오류 (클라이언트 오류)
  • 400: 잘못된 요청
  • 403: 접근 거부, WAF에 의해 차단된 경우
  • 429: 할당량 초과 또는 조절에 따른 제한
• 5xx 오류 (서버 오류)
  • 502: Lambda 프록시에서 호환되지 않는 응답 반환
  • 503: 서비스 이용 불가
  • 504: 백엔드의 응답 시간 초과 (29초 이후 자동 시간 초과)

 

 

AWS API Gateway - CORS

CORS 개념

• CORS는 브라우저 보안 기능으로, 다른 도메인에서 API 호출을 받을 수 있도록 허용하는 설정이다.
• API Gateway가 다른 도메인(교차 오리진)에서 호출을 받으려면 CORS를 활성화해야 한다.

• OPTIONS Pre-flight 요청
  • CORS 설정을 위해 브라우저는 OPTIONS 메서드를 사용하는 Preflight 요청을 API Gateway로 보낸다.
  • 이 요청에는 다음과 같은 헤더가 포함되어야 한다
    • Access-Control-Allow-Methods: 허용되는 HTTP 메서드를 명시.
    • Access-Control-Allow-Headers: 허용되는 헤더를 명시
    • Access-Control-Allow-Origin: 허용되는 오리진(도메인)을 명시
  • CORS 설정은 API Gateway 콘솔에서 활성화할 수 있다.

 

CORS – Enabled on the API Gateway

 

[CORS가 활성화된 경우의 요청 흐름 예시]

1. 정적 콘텐츠 로드
   • 웹 브라우저가 www.example.com의 S3 버킷에서 정적 콘텐츠(예: JavaScript 파일)를 가져오고
2. 교차 오리진 API 요청
   • 이 웹사이트의 JavaScript가 api.example.com으로 과 같은 다른 도메인(API Gateway)으로 API 호출을 시도하는 경우, 교차 오리진 요청이 발생한다.
3. Preflight 요청과 응답
   • 브라우저는 보안을 위해 OPTIONS 메서드로 API Gateway에 사전 요청(preflight)을 보내고, API Gateway는 해당 요청에 대한 응답을 통해 교차 오리진 요청을 허용할지 결정한다.
     • 응답 헤더에 Access-Control-Allow-Origin, Access-Control-Allow-Methods 등이 포함되어 있어야 한다.
4. 최종 API 호출
   • CORS 응답이 허용되면 브라우저는 API Gateway로 실제 요청(GET, PUT 등)을 전송할 수 있게 된다.

 

시험 대비에서는 API Gateway에서 CORS를 활성화할 수 있다는 점만 알고 있어도 충분!! :)
교차 오리진 요청을 허용할 때 이 설정이 필요함!! 정도까지만 이해하면 된다.

 

 

 

API Gateway – Security: IAM Permissions

IAM 권한을 사용해 API Gateway에 대한 접근을 제어할 수 있다.

• Authentication = IAM | Authorization = IAM Policy
  • IAM 정책을 이용해 API Gateway 접근을 제어한다.
  • 인증은 IAM을 통해 이루어지고, 권한 부여는 IAM 정책으로 관리된다.
  • 주로 AWS 내부에서 접근할 때 적합하며, EC2 인스턴스, Lambda 함수 또는 IAM 사용자가 API Gateway에 접근할 때 사용한다.
  • Signature v4를 사용해 IAM 증명을 헤더에 추가하여 API Gateway에서 인증과 권한 확인을 수행한다.

 

클라이언트가 API Gateway에 REST API 요청을 보낼 때, Sig v4 헤더가 포함된다. API Gateway는 이를 IAM으로 보내 권한을 확인하고, 인증되면 요청을 백엔드로 전달한다.

 

API Gateway – Resource Policies

 

• API Gateway에서 JSON 기반 리소스 정책을 설정해 누가 어떻게 접근할 수 있는지 정의할 수 있다.

• 주요 기능
  • 교차 계정 접근을 허용하며, IAM 보안과 결합해 다른 계정의 사용자에게도 접근 권한을 부여할 수 있다.
  • 특정 IP 주소 또는 VPC 엔드포인트에 대한 접근을 허용할 수 있다.

JSON 정책을 통해 특정 사용자와 역할에게 API 접근 권한을 부여하고, 특정 경로에 대해 접근을 허용.

 

API Gateway – Cognito User Pools

 

• Authentication = Cognito User Pools | Authorization = API Gateway Methods
  • Cognito는 사용자 데이터베이스 역할을 하며, 사용자 라이프사이클을 자동으로 관리한다.
  • 토큰이 자동으로 만료된다..
  • API Gateway와 Cognito를 통합하면 사용자가 Cognito를 통해 자동으로 인증을 받고, 권한은 API Gateway 메서드 레벨에서 설정된다.
  • 사용자 풀에서 인증을 받아 얻은 토큰을 API Gateway에 전달하여 접근을 허용하는 방식이다.
  • 설정이 간단해 사용자 인증이 필요한 경우 유용하다.

 

 

클라이언트는 Cognito로부터 토큰을 발급받아 API Gateway로 전달하며, API Gateway는 이를 검증하고 백엔드에 요청을 전달한다.

 

API Gateway – Lambda Authorizer

 

Lambda Authorizer는 토큰 기반 권한 부여자로, JSON 웹 토큰(JWT)이나 OAuth 토큰 같은 Bearer 토큰을 지원한다.

• Token-based Authorization
  • Lambda 함수가 토큰이나 요청 파라미터를 받아 인증하고, 필요한 IAM 정책을 생성해 반환한다. 생성된 정책은 캐싱된다.
  • 사용자 인증은 서드파티 인증 시스템을 통해 이루어지고, API Gateway는 Lambda Authorizer를 이용해 권한을 부여한다.
  • 유연성이 높고 직접 인증 및 권한 부여 논리를 설정할 수 있으나, 매번 Lambda 호출 시 비용이 발생할 수 있다.

 

클라이언트가 서드파티 인증 시스템에서 토큰을 받아 API Gateway로 전달하고, Lambda Authorizer가 이를 검증하여 접근을 허용한다.

 

 

API Gateway – Security Summary

API Gateway 보안을 위한 접근 방식

1. IAM
   • AWS 계정 내의 사용자 및 역할에게 적합하다.
   • Signature v4로 인증과 권한 부여를 처리하며, 리소스 정책을 통해 교차 계정 접근을 지원한다.
2. Custom Authorizer
   • 서드파티 토큰을 사용할 때 적합하다.
   • Lambda 함수에서 인증과 권한 부여를 처리하고, 결과를 캐싱하여 효율성을 높인다.
3. Cognito User Pools
   • AWS Cognito를 통해 자체 사용자 풀을 관리하고 인증한다.
   • 사용자 정의 코드가 필요 없으며, 백엔드에서 권한 부여를 구현해야 한다.

API Gateway 보안 방식을 이해하고 상황에 맞는 방법을 선택하는 것이 중요하다.

 

 

API Gateway – HTTP API vs REST API

API Gateway에서 제공하는 HTTP API와 REST API의 차이점을 이해하는 것이 중요하다.

• HTTP API
  • REST API보다 더 간단하고 비용 효율적인 옵션이다.
  • Lambda 프록시와 HTTP 프록시 통합, 프라이빗 통합을 지원한다.
  • OIDC와 OAuth 2.0 인증만을 제한적으로 지원하며, 데이터 매핑 기능이 없다.
  • 기본적으로 CORS를 지원하지만, 사용량 플랜과 API 키는 지원하지 않는다.
  • REST API와 비교해 비용이 저렴하지만 기능이 제한적이다.
• REST API
  • API Gateway의 가장 일반적인 형태로 HTTP API보다 다양한 인증 옵션을 제공한다.
  • 인증, CORS, 사용량 플랜, API 키 관리, 리소스 정책 등 모든 주요 기능을 지원한다.
  • Native OpenID Connect와 OAuth 2.0은 REST API에서는 지원되지 않는다.
  • REST API는 리소스 정책과 같은 추가적인 보안 옵션을 지원하여  Restful 서비스에 적합하다.

  

  HTTP API는 Native OpenID Connect 및 OAuth 2.0을 지원하지만, Resource Policies 지원은 REST API에만 적용된다.

HTTP API는 REST API에 비해 더 단순하고 저렴한 대안으로, 기본적인 프록시 및 인증 요구를 충족하는 데 적합하다. REST API는 고급 보안 및 인증이 필요한 경우에 사용하기 좋다.

 

 

API Gateway – WebSocket API 개요

• WebSocket의 정의
  • WebSocket은 사용자 브라우저와 서버 간에 양방향 상호작용을 제공하며, 클라이언트가 요청하지 않아도 서버가 정보, 푸시 알림을 보낼 수 있다.
  • 이를 통해 상태 유지 애플리케이션(stateful applications) 개발이 가능하다.
  • WebSocket API는 Lambda, DynamoDB, 혹은 HTTP 엔드포인트와 함께 사용할 수 있다.
• 활용 사례
  • WebSocket API는 실시간 애플리케이션 (채팅, 협업 플랫폼, 멀티플레이어 게임, 금융 거래 플랫폼 등)에 많이 사용된다.

 

• 기본 작동 원리
  • 클라이언트가 API Gateway의 WebSocket API에 접속하면 지속적인 연결이 유지된다.
  • 연결된 후, onConnect 람다 함수가 호출되고, 연결이 끊어질 때는 onDisconnect 람다 함수가 호출된다.
  • 지속적으로 메시지를 주고받기 위해 sendMessage 함수가 호출될 수 있다.

채팅 애플리케이션 예시 클라이언트가 메시지를 보낼 때마다 sendMessage라는 Lambda 함수가 호출되고, 연결 종료 시에는 onDisconnect 함수가 호출된다.

 

WebSocket API 연결 설정

• WebSocket URL
  • WebSocket URL은 wss://[고유ID].execute-api.[리전].amazonaws.com/[스테이지] 형식으로 작성된다.
  • 암호화된 WebSocket URL을 제공하여 보안을 강화한다.
  • 클라이언트가 API 게이트웨이의 WebSocket API에 연결되면, API Gateway는 connectionId를 생성하여 각 클라이언트를 식별하고, 이 connectionId를 활용해 DynamoDB에 사용자의 메타데이터를 저장할 수 있다.
  • connectionId는 클라이언트가 연결을 유지하는 동안 변경되지 않고 그대로 사용된다.

클라이언트가 WebSocket API에 연결하고, connectionId를 가진 Lambda 함수(onConnect)를 호출하며, 이 connectionId는 DynamoDB에 저장됨.

 

클라이언트에서 서버로 메시지 전송

• 메시지 전송 방식
  • 클라이언트는 WebSocket을 통해 메시지를 프레임 형태로 전송하며, 동일한 connectionId가 사용된다.
  • WebSocket API는 메시지를 처리할 Lambda 함수(sendMessage)를 호출하고, 필요 시 DynamoDB와 상호작용하여 데이터를 저장하거나 검색한다.
  • 즉 클라이언트가 메시지를 전송하면 동일한 connectionId를 통해 Lambda 함수가 호출되어 DynamoDB에 접근한다.

 

서버에서 클라이언트로 메시지 전송

• 서버는 클라이언트의 요청이 없어도 WebSocket URL을 통해 클라이언트에게 메시지를 전송할 수 있다.
• Connection URL이 생성되며, 이는 HTTP POST 요청을 통해 서버가 클라이언트로 메시지를 보낼 수 있게 한다.

• 서버가 클라이언트로 메시지를 전송할 때는 IAM Signature v4 인증을 사용해 보안 유지하며, 연결 URL에 /@connections/connectionid 형식을 사용해 메시지를 전송한다.

 

Connection URL 연산

• 연결 URL 연산 방식
  • POST: 서버에서 WebSocket 클라이언트로 메시지를 전송.
  • GET: 연결된 클라이언트의 최신 상태를 확인.
  • DELETE: WebSocket 연결에서 클라이언트 연결을 해제.

 

WebSocket API 라우팅

• 라우팅의 개념
  • WebSocket API는 JSON 메시지를 기반으로 특정 백엔드 기능으로 데이터를 라우팅할 수 있다.
  • 필수 라우트(예: connect, disconnect, default)와 사용자 정의 라우트(join, quit 등)를 정의할 수 있다.

 

• [일반적 흐름]
  • JSON 메시지를 API 게이트웨이에서 설정한 라우트 키에 따라 특정 Lambda 함수로 라우팅한다.(별도 라우트가 없을 경우, $default 라우트로 이동)
• [선택 표현식을 통한 흐름]
  • 선택 표현식을 사용하여 메시지의 특정 필드에 따라 다른 함수나 백엔드로 라우팅한다.

        >> 라우트 선택 표현식 예시

• • 예를 들어 $request.body.action과 같은 표현식을 사용하여, JSON 데이터의 action 필드가 "join"인 경우 join 라우트로 연결된다.

• JSON 데이터에 따라 라우트가 결정되며, action 필드의 값에 따라 API 게이트웨이가 join, quit, delete와 같은 라우트 키 테이블을 참조하여 적합한 백엔드로 연결된다.

 

API Gateway – 아키텍처

• 단일 인터페이스 생성
  • API 게이트웨이를 사용하면 회사의 모든 마이크로서비스를 단일 인터페이스로 노출할 수 있다. 이를 통해 클라이언트는 내부 구조를 알 필요 없이 다양한 서비스에 접근할 수 있다.
• API 엔드포인트와 다양한 리소스
  • API 엔드포인트는 다양한 백엔드 리소스와 연결할 수 있다. 예를 들어, 특정 서비스에 요청이 오면 이를 Elastic Load Balancer(ELB)를 통해 ECS 클러스터로 전달하거나, S3 버킷에 저장된 문서 리소스로 전달할 수 있다.
  • 클라이언트의 요청에 따라 여러 서비스로의 접근을 단일 API 게이트웨이에서 조율한다.

 

API Gateway 아키텍처 예시

[API Gateway 아키텍처 예시]

• customer1.example.com과 customer2.example.com이라는 두 클라이언트가 각각 API 게이트웨이에 접속한다.
• /service1 요청은 ELB를 통해 ECS 클러스터(마이크로서비스)로 전달되고, /docs 요청은 S3 버킷(문서 리소스)으로 전달된다. /service2 요청은 Amazon EC2 오토 스케일링 그룹에 연결된 ELB로 전달된다.

 

• 도메인 및 SSL 인증서 적용
  • API 게이트웨이 도메인을 Route 53을 통해 등록하고, 각 클라이언트가 독립된 도메인 주소를 가질 수 있다. 예를 들어 customer1.example.com과 customer2.example.com 같은 도메인을 설정하여 클라이언트가 서로 다른 주소로 접근하도록 할 수 있다.
  • 도메인마다 SSL 인증서를 적용해 보안성을 강화할 수 있습니다.
• 포워딩 및 트랜스포메이션 규칙
  
  • API 게이트웨이에서 포워딩 규칙과 데이터 변환을 설정하여, 백엔드로 요청을 보내기 전에 필요한 데이터 수정이 가능하다. 이를 통해 클라이언트로부터 받은 데이터를 가공하여 백엔드에서 요구하는 형식으로 변환할 수 있다.

 

클라이언트는 복잡한 백엔드 구조나 세부 사항을 알 필요 없이, API 게이트웨이의 단일 엔드포인트를 통해 필요한 서비스에 접근할 수 있다. SSL, 데이터 변환, 라우팅 등의 작업은 모두 API 게이트웨이 수준에서 관리된다.

API 게이트웨이를 통해 여러 마이크로서비스를 단일 엔드포인트로 통합하고, 필요한 보안 및 라우팅 설정을 수행하여 클라이언트에게 간소화된 API 접근성을 제공한다.