Wählen Sie zwischen CloudFront Functions und Lambda @Edge updateRequestOrigin() -Methode selectRequestOriginById() -Methode createRequestOriginMethode Group ()

Hilfsmethoden für die Änderung des Ursprungs

Dieser Abschnitt gilt, wenn Sie den für die Anfrage verwendeten Ursprung in Ihrem CloudFront Functions-Code dynamisch aktualisieren oder ändern. Sie können den Ursprung nur auf Anfrage des Betrachters aktualisieren ( CloudFront Funktionen). CloudFront Functions verfügt über ein Modul, das Hilfsmethoden zur dynamischen Aktualisierung oder Änderung des Ursprungs bereitstellt.

Um dieses Modul zu verwenden, erstellen Sie eine CloudFront Funktion mit JavaScript Runtime 2.0 und fügen Sie die folgende Anweisung in die erste Zeile des Funktionscodes ein:


import cf from 'cloudfront';

Weitere Informationen finden Sie unter Features von JavaScript Runtime 2.0 für CloudFront-Funktionen.

Anmerkung

Auf den Seiten der Test-API und Testkonsole wird nicht getestet, ob eine Ursprungsänderung stattgefunden hat. Durch das Testen wird jedoch sichergestellt, dass der Funktionscode fehlerfrei ausgeführt wird.

Wählen Sie zwischen CloudFront Functions und Lambda @Edge

Sie können Ihre Ursprünge aktualisieren, indem Sie entweder CloudFront Functions oder Lambda @Edge verwenden.

Wenn Sie CloudFront Functions verwenden, um Ursprünge zu aktualisieren, verwenden Sie den Viewer-Request-Event-Trigger, was bedeutet, dass diese Logik bei jeder Anfrage ausgeführt wird, wenn diese Funktion verwendet wird. Bei der Verwendung von Lambda@Edge befinden sich die Funktionen zur Aktualisierung des Ursprungs im Ereignisauslöser für Ursprungsanforderungen, sodass diese Logik nur bei Cache-Fehlern ausgeführt wird.

Ihre Wahl hängt weitgehend von Ihrer Arbeitslast und der bestehenden Nutzung von CloudFront Functions und Lambda @Edge in Ihren Distributionen ab. Die folgenden Überlegungen können Ihnen bei der Entscheidung helfen, ob Sie CloudFront Functions oder Lambda @Edge verwenden möchten, um Ihre Ursprünge zu aktualisieren.

CloudFront Functions ist in den folgenden Situationen am nützlichsten:

Wenn Ihre Anfragen dynamisch sind (was bedeutet, dass sie nicht zwischengespeichert werden können) und immer an den Ursprung weitergeleitet werden. CloudFront Functions bietet eine bessere Leistung und niedrigere Gesamtkosten.
Wenn Sie bereits über eine CloudFront Viewer-Anforderungsfunktion verfügen, die bei jeder Anfrage ausgeführt wird, können Sie die ursprüngliche Aktualisierungslogik zur vorhandenen Funktion hinzufügen.

Informationen zur Verwendung von CloudFront Funktionen zur Aktualisierung von Ursprüngen finden Sie in den folgenden Themen in den Hilfsmethoden.

Lambda@Edge ist in folgenden Situationen am besten geeignet:

Wenn Sie Inhalte haben, die in hohem Maße zwischengespeichert werden können, kann Lambda @Edge kostengünstiger sein, da es nur bei Cache-Fehlern ausgeführt wird, während CloudFront Functions bei jeder Anfrage ausgeführt wird.
Wenn Sie bereits über eine Lambda@Edge-Funktion für Ursprungsanforderungen verfügen, können Sie die Ursprungsaktualisierungslogik zur vorhandenen Funktion hinzufügen.
Diese Option ist auch von Vorteil, wenn Ihre Ursprungsaktualisierungslogik das Abrufen von Daten aus Datenquellen von Drittanbietern wie Amazon DynamoDB oder Amazon S3 erfordert.

Weitere Informationen zu Lambda@Edge finden Sie unter Anpassen am Edge mit Lambda@Edge.

updateRequestOrigin() -Methode

Verwenden Sie die Methode updateRequestOrigin(), um die Ursprungseinstellungen für eine Anforderung zu aktualisieren. Sie können diese Methode verwenden, um bestehende Ursprungseigenschaften für Ursprünge zu aktualisieren, die bereits in Ihrer Distribution definiert sind, oder um einen neuen Ursprung für die Anforderung zu definieren. Geben Sie hierfür die zu ändernden Eigenschaften an.

Wichtig

Alle Einstellungen, die Sie in der Methode updateRequestOrigin() nicht angeben, werden aus der vorhandenen Ursprungskonfiguration übernommen.

Der von der updateRequestOrigin() Methode festgelegte Ursprung kann ein beliebiger HTTP-Endpunkt sein und muss kein vorhandener Ursprung in Ihrer CloudFront Distribution sein.

Hinweise

Wenn Sie einen Ursprung aktualisieren, der Teil einer Ursprungsgruppe ist, wird nur der primäre Ursprung der Ursprungsgruppe aktualisiert. Der sekundäre Ursprung bleibt unverändert. Jeder Antwortcode des geänderten Ursprungs, der den Failover-Kriterien entspricht, löst einen Failover zum sekundären Ursprung aus.
Wenn Sie den Ursprungstyp ändern und OAC aktiviert ist, stellen Sie sicher, dass der Ursprungstyp in originAccessControlConfig mit dem neuen Ursprungstyp übereinstimmt.
Sie können die Methode updateRequestOrigin() nicht verwenden, um VPC-Ursprünge zu aktualisieren. Eine solche Anforderung würde fehlschlagen.

Anforderung


updateRequestOrigin({origin properties})

origin properties kann die folgenden Werte enthalten:

domainName (optional)

Der Domänenname des Ursprungs. Bei fehlender Angabe wird der Domainname des zugewiesenen Ursprungs verwendet.

Für benutzerdefinierte Ursprünge: Geben Sie einen DNS-Domainnamen an, z. B. www.example.com. Der Domainname darf keinen Doppelpunkt (:) enthalten und darf keine IP-Adresse sein. Der Domänenname kann bis zu 253 Zeichen lang sein.
Für S3-Ursprünge: Geben Sie den DNS-Domainnamen des Amazon-S3-Buckets an, z. B. amzn-s3-demo-bucket.s3.eu-west-1.amazonaws.com. Der Name kann bis zu 128 Zeichen lang sein und muss in Kleinbuchstaben geschrieben werden.

HostHeader (optional, für benutzerdefinierte Ursprünge außerhalb von S3)

Der Host-Header, der verwendet werden soll, wenn die Anfrage an den Ursprung gestellt wird. Wenn dies nicht angegeben wird, wird der Wert aus dem DomainName-Parameter verwendet. Wenn weder der Host-Header noch der Domain-Name-Parameter angegeben werden, wird der Domainname des zugewiesenen Ursprungs verwendet oder der Host-Header der eingehenden Anfrage, wenn die FTO-Richtlinie (Forward to Origin) den Host einschließt. Der Host-Header darf keinen Doppelpunkt (:) enthalten und darf keine IP-Adresse sein. Der Host-Header kann bis zu 253 Zeichen lang sein.

originPath (optional)

Der Verzeichnispfad auf dem Ursprung, aus dem die Anforderung den Inhalt abrufen soll. Der Pfad sollte mit einem Schrägstrich (/) beginnen, aber nicht damit enden. Zum Beispiel sollte er nicht mit example-path/ enden. Bei fehlender Angabe wird der Ursprungspfad des zugewiesenen Ursprungs verwendet.

Für benutzerdefinierte Ursprünge: Der Pfad sollte URL-kodiert sein und eine maximale Länge von 255 Zeichen haben.

customHeaders (optional)

Sie können benutzerdefinierte Header in die Anforderung aufnehmen, indem Sie für jeden benutzerdefinierten Header einen Header-Namen und einen -Wert angeben. Das Format unterscheidet sich von dem der Anforderungs- und Antwortheader in der Ereignisstruktur. Verwenden Sie die folgende Syntax für das Schlüssel-Wert-Paar:


{"key1": "value1", "key2": "value2", ...}

