Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Caching und Verfügbarkeit
Sie können CloudFront verwenden, um die Anzahl der Anforderungen zu verringern, auf die Ihr Ursprungsserver direkt antworten muss. Mit der CloudFront-Zwischenspeicherung werden mehr Objekte von CloudFront-Edge-Standorten bereitgestellt, die näher an Ihren Benutzern liegen. Dies reduziert die Belastung Ihres Ursprungs-Servers sowie die Latenz.
Je mehr Anforderungen CloudFront aus Edge-Caches bedienen kann, desto weniger Viewer-Anforderungen muss CloudFront an Ihren Ursprung weiterleiten, um die neueste Version oder eine eindeutige Version eines Objekts zu erhalten. Um CloudFront so zu optimieren, dass so wenig Anforderungen wie möglich an Ihren Ursprung gestellt werden, sollten Sie CloudFront Origin Shield verwenden. Weitere Informationen finden Sie unter [Verwenden Sie Amazon CloudFront Origin Shield](origin-shield.md).
Der Anteil der Anforderung, die direkt aus dem CloudFront-Cache bereitgestellt werden, im Vergleich zu allen Anforderungen, wird als *Cache-Trefferrate* bezeichnet. Sie können den Prozentsatz der Viewer-Anforderungen, die Treffer, Fehlschläge und Fehler sind, in der CloudFront-Konsole anzeigen. Weitere Informationen finden Sie unter [Anzeigen von CloudFront-Berichten zu Cache-Statistiken](cache-statistics.md).
Die Cache-Trefferrate wird von einer Reihe von Faktoren beeinflusst. Sie können Ihre CloudFront-Verteilungskonfiguration anpassen, um die Cache-Zugriffsrate zu verbessern, indem Sie die Anleitungen unter [Erhöhen des Anteils der Anforderungen, die direkt von den CloudFront-Caches bereitgestellt werden (Cache-Trefferrate)](cache-hit-ratio.md) befolgen.
Weitere Informationen zum Hinzufügen und Entfernen von Inhalten, die CloudFront bereitstellen soll, finden Sie unter [Hinzufügen, Entfernen oder Ersetzen von Inhalten, die von CloudFront verteilt werden](AddRemoveReplaceObjects.md).
**Topics**
+ [Erhöhen des Anteils der Anforderungen, die direkt von den CloudFront-Caches bereitgestellt werden (Cache-Trefferrate)](cache-hit-ratio.md)
+ [Verwenden Sie Amazon CloudFront Origin Shield](origin-shield.md)
+ [Optimieren der Hochverfügbarkeit mit CloudFront Origin Failover](high_availability_origin_failover.md)
+ [Verwalten der Dauer, die Inhalte im Cache bleiben (Ablauf)](Expiration.md)
+ [Zwischenspeichern von Inhalten auf der Grundlage von Abfragezeichenfolgeparametern](QueryStringParameters.md)
+ [Zwischenspeichern von Inhalten auf der Grundlage von Cookies](Cookies.md)
+ [Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern](header-caching.md)
# Erhöhen des Anteils der Anforderungen, die direkt von den CloudFront-Caches bereitgestellt werden (Cache-Trefferrate)
Sie können die Leistung verbessern, indem Sie den Anteil an Viewer-Anforderungen erhöhen, die direkt vom CloudFront-Cache bereitgestellt werden, anstatt für Inhalte auf Ihre Ursprungs-Server zurückzugreifen. Dies ist als Verbesserung der Cache-Trefferquote bekannt.
In den folgenden Abschnitten wird erläutert, wie Sie die Cache-Trefferrate erhöhen.
**Topics**
+ [Festlegen der Dauer der Zwischenspeicherung Ihrer Objekte in CloudFront](#cache-hit-ratio-duration)
+ [Verwenden von Origin Shield](#cache-hit-ratio-use-origin-shield)
+ [Zwischenspeichern auf der Grundlage von Abfragezeichenfolgeparametern](#cache-hit-ratio-query-string-parameters)
+ [Zwischenspeichern auf der Grundlage von Cookie-Werten](#cache-hit-ratio-cookies)
+ [Zwischenspeichern auf der Grundlage von Anfrage-Headern](#cache-hit-ratio-request-headers)
+ [Entfernen des `Accept-Encoding`-Headers, wenn keine Kompression erforderlich ist](#cache-hit-ratio-remove-accept-encoding)
+ [Bereitstellen von Medieninhalten über HTTP](#cache-hit-ratio-http-streaming)
## Festlegen der Dauer der Zwischenspeicherung Ihrer Objekte in CloudFront
Um Ihre Cache-Zugriffsrate zu erhöhen, können Sie Ihren Ursprung so konfigurieren, dass eine [Cache-Control-Max-Age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)-Richtlinie zu Ihren Objekten hinzugefügt wird, und den längsten Gebrauchswert für `max-age` festlegen. Je kürzer die Cache-Dauer ist, desto häufiger sendet CloudFront Anforderungen an Ihren Ursprung, um festzustellen, ob sich ein Objekt geändert hat, und um die neueste Version zu erhalten. Sie können die `max-age` mit den `stale-while-revalidate`- und `stale-if-error`-Anweisungen hinzufügen, um die Cache-Trefferquote unter bestimmten Bedingungen weiter zu verbessern. Weitere Informationen finden Sie unter [Verwalten der Dauer, die Inhalte im Cache bleiben (Ablauf)](Expiration.md).
## Verwenden von Origin Shield
CloudFront Origin Shield kann dazu beitragen, das Cache-Trefferverhältnis Ihrer CloudFront-Verteilung zu verbessern, da Ihrem Ursprung eine zusätzliche Cache-Ebene vorlagert. Wenn Sie Origin Shield verwenden, stammen alle Anforderungen von allen CloudFront-Caching-Layern an Ihren Ursprung von einem einzigen Speicherort. CloudFront kann jedes Objekt mit einer einzigen Ursprungsanforderung aus Origin Shield abrufen und alle anderen Ebenen des CloudFront-Caches (Edge-Standorte und [regionale Edge-Caches](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) können das Objekt aus Origin Shield abrufen.
Weitere Informationen finden Sie unter [Verwenden Sie Amazon CloudFront Origin Shield](origin-shield.md).
## Zwischenspeichern auf der Grundlage von Abfragezeichenfolgeparametern
Wenn Sie CloudFront so konfigurieren, dass die Zwischenspeicherung auf der Grundlage von Abfragezeichenfolgeparametern erfolgt, lässt sich die Zwischenspeicherung folgendermaßen verbessern:
+ Konfigurieren Sie CloudFront so, dass nur die Abfragezeichenfolgeparameter weitergeleitet werden, für die der Ursprung eindeutige Objekte zurückgibt.
+ Verwenden Sie die gleiche Schreibweise (Groß- oder Kleinschreibung) für alle Instances desselben Parameters. Wenn beispielsweise eine Anforderung `parameter1=A` und eine andere `parameter1=a` enthält, leitet CloudFront separate Anforderungen an Ihren Ursprung weiter, wenn eine Anforderung `parameter1=A` enthält und wenn eine Anforderung `parameter1=a` enthält. CloudFront speichert die von Ihrem Ursprung zurückgegebenen entsprechenden Objekte dann separat zwischen, auch wenn die Objekte identisch sind. Wenn Sie nur `A` oder `a` verwenden, leitet CloudFront weniger Anforderungen an Ihren Ursprung weiter.
+ Listen Sie Parameter in der gleichen Reihenfolge auf. Wenn eine Anforderung für ein Objekt die Abfragezeichenfolge `parameter1=a¶meter2=b` und eine weitere Anforderung für dasselbe Objekt `parameter2=b¶meter1=a` enthält, gibt wie bei den Unterschieden in der Schreibweise auch hier, dass CloudFront beide Anforderungen an Ihren Ursprung weiterleitet und die entsprechenden Objekte separat zwischenspeichert, auch wenn sie identisch sind. Wenn Sie immer die gleiche Reihenfolge für Parameter verwenden, leitet CloudFront weniger Anforderungen an Ihren Ursprung weiter.
Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Abfragezeichenfolgeparametern](QueryStringParameters.md). Wenn Sie die Abfragezeichenfolgen überprüfen möchten, die CloudFront an Ihren Ursprung weiterleitet, sehen Sie sich die Werte in der Spalte `cs-uri-query` in Ihren CloudFront-Protokolldateien an. Weitere Informationen finden Sie unter [Zugriffsprotokolle (Standardprotokolle)](AccessLogs.md).
## Zwischenspeichern auf der Grundlage von Cookie-Werten
Wenn Sie CloudFront so konfigurieren, dass die Zwischenspeicherung auf der Grundlage von Cookie-Werten erfolgt, lässt sich die Zwischenspeicherung folgendermaßen verbessern:
+ Konfigurieren Sie CloudFront so, dass anstatt aller Cookies nur spezifische Cookies weitergeleitet werden. Für die Cookies, für deren Weiterleitung an Ihren Ursprung Sie CloudFront konfigurieren, leitet CloudFront jede Kombination von Cookie-Name und -Wert weiter. Die Objekte, die Ihr Ursprung zurückgibt, werden dann separat gespeichert, auch wenn sie alle identisch sind.
Nehmen wir beispielsweise an, dass Viewer zwei Cookies in jeder Anfrage einfügen, dass jedes Cookie über drei mögliche Werte verfügt und dass alle Kombinationen von Cookie-Werten möglich sind. CloudFront leitet bis zu neun verschiedene Anforderungen für jedes Objekt an Ihren Ursprung weiter. Wenn Ihr Ursprung verschiedene Versionen eines Objekts auf der Grundlage nur eines dieser Cookies zurückgibt, leitet CloudFront mehr Anforderungen als notwendig an Ihren Ursprung weiter und speichert unnötigerweise mehrere identische Versionen des Objekts zwischen.
+ Erstellen Sie separate Cache-Verhalten für statischen und dynamischen Inhalt und konfigurieren Sie CloudFront so, dass Cookies nur für dynamische Inhalte an Ihren Ursprung weitergeleitet werden.
Nehmen wir beispielsweise an, dass Sie nur ein Cache-Verhalten für Ihre Verteilung haben und die Verteilung sowohl für dynamische Inhalte, wie beispielsweise `.js`-Dateien, als auch für `.css`-Dateien verwenden, die sich nur selten ändern. CloudFront speichert separate Versionen Ihrer `.css`-Dateien auf der Grundlage der Cookie-Werte zwischen, sodass jeder CloudFront-Edge-Standort eine Anforderung für jeden neuen Cookie-Wert oder jede neue Kombination von Cookie-Werten an Ihren Ursprung weiterleitet.
Wenn Sie ein Cache-Verhalten erstellen, für welches das Pfadmuster `*.css` ist und für welches CloudFront nicht auf der Grundlage von Cookie-Werten zwischenspeichert, leitet CloudFront Anforderungen für `.css`-Dateien nur für die erste Anforderung, die ein Edge-Standort für eine bestimmte `.css`-Datei empfängt, und für die erste Anforderung nach dem Ablaufen einer `.css`-Datei an Ihren Ursprung weiter.
+ Erstellen Sie nach Möglichkeit separate Cache-Verhaltensweisen für dynamische Inhalte, wenn Cookie-Werte für jeden Benutzer eindeutig sind (z. B. eine Benutzer-ID), und dynamische Inhalte, die je nach einer geringeren Anzahl eindeutiger Werte variieren.
Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Cookies](Cookies.md). Wenn Sie die Cookies überprüfen möchten, die CloudFront an Ihren Ursprung weiterleitet, sehen Sie sich die Werte in der Spalte `cs(Cookie)` in Ihren CloudFront-Protokolldateien an. Weitere Informationen finden Sie unter [Zugriffsprotokolle (Standardprotokolle)](AccessLogs.md).
## Zwischenspeichern auf der Grundlage von Anfrage-Headern
Wenn Sie CloudFront so konfigurieren, dass die Zwischenspeicherung auf der Grundlage von Anforderungs-Headern erfolgt, lässt sich die Zwischenspeicherung folgendermaßen verbessern:
+ Konfigurieren Sie CloudFront so, dass die Weiterleitung und Zwischenspeicherung nur auf der Grundlage von spezifischen Headern erfolgt, anstatt auf der Grundlage von allen Headern. Für die Header, die Sie angeben, leitet CloudFront jede Kombination aus Header-Name und -Wert weiter. Die Objekte, die Ihr Ursprung zurückgibt, werden dann separat gespeichert, auch wenn sie alle identisch sind.
**Anmerkung**
CloudFront leitet die in den folgenden Themen angegebenen Header immer an Ihren Ursprung weiter:
So verarbeitet CloudFront Anforderungen und leitet sie an Ihren Amazon-S3-Ursprungsserver weiter > [HTTP-Anforderungsheader, die CloudFront entfernt oder aktualisiert werden](RequestAndResponseBehaviorS3Origin.md#request-s3-removed-headers)
So verarbeitet CloudFront Anforderungen und leitet sie an Ihren benutzerdefinierten Ursprungsserver weiter > [Header und CloudFront Verhalten von HTTP-Anfragen (benutzerdefiniert und Amazon S3 S3-Ursprünge)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)
Wenn Sie CloudFront so konfigurieren, dass die Zwischenspeicherung auf der Grundlage von Anforderungs-Headern erfolgt, ändern Sie nicht die von CloudFront weitergeleiteten Header, sondern nur, ob CloudFront Objekte auf der Grundlage der Header-Werte zwischenspeichert.
+ Vermeiden Sie die Zwischenspeicherung auf der Grundlage von Anfrage-Headern mit einer hohen Anzahl von eindeutigen Werten.
Wenn Sie beispielsweise verschiedene Formate von Images auf der Grundlage des Geräts des Benutzers bereitstellen möchten, sollten Sie CloudFront nicht so konfigurieren, dass die Zwischenspeicherung auf der Grundlage des `User-Agent`-Headers erfolgt, der eine enorme Anzahl an möglichen Werten aufweist. Konfigurieren Sie CloudFront stattdessen so, dass die Zwischenspeicherung auf der Grundlage der Gerätetyp-Header `CloudFront-Is-Desktop-Viewer`, `CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-SmartTV-Viewer` und `CloudFront-Is-Tablet-Viewer` erfolgt. Wenn Sie zudem dieselbe Version des Images für Tablets und Desktops zurückgeben, leiten Sie nur den `CloudFront-Is-Tablet-Viewer`-Header weiter und nicht den `CloudFront-Is-Desktop-Viewer`-Header.
Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern](header-caching.md).
## Entfernen des `Accept-Encoding`-Headers, wenn keine Kompression erforderlich ist
Wenn die Komprimierung nicht aktiviert ist, weil der Ursprung sie nicht unterstützt, CloudFront sie nicht unterstützt oder der Inhalt nicht komprimierbar ist, können Sie die Cache-Trefferquote erhöhen, indem Sie ein Cache-Verhalten in Ihrer Verteilung einem Ursprung zuordnen, der den Custom Origin Header wie folgt festlegt:
+ **Header name (Header-Name**: `Accept-Encoding`
+ **Header value (Header-Wert)**: (Frei lassen)
Wenn Sie diese Konfiguration verwenden, entfernt CloudFront den `Accept-Encoding`-Header aus dem Cache-Schlüssel und schließt den Header nicht in die Ursprungsanforderungen ein. Diese Konfiguration gilt für alle Inhalte, die von CloudFront mit der Verteilung aus diesem Ursprung bereitgestellt werden.
## Bereitstellen von Medieninhalten über HTTP
Weitere Informationen zum Optimieren von Video-on-Demand-(VOD)- und Streaming-Videoinhalten finden Sie unter [Video-on-Demand und Live-Streaming-Video mit CloudFront](on-demand-streaming-video.md).
# Verwenden Sie Amazon CloudFront Origin Shield
CloudFront Origin Shield ist eine zusätzliche Ebene in der CloudFront Caching-Infrastruktur, die dazu beiträgt, die Auslastung Ihres Origins zu minimieren, seine Verfügbarkeit zu verbessern und die Betriebskosten zu senken. CloudFront Origin Shield bietet die folgenden Vorteile:
**Bessere Cache-Zugriffsrate**
Origin Shield kann dazu beitragen, die Cache-Trefferquote deiner CloudFront Distribution zu verbessern, da es eine zusätzliche Caching-Ebene vor deinem Origin bietet. Wenn du Origin Shield verwendest, werden alle Anfragen CloudFront von allen Cache-Layern an deinen Ursprung über Origin Shield geleitet, was die Wahrscheinlichkeit eines Cache-Treffers erhöht. CloudFrontkann jedes Objekt mit einer einzigen Ursprungsanfrage von Origin Shield an deinen Ursprung abrufen, und alle anderen Ebenen des CloudFront Caches (Edge-Standorte und [regionale Edge-Caches](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) können das Objekt von Origin Shield abrufen.
**Reduzierte Ursprungslast**
Origin Shield kann die Anzahl der [gleichzeitigen Anfragen](RequestAndResponseBehaviorCustomOrigin.md#request-custom-traffic-spikes) die für dasselbe Objekt an Ihren Ursprung gesendet werden, weiter reduzieren. Anfragen für Inhalte, die sich nicht im Origin-Shield-Cache befinden, werden mit anderen Anforderungen für dasselbe Objekt konsolidiert, was dazu führt, dass nur eine Anfrage an Ihren Ursprung gelangt. Wenn Sie weniger Anfragen an Ihrem Ursprung bearbeiten, kann die Verfügbarkeit Ihres Ursprungs bei Spitzenlasten oder unerwarteten Verkehrsspitzen aufrechterhalten und die Kosten für Dinge wie just-in-time Verpackung, Bildtransformationen und ausgehende Datenübertragung (DTO) gesenkt werden.
**Bessere Netzwerkleistung**
Wenn du Origin Shield in der AWS Region [aktivierst, die die niedrigste Latenz zu deinem Ursprung hat](#choose-origin-shield-region), kannst du eine bessere Netzwerkleistung erzielen. Bei Ursprüngen in einer AWS Region verbleibt der CloudFront Netzwerkverkehr bis zu deinem Ursprung im CloudFront Netzwerk mit hohem Durchsatz. Bei Ursprüngen außerhalb von AWS verbleibt der CloudFront Netzwerkverkehr im CloudFront Netzwerk bis hin zu Origin Shield, das über eine Verbindung mit niedriger Latenz zu deinem Ursprung verfügt.
Für die Nutzung von Origin Shield fallen zusätzliche Gebühren an. Weitere Informationen finden Sie unter [CloudFront Preise](https://aws.amazon.com/cloudfront/pricing/).
**Anmerkung**
Origin Shield wird für gRPC-Anforderungen nicht unterstützt. Wenn in einer Distribution, die gRPC unterstützt, Origin Shield aktiviert ist, funktionieren gRPC-Anforderungen weiterhin. Die Anforderungen werden jedoch direkt an den gRPC-Ursprung weitergeleitet, ohne Origin Shield zu durchlaufen. Weitere Informationen finden Sie unter [gRPC mit CloudFront Distributionen verwenden](distribution-using-grpc.md).
**Topics**
+ [Anwendungsfälle für Origin Shield](#origin-shield-use-cases)
+ [Wähle die AWS Region für Origin Shield](#choose-origin-shield-region)
+ [Origin Shield aktivieren](#enable-origin-shield)
+ [Schätzung der Kosten für Origin Shield](#origin-shield-costs)
+ [Hochverfügbarkeit bei Origin Shield](#origin-shield-high-availability)
+ [Wie Origin Shield mit anderen CloudFront Funktionen interagiert](#origin-shield-and-other-features)
## Anwendungsfälle für Origin Shield
CloudFront Origin Shield kann für viele Anwendungsfälle von Vorteil sein, darunter die folgenden:
+ Viewer, die über verschiedene geografische Regionen verteilt sind
+ Origins, die just-in-time Verpackungen für Live-Streaming oder on-the-fly Bildverarbeitung anbieten
+ Lokale Ursprünge mit Kapazitäts- oder Bandbreitenbeschränkungen
+ Workloads, die mehrere Netzwerke zur Inhaltsbereitstellung verwenden () CDNs
Origin Shield eignet sich möglicherweise in anderen Fällen nicht gut, z. B. dynamische Inhalte, die an den Ursprung weitergeleitet werden, Inhalte mit geringer Cachefähigkeit oder Inhalte, die selten angefordert werden.
In den folgenden Abschnitten werden die Vorteile von Origin Shield für die folgenden Anwendungsfälle erläutert.
**Topics**
+ [Viewer in verschiedenen geografischen Regionen](#os-use-cases-global-viewers)
+ [Mehrfach CDNs](#os-use-cases-multi-cdn)
### Viewer in verschiedenen geografischen Regionen
Mit Amazon wird die Belastung Ihres Ursprungs von Natur aus reduziert CloudFront, da Anfragen, die über den Cache bedient werden CloudFront können, nicht an Ihren Ursprung weitergeleitet werden. Zusätzlich zum CloudFront [globalen Netzwerk von Edge-Standorten dienen [regionale Edge-Caches](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)](https://aws.amazon.com/cloudfront/features/#Amazon_CloudFront_Infrastructure) als mittlere Caching-Ebene, um Cache-Treffer bereitzustellen und Anfragen von Zuschauern in nahegelegenen geografischen Regionen zu konsolidieren. Betrachteranfragen werden zuerst an einen nahe gelegenen CloudFront -Edge-Standort weitergeleitet. Wenn das Objekt an diesem Speicherort nicht zwischengespeichert wird, wird die Anforderung an einen regionalen Edge-Cache gesendet.
Wenn sich Viewer in verschiedenen geografischen Regionen befinden, können Anfragen über verschiedene regionale Edge-Caches weitergeleitet werden, von denen jeder eine Anfrage für denselben Inhalt an Ihren Ursprung senden kann. Aber mit Origin Shield erhalten Sie eine zusätzliche Caching-Ebene zwischen den regionalen Edge-Caches und Ihrem Ursprung. Alle Anfragen von allen regionalen Edge-Caches laufen durch Origin Shield, wodurch die Belastung Ihres Ursprungs weiter reduziert wird. Das folgende Diagramm verdeutlicht dies. In den folgenden Diagrammen ist der Ursprung AWS Elemental MediaPackage.
**Ohne Origin Shield**
Ohne Origin Shield erhält Ihr Ursprung möglicherweise doppelte Anfragen für denselben Inhalt, wie im folgenden Diagramm dargestellt.
![\[Ohne CloudFront Origin Shield erhält der Absender möglicherweise doppelte Anfragen.\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without.png)
**Mit Origin Shield**
Die Verwendung von Origin Shield kann dazu beitragen, die Belastung Ihres Ursprungs zu reduzieren, wie in der folgenden Abbildung gezeigt.
![\[Mit CloudFront Origin Shield kann der Absender weniger doppelte Anfragen erhalten.\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with.png)
### Mehrfach CDNs
Um Live-Videoveranstaltungen oder beliebte On-Demand-Inhalte bereitzustellen, können Sie mehrere Content Delivery Networks (CDNs) verwenden. Die Verwendung mehrerer Optionen CDNs kann gewisse Vorteile bieten, bedeutet aber auch, dass Ihr Absender möglicherweise viele doppelte Anfragen für denselben Inhalt erhält, die jeweils von unterschiedlichen CDNs oder unterschiedlichen Standorten innerhalb desselben CDN stammen. Diese redundanten Anfragen können sich negativ auf die Verfügbarkeit Ihrer Quelle auswirken oder zusätzliche Betriebskosten für Prozesse wie just-in-time Paketierung oder Datenübertragung (DTO) ins Internet verursachen.
Wenn du Origin Shield mit der Nutzung deiner CloudFront Distribution als Quelle für andere kombinierst CDNs, kannst du die folgenden Vorteile nutzen:
+ Es gehen weniger redundante Anfragen bei deinem Absender ein, was dazu beiträgt, die negativen Auswirkungen der Verwendung mehrerer Anfragen zu reduzieren CDNs.
+ Ein einheitlicher [Cache-Schlüssel](controlling-the-cache-key.md) für alle und eine zentrale Verwaltung für Funktionen CDNs, die den Ursprung betreffen.
+ Verbesserte Netzwerkleistung. Netzwerkverkehr von anderen CDNs wird an einem nahegelegenen CloudFront Edge-Standort beendet, was zu einem Treffer aus dem lokalen Cache führen kann. Wenn sich das angeforderte Objekt nicht im Edge-Location-Cache befindet, verbleibt die Anfrage an den Ursprung bis Origin Shield im CloudFront Netzwerk, wodurch ein hoher Durchsatz und eine geringe Latenz für den Ursprung gewährleistet werden. Wenn sich das angeforderte Objekt im Origin-Shield-Cache befindet, wird die Anfrage an Ihren Ursprung vollständig vermieden.
**Wichtig**
Wenn Sie Origin Shield in einer Multi-CDN-Architektur verwenden möchten und vergünstigte Preise erhalten möchten, [kontaktieren Sie uns](https://aws.amazon.com/contact-us/) oder Ihren AWS Vertriebsmitarbeiter für weitere Informationen. Zusätzliche Gebühren können anfallen.
Die folgenden Diagramme zeigen, wie diese Konfiguration dazu beitragen kann, die Belastung Ihres Originals zu minimieren, wenn Sie beliebte Live-Videoveranstaltungen mit mehreren anbieten CDNs. In den folgenden Diagrammen ist der Ursprung AWS Elemental MediaPackage.
**Ohne Origin Shield (mehrfach CDNs)**
Ohne Origin Shield kann Ihr Ursprung viele doppelte Anfragen für denselben Inhalt erhalten, die jeweils von einem anderen CDN stammen, wie im folgenden Diagramm dargestellt.
![\[Grafik, die zeigt, wie ein Ursprung doppelte Anforderungen empfangen kann, die jeweils von einem anderen CDN stammen\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without-multi-cdn.png)
**Mit Origin Shield (mehrfach CDNs)**
Die Verwendung von Origin Shield CloudFront als Ursprung für deinen anderen kann dazu beitragen CDNs, die Belastung deines Originals zu reduzieren, wie in der folgenden Abbildung dargestellt.
![\[Grafik, die zeigt, dass CloudFront Origin Shield weniger doppelte Anfragen erhält.\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with-multi-cdn.png)
## Wähle die AWS Region für Origin Shield
Amazon CloudFront bietet Origin Shield in AWS Regionen an, in denen CloudFront es einen [regionalen Edge-Cache](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) gibt. Wenn du Origin Shield aktivierst, wählst du die AWS Region für Origin Shield aus. Sie sollten die AWS -Region auswählen, die die niedrigste Latenz zu Ihrem Ursprung aufweist. Du kannst Origin Shield mit Ursprüngen verwenden, die in einer AWS Region liegen, und mit Ursprüngen, die sich nicht in einer Region befinden AWS.
### Bei Ursprüngen in einer AWS -Region
Wenn dein Ursprung in einer AWS Region liegt, stelle zunächst fest, ob dein Ursprung in einer Region liegt, in der Origin Shield CloudFront angeboten wird. CloudFront bietet Origin Shield in den folgenden AWS Regionen an.
+ US East (Ohio) – `us-east-2`
+ USA Ost (Nord-Virginia) – `us-east-1`
+ USA West (Oregon) – `us-west-2`
+ Asia Pacific (Mumbai) – `ap-south-1`
+ Asien-Pazifik (Seoul) – `ap-northeast-2`
+ Asia Pacific (Singapore) – `ap-southeast-1`
+ Asien-Pazifik (Sydney) – `ap-southeast-2`
+ Asien-Pazifik (Tokio) – `ap-northeast-1`
+ Europa (Frankfurt) – `eu-central-1`
+ Europa (Ireland) – `eu-west-1`
+ Europa (London) – `eu-west-2`
+ South America (São Paulo) – `sa-east-1`
+ Naher Osten (VAE) — `me-central-1`
**Wenn dein Ursprung in einer AWS Region liegt, in der Origin Shield CloudFront angeboten wird**
Wenn dein Ursprung in einer AWS Region liegt, in der Origin Shield CloudFront angeboten wird (siehe vorherige Liste), aktiviere Origin Shield in derselben Region wie dein Heimatland.
**Wenn dein Ursprung nicht in einer AWS Region liegt, in der Origin Shield CloudFront angeboten wird**
Wenn dein Ursprung nicht in einer AWS Region liegt, in der Origin Shield CloudFront angeboten wird, kannst du anhand der folgenden Tabelle herausfinden, in welcher Region Origin Shield aktiviert werden soll.
| **Bei einem Ursprung in...** | **Origin Shield aktivieren in...** |
| --- | --- |
| US West (N. California) – `us-west-1` | US West (Oregon) – `us-west-2` |
| Africa (Cape Town) – `af-south-1` | Europe (Ireland) – `eu-west-1` |
| Asia Pacific (Hong Kong) – `ap-east-1` | Asia Pacific (Singapore) – `ap-southeast-1` |
| Canada (Central) – `ca-central-1` | US East (N. Virginia) – `us-east-1` |
| Europe (Milan) – `eu-south-1` | Europe (Frankfurt) – `eu-central-1` |
| Europe (Paris) – `eu-west-3` | Europe (London) – `eu-west-2` |
| Europe (Stockholm) – `eu-north-1` | Europe (London) – `eu-west-2` |
| Middle East (Bahrain) – `me-south-1` | Asia Pacific (Mumbai) – `ap-south-1` |
### Für Ursprünge außerhalb von AWS
Sie können Origin Shield mit einem Ursprung verwenden, der lokal ist oder sich nicht in einer AWS -Region befindet. Aktiviere in diesem Fall Origin Shield in der AWS Region, die die niedrigste Latenz zu deinem Ursprung hat. Wenn du dir nicht sicher bist, welche AWS Region die niedrigste Latenz zu deinem Ursprung hat, kannst du die folgenden Vorschläge verwenden, um dir bei der Entscheidung zu helfen.
+ In der obigen Tabelle finden Sie eine Näherung darüber, welche AWS -Region basierend auf der geografischen Lage Ihres Ursprungs die niedrigste Latenz zu Ihrem Ursprung hat.
+ Sie können EC2 Amazon-Instances in verschiedenen AWS Regionen starten, die sich geografisch in der Nähe Ihres Ursprungs befinden, und einige Tests durchführen, `ping` um die typischen Netzwerklatenzen zwischen diesen Regionen und Ihrem Ursprung zu messen.
## Origin Shield aktivieren
Sie können Origin Shield aktivieren, um Ihre Cache-Trefferquote zu verbessern, die Belastung Ihres Ursprungs zu reduzieren und die Leistung zu verbessern. Um Origin Shield zu aktivieren, ändere die Origin-Einstellungen in einer CloudFront Distribution. Origin Shield ist eine Eigenschaft des Ursprungs. Für jeden Ursprung in deinen CloudFront Distributionen kannst du Origin Shield separat in der AWS Region aktivieren, die für diesen Ursprung die beste Leistung bietet.
Du kannst Origin Shield in der CloudFront Konsole CloudFormation, mit oder mit der CloudFront API aktivieren.
------
#### [ Console ]
**So aktivieren Sie Origin Shield für einen vorhandenen Ursprung (Konsole)**
1. Melde dich bei der an AWS-Managementkonsole und öffne die CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Wählen Sie die Verteilung mit dem Ursprung aus, den Sie aktualisieren möchten.
1. Wählen Sie den Tab **Ursprünge** aus.
1. Wählen Sie den zu aktualisierenden Ursprung und dann **Edit (Bearbeiten)** aus.
1. Wählen Sie bei **Enable Origin Shield (Origin Shield aktivieren)** die Option **Yes (Ja)** aus.
1. Wählen Sie bei **Origin Shield Region (Origin-Shield-Region)** die AWS -Region aus, in der Sie Origin Shield aktivieren möchten. Informationen zur Auswahl einer Region finden Sie unter [Wähle die AWS Region für Origin Shield](#choose-origin-shield-region).
1. Wählen Sie **Änderungen speichern ** aus.
Wenn der Verteilungsstatus **Deployed (Bereitgestellt)** lautet, ist Origin Shield bereit. Das dauert ein paar Minuten.
**So aktivieren Sie Origin Shield für einen neuen Ursprung (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Gehen Sie wie folgt vor, um den neuen Ursprung in einer vorhandenen Verteilung zu erstellen:
1. Wählen Sie die Verteilung aus, in der Sie den Ursprung erstellen möchten.
1. Wählen Sie **Create Origin (Ursprung erstellen)** aus und fahren Sie mit Schritt 3 fort.
Gehen Sie wie folgt vor, um den neuen Ursprung in einer neuen Standarddistribution zu erstellen:
1. Gehen Sie wie folgt vor, um eine Standarddistribution in der Konsole zu erstellen. Weitere Informationen finden Sie unter [Erstellen Sie eine CloudFront Distribution in der Konsole](distribution-web-creating-console.md#create-console-distribution).
1. Wählen Sie im Abschnitt **Einstellungen** die Option **Ursprungseinstellungen anpassen** aus. Fahren Sie mit Schritt 3 fort.
1. Wählen Sie bei **Enable Origin Shield (Origin Shield aktivieren)** die Option **Yes (Ja)** aus.
1. Wählen Sie bei **Origin Shield Region (Origin-Shield-Region)** die AWS -Region aus, in der Sie Origin Shield aktivieren möchten. Informationen zur Auswahl einer Region finden Sie unter [Wähle die AWS Region für Origin Shield](#choose-origin-shield-region).
1. Folgen Sie den Schritten in der Konsole, um die Erstellung Ihres Ursprungs oder Ihrer Distribution abzuschließen.
Wenn der Verteilungsstatus **Deployed (Bereitgestellt)** lautet, ist Origin Shield bereit. Das dauert ein paar Minuten.
------
#### [ CloudFormation ]
Um Origin Shield mit zu aktivieren CloudFormation, verwende die `OriginShield` `Origin` Eigenschaft im Eigenschaftstyp einer `AWS::CloudFront::Distribution` Ressource. Sie können die `OriginShield`-Eigenschaft einem vorhandenen `Origin` hinzufügen oder sie einschließen, wenn Sie einen neuen `Origin` erstellen.
Das folgende Beispiel zeigt die Syntax im YAML-Format für die Aktivierung von `OriginShield` in der Region USA West (Oregon) (`us-west-2`). Informationen zur Auswahl einer Region finden Sie unter [Wähle die AWS Region für Origin Shield](#choose-origin-shield-region). In diesem Beispiel wird nur der `Origin`-Eigenschaftstyp und nicht die gesamte `AWS::CloudFront::Distribution`-Ressource angezeigt.
```
Origins:
- DomainName: 3ae97e9482b0d011.mediapackage.us-west-2.amazonaws.com
Id: Example-EMP-3ae97e9482b0d011
OriginShield:
Enabled: true
OriginShieldRegion: us-west-2
CustomOriginConfig:
OriginProtocolPolicy: match-viewer
OriginSSLProtocols: TLSv1
```
Weitere Informationen findest du unter [AWS::CloudFront::Distribution Origin](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) im Abschnitt Ressourcen- und Eigenschaftenreferenzen des *AWS CloudFormation Benutzerhandbuchs*.
------
#### [ API ]
Um Origin Shield mit der CloudFront API mithilfe von AWS SDKs oder AWS Command Line Interface (AWS CLI) zu aktivieren, verwende den `OriginShield` Typ. Sie geben `OriginShield` in einem `Origin` in einer `DistributionConfig` an. Informationen zu diesem `OriginShield` Typ finden Sie in den folgenden Informationen in der *Amazon CloudFront API-Referenz*.
+ [OriginShield](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginShield.html)(Typ)
+ [Ursprung](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Origin.html) (Typ)
+ [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)(Typ)
+ [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)(Betrieb)
+ [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)(Betrieb)
Die spezifische Syntax für die Verwendung dieser Typen und Vorgänge variiert je nach SDK, CLI oder API-Client. Weitere Informationen finden Sie in der Referenzdokumentation zu Ihrem SDK, der CLI oder dem Client.
------
## Schätzung der Kosten für Origin Shield
Für Origin Shield fallen Gebühren basierend auf der Anzahl der Anfragen an, die als inkrementelle Ebene an Origin Shield gelangen.
Bei dynamischen (nicht zwischenspeicherbaren) Anforderungen, die an den Ursprung weitergeleitet werden, ist Origin Shield immer eine inkrementelle Ebene. Dynamische Anforderungen verwenden die HTTP-Methoden `PUT`, `POST`, `PATCH` und `DELETE`.
`GET`- und `HEAD`-Anforderungen mit einer Time-to-Live (TTL)-Einstellung von weniger als 3600 Sekunden werden als dynamische Anforderungen betrachtet. Darüber hinaus gelten `GET`- und `HEAD`-Anforderungen, bei denen das Caching deaktiviert wurde, auch als dynamische Anforderungen.
Verwenden Sie die folgende Formel, um Ihre Gebühren für Origin Shield für dynamische Anforderungen zu schätzen:
Gesamtzahl der dynamischen Anforderungen **x** Origin Shield-Ladung pro 10 000 Anforderungen**/**10 000
Bei nicht dynamischen Anforderungen mit den HTTP-Methoden `GET`, `HEAD` und `OPTIONS` ist Origin Shield manchmal eine inkrementelle Ebene. Wenn du Origin Shield aktivierst, wählst du das AWS-Region für Origin Shield. Für Anforderungen, die natürlich in den [regionalen Edge-Cache](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) in derselben Region wie Origin Shield gelangen, ist Origin Shield keine inkrementelle Ebene. Für diese Anforderungen fallen keine Origin-Shield-Gebühren an. Für Anforderungen, die an einen regionalen Edge-Cache in einer anderen Region als Origin Shield gelangen und dann zu Origin Shield wechseln, ist Origin Shield eine inkrementelle Ebene. Für diese Anfragen fallen Origin-Shield-Gebühren an.
Verwenden Sie die folgende Formel, um Ihre Gebühren für Origin Shield für zwischenspeicherbare Anfragen zu schätzen:
Gesamtzahl der zwischengespeicherten Anforderungen **x** (1 – Cache-Zugriffsrate) **x** Prozentsatz der Anforderungen, die von einem regionalen Edge-Cache in einer anderen Region an Origin Shield gelangen **x** Origin Shield-Ladung pro 10 000 Anforderungen **/**10 000
Weitere Informationen über die Gebühr pro 10 000 Anfragen für Origin Shield finden Sie unter [CloudFront – Preise](https://aws.amazon.com/cloudfront/pricing/).
## Hochverfügbarkeit bei Origin Shield
Origin Shield nutzt die Funktion für CloudFront [regionale Edge-Caches](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches). Jeder dieser Edge-Caches wird in einer AWS Region erstellt und verwendet mindestens drei [Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) mit Flotten von auto-scaling Amazon-Instances. EC2 Verbindungen von CloudFront-Standorten mit Origin Shield verwenden auch die aktive Fehlerverfolgung für jede Anforderung, um die Anforderung automatisch an einen sekundären Origin Shield-Speicherort weiterzuleiten, wenn der primäre Speicherort von Origin Shield nicht verfügbar ist.
## Wie Origin Shield mit anderen CloudFront Funktionen interagiert
In den folgenden Abschnitten wird erläutert, wie Origin Shield mit anderen CloudFront-Funktionen interagiert.
### Origin Shield und CloudFront Protokollierung
Um zu sehen, wann Origin Shield eine Anforderung verarbeitet hat, müssen Sie eine der folgenden Optionen aktivieren:
+ [CloudFront Standardprotokolle (Zugriffsprotokolle)](AccessLogs.md). Standardprotokolle werden kostenlos zur Verfügung gestellt.
+ [CloudFront Zugriffsprotokolle in Echtzeit](real-time-logs.md). Für die Verwendung von Echtzeit-Zugriffsprotokollen fallen zusätzliche Gebühren an. Weitere Informationen finden Sie unter [ CloudFrontAmazon-Preise](https://aws.amazon.com/cloudfront/pricing/).
Cache-Treffer von Origin Shield werden wie `OriginShieldHit` im `x-edge-detailed-result-type` Feld in den CloudFront Protokollen angezeigt. Origin Shield nutzt die [regionalen Edge-Caches CloudFront](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) von Amazon. Wenn eine Anfrage von einem CloudFront Edge-Standort an den regionalen Edge-Cache weitergeleitet wird, der als Origin Shield fungiert, wird sie `Hit` in den Protokollen als a gemeldet, nicht als`OriginShieldHit`.
### Origin Shield und Ursprungsgruppen
Origin Shield ist mit [CloudFront -Ursprungsgruppen](high_availability_origin_failover.md) kompatibel. Da das Origin Shield eine Eigenschaft des Ursprungs ist, werden Anfragen für jeden Ursprung immer über Origin Shield geleitet, selbst wenn der Ursprung Teil einer Ursprungsgruppe ist. Leitet die Anfrage für eine bestimmte Anfrage über das Origin Shield des primären Ursprungs an den primären Ursprung in der Ursprungsgruppe weiter. CloudFront Wenn diese Anfrage fehlschlägt (gemäß den Failover-Kriterien der Ursprungsgruppe), wird CloudFront die Anfrage über Origin Shield des sekundären Ursprungs an den sekundären Ursprung weitergeleitet.
### Origin Shield und Lambda@Edge
Origin Shield wirkt sich nicht auf die Funktionalität von [Lambda @Edge-Funktionen](lambda-at-the-edge.md) aus, kann sich jedoch auf die AWS -Region auswirken, in der diese Funktionen ausgeführt werden.
Wenn du Origin Shield mit Lambda @Edge verwendest, werden auf den Ursprung [gerichtete Trigger (Origin](lambda-cloudfront-trigger-events.md) Request und Origin Response) in der AWS Region ausgeführt, in der Origin Shield aktiviert ist. Wenn der primäre Origin Shield-Standort nicht verfügbar ist und Anfragen CloudFront an einen sekundären Origin Shield-Standort weitergeleitet werden, wechseln Lambda @Edge -Trigger ebenfalls dazu, den sekundären Origin Shield-Standort zu verwenden.
Viewerorientierte Auslöser sind nicht betroffen.
# Optimieren der Hochverfügbarkeit mit CloudFront Origin Failover
Sie können CloudFront mit Origin Failover für Szenarien einrichten, in denen eine hohe Verfügbarkeit erforderlich ist. Zunächst erstellen Sie eine *Ursprungsgruppe* mit zwei Ursprüngen: einem primären und einem sekundären. Wenn der primäre Ursprung nicht verfügbar ist oder bestimmte HTTP-Antwortstatuscodes zurückgibt, die auf einen Fehler hinweisen, wechselt CloudFront automatisch zum sekundären Ursprung.
Zum Einrichten eines Origin Failovers müssen Sie eine Verteilung mit mindestens zwei Ursprüngen haben. Anschließend erstellen Sie eine Ursprungsgruppe für Ihre Verteilung, die die beiden Ursprünge enthält, und von denen Sie einen als primär einstellen. Schließlich erstellen oder aktualisieren Sie ein Cache-Verhalten, um die Ursprungsgruppe zu verwenden.
Informationen zu den Schritten zum Einrichten von Ursprungsgruppen und zum Konfigurieren bestimmter Ursprungs-Failover-Optionen finden Sie unter [Erstellen einer Ursprungsgruppe](#concept_origin_groups.creating).
Nach der Konfiguration eines Ursprungs-Failovers für ein Cache-Verhalten geht CloudFront bei Viewer-Anforderungen wie folgt vor:
+ Bei einem Cache-Treffer gibt CloudFront das angeforderte Objekt zurück.
+ Bei einem Cache-Fehler leitet CloudFront die Anforderung an den primären Ursprung in der Ursprungsgruppe weiter.
+ Wenn der primäre Ursprung einen Statuscode zurückgibt, der nicht für Failover konfiguriert ist, z. B. einen HTTP 2xx- oder 3xx-Statuscode, stellt CloudFront dem Viewer das angeforderte Objekt bereit.
+ Wenn eine der folgenden Bedingungen eintritt:
+ Der primäre Ursprung gibt einen HTTP-Statuscode zurück, den Sie für das Failover konfiguriert haben
+ CloudFront kann keine Verbindung mit dem primären Ursprung herstellen (wenn 503 als Failover-Code festgelegt ist).
+ Die Antwort vom primären Ursprung dauert zu lange (Timeout) (wenn 504 als Failover-Code festgelegt ist)
Dann leitet CloudFront die Anforderung an den sekundären Ursprung in der Ursprungsgruppe weiter.
**Anmerkung**
In einigen Anwendungsfällen, z. B. beim Streamen von Videoinhalten, möchten Sie möglicherweise, dass CloudFront schnell ein Failover zum sekundären Ursprung ausführt. Informationen darüber, wie Sie anpassen können, wie schnell CloudFront einen Failover auf den sekundären Ursprung durchführt, finden Sie unter [Steuern von Timeouts und Verbindungsversuchen für Ursprünge](#controlling-attempts-and-timeouts).
CloudFront leitet alle eingehenden Anforderungen selbst dann an den primären Ursprung weiter, wenn bei der vorherigen Anforderung ein Failover auf den sekundären Ursprung stattfand. CloudFront sendet Anforderungen nur an den sekundären Ursprung, nachdem eine Anforderung an den primären Ursprung fehlschlug.
CloudFront führt nur dann ein Failover auf den sekundären Ursprung durch, wenn die HTTP-Methode der Viewer-Anfrage `GET`, `HEAD` oder `OPTIONS` lautet. CloudFront führt kein Failover durch, wenn der Viewer eine andere HTTP-Methode sendet (z. B. `POST`, `PUT` usw.)
Das folgende Diagramm veranschaulicht, wie Origin Failover funktioniert.
![\[Funktionsweise von Origin Failover\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-overview.png)
**Topics**
+ [Erstellen einer Ursprungsgruppe](#concept_origin_groups.creating)
+ [Steuern von Timeouts und Verbindungsversuchen für Ursprünge](#controlling-attempts-and-timeouts)
+ [Verwenden von Origin Failover mit Lambda@Edge-Funktionen](#concept_origin_groups.lambda)
+ [Verwenden von benutzerdefinierten Fehlerseiten mit Ursprung-Failover](#concept_origin_groups.custom-error)
## Erstellen einer Ursprungsgruppe
**So erstellen Sie eine Ursprungsgruppe**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die CloudFront-Konsole unter [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Wählen Sie die Verteilung aus, für die Sie die Ursprungsgruppe erstellen möchten.
1. Wählen Sie den Tab **Ursprünge** aus.
1. Stellen Sie sicher, dass die Verteilung mehr als einen Ursprung hat. Wenn dies nicht der Fall ist, fügen Sie einen zweiten Ursprung hinzu.
1. Wählen Sie auf der Registerkarte **Ursprünge** im Bereich **Ursprungsgruppen** die Option **Ursprungsgruppe erstellen** aus.
1. Wählen Sie die Ursprünge für die Ursprungsgruppe aus. Nachdem Sie Ursprünge hinzugefügt haben, verwenden Sie die Pfeile, um die Priorität festzulegen, d. h., welcher Ursprung primär und welcher sekundär ist.
1. Geben Sie einen Namen für die Ursprungsgruppe ein.
1. Wählen Sie die HTTP-Statuscodes aus, die als Failover-Kriterien verwendet werden sollen. Sie können eine beliebige Kombination der folgenden Statuscodes wählen: 400, 403, 404, 416, 500, 502, 503 oder 504. Wenn CloudFront eine Antwort mit einem der von Ihnen angegebenen Statuscodes erhält, wird ein Failover auf den sekundären Ursprung durchgeführt.
**Anmerkung**
CloudFront führt nur dann ein Failover auf den sekundären Ursprung durch, wenn die HTTP-Methode der Viewer-Anfrage `GET`, `HEAD` oder `OPTIONS` lautet. CloudFront führt kein Failover durch, wenn der Viewer eine andere HTTP-Methode sendet (z. B. `POST`, `PUT` usw.)
1. Geben Sie unter **Auswahlkriterien für den Ursprung** an, wie Ihre Ursprünge ausgewählt werden, wenn Ihre Distribution Viewer-Anforderungen weiterleitet. Sie können die folgenden Optionen auswählen:
**Standard**
CloudFront verwendet die Standardpriorität für Ursprünge, die Sie auf der Seite **Einstellungen** angeben.
**Medienqualitätswert**
CloudFront verfolgt und verwendet diesen Wert, um den ersten Ursprung zu bestimmen, an den die Anforderung weitergeleitet werden soll. Dadurch wird CloudFront auch autorisiert, asynchrone `HEAD`-Anforderungen an den alternativen Ursprung in der Ursprungsgruppe zu stellen, um dessen Medienqualitätswert zu ermitteln. Sie können diese Option nur für AWS Elemental MediaPackage-v2-Ursprünge wählen. Weitere Informationen finden Sie unter [Media Quality-Aware Resiliency](media-quality-score.md).
1. Wählen Sie **Ursprungsgruppe erstellen** aus.
Stellen Sie sicher, dass Sie Ihre Ursprungsgruppe als Ursprung für das Cacheverhalten Ihrer Distribution angeben. Weitere Informationen finden Sie unter [Name](DownloadDistValuesOrigin.md#DownloadDistValuesId).
## Steuern von Timeouts und Verbindungsversuchen für Ursprünge
Standardmäßig versucht CloudFront bis zu 30 Sekunden lang, eine Verbindung mit dem primären Ursprung in einer Ursprungsgruppe herzustellen (3 Verbindungsversuche von jeweils 10 Sekunden), bevor ein Failover zum sekundären Ursprung erfolgt. In einigen Anwendungsfällen, z. B. beim Streamen von Videoinhalten, möchten Sie möglicherweise, dass CloudFront ein Failover auf den sekundären Ursprung schneller ausführt. Sie können die folgenden Einstellungen anpassen, um zu beeinflussen, wie schnell CloudFront ein Failover zum sekundären Ursprung durchführt. Wenn der Ursprung ein sekundärer Ursprung oder ein Ursprung ist, der nicht Teil einer Ursprungsgruppe ist, wirken sich diese Einstellungen darauf aus, wie schnell CloudFront eine HTTP 504-Antwort an den Viewer zurückgibt.
Wenn Sie ein Failover schneller ausführen möchten, geben Sie ein kürzeres Verbindungstimeout, weniger Verbindungsversuche, oder beides an. Für benutzerdefinierte Ursprünge (einschließlich Amazon S3-Bucket-Ursprünge, die mit statischem Website-Hosting konfiguriert *sind*) können Sie auch das Timeout der Ursprungsantwort anpassen.
**Timeout der Ursprungsverbindung**
Die Einstellung für das Ursprungsverbindungs-Timeout wirkt sich darauf aus, wie lange CloudFront beim Versuch, eine Verbindung zum Ursprung herzustellen, wartet. Standardmäßig wartet CloudFront 10 Sekunden, um eine Verbindung herzustellen, Sie können jedoch 1–10 Sekunden (inklusive) angeben. Weitere Informationen finden Sie unter [Verbindungstimeout](DownloadDistValuesOrigin.md#origin-connection-timeout).
**Verbindungsversuche zum Ursprung**
Die Einstellung für die Ursprungsverbindungsversuche wirkt sich darauf aus, wie oft CloudFront versucht, eine Verbindung mit dem Ursprung herzustellen. Standardmäßig versucht CloudFront 3-Mal, eine Verbindung herzustellen, aber Sie können 1–3 (inklusive) angeben. Weitere Informationen finden Sie unter [Verbindungsversuche](DownloadDistValuesOrigin.md#origin-connection-attempts).
Bei einem benutzerdefinierten Ursprung (einschließlich eines Amazon S3-Buckets, der mit statischem Website-Hosting konfiguriert ist) wirkt sich diese Einstellung auch darauf aus, wie oft CloudFront im Falle eines Timeouts der Ursprungsantwort versucht, eine Antwort vom Ursprung zu erhalten.
**Ursprungs-Reaktions-Timeout**
Das Ursprungsantwort-Timeout, auch als Ursprungs-Lese-Timeout bezeichnet, wirkt sich darauf aus, wie lange CloudFront auf den Empfang einer Antwort (oder auf den Empfang der vollständigen Antwort) vom Ursprung wartet. Standardmäßig wartet CloudFront 30 Sekunden, Sie können jedoch 1–120 Sekunden (inklusive) angeben. Weitere Informationen finden Sie unter [Antwort-Timeout](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).
### So ändern Sie diese Einstellungen
**So ändern Sie diese Einstellungen in der [CloudFront-Konsole](https://console.aws.amazon.com/cloudfront/v4/home)**
+ Für einen neuen Ursprung oder eine neue Verteilung geben Sie diese Werte an, wenn Sie die Ressource erstellen.
+ Für einen vorhandenen Ursprung in einer vorhandenen Verteilung geben Sie diese Werte an, wenn Sie den Ursprung bearbeiten.
Weitere Informationen finden Sie unter [Referenz für alle Distributionseinstellungen](distribution-web-values-specify.md).
## Verwenden von Origin Failover mit Lambda@Edge-Funktionen
Sie können Lambda@Edge-Funktionen mit CloudFront-Verteilungen verwenden, die Sie mit Ursprungsgruppen eingerichtet haben. Um eine Lambda-Funktion zu verwenden, geben Sie sie in einem [Ursprungsanforderungs- oder Ursprungsantwort-Auslöser](lambda-cloudfront-trigger-events.md) für eine Ursprungsgruppe an, wenn Sie die Cache-Verhaltenweise erstellen. Wenn Sie eine Lambda@Edge-Funktion mit einer Ursprungsgruppe verwenden, kann die Funktion zweimal für eine einzelne Viewer-Anfrage ausgelöst werden. Betrachten Sie beispielsweise folgendes Szenario:
1. Sie erstellen eine Lambda@Edge-Funktion mit einem Ursprungsanfrage-Auslöser.
1. Die Lambda-Funktion wird einmal ausgelöst, wenn CloudFront eine Anforderung an den primären Ursprung sendet (bei einem Cache-Fehler).
1. Der primäre Ursprung antwortet mit einem HTTP-Statuscode, der für das Failover konfiguriert ist.
1. Die Lambda-Funktion wird erneut ausgelöst, wenn CloudFront dieselbe Anforderung an den sekundären Ursprung sendet.
Das folgende Diagramm illustriert die Funktionsweise von Origin Failover, wenn Sie eine Lambda@Edge-Funktion in eine Ursprungsanfrage oder einen Antwort-Auslöser einbeziehen.
![\[Funktionsweise von Origin Failover mit Lambda@Edge-Funktionen\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-with-lambda-edge.png)
Weitere Informationen zur Verwendung von Lambda@Edge-Auslösern finden Sie unter [Hinzufügen von Auslösern für eine Lambda@Edge-Funktion](lambda-edge-add-triggers.md).
Weitere Informationen zur Verwaltung des DNS-Failovers finden Sie unter [Konfigurieren von DNS-Failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) im *Entwicklerhandbuch für Amazon Route 53*.
## Verwenden von benutzerdefinierten Fehlerseiten mit Ursprung-Failover
Sie können benutzerdefinierte Fehlerseiten mit Ursprungsgruppen ähnlich verwenden wie Ursprünge, die nicht für Origin Failover konfiguriert wurden.
Wenn Sie Ursprungs-Failover verwenden, können Sie CloudFront so konfigurieren, dass eine benutzerdefinierte Fehlerseite für den primären oder sekundären Ursprung (oder beide) zurückgegeben wird:
+ **Benutzerdefinierte Fehlerseite für den primären Ursprung zurückgeben** – Wenn der primäre Ursprung einen HTTP-Statuscode zurückgibt, der nicht für Failover konfiguriert ist, gibt CloudFront die benutzerdefinierte Fehlerseite an die Viewer zurück.
+ **Benutzerdefinierte Fehlerseite für den sekundären Ursprung zurückgeben** – Wenn CloudFront einen Fehlerstatuscode vom sekundären Ursprung empfängt, gibt CloudFront die benutzerdefinierte Fehlerseite zurück.
Weitere Informationen zur Verwendung von benutzerdefinierten Fehlerseiten mit CloudFront finden Sie unter [Erstellen von benutzerdefinierten Fehlerantworten](GeneratingCustomErrorResponses.md).
# Verwalten der Dauer, die Inhalte im Cache bleiben (Ablauf)
Sie können steuern, wie lange Ihre Dateien in einem CloudFront-Cache zwischengespeichert werden, bevor CloudFront eine weitere Anforderung an Ihren Ursprung weiterleitet. Eine Reduzierung der Dauer ermöglicht Ihnen, dynamische Inhalte bereitzustellen. Eine Erhöhung der Dauer bedeutet, dass Ihre Benutzer eine bessere Leistung erhalten, da es wahrscheinlicher ist, dass Ihre Dateien direkt vom Edge-Cache bereitgestellt werden. Eine längere Dauer verringert darüber hinaus die Last auf Ihrem Ursprung.
In der Regel stellt CloudFront eine Datei von einem Edge-Standort bereit, bis die festgelegte Cache-Dauer vergangen ist – d. h. bis die Datei abläuft. Wenn der Edge-Standort nach dem Ablauf eine Anfrage für die Datei erhält, leitet CloudFront die Anfrage an den Ursprung weiter, um sicherzustellen, dass der Cache die neueste Version der Datei enthält. Die Antwort vom Ursprung hängt davon ab, ob die Datei geändert wurde:
+ Wenn der CloudFront-Cache bereits über die neueste Version verfügt, gibt der Ursprung den Statuscode zurüc `304 Not Modified`.
+ Wenn der CloudFront-Cache nicht über die neueste Version verfügt, gibt der Ursprung den Statuscode `200 OK` und die neueste Version der Datei zurück.
Wenn eine Datei an einem Edge-Standort nicht häufig angefordert wird, beseitigt CloudFront die Datei möglicherweise, d. h. entfernt die Datei vor dem Ablaufdatum, um Platz für häufiger angeforderte Dateien zu schaffen.
Wir empfehlen, die Cache-Dauer zu verwalten, indem Sie die Cache-Richtlinie Ihrer Distribution aktualisieren. Wenn Sie keine Cache-Richtlinie verwenden, beträgt die Standard-TTL (Time to Live) 24 Stunden. Sie können jedoch die folgenden Einstellungen aktualisieren, um die Standardeinstellung zu überschreiben:
+ Um die Cache-Dauer für alle Dateien mit demselben Pfadmuster zu ändern, können Sie die CloudFront-Einstellungen für **Mindest-TTL**, **Höchst-TTL** und **Standard-TTL** für ein Cache-Verhalten ändern. Weitere Informationen zu den einzelnen Einstellungen finden Sie unter [Mindest-TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL), [Höchst-TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) und [Standard-TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesDefaultTTL).
+ Um die Cache-Dauer für eine einzelne Datei zu ändern, können Sie Ihren Ursprung so konfigurieren, dass ein `Cache-Control`-Header mit der `max-age`- oder `s-maxage`-Richtlinie oder ein `Expires`-Header zu der Datei hinzugefügt wird. Weitere Informationen finden Sie unter [Verwenden von Headern zum Steuern der Cache-Dauer für einzelne Objekte](#expiration-individual-objects).
Weitere Informationen dazu, wie **Mindest-TTL**, **Standard-TTL** und **Höchst-TTL** mit `max-age`- und `s-maxage`-Richtlinien und dem `Expires`-Header-Feld interagieren, finden Sie unter [Angeben der Zeitspanne, die CloudFront Objekte zwischenspeichert](#ExpirationDownloadDist).
Darüber hinaus können Sie steuern, wie lange Fehler (z. B. `404 Not Found`) in einem CloudFront-Cache zwischengespeichert werden, bevor CloudFront erneut versucht, das angeforderte Objekt durch Weiterleiten einer weiteren Anforderung an Ihren Ursprung abzurufen. Weitere Informationen finden Sie unter [Wie CloudFront werden die HTTP-Statuscodes 4xx und 5xx von Ihrem Ursprung verarbeitet](HTTPStatusCodes.md).
**Topics**
+ [Verwenden von Headern zum Steuern der Cache-Dauer für einzelne Objekte](#expiration-individual-objects)
+ [Bereitstellung veralteter (abgelaufener) Inhalte](#stale-content)
+ [Angeben der Zeitspanne, die CloudFront Objekte zwischenspeichert](#ExpirationDownloadDist)
+ [Hinzufügen von Headern zu Ihren Objekten mithilfe der Amazon-S3-Konsole](#ExpirationAddingHeadersInS3)
## Verwenden von Headern zum Steuern der Cache-Dauer für einzelne Objekte
Sie können die Header `Cache-Control` und `Expires` verwenden, um zu steuern, wie lange Objekte im Cache zwischengespeichert werden. Die Einstellungen für **Mindest-TTL**, **Standard-TTL** und **Höchst-TTL** wirken sich auch auf die Cache-Dauer aus. Im Folgenden finden Sie einen Überblick darüber, wie sich Header auf die Cache-Dauer auswirken können:
+ Mit der `Cache-Control max-age`-Richtlinie können Sie festlegen, wie lange (in Sekunden) ein Objekt im Cache zwischengespeichert werden soll, bevor CloudFront das Objekt erneut vom Ursprungs-Server abruft. Die minimale Ablaufzeit, die CloudFront unterstützt, beträgt 0 Sekunden. Die Höchstwert beträgt 100 Jahre. Geben Sie den Wert im folgenden Format an:
`Cache-Control: max-age=`*Sekunden*
Beispielsweise veranlasst die folgende Richtlinie, dass CloudFront das zugehörige Objekt für 3600 Sekunden (1 Stunde) im Cache behält:
`Cache-Control: max-age=3600`
Wenn Sie möchten, dass Objekte für unterschiedliche Zeiträume in CloudFront-Edge-Caches und in Browser-Caches zwischengespeichert werden, können Sie die `Cache-Control max-age`- und die `Cache-Control s-maxage`-Richtlinie zusammen verwenden. Weitere Informationen finden Sie unter [Angeben der Zeitspanne, die CloudFront Objekte zwischenspeichert](#ExpirationDownloadDist).
+ Im `Expires`-Header-Feld können Sie ein Ablaufdatum und eine Ablaufzeit festlegen. Verwenden Sie dafür das in [RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 Abschnitt 3.3.1, Full Date](https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1) angegebene Format, zum Beispiel:
`Sat, 27 Jun 2015 23:59:59 GMT`
Wir empfehlen, die `Cache-Control max-age`-Richtlinie anstelle des `Expires`-Header-Felds zum Steuern der Zwischenspeicherung von Objekten zu verwenden. Wenn Sie sowohl für `Cache-Control max-age` als auch für `Expires` Werte festlegen, verwendet CloudFront nur den Wert von `Cache-Control max-age`.
Weitere Informationen finden Sie unter [Angeben der Zeitspanne, die CloudFront Objekte zwischenspeichert](#ExpirationDownloadDist).
Sie können nicht die HTTP-Header-Felder `Cache-Control` oder `Pragma` in einer `GET`-Anforderung von einem Viewer verwenden, um zu erzwingen, dass CloudFront für das Objekt zum Ursprungs-Server zurückkehrt. CloudFront ignoriert diese Header-Felder in Viewer-Anforderungen.
Weitere Informationen zu den Header-Feldern `Cache-Control` und `Expires` finden Sie in den folgenden Abschnitt in *RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1*:
+ [Abschnitt 14.9 Cache-Kontrolle](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9)
+ [Abschnitt 14.21 Läuft ab](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21)
## Bereitstellung veralteter (abgelaufener) Inhalte
CloudFront unterstützt die Cache-Kontrolldirektiven `Stale-While-Revalidate` und `Stale-If-Error`. Mit diesen Direktiven können Sie angeben, wie lange veraltete Inhalte für Viewer verfügbar sind.
**Topics**
+ [`Stale-While-Revalidate`](#stale-while-revalidate)
+ [`Stale-If-Error`](#stale-if-error-only)
+ [Verwenden beider Direktiven](#use-both-stale-directives)
### `Stale-While-Revalidate`
Diese Direktive ermöglicht es CloudFront, veraltete Inhalte aus dem Cache bereitzustellen, während gleichzeitig asynchron eine neue Version vom Ursprung abgerufen wird. Dies verbessert die Latenz, da Viewer sofort Antworten von Edge-Standorten erhalten, ohne auf den Abruf im Hintergrund warten zu müssen. Neue Inhalte werden für zukünftige Anforderungen im Hintergrund geladen.
**Example Beispiel: `Stale-While-Revalidate`**
CloudFront geht wie folgt vor, wenn Sie den `Cache-Control`-Header so einrichten, dass er diese Direktiven verwendet.
```
Cache-Control: max-age=3600, stale-while-revalidate=600
```
1. CloudFront speichert eine Antwort für eine Stunde (`max-age=3600`).
1. Wenn nach diesem Zeitraum eine Anforderung gestellt wird, stellt CloudFront den veralteten Inhalt bereit und sendet gleichzeitig eine Anforderung an den Ursprung, um den zwischengespeicherten Inhalt erneut zu validieren und zu aktualisieren.
1. Während der Inhalt erneut validiert wird, stellt CloudFront den veralteten Inhalt bis zu 10 Minuten lang (`stale-while-revalidate=600`) bereit.
**Anmerkung**
CloudFront stellt den veralteten Inhalt bis zum Wert der Direktive `stale-while-revalidate` oder dem Wert der [CloudFront-Höchst-TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) zur Verfügung, je nachdem, welcher Wert niedriger ist. Nach Ablauf der maximalen TTL-Dauer ist das veraltete Objekt unabhängig vom Wert `stale-while-revalidate` nicht mehr im Edge-Cache verfügbar.
### `Stale-If-Error`
Diese Direktive ermöglicht es CloudFront, veraltete Inhalte aus dem Cache bereitzustellen, wenn der Ursprung nicht erreichbar ist oder einen Fehlercode zwischen 500 und 600 zurückgibt. Dadurch wird sichergestellt, dass Viewer auch während eines Ausfalls des Ursprungs auf Inhalte zugreifen können.
**Example Beispiel: `Stale-If-Error`**
CloudFront geht wie folgt vor, wenn Sie den `Cache-Control`-Header so einrichten, dass er diese Direktiven verwendet.
```
Cache-Control: max-age=3600, stale-if-error=86400
```
1. CloudFront speichert die Antwort für eine Stunde (`max-age=3600`) im Cache.
1. Wenn der Ursprung ausgefallen ist oder nach diesem Zeitraum ein Fehler zurückgibt, stellt CloudFront den veralteten Inhalt bis zu 24 Stunden lang bereit (`stale-if-error=86400`).
1. Wenn Sie benutzerdefinierte Fehlerantworten konfiguriert haben, versucht CloudFront, den veralteten Inhalt bereitzustellen, wenn innerhalb der angegebenen Dauer von `stale-if-error` ein Fehler auftritt. Wenn der veraltete Inhalt nicht verfügbar ist, stellt CloudFront die benutzerdefinierten Fehlerantworten bereit, die Sie für den entsprechenden Fehlerstatuscode konfiguriert haben. Weitere Informationen finden Sie unter [Erstellen von benutzerdefinierten Fehlerantworten](GeneratingCustomErrorResponses.md).
**Hinweise**
CloudFront stellt den veralteten Inhalt bis zum Wert der Direktive `stale-if-error` oder dem Wert der [CloudFront-Höchst-TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) zur Verfügung, je nachdem, welcher Wert niedriger ist. Nach Ablauf der maximalen TTL-Dauer ist das veraltete Objekt unabhängig vom Wert `stale-if-error` nicht mehr im Edge-Cache verfügbar.
Wenn Sie `stale-if-error` nicht konfigurieren oder keine benutzerdefinierten Fehlerantworten festlegen, gibt CloudFront das veraltete Objekt zurück oder leitet die Fehlerantwort zurück an den Viewer, je nachdem, ob sich das angeforderte Objekt im Edge-Cache befindet oder nicht. Weitere Informationen finden Sie unter [Wie CloudFront werden Fehler verarbeitet, wenn Sie keine benutzerdefinierten Fehlerseiten konfiguriert haben](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).
### Verwenden beider Direktiven
`stale-while-revalidate` und `stale-if-error` sind unabhängige Cache-Kontrolldirektiven, die zusammen verwendet werden können, um die Latenz zu reduzieren und einen Puffer hinzuzufügen, damit Ihr Ursprung reagieren oder sich erholen kann.
**Example Beispiel: Verwendung beider Direktiven**
CloudFront geht wie folgt vor, wenn Sie den `Cache-Control`-Header so einrichten, dass er die folgenden Direktiven verwendet.
```
Cache-Control: max-age=3600, stale-while-revalidate=600, stale-if-error=86400
```
1. CloudFront speichert die Antwort für eine Stunde (`max-age=3600`) im Cache.
1. Wenn nach diesem Zeitraum eine Anforderung gestellt wird, stellt CloudFront den veralteten Inhalt bis zu 10 Minuten (`stale-while-revalidate=600`) bereit, während der Inhalt erneut überprüft wird.
1. Wenn der Ursprungsserver einen Fehler zurückgibt, während CloudFront versucht, den Inhalt erneut zu validieren, stellt CloudFront den veralteten Inhalt bis zu 24 Stunden lang bereit (`stale-if-error=86400`).
Caching stellt ein Gleichgewicht zwischen Leistung und Aktualität her. Die Verwendung von Richtlinien wie `stale-while-revalidate` und `stale-if-error` kann die Leistung und den Benutzerkomfort verbessern. Achten Sie jedoch darauf, dass die Konfigurationen darauf abgestimmt sind, wie aktuell Ihre Inhalte sein sollen. Richtlinien für veraltete Inhalte eignen sich am besten für Anwendungsfälle, in denen Inhalte aktualisiert werden müssen, die neueste Version jedoch nicht unbedingt erforderlich ist. Wenn sich Ihr Inhalt nicht oder nur selten ändert, kann `stale-while-revalidate` außerdem zu unnötigen Netzwerkanforderungen führen. Erwägen Sie stattdessen, eine lange Cachedauer festzulegen.
## Angeben der Zeitspanne, die CloudFront Objekte zwischenspeichert
Um die Zeit zu steuern, die CloudFront ein Objekt im Cache hält, bevor eine weitere Anfrage an den Ursprung gesendet wird, können Sie:
+ Die minimalen, maximalen und standardmäßigen TTL-Werte im Cache-Verhalten einer CloudFront-Verteilung festlegen. Sie können diese Werte in einer [Cache-Richtlinie](controlling-the-cache-key.md) festlegen, die an das Cache-Verhalten (empfohlen) oder in den Legacy-Cache-Einstellungen angehängt ist.
+ Die `Cache-Control`- oder `Expires`-Header in Antworten vom Ursprung einschließen. Diese Header helfen auch zu bestimmen, wie lange ein Objekt in einem Browser-Cache zwischengespeichert wird, bevor eine weitere Anforderung an CloudFront gesendet wird.
In der folgenden Tabelle wird erläutert, wie die vom Ursprung gesendeten `Cache-Control`- und `Expires`-Header mit den TTL-Einstellungen in einem Cache-Verhalten zusammenarbeiten, um das Caching zu beeinflussen.
****
| Urspung-Header | Mindest-TTL = 0 | Mindest-TTL > 0 |
| --- | --- | --- |
| **Der Ursprung fügt dem Objekt eine `Cache-Control: max-age`-Richtlinie hinzu** | **CloudFront-Caching** CloudFront speichert das Objekt für den niedrigen der Werte der `Cache-Control: max-age`-Richtlinie und der CloudFront-Höchst-TTL zwischen. **Browser-Caching** Browser speichern das Objekt für den Wert der `Cache-Control: max-age`-Richtlinie zwischen. | **CloudFront-Caching** Die CloudFront-Zwischenspeicherung ist abhängig von den Werten der CloudFront-Mindest- und -Höchst-TTL sowie der `Cache-Control max-age`-Richtlinie: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Browser-Caching** Browser speichern das Objekt für den Wert der `Cache-Control: max-age`-Richtlinie zwischen. |
| **Der Ursprung fügt dem Objekt keine `Cache-Control: max-age`-Richtlinie hinzu** | **CloudFront-Caching** CloudFront speichert das Objekt für den Wert der CloudFront-Standard-TTL zwischen. **Browser-Caching** Abhängig vom Browser. | **CloudFront-Caching** CloudFront speichert das Objekt für den höheren der Werte der CloudFront-Mindest-TTL und -Standard-TTL zwischen. **Browser-Caching** Abhängig vom Browser. |
| **Der Ursprung fügt dem Objekt `Cache-Control: max-age`- und `Cache-Control: s-maxage`-Richtlinien hinzu** | **CloudFront-Caching** CloudFront speichert das Objekt für den niedrigen der Werte der `Cache-Control: s-maxage`-Richtlinie und der CloudFront-Höchst-TTL zwischen. **Browser-Caching** Browser speichern das Objekt für den Wert der `Cache-Control max-age`-Richtlinie zwischen. | **CloudFront-Caching** Die CloudFront-Zwischenspeicherung ist abhängig von den Werten der CloudFront-Mindest- und -Höchst-TTL sowie der `Cache-Control: s-maxage`-Richtlinie: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Browser-Caching** Browser speichern das Objekt für den Wert der `Cache-Control: max-age`-Richtlinie zwischen. |
| **Der Ursprung fügt dem Objekt einen `Expires`-Header hinzu** | **CloudFront-Caching** CloudFront speichert das Objekt bis zum Datum im `Expires`-Header oder für den Wert der CloudFront-Höchst-TTL zwischen, je nachdem, welcher Zeitpunkt früher eintritt. **Browser-Caching** Browser speichern das Objekt bis zum Datum im `Expires`-Header zwischen. | **CloudFront-Caching** Die CloudFront-Zwischenspeicherung ist abhängig von den Werten der CloudFront-Mindest- und -Höchst-TTL sowie dem `Expires`-Header: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Browser-Caching** Browser speichern das Objekt bis zum Datum und der Uhrzeit im `Expires`-Header zwischen. |
| **Der Ursprung fügt Objekten `Cache-Control: no-cache`-, `no-store`-, und/oder `private`-Richtlinien hinzu** | CloudFront und Browser berücksichtigen die Header. | **CloudFront-Caching** CloudFront speichert Objekte für den Wert der CloudFront-Mindest-TTL zwischen. [Siehe die Warnung unter dieser Tabelle](#stale-if-error). **Browser-Caching** Browser berücksichtigen die Header. |
**Warnung**
Wenn Ihre Mindest-TTL größer als 0 ist, verwendet CloudFront die Mindest-TTL der Cache-Richtlinie, auch wenn die Direktiven `Cache-Control: no-cache`, `no-store` und/oder `private` in den Ursprungsheadern vorhanden sind.
Wenn der Ursprung erreichbar ist, ruft CloudFront das Objekt vom Ursprung ab und gibt es an den Viewer zurück.
Wenn der Ursprung nicht erreichbar ist und die minimale oder *maximale* TTL größer als 0 ist, bedient CloudFront das Objekt, das es zuvor vom Ursprung erhalten hat.
Um dieses Verhalten zu vermeiden, schließen Sie die `Cache-Control: stale-if-error=0`-Richtlinie in das vom Ursprung zurückgegebene Objekt ein. Dies führt dazu, dass CloudFront als Reaktion auf zukünftige Anfragen einen Fehler zurückgibt, wenn der Ursprung nicht erreichbar ist, anstatt das Objekt zurückzugeben, das es zuvor vom Ursprung erhalten hat.
CloudFront speichert den HTTP-Statuscode 501 („Nicht implementiert“) von einem S3-Ursprung nicht im Cache, wenn die Ursprungsheader die Direktiven `Cache-Control: no-cache`, `no-store` und/oder `private` enthalten. Dies ist das Standardverhalten für einen S3-Ursprung, auch wenn Ihre Einstellung für die [Mindest-TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) größer als 0 ist.
Weitere Informationen zum Ändern von Einstellungen für Verteilungen mithilfe der CloudFront-Konsole finden Sie unter [Eine Verteilung aktualisieren](HowToUpdateDistribution.md). Weitere Informationen zum Ändern von Einstellungen für Verteilungen mithilfe der CloudFront-API finden Sie unter [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
## Hinzufügen von Headern zu Ihren Objekten mithilfe der Amazon-S3-Konsole
Sie können das Header-Feld `Cache-Control` oder `Expires` zu Ihren Amazon-S3-Objekten hinzufügen. Ändern Sie dazu die Metadatenfelder für das Objekt.
**So fügen Sie ein `Cache-Control`- oder `Expires`-Header-Feld zu Amazon-S3-Objekten hinzu**
1. Folgen Sie den Anleitungen im Abschnitt **Ersetzen systemdefinierter Metadaten** im Thema [Bearbeiten von Objektmetadaten in der Amazon-S3-Konsole](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) im *Benutzerhandbuch für Amazon S3*.
1. Wählen Sie für **Schlüssel** den Namen des Headers aus, den Sie hinzufügen (**Cache-Control** oder **Expires**).
1. Geben Sie für **Wert** einen Header-Wert ein. Zum Beispiel könnten Sie für einen `Cache-Control`-Header `max-age=86400` eingeben. Für `Expires` könnten Sie ein Ablaufdatum und eine Uhrzeit wie `Wed, 30 Jun 2021 09:28:00 GMT` eingeben.
1. Folgen Sie den restlichen Schritten, um Ihre Metadatenänderungen zu speichern.
# Zwischenspeichern von Inhalten auf der Grundlage von Abfragezeichenfolgeparametern
Einige Webanwendungen verwenden zum Senden von Informationen an den Ursprung Abfragezeichenfolgen. Eine Abfragezeichenfolge ist der Teil einer Webanfrage nach dem Zeichen `?`. Die Zeichenfolge kann einen oder mehrere durch das Zeichen `&` getrennte Parameter enthalten. Im folgenden Beispiel enthält die Abfragezeichenfolge zwei Parameter, *color=red* und *size=large*:
`https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`
Bei Verteilungen können Sie wählen, ob CloudFront Abfragezeichenfolgen an Ihren Ursprung weiterleiten und ob Ihr Inhalt auf der Grundlage von allen oder von ausgewählten Parametern zwischengespeichert werden soll. Warum kann dies sinnvoll sein? Betrachten Sie das folgende Beispiel.
Angenommen, Ihre Website ist in fünf Sprachen verfügbar. Die Verzeichnisstruktur und Dateinamen für alle fünf Versionen der Website sind identisch. Wenn ein Benutzer Ihre Website aufruft, beinhalten die an CloudFront weitergeleiteten Anforderungen einen Sprachabfrage-Zeichenfolgeparameter auf der Grundlage der vom Benutzer ausgewählten Sprache. Sie können CloudFront so konfigurieren, dass Abfragezeichenfolgen auf der Grundlage des Sprachparameters an den Ursprung weitergeleitet und Zwischenspeicherungen vorgenommen werden. Wenn Sie Ihren Webserver so konfigurieren, dass die Version einer bestimmten Seite zurückgegeben wird, die der ausgewählten Sprache entspricht, speichert CloudFront alle Sprachversionen auf der Grundlage des Werts des Sprachabfrage-Zeichenfolgeparameters separat zwischen.
In diesem Beispiel, in dem die Hauptseite Ihrer Website `main.html` ist, führen die folgenden fünf Anforderungen dazu, dass CloudFront `main.html` fünfmal zwischenspeichert, einmal für jeden Wert des Sprachabfrage-Zeichenfolgenparameters:
+ `https://d111111abcdef8.cloudfront.net/main.html?language=de`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=en`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=es`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=fr`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=jp`
Beachten Sie Folgendes:
+ Einige HTTP-Server verarbeiten keine Abfragezeichenfolgeparameter und geben daher nicht unterschiedliche Versionen eines Objekts auf der Grundlage der Parameterwerte zurück. Wenn Sie bei diesen Ursprüngen CloudFront so konfigurieren, dass Abfragezeichenfolgeparameter an den Ursprung weitergeleitet werden, speichert CloudFront weiterhin auf der Grundlage der Parameterwerte zwischen, selbst wenn der Ursprung für jeden Parameterwert identische Versionen des Objekts an CloudFront zurückgibt.
+ Damit Abfragezeichenfolgeparameter wie im obigen Beispiel beschrieben mit den Sprachen funktionieren, müssen Sie das Zeichen `&` als Trennzeichen zwischen den Abfragezeichenfolgeparametern verwenden. Wenn Sie ein anderes Trennzeichen verwenden, erhalten Sie möglicherweise unerwartete Ergebnisse, je nachdem, welche Parameter CloudFront als Basis für die Zwischenspeicherung verwenden soll und in welcher Reihenfolge sie in der Abfragezeichenfolge angezeigt werden.
Die folgenden Beispiele zeigen, was passiert, wenn Sie ein anderes Trennzeichen verwenden und CloudFront so konfigurieren, dass die Zwischenspeicherung nur auf der Grundlage des `color`-Parameters erfolgt:
+ In der folgenden Anforderung speichert CloudFront Ihre Inhalte auf der Grundlage des Werts des Parameters `color` zwischen. CloudFront interpretiert den Wert jedoch als *red;size=large*:
`https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red;size=large`
+ In der folgenden Anforderung speichert CloudFront Ihre Inhalte zwischen, jedoch nicht basierend auf den Abfragezeichenfolgeparametern. Der Grund hierfür ist, dass Sie CloudFront so konfiguriert haben, dass die Zwischenspeicherung auf der Grundlage des Parameters `color` erfolgt, CloudFront die folgende Zeichenfolge jedoch so interpretiert, dass sie nur einen `size`-Parameter mit dem Wert *large;color=red* enthält:
`https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large;color=red`
Sie können CloudFront für eine der folgenden Aktionen konfigurieren:
+ Keine Abfragezeichenfolge an den Ursprung weiterleiten. Wenn Sie keine Abfragezeichenfolgen weiterleiten, speichert CloudFront nicht auf der Grundlage von Abfragezeichenfolgeparametern zwischen.
+ Abfragezeichenfolgen an den Ursprung weiterleiten und auf der Grundlage aller Parameter in der Abfragezeichenfolge zwischenspeichern.
+ Abfragezeichenfolgen an den Ursprung weiterleiten und auf der Grundlage spezifischer Parameter in der Abfragezeichenfolge zwischenspeichern.
Weitere Informationen finden Sie unter [Optimieren der Zwischenspeicherung](#query-string-parameters-optimizing-caching).
**Topics**
+ [Konsolen- und API-Einstellungen für die Weiterleitung und Zwischenspeicherung von Abfragezeichenfolgen](#query-string-parameters-console)
+ [Optimieren der Zwischenspeicherung](#query-string-parameters-optimizing-caching)
+ [Parameter für Abfragezeichenfolgen und CloudFront-Standardprotokolle abfragen (Zugriffsprotokolle)](#query-string-parameters-access-logs)
## Konsolen- und API-Einstellungen für die Weiterleitung und Zwischenspeicherung von Abfragezeichenfolgen
Wenn Sie eine Distribution in der CloudFront-Konsole erstellen, konfiguriert CloudFront die Weiterleitung und das Zwischenspeichern von Abfragezeichenfolgen für Sie auf der Grundlage Ihres Quelltyps. Sie können diese Einstellungen auch manuell bearbeiten. Weitere Informationen zu den folgenden Einstellungen finden Sie in der [Referenz für alle Distributionseinstellungen](distribution-web-values-specify.md):
+ [Weiterleitung und Zwischenspeicherung von Abfragezeichenfolgen](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryString)
+ [Zulassungsliste für Abfragezeichenfolgen](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryStringAllowlist)
Informationen dazu, wie Sie die Weiterleitung und Zwischenspeicherung von Abfragezeichenfolgen mit der CloudFront-API konfigurieren, finden Sie unter [CachePolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CachePolicy.html) und [OriginRequestPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginRequestPolicy.html) in der *Referenz zur Amazon CloudFront API*.
## Optimieren der Zwischenspeicherung
Wenn Sie CloudFront konfigurieren, basierend auf Abfragezeichenfolgenparametern zwischenzuspeichern, können Sie die folgenden Schritte ausführen, um die Anzahl der Anforderungen reduzieren, die von CloudFront an Ihren Ursprung weitergeleitet werden. Wenn CloudFront-Edge-Standorte Objekte bereitstellen, reduzieren Sie die Belastung Ihres Ursprungs-Servers und reduzieren die Latenz, da Objekte von Standorten bereitgestellt werden, die näher an Ihren Benutzern liegen.
**Zwischenspeichern auf der ausschließlichen Grundlage von Parametern, für die Ihr Ursprung verschiedene Versionen eines Objekts zurückgibt**
Für jeden Abfragezeichenfolgeparameter, den Ihre Webanwendung an CloudFront weiterleitet, leitet CloudFront Anforderungen für jeden Parameterwert an Ihren Ursprung weiter und speichert eine separate Version des Objekts für jeden Parameterwert zwischen. Dies gilt auch, wenn Ihr Ursprung unabhängig vom Parameterwert immer dasselbe Objekt zurückgibt. Bei mehreren Parametern multiplizieren sich die Anzahl der Anfragen und die Anzahl der Objekte.
Wir empfehlen, CloudFront so zu konfigurieren, dass die Zwischenspeicherung auf ausschließlicher Grundlage der Abfragezeichenfolgeparameter erfolgt, für die Ihr Ursprung verschiedene Versionen zurückgibt, und dass Sie sorgfältig abwägen, welche Vorteile die Zwischenspeicherung auf der Grundlage aller Parameter hat. Nehmen wir beispielsweise an, dass Sie eine Einzelhandels-Website besitzen. Sie haben Bilder einer Jacke in sechs verschiedenen Farben und es gibt die Jacke in zehn verschiedenen Größen. Die Bilder, die Sie von der Jacke haben, zeigen die verschiedenen Farben, jedoch nicht die verschiedenen Größen. Um die Zwischenspeicherung zu optimieren, sollten Sie CloudFront so konfigurieren, dass die Zwischenspeicherung auf ausschließlicher Grundlage der Farbparameter erfolgt und nicht auf Grundlage der Größenparameter. Dies erhöht die Wahrscheinlichkeit, dass CloudFront eine Anforderung aus dem Cache bereitstellen kann, um die Leistung zu verbessern und die Auslastung des Ursprungs zu reduzieren.
**Parameter immer in der gleichen Reihenfolge auflisten**
Die Reihenfolge der Parameter in Abfragezeichenfolgen ist wichtig. Im folgenden Beispiel sind die Abfragezeichenfolgen identisch, abgesehen davon, dass die Parameter eine andere Reihenfolge aufweisen. Dadurch wird CloudFront veranlasst, zwei separate Anforderungen für image.jpg an Ihren Ursprung weiterzuleiten und zwei verschiedene Versionen des Objekts zwischenzuspeichern:
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large&color=red`
Wir empfehlen, Parameternamen immer in der gleichen Reihenfolge aufzulisten, beispielsweise in alphabetischer Reihenfolge.
**Immer dieselbe Schreibweise für Parameternamen und -werte verwenden**
CloudFront berücksichtigt bei der Zwischenspeicherung auf der Grundlage von Abfragezeichenfolgeparametern die Schreibweise von Parameternamen und -werten. Im folgenden Beispiel sind die Abfragezeichenfolgen identisch, abgesehen von der Schreibweise der Parameternamen und -werte. Dadurch wird CloudFront veranlasst, vier separate Anforderungen für image.jpg an Ihren Ursprung weiterzuleiten und vier verschiedene Versionen des Objekts zwischenzuspeichern:
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=Red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=Red`
Wir empfehlen, konsistent dieselbe Schreibweise für Parameternamen und -werte zu verwenden, beispielsweise nur Kleinbuchstaben.
**Keine Parameternamen verwenden, die mit signierten URLs in Konflikt stehen**
Wenn Sie signierte URLs verwenden, um den Zugriff auf Ihre Inhalte einzuschränken (wenn Sie vertrauenswürdiger Aussteller zu Ihrer Verteilung hinzugefügt haben), entfernt CloudFront die folgenden Abfragezeichenfolgeparameter, bevor der Rest Ihrer URL an Ihren Ursprung weitergeleitet wird:
+ `Expires`
+ `Key-Pair-Id`
+ `Policy`
+ `Signature`
Wenn Sie signierte URLs verwenden und CloudFront so konfigurieren möchten, dass Abfragezeichenfolgen an Ihren Ursprung weitergeleitet werden, können Ihre eigenen Abfragezeichenfolgeparameter nicht mit `Expires`, `Key-Pair-Id`, `Policy` oder `Signature` benannt werden.
## Parameter für Abfragezeichenfolgen und CloudFront-Standardprotokolle abfragen (Zugriffsprotokolle)
Wenn Sie die Protokollierung aktivieren, protokolliert CloudFront die vollständige URL einschließlich der Parameter für Abfragezeichenfolgen. Dies gilt unabhängig davon, ob Sie CloudFront so konfiguriert haben, dass Abfragezeichenfolgen an den Ursprung weitergegeben werden. Weitere Informationen zur CloudFront-Protokollierung finden Sie unter [Zugriffsprotokolle (Standardprotokolle)](AccessLogs.md).
# Zwischenspeichern von Inhalten auf der Grundlage von Cookies
Cookies werden von CloudFront standardmäßig nicht berücksichtigt, wenn Anforderungen und Antworten verarbeitet werden oder wenn Sie Ihre Objekte an Edge-Standorten zwischenspeichern. Wenn CloudFront zwei Anforderungen empfängt, die bis auf die Informationen im `Cookie`-Header identisch sind, behandelt CloudFront die Anforderungen standardmäßig als identisch und gibt dasselbe Objekt für beide Anforderungen zurück.
Sie können CloudFront so konfigurieren, dass einige oder alle Cookies in Viewer-Anforderungen an Ihren Ursprungs-Server weitergeleitet werden und separate Versionen Ihrer Objekte basierend auf den Cookie-Werten, die weitergeleitet werden. Wenn Sie dies tun, verwendet CloudFront einige oder alle Cookies in Viewer-Anforderungen – je nachdem, welche gemäß der Konfiguration weitergeleitet werden –, um ein Objekt im Cache eindeutig zu identifizieren.
Nehmen wir beispielsweise an, dass Anfragen für `locations.html` ein `country`-Cookie enthalten, das entweder den Wert `uk` oder `fr` hat. Wenn Sie CloudFront so konfigurieren, dass Ihre Objekte auf der Grundlage des Werts des `country`-Cookies zwischengespeichert werden, leitet CloudFront Anforderungen für `locations.html` an den Ursprung weiter und fügt das `country`-Cookie und den Cookie-Werte ein. Ihr Ursprung gibt `locations.html` zurück, und CloudFront speichert das Objekt einmal für Anforderungen zwischen, in denen der Wert des `country`-Cookies `uk` ist, und einmal für Anforderungen, in denen der Wert `fr` ist.
**Wichtig**
Amazon S3 und einige HTTP-Server verarbeiten keine Cookies. Konfigurieren Sie CloudFront nicht so, dass Cookies an einen Ursprung weitergeleitet werden, der keine Cookies verarbeitet oder seine Antwort aufgrund von Cookies nicht variiert. Dies hat zur Folge, dass CloudFront weitere Anforderungen für dasselbe Objekt an den Ursprung weiterleitet, wodurch die Leistung verringert und die Last auf den Ursprung erhöht wird. Wenn in Anbetracht des vorherigen Beispiels Ihr Ursprung das `country`-Cookie nicht verarbeitet oder immer die gleiche Version von `locations.html` an CloudFront zurückgibt, unabhängig vom Wert des `country`-Cookies, konfigurieren Sie CloudFront nicht so, dass dieses Cookie weitergeleitet wird.
Ist Ihr benutzerdefinierter Ursprung dagegen von einem bestimmten Cookie abhängig oder sendet er verschiedene Antworten basierend auf einem Cookie, konfigurieren Sie CloudFront so, dass dieses Cookie an den Ursprung weitergeleitet wird. Andernfalls wird das Cookie von CloudFront entfernt, bevor die Anforderung an den Ursprung weitergeleitet wird.
Zum Konfigurieren der Cookie-Weiterleitung aktualisieren Sie das Cache-Verhalten Ihrer Verteilung. Weitere Informationen über Cache-Verhalten finden Sie unter [Einstellungen für das Cache-Verhalten](DownloadDistValuesCacheBehavior.md), insbesondere in den Abschnitten [Cookies weiterleiten](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardCookies) und [Zulassungslisten-Cookies](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies).
Sie können jedes Cache-Verhalten so konfigurieren, dass eine der folgenden Aktionen ausgeführt wird:
+ **Weiterleitung aller Cookies an Ihren Ursprung** – CloudFront fügt alle Cookies an, die vom Viewer gesendet werden, wenn Anforderungen an den Ursprung weitergeleitet werden. Wenn Ihr Ursprung eine Antwort zurückgibt, speichert CloudFront die Antwort unter Verwendung die Cookies-Namen und -Werte in der Viewer-Anforderung zwischen. Wenn die Ursprungsantwort `Set-Cookie`-Header enthält, gibt CloudFront sie mit dem angeforderten Objekt an den Viewer zurück. CloudFront speichert auch die `Set-Cookie`-Header mit dem vom Ursprung zurückgegebenen Objekt zwischen und sendet diese `Set-Cookie`-Header an Viewer für alle Cache-Treffer.
+ **Weiterleiten eines Satzes von Cookies, die Sie festlegen** – CloudFront entfernt alle Cookies, die der Viewer sendet, die sich nicht auf der Whitelist befinden, bevor eine Anforderung an den Ursprung weitergeleitet wird. CloudFront speichert die Antwort unter Verwendung der aufgelisteten Cookie-Namen und -Werte in der Viewer-Anforderung zwischen. Wenn die Ursprungsantwort `Set-Cookie`-Header enthält, gibt CloudFront sie mit dem angeforderten Objekt an den Viewer zurück. CloudFront speichert auch die `Set-Cookie`-Header mit dem vom Ursprung zurückgegebenen Objekt zwischen und sendet diese `Set-Cookie`-Header an Viewer für alle Cache-Treffer.
Weitere Informationen zum Angeben von Platzhaltern in Cookie-Namen finden Sie unter [Zulassungslisten-Cookies](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies).
Informationen zum aktuellen Kontingent für die Anzahl von Cookie-Namen, die Sie für jedes Cache-Verhalten weiterleiten können, oder zum Anfordern eines höheren Kontingents finden Sie unter [Kontingente für Abfragezeichenfolgen (Legacy-Cache-Einstellungen)](cloudfront-limits.md#limits-allowlisted-query-strings).
+ **Kein Weiterleiten von Cookies an Ihren Ursprung** – CloudFront speichert Ihre Objekte nicht auf der Grundlage von Cookie-Werten, die vom Viewer gesendet werden, zwischen. Außerdem entfernt CloudFront Cookies, bevor Anforderungen an Ihren Ursprung weitergeleitet werden, und entfernt `Set-Cookie`-Header aus Antworten, bevor Antworten an Ihre Viewer zurückgegeben werden. Da Ihre Ursprungsressourcen auf diese Weise nicht optimal genutzt werden, sollten Sie bei der Auswahl dieses Cacheverhaltens sicherstellen, dass Ihr Ursprung standardmäßig keine Cookies in Ursprungsantworten enthält.
Beachten Sie die folgenden Informationen zur Angabe des Cookies, das Sie weiterleiten möchten:
**Zugriffsprotokolle**
Wenn Sie CloudFront so konfigurieren, dass Anforderungen und Cookies protokolliert werden, protokolliert CloudFront alle Cookies und alle Cookie-Attribute, auch wenn Sie CloudFront so konfigurieren, dass keine Cookies an Ihren Ursprung weitergeleitet werden, oder wenn Sie CloudFront so konfigurieren, dass nur bestimmte Cookies weitergeleitet werden. Weitere Informationen zur CloudFront-Protokollierung finden Sie unter [Zugriffsprotokolle (Standardprotokolle)](AccessLogs.md).
**Groß-/Kleinschreibung**
Bei Cookie-Namen und -Werten muss die Groß-/Kleinschreibung beachtet werden. Wenn zum Beispiel CloudFront so konfiguriert ist, dass alle Cookies weitergeleitet werden, und zwei Viewer-Anforderungen für dasselbe Objekt Cookies haben, die abgesehen von der Groß-/Kleinschreibung identisch sind, speichert CloudFront das Objekt zweimal.
**CloudFront sortiert Cookies**
Wenn CloudFront so konfiguriert ist, dass Cookies (alle oder eine Teilmenge) weitergeleitet werden, sortiert CloudFront die Cookies in natürlicher Reihenfolge nach Cookie-Namen, bevor die Anforderung an Ihren Ursprung weitergeleitet wird.
Cookie-Namen, die mit dem Zeichen `$` beginnen, werden nicht unterstützt. CloudFront entfernt das Cookie, bevor die Anforderung an den Ursprung weitergeleitet wird. Sie können das Zeichen `$` entfernen oder ein anderes Zeichen am Anfang des Cookie-Namens angeben.
**`If-Modified-Since` and `If-None-Match`**
Bedingte Anforderungen `If-Modified-Since` und `If-None-Match` werden nicht unterstützt, wenn CloudFront so konfiguriert ist, dass Cookies (alle oder eine Teilmenge) weitergeleitet werden.
**Standard-Name-Wert-Paar-Format erforderlich**
Cookie-Header werden von CloudFront nur weitergeleitet, wenn der Wert dem [Standard-Name-Wert-Paar-Format](https://tools.ietf.org/html/rfc6265#section-4.1.1) entspricht. Beispiel: `"Cookie: cookie1=value1; cookie2=value2"`.
**Deaktivieren der Zwischenspeicherung von `Set-Cookie`-Headern**
Wenn CloudFront so konfiguriert ist, dass Cookies an den Ursprung (alle oder bestimmte Cookies) weitergeleitet werden, werden auch die `Set-Cookie`-Header zwischengespeichert, die in der Ursprungsantwort empfangen wurden. CloudFront schließt diese `Set-Cookie`-Header in seine Antwort auf den ursprünglichen Viewer ein und schließt sie auch in nachfolgenden Antworten ein, die aus dem CloudFront-Cache bereitgestellt werden.
Wenn Sie Cookies an Ihrem Ursprung erhalten möchten, aber nicht wollen, dass CloudFront die `Set-Cookie`-Header in den Antworten Ihres Ursprungs zwischenspeichert, konfigurieren Sie Ihren Ursprung so, dass ein `Cache-Control`-Header mit einer `no-cache`-Direktive hinzugefügt wird, `Set-Cookie` als Feldname angibt. Beispiel: `Cache-Control: no-cache="Set-Cookie"`. Weitere Informationen finden Sie unter [Response Cache-Control-Direktiven](https://tools.ietf.org/html/rfc7234#section-5.2.2) im *Hypertext Transfer Protocol (HTTP/1.1): Caching* Standard.
**Maximallänge von Cookie-Namen**
Wenn Sie CloudFront so konfigurieren, dass bestimmte Cookies an Ihren Ursprung weitergeleitet werden, darf die Gesamtzahl der Bytes in allen Cookie-Namen, die von CloudFront weitergeleitet werden sollen, 512 minus der Anzahl der Cookies, die Sie weiterleiten, nicht überschreiten. Wenn Sie CloudFront beispielsweise so konfigurieren, dass 10 Cookies an Ihren Ursprung weitergeleitet werden, darf die Gesamtlänge der Namen der 10 Cookies nicht größer sein als 502 Bytes (512–10).
Wenn Sie CloudFront so konfigurieren, dass alle Cookies an Ihren Ursprung weitergeleitet werden, ist die Länge der Cookie-Namen unerheblich.
Weitere Informationen zur Verwendung der CloudFront-Konsole zum Aktualisieren einer Verteilung, damit CloudFront Cookies an den Ursprung weiterleitet, finden Sie unter [Eine Verteilung aktualisieren](HowToUpdateDistribution.md). Informationen zur Verwendung der CloudFront-API zum Aktualisieren einer Verteilung finden Sie unter [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) in der *Amazon CloudFront API-Referenz*.
# Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern
In CloudFront können Sie wählen, ob CloudFront Header an Ihren Ursprung weiterleiten und separate Versionen Ihrer Objekte basierend auf Cookiewerten in Viewer-Anforderungen zwischenspeichern soll. Auf diese Weise können Sie auf der Grundlage des Geräts, das der Benutzers verwendet, des Standorts des Viewers, der Spracheinstellung des Viewers und einer Vielzahl anderer Kriterien unterschiedliche Versionen Ihrer Inhalte bereitstellen.
**Topics**
+ [Header und Verteilungen – Übersicht](#header-caching-web)
+ [Auswählen der Header, auf denen die Zwischenspeicherung basieren soll](#header-caching-web-selecting)
+ [Konfigurieren der Beachtung von CORS-Einstellungen durch CloudFront](#header-caching-web-cors)
+ [Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp](#header-caching-web-device)
+ [Konfigurieren der Zwischenspeicherung basierend auf der Sprache des Viewers](#header-caching-web-language)
+ [Konfigurieren der Zwischenspeicherung basierend auf dem Standort des Viewers](#header-caching-web-location)
+ [Konfigurieren der Zwischenspeicherung basierend auf dem Protokoll der Anforderung](#header-caching-web-protocol)
+ [Konfigurieren der Zwischenspeicherung für komprimierte Dateien](#header-caching-web-compressed)
+ [Auswirkungen der Zwischenspeicherung auf der Grundlage von Headern auf die Leistung](#header-caching-web-performance)
+ [Auswirkungen der Schreibweise von Headern und Header-Werten auf die Zwischenspeicherung](#header-caching-web-case)
+ [Von CloudFront an den Viewer zurückgegebene Header](#header-caching-web-response)
## Header und Verteilungen – Übersicht
Standardmäßig berücksichtigt CloudFront keine Header bei der Zwischenspeicherung Ihrer Objekte an Edge-Standorten. Wenn Ihr Ursprung zwei Objekte zurückgibt, die sich nur durch die Werte in den Anforderungs-Headern unterscheiden, speichert CloudFront nur eine Version des Objekts zwischen.
Sie können CloudFront so konfigurieren, dass Header an den Ursprung weitergeleitet werden. Dies bewirkt, dass CloudFront mehrere Versionen eines Objekts auf der Grundlage der Werte in einem oder mehreren Anforderungs-Headern zwischenspeichert. Um CloudFront so zu konfigurieren, dass es Objekte basierend auf den Werten bestimmter Header im Cache speichert, geben Sie Einstellungen für das Cache-Verhalten für Ihre Verteilung vor. Weitere Informationen finden Sie unter [Cache-Speicherung basierend auf ausgewählten Anforderungs-Headern](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders).
Nehmen wir beispielsweise an, dass Viewer-Anforderungen für `logo.jpg` einen benutzerdefinierten `Product`-Header enthalten, der entweder den Wert `Acme` oder `Apex` hat. Wenn Sie CloudFront so konfigurieren, dass Ihre Objekte auf der Grundlage des Werts des `Product`-Headers zwischengespeichert werden, leitet CloudFront Anforderungen für `logo.jpg` an den Ursprung weiter und fügt den `Product`-Header und die Header-Werte ein. CloudFront speichert `logo.jpg` einmal für Anforderungen zwischen, in denen der Wert des `Product`-Headers `Acme` ist, und einmal für Anforderungen, bei denen der Wert `Apex` ist.
Sie können jedes Cache-Verhalten in einer Verteilung so konfigurieren, dass eine der folgenden Aktionen ausgeführt wird:
+ Weiterleiten aller Header an Ihren Ursprung
**Anmerkung**
**Für Legacy-Cache-Einstellungen** – Wenn Sie CloudFront so konfigurieren, dass alle Header an Ihren Ursprung weitergeleitet werden, speichert CloudFront die Objekte bei diesem Cache-Verhalten nicht zwischen. Stattdessen werden alle Anfragen an den Ursprung gesendet.
+ Weiterleiten einer Liste von Headern, die Sie festlegen. CloudFront speichert Ihre Objekte auf der Grundlage der Werte in den Headern zwischen. Außerdem leitet CloudFront die standardmäßig weitergeleiteten Header weiter, aber speichert Ihre Objekte ausschließlich auf der Grundlage der Header, die Sie angeben.
+ Weiterleiten nur der Standard-Header. Bei dieser Konfiguration speichert CloudFront Ihre Objekte nicht auf der Grundlage der Werte im Anforderungs-Header zwischen.
Informationen zum aktuellen Kontingent für die Anzahl von Headern, die Sie für jedes Cache-Verhalten weiterleiten können, oder zum Anfordern eines höheren Kontingents finden Sie unter [Kontingente für Header](cloudfront-limits.md#limits-custom-headers).
Weitere Informationen zur Verwendung der CloudFront-Konsole zum Aktualisieren einer Verteilung, damit CloudFront Header an den Ursprung weiterleitet, finden Sie unter [Eine Verteilung aktualisieren](HowToUpdateDistribution.md). Informationen zur Verwendung der CloudFront-API zum Aktualisieren einer vorhandenen Verteilung finden Sie unter [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) in der *Amazon CloudFront API-Referenz*.
## Auswählen der Header, auf denen die Zwischenspeicherung basieren soll
Die Header, die Sie an den Ursprung weiterleiten können und auf deren Grundlage die Zwischenspeicherung in CloudFront erfolgt, hängen davon ab, ob es sich bei Ihrem Ursprung um einen Amazon S3-Bucket oder um einen benutzerdefinierten Ursprung handelt.
+ **Amazon S3** – Sie können CloudFront so konfigurieren, dass Ihre Objekte basierend auf einer Reihe von bestimmten Headern weitergeleitet und zwischengespeichert werden (siehe die folgende Liste der Ausnahmen). Allerdings empfehlen wir, möglichst keine Header mit einem Amazon-S3-Ursprung weiterzuleiten, es sei denn, Sie implementieren Cross-Origin Resource Sharing (CORS, ursprungsübergreifende gemeinsame Nutzung von Ressourcen) oder möchten Inhalte mit Lambda@Edge in Ereignissen auf Ursprungsseite personalisieren.
+ Zum Konfigurieren von CORS müssen Sie Header weiterleiten, die CloudFront erlauben, Inhalte für Websites zu verteilen, die für Cross-Origin Resource Sharing (CORS, ursprungsübergreifende gemeinsame Nutzung von Ressourcen) aktiviert sind. Weitere Informationen finden Sie unter [Konfigurieren der Beachtung von CORS-Einstellungen durch CloudFront](#header-caching-web-cors).
+ Um Inhalte mithilfe von Headern zu personalisieren, die Sie an Ihren Amazon S3-Ursprung weiterleiten, schreiben und fügen Sie Lambda@Edge-Funktionen hinzu und ordnen diese Ihrer CloudFront-Verteilung zu, damit sie durch ein Ereignis auf Ursprungsseite ausgelöst werden. Weitere Informationen zum Verwenden von Headern, um Inhalte zu personalisieren, finden Sie unter [Personalisieren von Inhalten nach Land oder Gerätetyp-Header – Beispiele](lambda-examples.md#lambda-examples-redirecting-examples).
Wir empfehlen, möglichst keine Header weiterzuleiten, die Sie nicht zum Personalisieren von Inhalten verwenden, da das Weiterleiten zusätzlicher Header zu einer Verringerung der Cache-Trefferrate führen kann. Das bedeutet, dass CloudFront nicht in der Lage ist, mehr Anfragen über Edge-Caches zu verarbeiten als einen Anteil aller Anfragen.
+ **Benutzerdefinierter Ursprung ** – Sie können CloudFront so konfigurieren, dass die Zwischenspeicherung auf der Grundlage des Werts eines beliebigen Anforderungs-Headers erfolgt, mit Ausnahme der folgenden:
+ `Connection`
+ `Cookie` – Wenn die Weiterleitung und Zwischenspeicherung auf der Grundlage von Cookies erfolgen soll, verwenden Sie eine separate Einstellung in Ihrer Verteilung. Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Cookies](Cookies.md).
+ `Host (for Amazon S3 origins)`
+ `Proxy-Authorization`
+ `TE`
+ `Upgrade`
Sie können CloudFront so konfigurieren, dass Objekte auf der Grundlage von Werten in den Headern `Date` und `User-Agent` zwischengespeichert werden; dies wird jedoch nicht empfohlen. Diese Header können eine Vielzahl möglicher Werte enthalten; das Zwischenspeichern auf Basis dieser Werte würde dazu führen, dass wesentlich mehr Anforderungen von CloudFront an Ihren Ursprungs-Server weitergeleitet werden.
Eine vollständige Liste der HTTP-Anfrage-Header und Informationen dazu, wie CloudFront diese verarbeitet, finden Sie unter [Header und CloudFront Verhalten von HTTP-Anfragen (benutzerdefiniert und Amazon S3 S3-Ursprünge)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior).
## Konfigurieren der Beachtung von CORS-Einstellungen durch CloudFront
Wenn Sie Cross-Origin Resource Sharing (CORS) auf einem Amazon S3-Bucket oder einem benutzerdefinierten Ursprung aktiviert haben, müssen Sie bestimmte Header zum Weiterleiten auswählen, um die CORS-Einstellungen zu berücksichtigen. Die Header, die Sie weiterleiten müssen, sind abhängig vom Ursprung (Amazon S3 oder benutzerdefiniert) und von der Tatsache, ob Sie `OPTIONS`-Antworten zwischenspeichern möchten, unterschiedlich.
**Amazon-S3**
+ Wenn Sie möchten, dass `OPTIONS`-Antworten im Cache gespeichert werden, führen Sie die folgenden Schritte aus:
+ Wählen Sie die Optionen für die Standardeinstellungen für das Cache-Verhalten aus, mit denen das Zwischenspeichern von `OPTIONS`-Antworten aktiviert wird.
+ Konfigurieren Sie CloudFront so, dass die folgenden Header weitergeleitet werden: `Origin`, `Access-Control-Request-Headers` und `Access-Control-Request-Method`.
+ Wenn Sie nicht möchten, dass `OPTIONS`-Antworten im Cache gespeichert werden, konfigurieren Sie CloudFront so, dass der `Origin`-Header zusammen mit allen Headern, die für Ihren Ursprung erforderlich sind, weitergeleitet wird (z. B. `Access-Control-Request-Headers`, `Access-Control-Request-Method` oder andere).
**Benutzerdefinierte Ursprünge** – Leiten Sie den `Origin`-Header zusammen mit anderen Headern weiter, die für Ihren Ursprung erforderlich sind.
Um CloudFront so zu konfigurieren, dass Antworten basierend auf CORS gespeichert werden, müssen Sie CloudFront so konfigurieren, dass Header mithilfe einer Cache-Richtlinie weitergeleitet werden. Weitere Informationen finden Sie unter [Steuern des Cache-Schlüssels mit einer Richtlinie](controlling-the-cache-key.md).
Weitere Informationen zu CORS und Amazon S3 finden Sie unter [Cross-Origin Resource Sharing (CORS) verwenden](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*.
## Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp
Wenn Sie möchten, dass CloudFront verschiedene Versionen Ihrer Objekte basierend auf dem von einem Benutzer für die Anzeige Ihrer Inhalte verwendeten Gerät zwischenspeichert, konfigurieren Sie CloudFront so, dass der entsprechende Header an Ihren benutzerdefinierten Ursprung weitergeleitet wird:
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`
Basierend auf dem Wert des `User-Agent`-Headers setzt CloudFront den Wert dieser Header auf `true` oder `false`, bevor die Anforderung an Ihren Ursprung weitergeleitet wird. Wenn ein Gerät in mehr als eine Kategorie fällt, können mehrere Werte sei `true`. Beispielsweise setzt CloudFront bei einigen Tablet-Geräten möglicherweise `CloudFront-Is-Mobile-Viewer` und `CloudFront-Is-Tablet-Viewer` auf `true`.
## Konfigurieren der Zwischenspeicherung basierend auf der Sprache des Viewers
Wenn Sie möchten, dass CloudFront verschiedene Versionen Ihrer Objekte auf der Grundlage der Sprache zwischenspeichert, die in der Anforderung angegeben ist, konfigurieren Sie CloudFront so, dass der `Accept-Language`-Header an Ihren Ursprung weitergeleitet wird.
## Konfigurieren der Zwischenspeicherung basierend auf dem Standort des Viewers
Wenn Sie möchten, dass CloudFront verschiedene Versionen Ihrer Objekte auf der Grundlage des Landes zwischenspeichert, aus dem die Anforderung, konfigurieren Sie CloudFront so, dass der `CloudFront-Viewer-Country`-Header an Ihren Ursprung weitergeleitet wird. CloudFront konvertiert automatisch die IP-Adresse, über welche die Anforderung erfolgte, in einen zweistelligen Ländercode. Eine benutzerfreundliche Liste der Ländercodes, die nach Code und Ländername sortiert werden kann, finden Sie im Wikipedia-Eintrag [ISO 3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2).
## Konfigurieren der Zwischenspeicherung basierend auf dem Protokoll der Anforderung
Wenn Sie möchten, dass CloudFront abhängig vom Anforderungsprotokoll (HTTP oder HTTPS) verschiedene Versionen Ihrer Objekte zwischenspeichert, konfigurieren Sie CloudFront so, dass der `CloudFront-Forwarded-Proto`-Header an Ihren Ursprung weitergeleitet wird.
## Konfigurieren der Zwischenspeicherung für komprimierte Dateien
Wenn Ihr Ursprung die Brotli-Komprimierung unterstützt, können Sie die Zwischenspeicherung basierend auf dem `Accept-Encoding`-Header durchführen. Konfigurieren Sie die Zwischenspeicherung nur dann basierend auf `Accept-Encoding`, wenn Ihr Ursprungs-Server abhängig vom Header unterschiedliche Inhalte bereitstellt.
## Auswirkungen der Zwischenspeicherung auf der Grundlage von Headern auf die Leistung
Wenn Sie CloudFront so konfigurieren, dass eine Zwischenspeicherung basierend auf einem oder mehreren Headern erfolgt, und die Header mehr als einen möglichen Wert enthalten, leitet CloudFront mehr Anforderungen für dasselbe Objekt an Ihren Ursprungs-Server weiter. Dadurch wird die Leistung verringert und die Last auf Ihrem Ursprungs-Server erhöht. Wenn Ihr Ursprungs-Server unabhängig vom Wert eines bestimmten Headers das gleiche Objekt zurückgibt, empfehlen wir, CloudFront nicht so zu konfigurieren, dass eine Zwischenspeicherung auf der Grundlage von diesem Header erfolgt.
Wenn Sie CloudFront so konfigurieren, dass mehr als ein Header weitergeleitet wird, wirkt sich die Reihenfolge der Header in Viewer-Anforderungen nicht auf die Zwischenspeicherung aus, solange die Werte identisch sind. Wenn beispielsweise eine Anforderung die Header A:1,B:2 und eine andere Anforderung B:2,A:1 enthält, speichert CloudFront nur eine Kopie des Objekts zwischen.
## Auswirkungen der Schreibweise von Headern und Header-Werten auf die Zwischenspeicherung
Wenn die Zwischenspeicherung in CloudFront auf der Grundlage von Header-Werten erfolgt, wird die Schreibweise des Header-Namens nicht berücksichtigt, die Schreibweise des Header-Werts hingegen schon:
+ Wenn Viewer-Anforderungen sowohl `Product:Acme` als `product:Acme` enthalten, speichert CloudFront ein Objekt nur einmal zwischen. Der einzige Unterschied zwischen ihnen ist die Schreibweise des Header-Namens, die sich nicht auf die Zwischenspeicherung auswirkt.
+ Wenn Viewer-Anforderungen sowohl `Product:Acme` als auch `Product:acme` enthalten, speichert CloudFront ein Objekt zweimal zwischen, da der Wert in einigen Anforderungen `Acme` und in anderen `acme` ist.
## Von CloudFront an den Viewer zurückgegebene Header
Wenn CloudFront so konfiguriert wird, dass Header weitergeleitet und zwischengespeichert werden, wirkt sich dies nicht darauf aus, welche Header CloudFront an den Viewer zurückgibt. CloudFront gibt alle Header zurück, die es vom Ursprung abruft, mit einigen wenigen Ausnahmen: Weitere Informationen finden Sie im entsprechenden Thema:
+ **Amazon S3-Ursprünge – ** siehe [HTTP-Antwort-Header, die CloudFront entfernt oder aktualisiert werden](RequestAndResponseBehaviorS3Origin.md#response-s3-removed-headers).
+ **Benutzerdefinierte Ursprünge – ** Siehe [HTTP-Antwort-Header, die CloudFront entfernen oder ersetzen](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomRemovedHeaders).