서버리스와 모의 통합 AWS API 게이트웨이 추가

이번 주에 흥미로운 사용 사례가 나에게 왔습니다. AWS API Gateway에는 Lambda와 통합되는 REST API가 있습니다. 이것은 Serverless 을 사용하여 설정됩니다. 이것은 다중 테넌트 시스템이며 이전 클라이언트가 정리를 수행하지 않았기 때문에 기본적으로 오류를 반환하는 많은 호출을 여전히 받고 있습니다(테넌트가 더 이상 우리 편에 존재하지 않기 때문). AWS Lambda에서 이것은 쓸데없는 호출이 많고 월말에 더 높은 청구액을 의미합니다. 다음은 Lambda가 호출되기 전에 API 게이트웨이에서 오류를 반환하는 방법입니다. 즉, AWS 인프라가 이를 처리하도록 합시다.

리소스

AWS 콘솔의 이 스크린샷은 우리가 끝내고자 하는 것을 명확하게 보여줍니다.

이것을 분석해 보겠습니다. 이전에는 /{proxy+} 리소스만 있었습니다. 이것은 경로가 람다로 전송되고 람다가 라우팅을 처리함을 의미합니다. 프록시 통합이라고 하는 것을 사용하는 대신 API 게이트웨이에 리소스를 배치하도록 선택할 수 있지만 여기서는 실제로 문제가 되지 않습니다(또한 제 생각에는 선호도 문제일 뿐입니다). https://example.com/goodtenant/whatever에 요청이 있을 때 우리는 Lambda를 호출하고 응답을 반환하려고 합니다. 그러나 우리의 나쁜 테넌트가 https://example.com/badtenant/whatever에 요청을 하는 경우, 우리는 그들을 짧게 멈추고 즉시 오류를 반환하기를 원합니다.

따라서 위의 스크린샷에서 /badtenant에 대한 모든 요청 또는 해당 하위 경로는 오류를 반환해야 합니다.

통합

이제 모의 통합을 가리키고 (이 경우) HTTP 403을 반환하려면 이badtenant 리소스도 필요합니다. 다음과 같이 표시됩니다.

"MOCK"유형의 통합이 필요하고 모의 엔드포인트가 반환하는 모든 결과에 대해 HTTP 403을 반환하도록 해야 합니다. 모의 엔드포인트에서 몇 가지 기본 논리를 넣어 응답을 반환할 수 있습니다. 미니 람다처럼 보세요. 우리의 경우 어쨌든 결국 403을 반환할 것이기 때문에 우리가 무엇을 반환하는지는 별로 중요하지 않습니다.

서버리스 파일

이제 가장 중요한 부분은 serverless.yml이 다음과 같아야 한다는 것입니다(흥미롭지 않은 부분 생략).

functions:
  main:
    handler: lib/index.handler
    name: myLambda
    events:
      - http: POST /{proxy+}

...

resources:
  Resources:
    ApiGatewayResourceBadTenant:
     Type: AWS::ApiGateway::Resource
     Properties:
       ParentId:
         Fn::GetAtt: ["ApiGatewayRestApi", "RootResourceId"]
       PathPart: "badtenant"
       RestApiId:
         Ref: ApiGatewayRestApi
    ApiGatewayResourceBadTenantProxyVar:
      Type: AWS::ApiGateway::Resource
      Properties:
        ParentId:
          Ref: ApiGatewayResourceBadTenant
        PathPart: "{proxy+}"
        RestApiId:
          Ref: ApiGatewayRestApi
    ApiGatewayResourceeBadTenantProxyVarAny:
      Type: AWS::ApiGateway::Method
      Properties:
        HttpMethod: ANY
        ResourceId:
          Ref: ApiGatewayResourceBadTenantProxyVar
        RestApiId:
          Ref: ApiGatewayRestApi
        Integration:
          Type: MOCK
          PassthroughBehavior: NEVER
          RequestTemplates:
            application/json: "{\"statusCode\":403}"
          IntegrationResponses:
            - SelectionPattern: .*
              StatusCode: 403
        MethodResponses:
          - StatusCode: 403
        AuthorizationType: NONE

본질적으로 이것이 하는 일은 ApiGatewayResourceBadTenant 라는 새 리소스를 정의하는 것입니다. 상위( ApiGatewayRestApi )는 서버리스 프레임워크에 의해 생성되며 항상 ApiGatewayRestApi 라고 합니다. 리소스 아래에 프록시 리소스를 만듭니다. 그리고 그 아래에 메서드를 만듭니다.

이 메서드는 MOCK 통합을 포함하고 403을 반환합니다.

테스트

이를 서버리스로 배포한 후 필요한 리소스를 생성해야 합니다. 나쁜 세입자에게 전화를 걸면 403이 표시됩니다.

이것은 순수 API 게이트웨이이며 Lambda 중 하나도 호출되지 않았습니다.

그게 다야!

조각들을 모으는 데 시간이 좀 걸렸지만 결국에는 상당히 간단하고 우아한 해결책이 되었습니다. AWS 콘솔에서 수동으로 아무 것도 할 필요가 없습니다. 즉, 모든 것이 자동화되고 소스 제어에 남아 있습니다. 그러나 우리는 나쁜 세입자가 Lambda를 너무 많이 트리거하는 것을 막을 수 있습니다. 이는 Amazon 청구서에 좋습니다!