API Gateway

REST 및 WebSocket API를 생성, 게시, 유지, 모니터링 및 보호하기 위한 AWS 서비스API 개발자는 AWS 또는 다른 웹 서비스를 비롯해 AWS 클라우드에 저장된 데이터에 액세스하는 API를 생성할 수 있음

API Gateway Architecture

API Gateway 기능

Amazon API Gateway는 다음과 같은 기능을 제공

• 상태 저장(WebSocket) 및 상태 비저장(HTTP 및 REST) API에 대한 지원

• 강력하고 유연한 인증 메커니즘(예: AWS Identity and Access Management 정책, Lambda 권한 부여자 함수, Amazon Cognito 사용자 풀 등)

• API를 게시하기 위한 개발자 포털

• 변경 사항을 안전하게 롤아웃하기 위한 Canary 릴리스 배포

• API 사용 및 API 변경에 대한 CloudTrail 로깅 및 모니터링

• 경보 설정 기능을 포함한 CloudWatch 액세스 로깅 및 실행 로깅

• AWS CloudFormation 템플릿을 사용하여 API 생성을 활성화할 수 있는 기능

• 사용자 지정 도메인 이름 지원

• 일반적인 웹 익스플로잇으로부터 API를 보호하기 위해 AWS WAF와 통합

• 성능 지연 시간 파악 및 학습을 위해 AWS X-Ray와 통합

서버리스 아키텍처의 일부로 구성

API Gateway는 AWS Lambda 및 HTTP 엔드포인트와 간소한 프록시 통합을 지원하기 떄문에 AWS 서버리스 인프라의 앱 페이싱(app-facing) 부분을 구성 가능

사용 대상

API Gateway를 사용하는 개발자는 다음과 같음

1. API 개발자 API를 생성하고 배포하여 API Gateway에서 필요한 기능을 구현 API 개발자는 AWS 계정 내에서 API를 소유한 IAM 사용자여야 함

2. 앱 개발자 API Gateway에서 API 개발자가 생성한 WebSocket 또는 REST API를 호출하여 AWS 서비스를 호출하기에 효과적인 애플리케이션을 구축

앱 개발자는 API 개발자의 고객이기에, API에 IAM 권한이 필요하지 않거나 Amazon Cognito 사용자 풀 자격 증명 연동에서 지원하는 타사 연동 자격 증명 공급자를 통해 사용자 권한 부여를 지원하는 경우, 앱 개발자는 AWS 계정을 보유할 필요가 없음

API Gateway 개념

• API Gateway

  • 백엔드 HTTP 엔드포인트, AWS Lambda 함수 또는 기타 AWS 서비스를 노출하기 위한 RESTful 애플리케이션 프로그래밍 인터페이스(API)의 생성, 배포 및 관리

  • AWS Lambda 함수 또는 기타 AWS 서비스를 노출하기 위한 WebSocket의 생성, 배포 및 관리

  • 프런트 엔드 HTTP 및 WebSocket 엔드포인트를 통해 노출된 API 메서드 호출

• API Gateway HTTP API 백엔드 HTTP 엔드포인트 또는 Lambda 함수와 통합된 라우팅 및 메서드의 모음 이 모음을 하나 이상의 스테이지로 배포할 수 있음 각 라우팅은 API Gateway에서 지원되는 고유의 HTTP 동사를 가진 API 메서드를 하나 이상 노출됨

• API Gateway REST API 백엔드 HTTP 엔드포인트, Lambda 함수 또는 기타 AWS 서비스와 통합되어 있는 HTTP 리소스와 메서드의 모음 이 모음을 하나 이상의 스테이지로 배포할 수 있음 각 API 리소스는 API Gateway에서 지원하는 전용 HTTP 동사가 있는 API 메서드를 하나 이상 표시 가능

• API Gateway WebSocket API 백엔드 HTTP 엔드포인트, Lambda 함수 또는 기타 AWS 서비스와 통합되어 있는 WebSocket 라우팅과 라우팅 키의 모음 이 모음을 하나 이상의 스테이지로 배포할 수 있음 API 메서드는 프런트 엔드 WebSocket 연결을 통해 호출되며, 이 엔드포인트를 등록된 사용자 지정 도메인 이름과 연결할 수 있음

• API 배포 API Gateway API의 특정 시점 스냅샷 클라이언트가 사용할 수 있게 하려면 배포가 하나 이상의 API 단계와 연결되어 있어야 함