Sie können keine Header hinzufügen, die nicht erlaubt sind, und ein Header mit dem gleichen Namen kann in den headers eingehender Anforderungen nicht vorhanden sein. Der Headername muss im Funktionscode in Kleinbuchstaben geschrieben werden. Wenn CloudFront Functions das Ereignisobjekt wieder in eine HTTP-Anforderung konvertiert, wird der erste Buchstabe jedes Worts in Header-Namen groß geschrieben und die Wörter werden durch einen Bindestrich getrennt.

Wenn der Funktionscode beispielsweise einen Header mit dem Namenexample-header-name, CloudFront konvertiert diesen Example-Header-Name in der HTTP-Anfrage in einen Header hinzufügt. Weitere Informationen erhalten Sie unter Benutzerdefinierte Header, die CloudFront nicht zu Ursprungsanforderungen hinzufügen kann und Einschränkungen für Edge-Funktionen.

Bei fehlender Angabe werden benutzerdefinierte Header des zugewiesenen Ursprungs verwendet.

connectionAttempts (optional)

Gibt an, wie oft CloudFront versucht wird, eine Verbindung zum Ursprung herzustellen. Der Mindestwert ist 1 und der Höchstwert 3. Bei fehlender Angabe wird die Anzahl von Verbindungsversuchen des zugewiesenen Ursprungs verwendet.

originShield (optional)

Dadurch wird CloudFront Origin Shield aktiviert oder aktualisiert. Die Verwendung von Origin Shield kann dazu beitragen, die Belastung Ihres Ursprungs zu reduzieren. Weitere Informationen finden Sie unter Verwenden Sie Amazon CloudFront Origin Shield. Bei fehlender Angabe werden die Origin-Shield-Einstellungen des zugewiesenen Ursprungs verwendet.

aktiviert (erforderlich)

Boolescher Ausdruck zur Aktivierung oder Deaktivierung von Origin Shield. Akzeptierte Werte sind true oder false.

Region (erforderlich, wenn aktiviert)

Das AWS-Region für Origin Shield. Geben Sie die AWS-Region an, die die niedrigste Latenz zu Ihrem Ursprung aufweist. Verwenden Sie den Regionscode, nicht den Namen der Region. Geben Sie beispielsweise us-east-2 für die Region USA Ost (Ohio) an.

Wenn du CloudFront Origin Shield aktivierst, musst du das AWS-Region dafür angeben. Eine Liste der verfügbaren AWS-Regionen und Hilfe bei der Auswahl der besten Region für Ihren Ursprung finden Sie unter Wähle die AWS Region für Origin Shield.

originAccessControlConfig (optional)

Die eindeutige Kennung der Ursprungszugriffssteuerung (OAC) für diesen Ursprung. Dies wird nur verwendet, wenn der Ursprung ein CloudFront OAC unterstützt, z. B. Amazon S3, Lambda-Funktion URLs und MediaStore MediaPackage V2. Bei fehlender Angabe werden die OAC-Einstellungen des zugewiesenen Ursprungs verwendet.

Die veraltete Ursprungszugriffsidentität (OAI) wird nicht unterstützt. Weitere Informationen finden Sie unter Beschränken des Zugriffs auf einen AWS -Ursprung.

aktiviert (erforderlich)

Boolescher Ausdruck zum Aktivieren oder Deaktivieren von OAC. Akzeptierte Werte sind true oder false.

signingBehavior (erforderlich, wenn aktiviert)

Gibt an, welche Anfragen CloudFront signiert werden (fügt Authentifizierungsinformationen hinzu). Geben Sie always für den häufigsten Anwendungsfall an. Weitere Informationen finden Sie unter Erweiterte Einstellungen für die Ursprungszugriffssteuerung.

Folgende Werte sind in diesem Feld möglich:

always— CloudFront signiert alle ursprünglichen Anfragen und überschreibt dabei den Authorization Header der Viewer-Anfrage, falls vorhanden.
never— signiert CloudFront keine ursprünglichen Anfragen. Dieser Wert deaktiviert die Ursprungszugriffssteuerung für den Ursprung.
no-override— Wenn die Viewer-Anfrage den Authorization Header nicht enthält, wird die ursprüngliche Anfrage CloudFront signiert. Wenn die Viewer-Anfrage den Authorization Header enthält, wird die ursprüngliche Anfrage CloudFront nicht signiert und stattdessen der Authorization Header aus der Viewer-Anfrage weitergegeben.

