AppSync용 맞춤 도메인 이름을 설정하는 방법

나는 이전에 five reasons you should consider AppSync over API Gateway에 대해 썼습니다. API Gateway가 지원하지만 아직 기본 제공되는 AppSync로는 할 수 없는 한 가지는 사용자 지정 도메인 이름입니다.

멋진 새 AppSync API는 XYZ.appsync-api.us-east-1.amazonaws.com/graphql에서 사용할 수 있지만 dev.example.com/graphql가 훨씬 더 기억하기 쉽고 유익하기 때문에 사람들이 대신 자체 도메인을 사용하기를 원합니다.

이 게시물에서는 이를 수행할 수 있는 두 가지 방법을 살펴보겠습니다.

클라우드프론트

이것이 제가 선호하는 방식입니다. 설정하기 쉽고 실행 비용이 저렴합니다.

AppSync API 리소스가 GraphQlApi라고 가정합니다(서버리스 프레임워크에서 serverless-appsync-plugin을 사용하는 경우 이것이 사용할 논리 ID입니다). 트래픽을 AppSync API로 라우팅하도록 구성해야 하는 CloudFormation 리소스입니다.

AppSyncDistribution:
  Type: AWS::CloudFront::Distribution
  Properties:
    DistributionConfig:
      Origins:
        - Id: AppSync
          DomainName:
            Fn::Select:
              - '2'
              - Fn::Split:
                  - "/"
                  - Fn::GetAtt:
                      - GraphQlApi
                      - GraphQLUrl
          CustomOriginConfig:
            HTTPPort: 80
            HTTPSPort: 443
            OriginProtocolPolicy: https-only
            OriginSSLProtocols:
              - TLSv1
              - TLSv1.1
              - TLSv1.2
          OriginPath: ''
      Enabled: true
      HttpVersion: http2
      Comment: CloudFront distribution for the Patient AppSync API
      Aliases:
        - <INSERT DOMAIN NAME HERE, e.g. dev.example.com>
      PriceClass: PriceClass_100
      DefaultCacheBehavior:
        AllowedMethods:
          - HEAD
          - OPTIONS
          - GET
          - DELETE
          - POST
          - PUT
          - PATCH
        CachedMethods:
          - HEAD
          - OPTIONS
          - GET
        ForwardedValues:
          QueryString: true
          Headers:
            - x-api-key
            - Authorization
          Cookies:
            Forward: all
        MinTTL: 0
        DefaultTTL: 0
        TargetOriginId: AppSync
        ViewerProtocolPolicy: redirect-to-https
        Compress: true
      CustomErrorResponses: []
      ViewerCertificate:
        AcmCertificateArn: <INSERT ARN HERE>
        SslSupportMethod: sni-only

Serverless framework 을 사용하는 경우 serverless-appsync-cloudfront 플러그인도 확인해야 합니다. 그것은 당신을 위해 일을 훨씬 쉽게 만들 수 있습니다. 그러나 작성 당시에는 앞서 언급한 GraphQlApi와 함께 사용하기 위해 AppSync API의 논리적 ID(예상serverless-appsync-plugin)를 가정합니다.

API 게이트웨이

이를 수행할 수 있는 또 다른 방법은 API 게이트웨이를 사용하는 것입니다. 트래픽을 AppSync API로 라우팅하는 HTTP 프록시를 설정한 다음 API Gateway에서 사용자 지정 도메인 이름을 구성할 수 있습니다.

CloudFront를 사용할 때보다 이 접근 방식은 설정하는 데 더 많은 작업이 필요하며 모든 요청이 API 게이트웨이를 거쳐야 하기 때문에 CloudFront를 사용할 때보다 더 많은 비용과 대기 시간이 발생합니다.

서버리스 프레임워크를 사용하는 경우 또 다른 걸림돌은 Lambda 함수 없이 API 게이트웨이를 쉽게 선언할 수 없다는 것입니다. 다행히 SAM의 매크로AWS::Serverless-2016–10–31를 에서와 같이 serverless.yml로 가져오면 이 문제를 해결할 수 있습니다. 이를 통해 SAM의AWS::Serverless::Api 리소스 유형을 사용하여 API 게이트웨이를 구성할 수 있습니다.

ApiGateway:
  Type: AWS::Serverless::Api
  Properties:
    Name: AppSyncApiProxy
    StageName: dev
    OpenApiVersion: "3.0.1"
    DefinitionBody:
      openapi: "3.0.1"
      paths:
        /{proxy+}:
          "x-amazon-apigateway-any-method":
            consumes:
              - "application/json"
            produces:
              - "application/json"
            parameters:
              - name: proxy
                in: path
                required: true
                type: string
            x-amazon-apigateway-integration:
              uri: 
                Fn::Join:
                  - ''
                  - - 'https://'
                    - Fn::Select:
                        - '2'
                        - Fn::Split:
                            - "/"
                            - Fn::GetAtt:
                                - GraphQlApi
                                - GraphQLUrl
                    - '/{proxy}'
              passthroughBehavior: when_no_match
              httpMethod: ANY
              type: http_proxy                  
              requestParameters:
                integration.request.path.proxy : method.request.path.proxy
    EndpointConfiguration: REGIONAL

ApiGatewayDomainName:
  Type: AWS::ApiGateway::DomainName
  Properties:
    DomainName: <INSERT DOMAIN NAME>
    EndpointConfiguration:
      Types:
        - REGIONAL
    RegionalCertificateArn: <INSERT ARN HERE>

ApiGatewayBasePathMapping:
  Type: AWS::ApiGateway::BasePathMapping
  DependsOn:
    - ApiGatewayDomainName
  Properties:
    DomainName: <INSERT DOMAIN NAME>
    RestApiId: !Ref ApiGateway
    Stage: !Ref ApiGateway.Stage

여기서 주목해야 할 한 가지는 기본적으로 SAM이 Stage라는 API 게이트웨이 단계를 생성한다는 것입니다. 이는 SAM의 오래된 버그인 것으로 보이며 해결 방법은 OpenApiVersion를 3.0.1로 설정하는 것입니다.

Route53

이 두 접근 방식의 마지막 단계로 호스팅 영역에서 이들에 대한 Route53 레코드를 구성해야 합니다.

CloudFront의 경우 다음과 같은 것이 필요합니다.



API 게이트웨이의 경우 사용자 지정 도메인(API 게이트웨이에서)에 대한 API Gateway domain name를 캡처하고 이에 대해 Route53 레코드를 구성해야 합니다.





CloudFormation을 사용하여 이를 구성할 수도 있습니다.

요약

이 두 접근 방식을 모두 사용하여 AppSync에 대한 사용자 지정 도메인 이름(예: dev.example.com )을 생성할 수 있습니다. 발신자는 dev.example.com/graphql를 통해 AppSync API에 액세스할 수 있으며 훨씬 더 사용자 친화적이고 기억하기 쉽습니다.

위에서 언급했듯이 CloudFront 접근 방식을 선호하는 이유는 구성이 더 쉽고 비용 오버헤드가 무시할 수 있을 정도이기 때문입니다.

실습 튜토리얼을 통해 GraphQL 및 AppSync를 배우고 싶다면 제 new AppSync course에서 AppSync, Lambda, DynamoDB, Cognito 및 Vue.js의 조합을 사용하여 Twitter 복제본을 빌드하는 방법을 확인하십시오. 다양한 GraphQL 모델링 기술, 리졸버 디버깅 방법, CI/CD, 모니터링 및 경고 등에 대해 배우게 됩니다.