• API 개발자 API Gateway 배포를 소유한 AWS 계정(예: 프로그래밍 액세스도 지원하는 서비스 공급자)

• API 엔드포인트 특정 리전에 배포되는 API Gateway의 API 호스트 이름 호스트 이름은 {api-id}.execute-api.{region}.amazonaws.com. 다음과 같은 유형의 API 끝점이 지원됨

  • 엣지 최적화 API 엔드포인트

  • 프라이빗 API 엔드포인트

  • 리전 API 엔드포인트

• API 키 영숫자 문자열로 API Gateway 사용하여 앱 REST 또는 websocket API를 사용하는 개발자 API Gateway 를 대신하여 API 키를 생성하거나 CSV 파일에서 가져올 수 있음 API 키와 Lambda 권한 부여자 또는 사용량 계획을 함께 사용하여 API 액세스를 제어할 수 있음

• API 단계 API의 수명 주기 상태에 대한 논리적 참조(예: 'dev', 'prod', 'beta', 'v2') API 단계는 API ID와 단계 이름으로 식별됨

• 앱 개발자 API 개발자가 배포한 API와 상호 작용하며 AWS 계정이 있거나 없을 수도 있는 앱 생성자 앱 개발자는 일반적으로 API 키로 식별되게 됨

• 콜백 URL 새 클라이언트가 WebSocket 연결을 통해 연결되면 API Gateway에서 통합을 호출하여 클라이언트의 콜백 URL을 저장할 수 있음 이 콜백 URL을 사용하여 백엔드 시스템에서 클라이언트로 메시지를 보낼 수 있음

• 개발자 포털 고객이 API 제품(API 게이트웨이 사용량 계획)을 등록, 검색 및 구독하고, API 키를 관리하고, API에 대한 사용 지표를 볼 수 있게 해주는 애플리케이션

• 엣지 최적화 API 엔드포인트 AWS 리전에서 일반적으로 손쉽게 클라이언트 액세스가 가능하도록 CloudFront 배포판을 사용할 때 지정된 리전에 배포되는 API Gateway API의 기본 호스트 이름 API 요청은 지리적으로 다양한 클라이언트를 위해 연결 시간을 일반적으로 향상시키는 가장 가까운 CloudFront 입지 지점(POP)으로 라우팅됨

• 통합 요청 API Gateway에서 WebSocket API 라우팅 또는 REST API 메서드의 내부 인터페이스로, 여기에서 라우팅 요청의 본문 또는 메서드의 본문 및 파라미터를 백엔드에서 요구하는 형식으로 매핑함

• 통합 응답 API Gateway에서 WebSocket API 라우팅 또는 REST API 메서드의 내부 인터페이스로, 백엔드에서 클라이언트 앱으로 반환되는 응답 형식으로 받은 상태 코드, 헤더, 페이로드를 여기에서 매핑함

• 매핑 템플릿 VTL(Velocity Template Language)에 나온 스크립트로, 프런트엔드 데이터 형식으로 된 요청 본문을 백엔드 데이터 형식으로 변환하거나 백엔드 데이터 형식으로 된 응답 본문을 프런트엔드 데이터 형식으로 변환 통합 요청 또는 통합 응답에 매핑 템플릿이 지정될 수 있음 이들은 실행 시간에 컨텍스트 및 스테이지 변수로 제공되는 데이터를 참조할 수 있음 매핑은 요청에 대해 클라이언트에서 백엔드로 통합을 통해 헤더나 본문을 전달하는 자격 증명 변환만큼 간단할 수 있음 백엔드에서 클라이언트로 페이로드가 전달되는 응답의 경우도 마찬가지

• 메서드 요청 API 방법의 공용 인터페이스 API Gateway 애플리케이션 개발자가 API를 통해 백엔드에 액세스하기 위해 전송해야 하는 매개 변수 및 본체를 정의

• 메서드 응답 REST API의 퍼블릭 인터페이스로, 앱 개발자가 API의 응답에 기대하는 본문 모델, 헤더, 상태 코드를 여기서 정의

• 모의 통합 모의 통합에서는 통합 백엔드가 없어도 API Gateway에서 직접 API 응답이 생성됨 API 개발자는 API Gateway가 모의 통합 요청에 응답하는 방법을 결정되며, 이를 위해, 메서드의 통합 요청 및 통합 응답을 구성하여 정해진 상태 코드와 응답을 연결함