Warnung
Um den Authorization-Header aus der Viewer-Anforderung zu übergeben, müssen Sie ihn einer Ursprungsanforderungsrichtlinie für alle Cache-Verhaltensweisen hinzufügen, die Ursprünge verwenden, die dieser Ursprungszugriffssteuerung zugeordnet sind. Weitere Informationen finden Sie unter Steuern von Ursprungsanforderungen anhand einer Richtlinie.

signingProtocol (erforderlich, wenn aktiviert)

Das Signaturprotokoll des OAC, das festlegt, wie Anfragen CloudFront signiert (authentifiziert) werden. Der einzige gültige Wert ist sigv4.

originType (erforderlich, wenn aktiviert)

Der Typ des Ursprungs für diese OAC. Gültige Werte sind: s3, mediapackagev2, mediastore und lambda.

Timeouts (optional)

Timeouts, die Sie angeben können, wie lange versucht CloudFront werden soll, darauf zu warten, dass Origins antwortet oder Daten sendet. Bei fehlender Angabe werden die Timeout-Einstellungen des zugewiesenen Ursprungs verwendet.

Anmerkung

Sofern nicht anders vermerkt, unterstützen diese Timeouts sowohl benutzerdefinierte Ursprünge als auch Amazon-S3-Ursprünge.

readTimeout (optional)

readTimeout gilt für die beiden folgenden Werte:

Wie lange (in Sekunden) auf eine Antwort CloudFront gewartet wird, nachdem eine Anfrage an den Ursprung weitergeleitet wurde.
Wie lange (in Sekunden) nach dem Empfang eines Antwortpakets vom Ursprung und vor dem Empfang des nächsten Pakets CloudFront gewartet wird.

Das Mindestwert für das Timeout ist 1 Sekunde und der Höchstwert 120 Sekunden. Weitere Informationen finden Sie unter Antwort-Timeout.

responseCompletionTimeout (Optional)

Die Zeit (in Sekunden), während der eine Anfrage vom CloudFront Absender geöffnet bleiben und auf eine Antwort warten kann. Wenn bis zu diesem Zeitpunkt noch keine vollständige Antwort vom Ursprung eingegangen ist, wird die Verbindung CloudFront beendet.

Der Wert für responseCompletionTimeout muss größer oder gleich dem für readTimeout angegebenen Wert sein. Weitere Informationen finden Sie unter Timeout für den Abschluss der Antwort.

keepAliveTimeout (Optional)

Dieses Timeout gilt nur für benutzerdefinierte Ursprünge, nicht für Amazon-S3-Ursprünge. (Bei S3-Ursprungskonfigurationen werden diese Einstellungen ignoriert.)

Das keepAliveTimeout gibt an, wie lange versucht CloudFront werden soll, die Verbindung zum Ursprung aufrechtzuerhalten, nachdem das letzte Paket der Antwort empfangen wurde. Das Mindestwert für das Timeout ist 1 Sekunde und der Höchstwert 120 Sekunden. Weitere Informationen finden Sie unter Keep-Alive-Timeout (nur benutzerdefinierte und VPC-Ursprünge).

connectionTimeout (optional)

Die Anzahl der Sekunden, die CloudFront gewartet wird, wenn versucht wird, eine Verbindung zum Ursprung herzustellen. Das Mindestwert für das Timeout ist 1 Sekunde und der Höchstwert 10 Sekunden. Weitere Informationen finden Sie unter Verbindungstimeout.

customOriginConfig (Optional)

Verwenden Sie customOriginConfig, um Verbindungseinstellungen für Ursprünge anzugeben, die kein Amazon-S3-Bucket sind. Es gibt eine Ausnahme: Sie können diese Einstellung festlegen, wenn der S3-Bucket mit statischem Website-Hosting konfiguriert wird. (Bei anderen Arten von S3-Bucket-Konfigurationen werden diese Einstellungen ignoriert.) Wenn customOriginConfig nicht angegeben wird, werden die Einstellungen des zugewiesenen Ursprungs verwendet.

