it-swarm.com.de

Wie fügen Sie CloudFront vor dem API-Gateway hinzu?

API Gateway (APIG): Während CloudFront (CF) verwendet wird, wird kein CDN Edge-Caching unterstützt. Wenn ich eine CF-Distribution für die Verwendung von APIG als benutzerdefiniertes Origin konfiguriert habe, erhalte ich eine Fehlermeldung, deren Berechtigung abgelehnt wurde.

Wie konfiguriere ich CF, um dies zu beheben?

31
rynop

Bis das API-Gateway (APIG) Edge-Caching über die interne Verwendung von CloudFormation (CF) unterstützt, ist eine Problemumgehung aufgetreten. 

Sie können zwar CF dist vor APIG stellen. Der Trick besteht darin, nur "Viewer Protocol Policy" für HTTPS zu erzwingen UND den Host-Header nicht weiterzuleiten, da APIG SNI benötigt.

Ich habe meine CF "Standard-Cache-Verhaltenseinstellungen" so eingerichtet, dass keine Header weitergeleitet werden, und die "Viewer-Protokollrichtlinie" wurde auf "Nur HTTPS" gesetzt. Das funktioniert. Hoffe das hilft anderen.

Hier ist ein CloudFormation-Ressourcenobjekt, das über alle erforderlichen Konfigurationen verfügt (Hinweis: Ich verwende die Konvention <stage>--<app name> für StackName):

CloudFront:  
    Type: AWS::CloudFront::Distribution
    Properties:
      DistributionConfig:
        Enabled: true
        IPV6Enabled: true
        HttpVersion: http2
        Comment: !Join [ '--', [!Ref 'AWS::StackName', ' Cloud Front']]
        Aliases: [!Ref CloudFrontCname]
        ViewerCertificate:
          AcmCertificateArn: !Ref AcmCertificateArn
          SslSupportMethod: sni-only
          MinimumProtocolVersion: TLSv1.1_2016
        Origins:
        - Id: APIGOrigin
          DomainName: !Sub
            - ${apigId}.execute-api.${AWS::Region}.amazonaws.com
            - { apigId: !Ref ApiGatewayLambdaProxy }
          OriginPath: !Sub
            - /${Stage}
            - { Stage: !Select [ "0", !Split [ '--', !Ref 'AWS::StackName' ] ] }
          CustomOriginConfig:
            # HTTPPort: 80
            HTTPSPort: 443
            OriginProtocolPolicy: https-only
          OriginCustomHeaders:
            - HeaderName: 'Verify-From-Cf'
              HeaderValue: !Ref VerifyFromCfHeaderVal
        DefaultCacheBehavior:
          AllowedMethods: ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
          CachedMethods: ["GET", "HEAD", "OPTIONS"]
          ForwardedValues:
            Headers:
            - Access-Control-Request-Headers
            - Access-Control-Request-Method
            - Origin
            - Authorization
            # - Host APIG needs to use SNI
            QueryString: true
          TargetOriginId: APIGOrigin
          ViewerProtocolPolicy: https-only
          Compress: true
          DefaultTTL: 0
        CustomErrorResponses:
        - ErrorCachingMinTTL: 0
          ErrorCode: 400
        - ErrorCachingMinTTL: 1
          ErrorCode: 403
        - ErrorCachingMinTTL: 5
          ErrorCode: 500
  DNSARecord:    
    Type: AWS::Route53::RecordSet
    Properties:
      Comment: !Ref 'AWS::StackName'
      Name: !Ref CloudFrontCname
      Type: A
      HostedZoneName: !Join ['.', [ !Select [1, !Split ['.', !Ref CloudFrontCname]], !Select [2, !Split ['.', !Ref CloudFrontCname]], '']]
      AliasTarget:
        HostedZoneId: !Ref Route53HostedZoneId
        DNSName: !GetAtt CloudFront.DomainName
  DNSAAAARecord:    
    Type: AWS::Route53::RecordSet
    Properties:
      Comment: !Ref 'AWS::StackName'
      Name: !Ref CloudFrontCname
      Type: AAAA
      HostedZoneName: !Join ['.', [ !Select [1, !Split ['.', !Ref CloudFrontCname]], !Select [2, !Split ['.', !Ref CloudFrontCname]], '']]
      AliasTarget:
        HostedZoneId: !Ref Route53HostedZoneId
        DNSName: !GetAtt CloudFront.DomainName

Spätes Update 2018

  • CloudFormation unterstützt schließlich die Einstellung von SSL-Protokollen: MinimumProtocolVersion: TLSv1.1_2016
  • Ich habe diese (und viele andere) Best Practices zu einem OSS-Projekt gebacken: aws-blueprint
51
rynop

Wenn das API-Gateway einen Fehler 403 zurückgibt, wird Folgendes angezeigt:

Der Berechtigungsheader erfordert den Parameter 'Credential'. Genehmigung Header erfordert den Parameter 'Signatur'. Berechtigungsheader erfordert Parameter 'SignedHeaders'. Der Berechtigungsheader erfordert das Vorhandensein von entweder ein 'X-Amz-Date' oder ein 'Date'-Header.

es kann auch sein, dass der Origin-Endpunkt falsch ist. "Das API-Gateway behandelt alle Fehler in nicht vorhandenen Pfaden als 403-Fehler, für die keine Berechtigung erteilt wurde, und nicht als 404-Fehler." (siehe diesen Support-Thread ).

Ich habe diesen Fehler erhalten und davon ausgegangen, dass ich den Autorisierungsheader falsch weitergeleitet habe, aber ich hatte einfach den Ursprungspfad falsch konfiguriert.

2
Kevin

Hinzufügen zu vorherigen Antworten: 

es ist wichtig, dass das Verhaltenspfadmuster tatsächlich einem "echten" Pfad entspricht. 


Wenn der API-Endpunkt <id>.execute-api.<region>.amazonaws.com/stage-name/my-api ist

Und Origin-Domäne + Pfad ist <id>.execute-api.<region>.amazonaws.com/stage-name

Das Verhaltenspfadmuster mussmy-api, my-api/*, my-api/something usw. Sein


Ich weiß nicht warum, aber ich dachte, dass das Pfadmuster beispielsweise als Alias ​​verwendet werden kann:

https://www.example.com/random-name (Pfadmuster random-name) wird in Domäne + Pfad in Origin aufgelöst, z. B. <id>.execute-api.<region>.amazonaws.com/stage-name.

Das ist nicht der Fall.

0
Solo

Mit dem Start der regionalen API-Gateway-Endpunkte im November 2017 ist es meiner Meinung nach jetzt optimal, diese mit CloudFront-Distributionen zu verwenden. Einige detaillierte Anweisungen zum Wechsel von Edge-optimierten zu regionalen APIs und zum Einrichten der CloudFront-Distributionen finden Sie hier: 

AWS API Gateway sollte die Verwendung von TLS v1 verhindern

0
Alistair