• 모델 요청 또는 응답 페이로드의 데이터 구조를 지정하는 데이터 스키마 모델은 API에서 강력한 형식의 SDK를 생성하는 데 필요하며, 페이로드를 확인하는 데에도 사용됨 모델은 샘플 매핑 템플릿을 생성해 프로덕션 매핑 템플릿 생성을 시작하기에 편리한 도구로, 있으면 유용하기는 하지만 매핑 템플릿을 생성할 때 모델은 필요하지 않음

• 프라이빗 API 엔드포인트 인터페이스 VPC 엔드포인트를 통해 노출되고 클라이언트가 VPC 내부의 프라이빗 API 리소스에 안전하게 액세스할 수 있도록 해주는 API 엔드포인트 프라이빗 API는 퍼블릭 인터넷과 격리되어 있으며, 액세스 권한이 있는 API Gateway의 VPC 엔드포인트를 사용해야만 액세스할 수 있음

• 프라이빗 통합 리소스를 퍼블릭 인터넷에 노출하지 않고, 클라이언트가 프라이빗 REST API 엔드포인트를 통해 고객 VPC 내부의 리소스에 액세스할 수 있는 API Gateway 통합 유형임

• 프록시 통합 간소화된 API Gateway 통합 구성. HTTP 프록시 통합 또는 Lambda 프록시 통합으로 프록시 통합을 설정할 수 있음 HTTP 프록시 통합에서 API Gateway는 프런트 엔드와 HTTP 백엔드 간에 전체 요청 및 응답을 전달함 Lambda 프록시 통합에서 API Gateway는 전체 요청을 백엔드 Lambda 함수의 입력값으로 전송함 그런 다음 API Gateway는 Lambda 함수 출력을 프런트 엔드 HTTP 응답으로 변환함 REST API에서 프록시 통합은 프록시 리소스에서 가장 많이 사용되며, 복잡한 경로 변수(예: {proxy+})와 catch-all ANY 메서드로 표시됨

• 빠른 생성 빠른 생성을 사용하여 HTTP API 생성을 간소화할 수 있습니다. 빠른 생성은 Lambda 는 HTTP 통합, 기본 catch-all 라우팅, 변경 사항을 자동 배포하도록 구성된 기본 스테이지를 사용하여 API를 생성

• 리전 API 엔드포인트 특정 리전에 배포되고 동일한 AWS 리전에서 EC2 인스턴스와 같은 클라이언트에 서비스를 제공하는 API의 호스트 이름으로, API 요청은 CloudFront 배포판을 거치지 않고 리전별 API Gateway로 직접 지정됨 리전 내 요청의 경우 리전 엔드포인트는 CloudFront 배포판에 대한 불필요한 왕복을 우회함 뿐만 아니라, 리전 엔드포인트에 지연 시간 기반 라우팅을 적용하여 동일한 리전 API 엔드포인트 구성을 사용해 여러 리전에 API를 배포하고, 배포된 각 API에 동일한 사용자 지정 도메인 이름을 설정하고, 클라이언트 요청을 지연 시간이 가장 짧은 리전에 라우팅하도록 Route 53에서 지연 시간 기반 DNS 레코드를 구성할 수도 있음

• 라우팅 API Gateway에서 WebSocket 라우팅은 수신 메시지를 메시지 내용에 따라 AWS Lambda 함수 같은 특정 통합으로 연결하는 데 사용됨 WebSocket API를 정의할 때 라우팅 키와 통합 백엔드를 지정하며, 라우팅 키는 메시지 본문의 속성임 수신 메시지에서 라우팅 키가 일치하면 통합 백엔드가 호출됨 일치하지 않는 라우팅 키에 대해 기본 라우팅을 설정하거나, 라우팅을 수행하고 요청을 처리하는 백엔드 구성 요소로 메시지를 전달하는 프록시 모델을 지정할 수도 있음

• 라우팅 요청 API Gateway에 있는 WebSocket API 메서드의 퍼블릭 인터페이스로, 본문을 정의 앱 개발자가 API를 통해 백엔드에 액세스하려면 반드시 이 파라미터와 본문을 요청에 포함시켜 보내야 함

• 라우팅 응답 WebSocket API의 퍼블릭 인터페이스로, 앱 개발자가 API Gateway에 기대하는 본문 모델, 헤더, 상태 코드를 여기서 정의하게 됨