Port (erforderlich)

Der HTTP-Port, über CloudFront den eine Verbindung zum Ursprung hergestellt wird. Geben Sie den HTTP-Port an, den der Ursprung überwacht.

Protokoll (erforderlich)

Gibt das Protokoll (HTTP oder HTTPS) an, das für die Verbindung zum Ursprung CloudFront verwendet wird. Gültige Werte sind:

http— verwendet CloudFront immer HTTP, um eine Verbindung zum Ursprung herzustellen
https— verwendet CloudFront immer HTTPS, um eine Verbindung zum Ursprung herzustellen

sslProtocols (erforderlich)

Eine Liste, die das SSL/TLS Mindestprotokoll angibt, das CloudFront verwendet wird, wenn Sie über HTTPS eine Verbindung zu Ihrem Ursprung herstellen. Gültige Werte sind: SSLv3, TLSv1, TLSv1.1 und TLSv1.2. Weitere Informationen finden Sie unter Mindest-SSL-Protokoll für Ursprung.

ipAddressType (Optional)

Gibt den IP-Adresstyp an, der für die Verbindung mit dem Ursprung CloudFront verwendet wird. Gültige Werte sind: ipv4, ipv6 und dualstack. Die Änderung von ipAddressType wird nur unterstützt, wenn auch die domainName-Eigenschaft geändert wird.

sni (optional, für benutzerdefinierte Ursprünge, die nicht zu S3 gehören)

Die Server Name Indication (SNI) ist eine Erweiterung des Transport Layer Security (TLS) -Protokolls, mit der ein Client zu Beginn des TLS-Handshake-Prozesses angibt, mit welchem Hostnamen er eine Verbindung herstellen möchte. Dieser Wert sollte mit einem allgemeinen Namen auf einem TLS-Zertifikat auf Ihrem Ursprungsserver übereinstimmen. Andernfalls könnte Ihr Ursprungsserver einen Fehler ausgeben.

Wenn dies nicht angegeben wird, wird der Wert aus dem hostHeader Parameter verwendet. Wenn der Host-Header nicht angegeben wird, wird der Wert aus dem domainName Parameter verwendet.

Wenn weder der Host-Header noch der Domain-Name-Parameter angegeben werden, wird der Domainname des zugewiesenen Ursprungs verwendet oder der Host-Header der eingehenden Anfrage, wenn die FTO-Richtlinie (Forward to Origin) den Host einschließt. Das SNI darf keinen Doppelpunkt (:) enthalten und darf keine IP-Adresse sein. Das SNI kann bis zu 253 Zeichen lang sein.

allowedCertificateNames (optional, für benutzerdefinierte Ursprünge außerhalb von S3)

Sie können eine Liste gültiger Zertifikatsnamen hinzufügen, die verwendet werden sollen, CloudFront um die Domainübereinstimmung mit Ihrem Ursprungsserver-TLS-Zertifikat während des TLS-Handshakes mit Ihrem Ursprungsserver zu validieren. Dieses Feld erwartet eine Reihe gültiger Domainnamen und kann Platzhalterdomänen enthalten, wie z. *.example.com

Sie können bis zu 20 zulässige Zertifikatsnamen angeben. Jeder Zertifikatsname kann bis zu 64 Zeichen lang sein.

Beispiel – Aktualisierung auf den Ursprung der Amazon-S3-Anforderung

Das folgende Beispiel ändert den Ursprung der Viewer-Anforderung in einen S3-Bucket, aktiviert OAC und setzt benutzerdefinierte Header zurück, die an den Ursprung gesendet wurden.


cf.updateRequestOrigin({
    "domainName" : "amzn-s3-demo-bucket-in-us-east-1.s3.us-east-1.amazonaws.com",
    "originAccessControlConfig": {
        "enabled": true,
        "signingBehavior": "always",
        "signingProtocol": "sigv4",
        "originType": "s3"
    },
    // Empty object resets any header configured on the assigned origin
    "customHeaders": {}
});

Beispiel – Aktualisierung auf Application Load Balancer als Anforderungsursprung