• 사용량 계획 사용량 계획은 선택한 API 클라이언트에게 하나 이상의 배포된 REST 또는 WebSocket API에 대한 액세스를 제공하고, 사용량 계획을 사용해 조절 및 할당량 제한을 구성할 수 있으며, 이는 개별 클라이언트 API 키에 적용됨

• WebSocket 연결 API Gateway는 클라이언트와 API Gateway 자체 사이에 영구적인 연결을 유지 API Gateway과 Lambda 함수와 같은 백엔드 통합 간에는 지속적인 연결이 없으며, 백엔드 서비스는 클라이언트에서 수신한 메시지의 내용에 따라 필요 시 호출됨

API Gateway 종류

1. HTTP API REST API보다 대기 시간이 짧고 비용이 저렴하게 RESTful API를 구성 가능 AWS Lambda 함수 또는 공개 라우팅이 가능한 HTTP 엔드포인트에 요청을 전송할 수 있음 HTTP API는 OpenID Connect 및 OAuth 2.0 권한 부여를 지원 또한 CORS(Cross-Origin Resource Sharing) 및 자동 배포가 기본적으로 지원됨

2. REST API API Gateway REST API는 리소스와 메서드로 구성 리소스란 앱이 리소스 경로를 통해 액세스할 수 있는 논리적 엔터티 메서드는 API 사용자가 제출한 REST API 요청 및 사용자에게 반환되는 응답

   앱은 백엔드에서 요청된 데이터를 저장하고 가져오는 위치를 알 필요가 없으며, API Gateway REST API에서 프런트엔드는 메서드 요청 및 메서드 응답으로 캡슐화되고 API는 integration requests(통합 요청) 및 integration responses(통합 응답)을 이용해 백엔드와 통신하게 됨

   통합 응답을 클라이언트에 대한 (해당 HTTP 상태 코드의) 적절한 메서드 응답으로 라우팅하려면, 통합에서 메서드로 필요한 응답 파라미터를 매핑하도록 통합 응답을 구성하면 됨 그런 다음, 필요에 따라 백엔드의 출력 데이터 형식을 프런트엔드의 형식으로 변환 API Gateway를 사용하면 페이로드의 스키마나 모델을 정의하여 본문 매핑 템플릿을 손쉽게 설정 가능

3. WebSocket API WebSocket API에서 클라이언트와 서버는 언제든 서로 메시지를 보낼 수 있음 백엔드 서버는 복잡한 폴링 메커니즘을 구현할 필요 없이 연결된 사용자 및 장치로 데이터를 쉽게 푸시할 수 있음

   API Gateway WebSocket API를 사용하면 연결이나 대용량 데이터 교환을 관리하기 위해 서버를 프로비저닝하거나 관리하지 않고도 안전한 실시간 통신 애플리케이션을 구축할 수 있음

   • 채팅 애플리케이션

   • 주식 시세 표시기와 같은 실시간 대시 보드

   • 실시간 경고 및 알림

HTTP API와 REST API 비교

HTTP API는 대기 시간이 짧고 비용 효과적인 AWS Lambda 프록시 및 HTTP 프록시 API를 위해 설계됨 HTTP API는 OIDC 및 OAuth 2.0 인증을 지원하며 CORS 및 자동 배포에 대한 기본 지원을 제공하고, 이전 세대 REST API는 현재 더 많은 기능을 제공하며 API 요청 및 응답을 완전히 제어가 가능

권한 부여자
	HTTP API	REST API
AWS Lambda		✔
IAM		✔
Amazon Cognito	✔*	✔
OpenID Connect/OAuth 2.0	✔
* Amazon Cognito를 JWT 발급자로 사용
Integration
	HTTP API	REST API
HTTP 프록시	✔	✔
Lambda 프록시	✔	✔
HTTP		✔
AWS 서비스	✔	✔
프라이빗 통합	✔	✔
모의		✔
API 관리
	HTTP API	REST API
사용량 계획		✔
API 키		✔
사용자 지정 도메인 이름	✔*	✔
* HTTP API TLS 1.0 지원 안됨
개발
	HTTP API	REST API
Cache		✔
변환 요청		✔
요청/응답 검증		✔
호출 테스트		✔
CORS 구성	✔
자동 배포	✔
기본 단계	✔
기본 경로	✔
Security
	HTTP API	REST API
클라이언트 인증서		✔
AWS WAF		✔
리소스 정책		✔
API 유형
	HTTP API	REST API
리전	✔	✔
엣지 최적화		✔
프라이빗		✔
Monitoring
	HTTP API	REST API
Amazon CloudWatch Logs에 대한 액세스 로그	✔	✔
Amazon Kinesis Data Firehose에 대한 액세스 로그		✔
실행 로그		✔
Amazon CloudWatch 지표	✔	✔
AWS X-Ray		✔

HTTP API

개발

생성

함수 API를 생성하려면 최소 하나 이상의 라우팅, 통합, 스테이지 및 배포가 있어야 함

라우팅

수신 API 요청을 백엔드 리소스로 직접 라우팅 경로는 HTTP 메서드와 리소스 경로(예: GET /pets)라는 두 부분으로 구성 라우팅에 대한 특정 HTTP 메서드를 정의할 수 있으나, ANY 메서드를 사용하여 리소스에 대해 정의하지 않은 모든 메서드와 일치시킬 수도 있음 다른 경로와 일치하지 않는 요청에 대해 catch-all 역할을 하는 $default 경로를 생성할 수 있음

• 경로 변수 작업 HTTP API 라우팅에서 경로 변수를 사용

  예) GET /pets/{petID} 라우팅은 클라이언트가 https://api-id.execute-api.us-east-2.amazonaws.com/pets/6에 제출하는 GET 요청을 포착

  복잡한 경로 변수는 라우팅의 모든 하위 리소스를 포착하게 됨 복잡한 경로 변수를 생성하려면 변수 이름에 +을 추가 (예: {proxy+}) 복잡한 경로 변수는 리소스 경로의 끝에 있어야함

• 쿼리 문자열 파라미터 작업 HTTP API에 대한 요청에 포함된 경우 API Gateway에서는 기본적으로 쿼리 문자열 파라미터를 백엔드 통합으로 보냄

  예) 클라이언트가 요청을 https://api-id.execute-api.us-east-2.amazonaws.com/pets?id=4&type=dog에 보내는 경우 쿼리 문자열 파라미터 ?id=4&type=dog가 통합에 전송되게 됨

• $default 라우팅 작업 $default 라우팅은 API의 다른 라우팅과 명시적으로 일치하지 않는 요청을 포착

  $default 라우팅이 요청을 받는 경우 API Gateway에서 전체 요청 경로를 통합에 보냄 예) $default 라우팅만 있는 API를 생성하여 https://petstore-demo-endpoint.execute-api.com HTTP 엔드포인트가 있는 ANY 메서드에 통합할 수 있음 요청을 https://api-id.execute-api.us-east-2.amazonaws.com/store/checkout에 보내는 경우 API Gateway에서 요청을 https://petstore-demo-endpoint.execute-api.com/store/checkout에 보냄

• API 요청 라우팅 클라이언트가 API 요청을 보내는 경우 API Gateway에서 먼저 요청을 라우팅할 단계를 결정하게 됨 요청이 단계와 명시적으로 일치하는 경우 API Gateway는 요청을 해당 단계로 보내게 되며, 요청과 완전히 일치하는 단계가 없는 경우 API Gateway는 요청을 $default 단계로 보내게 됨 만약 $default 단계가 없으면 API가 {"message":"Not Found"}를 반환하게 됨

  API Gateway 라우팅 우선 순위 1. 라우팅 및 메서드에 완전히 일치 2. 복잡한 경로 변수({proxy+})가 있는 라우팅 및 메서드에 일치 3. $default 라우팅

  라우팅 예제 1. GET /pets/dog/{id} 2. GET /pets/{proxy+} 3. ANY /{proxy+} 4. $default

  요청	선택한 라우팅	설명
  GET https://api-id.execute-api.region.amazonaws.com/pets/dog/1	GET /pets/dog/{id}	완전히 일치
  GET https://api-id.execute-api.region.amazonaws.com/pets/cat/1	GET /pets/{proxy+}	요청이 라우팅과 완전히 일치하지 않으나, GET 메서드와 복잡한 경로 변수가 있는 라우팅 포착
  POST https://api-id.execute-api.region.amazonaws.com/test/5	ANY /{proxy+}	ANY 메서드는 라우팅에 대해 정의하지 않은 모든 메서드와 일치함. 복잡한 경로 변수가 있는 라우팅은 $default 라우팅보다 우선 순위가 높게 됨

액세스 제어