Das folgende Beispiel ändert den Ursprung der Viewer-Anforderung in einen Application Load Balancer und legt einen benutzerdefinierten Header und Timeouts fest.


cf.updateRequestOrigin({
    "domainName" : "example-1234567890.us-east-1.elb.amazonaws.com",
    "timeouts": {
        "readTimeout": 30,
        "connectionTimeout": 5
    },
    "customHeaders": {
        "x-stage": "production",
        "x-region": "us-east-1"
    }
});

Beispiel – Aktualisierung auf einen Ursprung mit aktiviertem Origin Shield

Im folgenden Beispiel ist Origin Shield für den Ursprung in der Distribution aktiviert. Der Funktionscode aktualisiert nur den für den Ursprung verwendeten Domainnamen und lässt alle anderen optionalen Parameter weg. In diesem Fall wird Origin Shield weiterhin mit dem geänderten Ursprungsdomainnamen verwendet, da die Origin-Shield-Parameter nicht aktualisiert wurden.


cf.updateRequestOrigin({
    "domainName" : "www.example.com"
});

Beispiel — Aktualisieren Sie den Host-Header, das SNI und die Namen der zulässigen Zertifikate

Warnung

In den meisten Anwendungsfällen müssen Sie diese Art der Änderung nicht für Anfragen verwenden, die an Ihren Absender gesendet werden. Diese Parameter sollten nur verwendet werden, wenn Sie wissen, welche Auswirkungen eine Änderung dieser Werte hat.

Im folgenden Beispiel werden der Domainname, der Host-Header, SNI und zulässige Zertifikate für die Anfrage auf den Ursprung geändert.


cf.updateRequestOrigin({ 
    "domainName": "www.example.com", 
    "hostHeader": "test.example.com", 
    "sni": "test.example.net", 
    "allowedCertificateNames": ["*.example.com", "*.example.net"],
});

selectRequestOriginById() -Methode

Verwenden Sie selectRequestOriginById(), um einen vorhandenen Ursprung zu aktualisieren, indem Sie einen anderen Ursprung auswählen, der bereits in Ihrer Distribution konfiguriert ist. Diese Methode verwendet dieselben Einstellungen, die durch den aktualisierten Ursprung definiert sind.

Diese Methode akzeptiert nur Ursprünge, die bereits in derselben Distribution definiert sind, die beim Ausführen der Funktion verwendet wurde. Ursprünge werden durch die Ursprungs-ID referenziert. Dabei handelt es sich um den Ursprungsnamen, den Sie bei der Einrichtung des Ursprungs definiert haben.

Wenn in Ihrer Distribution ein VPC-Ursprung konfiguriert ist, können Sie mit dieser Methode Ihren Ursprung auf Ihren VPC-Ursprung aktualisieren. Weitere Informationen finden Sie unter Zugriffsbeschränkung mit VPC-Ursprüngen.

Anforderung


cf.selectRequestOriginById(origin_id, {origin_overrides})

Im vorherigen Beispiel origin_id handelt es sich um eine Zeichenfolge, die auf den Ursprungsnamen eines Ursprungs in der Distribution verweist, auf der die Funktion ausgeführt wird. Der origin_overrides Parameter kann Folgendes enthalten:

HostHeader (optional, für benutzerdefinierte Ursprünge, die nicht zu S3 gehören)

Der Host-Header, der verwendet werden soll, wenn die Anfrage an den Ursprung gestellt wird. Wenn dies nicht angegeben wird, wird der Wert aus dem domainName Parameter verwendet.

Wenn weder der Host-Header noch der Domain-Namen-Parameter angegeben werden, wird der Domainname des zugewiesenen Ursprungs verwendet oder der Host-Header der eingehenden Anfrage, wenn die FTO-Richtlinie (Forward to Origin) den Host einschließt. Der Host-Header darf keinen Doppelpunkt (:) enthalten und darf keine IP-Adresse sein. Der Host-Header kann bis zu 253 Zeichen lang sein.

sni (optional, für benutzerdefinierte Ursprünge außerhalb von S3)