JWT(JSON Web Token)를 OIDC(OpenID Connect) 및 OAuth 2.0 프레임워크의 일부로 사용하여 API에 대한 클라이언트 액세스를 제한 API의 경로에 대해 JWT 권한 부여자를 구성하면 API Gateway는 클라이언트가 API 요청과 함께 제출하는 JWT를 검증

API 요청 권한 부여

API Gateway는 다음과 같은 일반 워크플로우

1. 토큰에 대한 identitySource를 확인 identitySource에는 토큰만 포함하거나 Bearer 접두사가 붙은 토큰만 포함될수 있음

2. 토큰 디코딩

3. 발행자의 jwks_uri에서 가져온 퍼블릭 키를 사용하여 토큰의 알고리즘과 서명을 확인 현재 RSA 기반 알고리즘만 지원

4. 클레임을 검증 API Gateway는 다음과 같은 토큰 클레임을 평가

   • kid – 토큰에는 토큰에 서명한 jwks_uri의 키와 일치하는 헤더 클레임 유무

   • iss – 권한 부여자에 대해 구성된 issuer와 일치

   • aud 또는 client_id – 권한 부여자에 대해 구성된 audience 항목 중 하나와 일치

   • exp – 현재 시간(UTC 기준) 이후 여부

   • nbf – 현재 시간(UTC 기준) 이전 여부

   • iat – 현재 시간(UTC 기준) 이전 여부

   • scope 또는 scp – 토큰에 라우팅의 authorizationScopes 범위 중 하나 이상이 포함 여부

이러한 단계 중 하나라도 실패하면 API Gateway는 API 요청을 거부 JWT를 검증한 후 API Gateway는 토큰의 클레임을 API 경로의 통합에 전달 Lambda 함수와 같은 백엔드 리소스는 $context.authorizer.claims의 JWT 클레임에 액세스 가능

통합(Integration)

통합 백엔드 리소스에 라우트를 연결 HTTP APIs, Lambda 프록시, AWS 서비스 및 HTTP 프록시 통합 지원

1. HTTP API 라우팅을 공개적으로 라우팅할 수 있는 HTTP 엔드포인트에 연결할 수 있음 API Gateway이 프런트 엔드와 백엔드 사이에 전체 요청 및 응답을 전달

   경로 변수와의 HTTP 프록시 통합 HTTP API 라우팅에서 경로 변수를 사용 예) 라우팅 /pets/{petID}은 /pets/6에 대한 요청을 포착

2. Lambda 클라이언트가 API를 호출하면 API Gateway는 Lambda 함수에 요청을 전송하고 함수의 응답을 클라이언트에 반환

   • 페이로드 형식 버전 API Gateway에서 Lambda 통합으로 전송하는 데이터의 형식과 API Gateway이 Lambda에서 응답을 해석하는 방법을 지정

     Version 2.0 (Default)

       {
           "version": "2.0",
           "routeKey": "$default",
           "rawPath": "/my/path",
           "rawQueryString": "parameter1=value1&parameter1=value2&parameter2=value",
           "cookies": [
               "cookie1",
               "cookie2"
           ],
           "headers": {
               "Header1": "value1",
               "Header2": "value1,value2"
           },
           "queryStringParameters": {
               "parameter1": "value1,value2",
               "parameter2": "value"
           },
           "requestContext": {
               "accountId": "123456789012",
               "apiId": "api-id",
               "authorizer": {
                   "jwt": {
                       "claims": {
                           "claim1": "value1",
                           "claim2": "value2"
                       },
                       "scopes": [
                           "scope1",
                           "scope2"
                       ]
                   }
               },
               "domainName": "id.execute-api.us-east-1.amazonaws.com",
               "domainPrefix": "id",
               "http": {
                   "method": "POST",
                   "path": "/my/path",
                   "protocol": "HTTP/1.1",
                   "sourceIp": "IP",
                   "userAgent": "agent"
               },
               "requestId": "id",
               "routeKey": "$default",
               "stage": "$default",
               "time": "12/Mar/2020:19:03:58 +0000",
               "timeEpoch": 1583348638390
           },
           "body": "Hello from Lambda",
           "pathParameters": {
               "parameter1": "value1"
           },
           "isBase64Encoded": false,
           "stageVariables": {
               "stageVariable1": "value1",
               "stageVariable2": "value2"
           }
       }

     Version 1.0

       {
           "version": "1.0",
           "resource": "/my/path",
           "path": "/my/path",
           "httpMethod": "GET",
           "headers": {
               "Header1": "value1",
               "Header2": "value2"
           },
           "multiValueHeaders": {
               "Header1": [
                   "value1"
               ],
               "Header2": [
                   "value1",
                   "value2"
               ]
           },
           "queryStringParameters": {
               "parameter1": "value1",
               "parameter2": "value"
           },
           "multiValueQueryStringParameters": {
               "parameter1": [
                   "value1",
                   "value2"
               ],
               "parameter2": [
                   "value"
               ]
           },
           "requestContext": {
               "accountId": "123456789012",
               "apiId": "id",
               "authorizer": {
                   "claims": null,
                   "scopes": null
               },
           "domainName": "id.execute-api.us-east-1.amazonaws.com",
           "domainPrefix": "id",
           "extendedRequestId": "request-id",
           "httpMethod": "GET",
               "identity": {
                   "accessKey": null,
                   "accountId": null,
                   "caller": null,
                   "cognitoAuthenticationProvider": null,
                   "cognitoAuthenticationType": null,
                   "cognitoIdentityId": null,
                   "cognitoIdentityPoolId": null,
                   "principalOrgId": null,
                   "sourceIp": "IP",
                   "user": null,
                   "userAgent": "user-agent",
                   "userArn": null
               },
               "path": "/my/path",
               "protocol": "HTTP/1.1",
               "requestId": "id=",
               "requestTime": "04/Mar/2020:19:15:17 +0000",
               "requestTimeEpoch": 1583349317135,
               "resourceId": null,
               "resourcePath": "/my/path",
               "stage": "$default"
           },
           "pathParameters": null,
           "stageVariables": null,
           "body": "Hello from Lambda!",
           "isBase64Encoded": true
       }

   • Lambda 함수 응답 형식 페이로드 형식 버전에 따라 Lambda 함수가 반환해야 하는 응답 구조를 결정하게 됨

     Version 1.0

       {
           "isBase64Encoded": true|false,
           "statusCode": httpStatusCode,
           "headers": { "headerName": "headerValue", ... },
           "multiValueHeaders": { 
               "headerName": ["headerValue", "headerValue2", ...], ... 
           },
           "body": "..."
       }

     Version 2.0 API Gateway은 Lambda 함수가 유효한 JSON을 반환하고 statusCode를 반환하지 않으면 다음과 같이 가정하게 됨

     • isBase64Encoded = false

     • statusCode = 200

     • content-type = application/json

     • body은 함수의 응답

       {
         "cookies" : ["cookie1", "cookie2"],
         "isBase64Encoded": true|false,
         "statusCode": httpStatusCode,
         "headers": { "headerName": "headerValue", ... },
         "body": "Hello from Lambda!"
       }

3. AWS 서비스 클라이언트가 일류 통합(first-class intergration)으로 뒷받침되는 경로를 호출하는 경우, API Gateway 호출을 AWS 서비스 API를 제공

   매핑 요청 매개 변수

   유형	예	참고
   헤더 값	$request.header.name	헤더 이름은 대/소문자를 구분하지 않음. API Gateway 예를 들어 여러 헤더 값을 쉼표로 결합. "header1": "value1,value2".
   쿼리 문자열 값	$request.querystring.name	쿼리 문자열 이름은 대/소문자를 구분합니다. API Gateway 예를 들어 여러 값을 쉼표로 결합 "querystring1": "Value1,Value2"
   경로 매개변수	$request.path.name	요청 에서 경로 매개 변수의 값. 예) 경로가 /pets/{petId}을(를) 매핑가능. petId 요청의 매개 변수 $request.path.petId.
   바디 패스 요청	$request.body	API Gateway 를 통해 전체 요청 본체를 전달
   요청 본문	$request.body.name	A JSON 경로 표현. 재발성 하강($request.body..name) 및 필터 표현식(?(expression))을(를) 지원하지 않음
   컨텍스ㅑ트 변수	contextvariableName	지원되는 컨텍스트 변수
   단계 변수	$stagevariables.variableName	단계 변수
   정적 값	string	일정한 값.

통합 하위 유형 참조
* EventBridge-PutEvents
* SQS-SendMessage
* SQS-ReceiveMessage
* SQS-DeleteMessage
* SQS-PurgeQueue
* AppConfig-GetConfiguration
* Kinesis-PutRecord
* StepFunctions-StartExecution
* StepFunctions-StopExecution  