Wenn dies nicht angegeben wird, wird der Wert aus dem hostHeader Parameter verwendet. Wenn der Host-Header nicht angegeben wird, wird der Wert aus dem domainName Parameter verwendet.

allowedCertificateNames (optional, für benutzerdefinierte Ursprünge außerhalb von S3)

Sie können bis zu 20 zulässige Zertifikatsnamen angeben. Jeder Zertifikatsname kann bis zu 64 Zeichen lang sein.

Anforderung


selectRequestOriginById(origin_id)

Im vorherigen Beispiel handelt es sich bei origin_id um eine Zeichenfolge, die auf den Namen eines Ursprungs in der Distribution verweist, in der die Funktion ausgeführt wird.

Beispiel – Auswahl des Ursprungs der Amazon-S3-Anforderung

Im folgenden Beispiel wird der Ursprung namens amzn-s3-demo-bucket-in-us-east-1 aus der Liste der mit der Distribution verknüpften Ursprünge ausgewählt und die Konfigurationseinstellungen des Ursprungs amzn-s3-demo-bucket-in-us-east-1 werden auf die Anforderung angewendet.


cf.selectRequestOriginById("amzn-s3-demo-bucket-in-us-east-1");

Beispiel – Auswahl des Anforderungsursprungs von Application Load Balancer

Im folgenden Beispiel wird ein Application Load Balancer namens myALB-prod als Ursprung aus der Liste der mit der Distribution verknüpften Ursprünge ausgewählt und die Konfigurationseinstellungen von myALB-prod werden auf die Anforderung angewendet.


cf.selectRequestOriginById("myALB-prod");

Beispiel — Wählen Sie den Ursprung der Application Load Balancer Balancer-Anforderung aus und überschreiben Sie den Host-Header

Wie im vorherigen Beispiel wählt das folgende Beispiel einen Application Load Balancer Balancer-Ursprung aus, der myALB-prod aus der Liste der mit der Verteilung verknüpften Ursprünge benannt ist, und wendet die Konfigurationseinstellungen von myALB-prod auf die Anfrage an. Dieses Beispiel überschreibt jedoch den Host-Header-Wert mit. origin_overrides


cf.overrideRequestOrigin("myALB-prod",{ 
        "hostHeader" : "test.example.com"
});

createRequestOriginMethode Group ()

Verwenden Sie createRequestOriginGroup(), um zwei Ursprünge zu definieren, die als Ursprungsgruppe für Failover in Szenarien verwendet werden sollen, die hohe Verfügbarkeit erfordern.

Eine Ursprungsgruppe umfasst zwei Ursprünge (einen primären und einen sekundären) und ein Failover-Kriterium, das Sie angeben. Sie erstellen eine Ursprungsgruppe, um das Origin-Failover in CloudFront zu unterstützen. Wenn Sie mit dieser Methode eine Ursprungsgruppe erstellen oder aktualisieren, können Sie die Ursprungsgruppe anstelle eines einzelnen Ursprungs angeben. CloudFront führt unter Verwendung der Failover-Kriterien ein Failover vom primären Ursprung zum sekundären Ursprung durch.

Wenn in Ihrer Distribution ein VPC-Ursprung konfiguriert ist, können Sie diese Methode verwenden, um eine Ursprungsgruppe mithilfe eines VPC-Ursprungs zu erstellen. Weitere Informationen finden Sie unter Zugriffsbeschränkung mit VPC-Ursprüngen.

Anforderung


createRequestOriginGroup({origin_group_properties})

In den vorangegangenen Beispielen kann origin_group_properties Folgendes enthalten:

originIds (erforderlich)

Array von origin_ids, wobei origin_id eine Zeichenfolge ist, die auf den Namen eines Ursprungs in der Distribution verweist, in der die Funktion ausgeführt wird. Sie müssen zwei Ursprünge als Teil des Arrays angeben. Der erste Ursprung in der Liste ist der primäre Ursprung und der zweite dient als sekundärer Ursprung für Failover-Zwecke.

OriginOverrides (optional)

Einige erweiterte Einstellungen können mithilfe des Parameters überschrieben werden. {origin_overrides} origin overrides kann die folgenden Werte enthalten:

HostHeader (optional, für benutzerdefinierte Ursprünge außerhalb von S3)