각 서비스 API별 필요한 파라미터 값이 다르므로 자세한 사항은 다음 경로 참고  
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-aws-services-reference.html

1. 프라이빗 프라이빗 통합을 사용하면 VPC의 프라이빗 리소스(예: Application Load Balancer 또는 Amazon ECS 컨테이너 기반 애플리케이션)와의 API 통합을 생성 가능 프라이빗 통합을 생성하려면 먼저 VPC 링크가 필요함 기본적으로 프라이빗 통합 트래픽은 HTTP 프로토콜을 사용하며, tlsConfig를 지정하여 HTTPS를 사용할수 있음

   1. Application Load Balancer 또는 Network Load Balancer를 사용

   2. AWS Cloud Map 서비스 검색을 사용 Amazon ECS를 사용하여 AWS Cloud Map에서 항목을 채우는 경우, SRV 레코드를 사용하도록 Amazon ECS 작업을 구성해야 하며, “A” 레코드는 지원되지 않음

CORS(Cross-Origin Resource Sharing)

브라우저에서 실행 중인 스크립트에서 시작되는 HTTP 요청을 제한하는 브라우저 보안 기능 CORS는 일반적으로 다른 도메인이나 오리진에 호스팅된 API에 액세스하는 웹 애플리케이션을 빌드하는 데 필요 CORS를 활성화하여 다른 도메인에 호스팅된 웹 애플리케이션에서 API에 대한 요청을 허용할 수 있음 예) API가 https://{api_id}.execute-api.{region}.amazonaws.com/에 호스팅되고 example.com에 호스팅된 웹 애플리케이션에서 API를 호출하려는 경우 API가 CORS를 지원해야 함

CORS 요청의 경우 API Gateway는 구성된 CORS 헤더를 통합의 응답에 추가하게 되며, CORS 구성에서 다음과 같은 매개 변수를 지정할 수 있음

CORS 헤더	CORS 구성 속성	예제 값
Access-Control-Allow-Origin	allowOrigins	https://www.example.com *( 모든 오리진 허용) https://*( https://로 시작하는 모든 오리진 허용) http://*( http://로 시작하는 모든 오리진 허용)
Access-Control-Allow-Credentials	allowCredentials	TRUE
Access-Control-Expose-Headers	exposeHeaders	Date, x-api-id
Access-Control-Max-Age	maxAge	300
Access-Control-Allow-Methods	allowMethods	GET, POST, DELETE, *
Access-Control-Allow-Headers	allowHeaders	Authorization, *

Publish

스테이지 및 사용자 지정 도메인 이름을 사용하여 클라이언트가 호출할 수 있도록 API를 게시하게 됨

Stages

API 단계는 API의 수명 주기 상태에 대한 논리적 참조임 (예: dev, prod, beta, v2)

사용자 지정 도메인 이름을 사용하여 클라이언트가 API를 호출할 수 있도록 기본 URL인 https://api-id.execute-api.region.amazonaws.com/stage 보다 더 간단하고 직관적인 URL을 사용할수 있음

배포는 API 구성의 스냅샷으로 단계에 API를 배포한 후에는 클라이언트가 API를 호출할 수 있음

변경 사항을 적용하려면 API를 배포해야 하고, 자동 배포를 활성화하면 API에 대한 변경 사항이 자동으로 릴리스되게 됨

단계 변수

단계 변수는 HTTP API의 단계에 대해 정의할 수 있는 키-값 페어 환경 변수와 비슷한 역할을 하며, API 설정에 사용하게 됨

Protect

너무 많은 요청으로 인해 API가 가득 차는 것을 방지하기 위해 Amazon API Gateway에서는 토큰 버킷 알고리즘을 사용하여 API에 대한 요청을 조절 API Gateway에서 한도 초과 요청을 실패하고 429 Too Many Requests 오류 응답을 클라이언트에 반환하게 됨

계정 수준 조절

기본적으로 API Gateway에서는 안정적인 상태의 요청 속도를 10,000rps(초당 요청 수)로 제한, AWS 계정 내 모든 API에 대해 버스트(즉, 최대 버킷 크기)를 5,000 요청으로 제한

라우팅 수준 조절

API의 특정 단계 또는 개별 라우팅에 대해 계정 수준 요청 스로틀 한도를 재정의 계정 수준 조절을 넘어갈수는 없음

REST API

To Be Continued

Websocket API

To Be Continued