Der Host-Header, der verwendet werden soll, wenn die Anfrage an den Ursprung gestellt wird. Wenn dies nicht angegeben wird, wird der Wert aus dem domainName Parameter verwendet.

sni (optional, für benutzerdefinierte Ursprünge außerhalb von S3)

Die Server Name Indication (SNI) ist eine Erweiterung des TLS-Protokolls (Transport Layer Security), mit der ein Client zu Beginn des TLS-Handshaking-Prozesses angibt, mit welchem Hostnamen er eine Verbindung herstellen möchte. Dieser Wert sollte mit einem allgemeinen Namen auf einem TLS-Zertifikat auf Ihrem Ursprungsserver übereinstimmen, da Ihr Ursprungsserver andernfalls möglicherweise einen Fehler ausgibt.

Wenn dies nicht angegeben wird, wird der Wert aus dem hostHeader Parameter verwendet. Wenn der Host-Header nicht angegeben wird, wird der Wert aus dem domainName Parameter verwendet.

allowedCertificateNames (optional, für benutzerdefinierte Ursprünge außerhalb von S3)

Sie können bis zu 20 zulässige Zertifikatsnamen angeben. Jeder Zertifikatsname kann bis zu 64 Zeichen lang sein.

selectionCriteria (optional)

Wählen Sie default aus, um die standardmäßigen Ursprungs-Failover-Kriterien zu verwenden, oder verwenden Sie die auf media-quality-score basierte Failover-Logik. Gültige Werte sind:

default verwendet die Failover-Kriterien basierend auf den Statuscodes, die in failoverCriteria angegeben sind. Bei fehlender Angabe für selectionCriteria wird default verwendet.
media-quality-score wird verwendet, wenn die Funktion zum Routing unter Berücksichtigung der Medienqualität verwendet wird.

failoverCriteria (erforderlich)

Eine Reihe von Statuscodes, die, wenn sie vom primären Ursprung zurückgegeben werden, einen Failover CloudFront zum sekundären Ursprung auslösen. Wenn Sie eine bestehende Ursprungsgruppe überschreiben, überschreibt dieses Array alle Failover-Statuscodes, die in der ursprünglichen Konfiguration der Ursprungsgruppe festgelegt sind.

Wenn Sie diese Option verwenden media-quality-scoreselectionCriteria, CloudFront wird versucht, Anfragen auf der Grundlage des Medienqualitätsfaktors weiterzuleiten. Wenn der ausgewählte Ursprung einen in diesem Array festgelegten Fehlercode zurückgibt, CloudFront wird ein Failover zum anderen Ursprung durchgeführt.

Beispiel – Erstellen einer Ursprungsgruppe für Anforderungen

Im folgenden Beispiel wird eine Ursprungsgruppe für eine Anfrage erstellt, die den Ursprung IDs verwendet. Diese Ursprünge IDs stammen aus der Konfiguration der Ursprungsgruppe für die Distribution, die zur Ausführung dieser Funktion verwendet wurde.

Optional können Sie sie verwenden, originOverrides um die ursprünglichen Gruppenkonfigurationen für snihostHeader, und zu überschreibenallowedCertificateNames.


import cf from 'cloudfront';

function handler(event) {
    cf.createRequestOriginGroup({
        "originIds": [
            {
                "originId": "origin-1",
                "originOverrides": {
                    "hostHeader": "hostHeader.example.com",
                    "sni": "sni.example.com",
                    "allowedCertificateNames": ["cert1.example.com", "cert2.example.com", "cert3.example.com"]
                }
            },
            {
                "originId": "origin-2",
                "originOverrides": {
                    "hostHeader": "hostHeader2.example.com",
                    "sni": "sni2.example.com",
                    "allowedCertificateNames": ["cert4.example.com", "cert5.example.com"]
                }
            }
        ],
        "failoverCriteria": {
            "statusCodes": [500]
        }
    });
    
    event.request.headers['x-hookx'] = { value: 'origin-overrides' };
    return event.request;
}

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Hilfsmethoden für Schlüsselwertspeicher

Hilfsmethoden für CloudFront SaaS Manager-Eigenschaften