Amazon CloudFront – Häufig gestellte Fragen

Mit CloudFront können Sie Ihre Inhalte über ein globales Netzwerk aus Rechenzentren, die als Edge-Standorte bezeichnet werden, bereitstellen. Die regionalen Edge-Caches befinden sich zwischen Ihrem Ursprungs-Webserver und den globalen Edge-Standorten, die Inhalte direkt an Ihre Betrachter weiterleiten. Auf diese Weise wird die Leistung Ihrer Betrachter verbessert und gleichzeitig der Betriebsaufwand sowie die Kosten für die Skalierung Ihrer Ursprungsressourcen verringert.

Amazon CloudFront besitzt mehrere global verteilte Regional Edge Caches (oder RECs), die eine zusätzliche Caching-Ebene nahe des Endbenutzers bereitstellen. Diese Standorte befinden sich zwischen Ihrem Ursprungs-Webserver und den globalen AWS-Edge-Standorten, die Inhalte direkt an Ihre Benutzer weiterleiten. Da zwischengespeicherte Objekte immer unbeliebter werden, ist es möglich, dass einzelne Edge-Standorte diese Objekte entfernen, um Platz für beliebtere Inhalte zu schaffen. Regionale Edge-Caches haben eine größere Cache-Breite als die einzelnen Edge-Speicherorte, sodass Ihre Objekte an diesen Speicherorten länger zwischengespeichert werden. Auf diese Weise bleiben mehr Inhalte in der Nähe der Betrachter und CloudFront muss nicht zu Ihrem Ursprungs-Webserver zurückkehren, sodass sich die Gesamtleistung für die Betrachter verbessert. So greifen die CloudFront-Edge-Standorte in Europa jetzt auf den regionalen Edge-Cache in Frankfurt zu, um ein Objekt abzurufen, bevor sie zu Ihrem Ursprungs-Webserver zurückkehren. Regionale Edge-Cache-Standorte können mit jeder Quelle verwendet werden, wie etwa S3, EC2 oder benutzerdefinierten Quellen. RECs werden in Regionen übersprungen, die aktuell Ihre Anwendungsquellen hosten.

Ja. Sie müssen keine Änderungen an Ihren CloudFront-Verteilungen vornehmen; diese Funktion ist standardmäßig für alle neuen und vorhandenen CloudFront-Verteilungen aktiviert. Für diese Funktion fallen keine zusätzlichen Gebühren an.

Amazon CloudFront verwendet ein globales Netzwerk von Edge-Standorten sowie regionale Edge-Caches für die Bereitstellung von Inhalten. Eine vollständige Liste der Amazon-CloudFront-Standorte finden Sie hier.

Ja. Mithilfe der Geo-Einschränkungsfunktion können Sie eine Liste von Ländern angeben, in denen Ihre Benutzer auf Ihre Inhalte zugreifen können. Alternativ ist die Angabe von Ländern möglich, in denen nicht auf Ihre Inhalte zugegriffen werden kann. In beiden Fällen antwortet CloudFront auf eine Anforderung von einem Betrachter in einem eingeschränkten Land mit einem HTTP-Statuscode 403 (Unzulässig).

Die Genauigkeit zwischen IP-Adresse und Länderlisten-Datenbank ist regionsabhängig unterschiedlich. Gemäß letzten Tests beträgt unsere Gesamtgenauigkeit für die Zuordnung von IP-Adresse zum Land 99,8 %.

Ja. Sie können benutzerdefinierte Fehlermeldungen (zum Beispiel eine HTML-Datei oder eine JPG-Grafik) mit Ihrem eigenen Branding und Inhalte für eine Reihe von HTTP 4xx- und 5xx-Antworten erstellen. Danach können Sie Amazon CloudFront so konfigurieren, dass Ihre benutzerdefinierten Fehlermeldungen an den Betrachter zurückgegeben werden, wenn Ihr Ursprung einen der angegebenen Fehler an CloudFront zurückgibt.

Wenn kein Cache-Kontroll-Header festgelegt ist und eine Anforderung mehr als 24 Stunden nach der letzten Überprüfung des Ursprungs auf Änderungen an der Datei erfolgt, sucht jeder Edge-Standort standardmäßig nach einer aktualisierten Version Ihrer Datei. Dieser Zeitraum wird "Ablaufzeitraum" genannt. Sie können den Ablaufzeitraum beliebig zwischen null Sekunden und jeder anderen Zeitspanne wählen, indem Sie die Cache-Kontroll-Header der Dateien auf Ihrem Ursprung entsprechend einstellen. Amazon CloudFront bestimmt anhand der Cache-Kontroll-Header, wie häufig der Ursprung auf eine aktuelle Version der Datei überprüft werden muss. Wenn der Ablaufzeitraum auf 0 Sekunden festgelegt ist, bestätigt Amazon CloudFront jede Anforderung erneut beim Ursprungsserver. Wenn sich Ihre Dateien nicht häufig ändern, empfiehlt es sich, einen langen Ablaufzeitraum zu wählen und ein Versionierungssystem zum Verwalten von Dateiaktualisierungen einzuführen.

Es gibt mehrere Möglichkeiten, eine Datei aus den Edge-Standorten zu entfernen. Sie können die Datei einfach von Ihrem Ursprung löschen. Wenn die Inhalte die an den Edge-Standorten den in den HTTP-Headern der einzelnen Objekte definierte Ablauffrist erreichen, werden sie entfernt. Falls beleidigende oder potenziell gefährliche Materialien vor der angegebenen Ablaufzeit entfernt werden müssen, können Sie mit der Aufhebungs-API das Objekt von allen Amazon CloudFront-Edge-Standorten entfernen. Die Tarife für Aufhebungsanforderungen finden Sie hier.

Wenn Sie Objekte einzeln aufheben, können Sie pro aktiver Verteilung Aufhebungsanforderungen für bis zu 3 000 Objekte gleichzeitig haben. Hierbei kann es sich um eine Aufhebungsanforderung für bis zu 3 000 Objekte, bis zu 3 000 Anforderungen für je ein Objekt oder jede weitere Kombination handeln, die 3 000 Objekte nicht übersteigt.

Wenn Sie den Platzhalter * verwenden, können Sie Anforderungen für bis zu 15 aktive Aufhebungspfade gleichzeitig haben. Sie können auch Aufhebungsanforderungen für bis zu 3 000 Objekte pro aktiver Verteilung gleichzeitig haben. Die Beschränkung für Platzhalter-Aufhebungsanfragen ist unabhängig von der Beschränkung für die Aufhebung einzelner Objekte. Wenn diese Beschränkung überschritten wird, erhalten Sie eine Fehlermeldung, bis eine der zuvor durchgeführten Anforderungen abgeschlossen ist.

Sie sollten die Aufhebung nur unter unerwarteten Umständen durchführen. Wenn Sie bereits im Voraus wissen, dass Ihre Dateien regelmäßig aus dem Zwischenspeicher entfernt werden müssen, empfiehlt es sich, ein Versionierungssystem einzuführen und/oder einen kurzen Ablaufzeitraum festzulegen.

Bei den eingebetteten Points of Presence (PoPs) von CloudFront handelt es sich um eine Art von CloudFront-Infrastruktur, die in den Netzwerken von Internetdienstanbietern (ISP) und Mobilfunkbetreibern (MNO) in der Nähe der Endnutzer bereitgestellt wird. Eingebettete PoPs sind speziell für die Bereitstellung umfangreicher Live-Streaming-Events, Video-on-Demand (VOD) und Spiele-Downloads konzipiert. Diese eingebetteten PoPs gehören Amazon und werden von Amazon betrieben. Sie werden auf der letzten Meile der ISP-/MNO-Netzwerke eingesetzt, um Kapazitätsengpässe in überlasteten Netzwerken zu vermeiden, die Endnutzer mit Inhaltsquellen verbinden, wodurch die Leistung verbessert wird.

Eingebettete CloudFront-POPs unterscheiden sich von CloudFront-POPs je nachdem, wo sie bereitgestellt werden und welche Inhalte sie bereitstellen. Eingebettete CloudFront-PoPs werden direkt in ISP- und MNO-Netzwerken bereitgestellt, im Gegensatz zu CloudFront-POPs, die innerhalb des AWS-Netzwerks bereitgestellt werden. Eingebettete POPs wurden speziell für die Bereitstellung von umfangreichem zwischenspeicherbarem Datenverkehr wie Videostreams und Spiele-Downloads entwickelt, wohingegen CloudFront-POPs darauf ausgelegt sind, eine Vielzahl von Workloads bereitzustellen, einschließlich zwischenspeicherbarer und dynamischer Inhalte.

Die eingebetteten POPs von CloudFront sind so konzipiert, dass sie zwischenspeicherbare Inhalte bereitstellen, auf die viele Endnutzer gleichzeitig zugreifen können, wie z. B. umfangreiches Live-Videostreaming, Video-on-Demand und Spiele-Downloads.

Nein, für die Verwendung von eingebetteten CloudFront-POPs fallen keine zusätzlichen Gebühren an.

Eingebettete POPs sind eine Opt-in-Funktion, die für die Bereitstellung von umfangreichem zwischenspeicherbarem Datenverkehr vorgesehen ist. Bitte wenden Sie sich an Ihren AWS-Vertriebsmitarbeiter, um zu prüfen, ob eingebettete POPs für Ihre Workloads geeignet sind.

Nein, Sie müssen keine neue Distribution speziell für eingebettete POPs erstellen. Wenn Ihr Workload geeignet ist, aktiviert CloudFront auf Anfrage eingebettete PoPs für Ihre bestehende Distribution.

Sie müssen sich nicht zwischen eingebetteten CloudFront-POPs oder CloudFront-POPs für die Inhaltsbereitstellung entscheiden. Sobald Ihre CloudFront-Distribution für eingebettete POPs aktiviert ist, verwendet das Routingsystem von CloudFront dynamisch sowohl CloudFront-POPs als auch eingebettete POPs, um Inhalte bereitzustellen und so eine optimale Leistung für Endbenutzer sicherzustellen.

Bitte kontaktieren Sie uns, um mit der Bereitstellung von eingebetteten POPs in Ihrem Netzwerk zu beginnen.

Sie können das eingebettete POP-Portal verwenden, um eingebettete POPs zu verwalten, die in Ihrem Netzwerk bereitgestellt werden. Das eingebettete POP-Portal ist in das AWS Interconnect Portal integriert und bietet eine einheitliche Oberfläche für die einfache Selbstbedienung einer Vielzahl von Aufgaben im Zusammenhang mit dem gesamten Lebenszyklus dieser POPs. Dazu gehören das Anfordern neuer Appliances, das Verfolgen des Anforderungsfortschritts, das Überwachen von Leistungsstatistiken und das Anfordern von Support. Sie können auf das Portal zugreifen, indem Sie sich mit Ihrem PeeringDB-Konto mit Single Sign-On (SSO) authentifizieren.

Ja. Amazon CloudFront (außer die Bereitstellung von Inhalten über CloudFront Embedded POPs) ist im Umfang der Services mit enthalten, die mit PCI-DSS (Payment Card Industry Data Security Standard) auf Händlerlevel 1 (das ist das höchste Kompatibilitätslevel für Serviceanbieter) kompatibel sind. Weitere Informationen finden Sie im Entwicklerhandbuch.

AWS hat sein HIPAA-Compliance-Programm um Amazon CloudFront [außer die Inhaltsbereitstellung über CloudFront Embedded POPs] als HIPAA-fähigen Service erweitert. Wenn Sie ein abgeschlossenes Business Associate Agreement (BAA) mit AWS haben, können Sie Amazon CloudFront [außer die Inhaltsbereitstellung über CloudFront Embedded POPs] verwenden, um die Bereitstellung geschützter Gesundheitsinformationen (PHI) zu beschleunigen. Weitere Informationen finden Sie im Entwicklerhandbuch unter Compliance mit HIPAA.

Amazon CloudFront [außer der Bereitstellung von Inhalten über CloudFront Embedded POPs] entspricht den SOC-Maßnahmen (System & Organization Control). SOC-Berichte sind durch unabhängige Dritte erstellte Prüfberichte, die nachweisen, wie AWS wichtige Compliance-Kontrollen und -Ziele erfüllt. Weitere Informationen finden Sie im Entwicklerhandbuch unter Compliance mit AWS SOC.

Die Berichte AWS SOC 1 und SOC 2 stehen Kunden zur Verfügung, die AWS Artifact, ein Self-Service-Portal, über das Kunden nach Bedarf die Konformitätsberichte zu AWS abrufen können, nutzen. Melden Sie sich bei AWS Artifact in der AWS-Managementkonsole an, oder erfahren Sie mehr unter Erste Schritte mit AWS Artifact. Der neueste Bericht AWS SOC 3 ist der Öffentlichkeit auf der AWS-Website verfügbar.

Amazon CloudFront unterstützt derzeit GET-, HEAD-, POST-, PUT-, PATCH-, DELETE- und OPTIONS-Anforderungen.

Amazon CloudFront speichert Antworten auf POST-, PUT-, DELETE- und PATCH-Anforderungen nicht – diese Anforderungen werden per Proxy an den Ursprungsserver zurückgesendet. Für die Antworten auf OPTIONS-Anforderungen können Sie Caching aktivieren.

Verfügen Sie bereits über eine verteilte Amazon CloudFront-Umgebung, können Sie HTTP/2 mithilfe der API oder der Management Console aktivieren. Navigieren Sie in der Konsole zu der Seite mit der Verteilungskonfiguration und suchen Sie den Bereich "Unterstützte HTTP-Versionen". Dort können Sie "HTTP/2", "HTTP/1.1" oder "HTTP/1.0" auswählen. HTTP/2 wird für alle neuen CloudFront-Verteilungen automatisch aktiviert.

Amazon CloudFront unterstützt derzeit HTTP/2 für die Bereitstellung von Inhalten für die Browser und Clients Ihrer Betrachter. Für die Kommunikation zwischen Edge-Standorten und Ihren Ursprungs-Servern verwendet Amazon CloudFront weiterhin HTTP/1.1.

Derzeit nicht. Die meisten modernen Browser unterstützen HTTP/2 jedoch nur über eine verschlüsselte Verbindung. Weitere Informationen zur Verwendung von SSL mit Amazon CloudFront finden Sie hier.

HTTP/3 ist die dritte Hauptversion des Hypertext Transfer Protocol. HTTP/3 verwendet QUIC, ein auf dem User-Datagram-Protokoll (UDP) und Stream-Multiplexing basierendes und sicheres Transportprotokoll, das die Fähigkeiten bestehender Übertragungssteuerungsprotokolle (TCP), TLS und HTTP/2 kombiniert und verbessert. HTTP/3 bietet mehrere Vorteile gegenüber vorherigen HTTP-Versionen, darunter schnellere Reaktionszeiten und verbesserte Sicherheit.

HTTP/3 basiert auf QUIC, einem neuen, hochleistungsfähigen, widerstandsfähigen und sicheren Internet-Transportprotokoll. Die HTTP/3-Unterstützung von CloudFront baut auf s2n-quic auf, einer neuen quelloffenen QUIC-Protokollimplementierung in Rust. Weitere Informationen über QUIC, finden Sie im Blog „Einführung in s2n-quic“. 

Kunden suchen ständig nach Wegen, Endbenutzern schnellere und sicherere Anwendungen bereitzustellen. Da die Internetverwendung global steigt und sich immer mehr Benutzer mit Mobilgeräten von Fernnetzwerken aus verbinden, sind bessere Performance und Zuverlässigkeit wichtiger denn je. HTTP/3 ermöglicht dies, da es mehrere Leistungsverbesserungen gegenüber früheren HTTP-Versionen bietet:

1. Schnellere und zuverlässigere Verbindungen – CloudFront verwendet 1-RTT für den TLS-Handshake für HTTP/3, wodurch sich die Zeit für den Verbindungsaufbau verkürzt und die Anzahl der Handshake-Fehler im Vergleich zu früheren HTTP-Versionen entsprechend verringert.
2. Bessere Web-Performance – Die HTTP/3-Implementierung von CloudFront unterstützt clientseitige Verbindungsmigrationen, so dass sich Client-Anwendungen bei schlechten Verbindungen mit minimalen Unterbrechungen erholen können. Im Gegensatz zu TCP ist QUIC nicht verlustfrei, so dass es sich besser für überlastete Netzwerke mit hohen Paketverlusten eignet. Außerdem ermöglicht QUIC eine schnellere Wiederherstellung der Verbindung bei der Übergabe von Wifi- oder Mobilfunkverbindungen.
3. Sicherheit – HTTP/3 bietet im Vergleich zu früheren Versionen von HTTP eine umfassendere Sicherheit, indem es die während des TLS-Handshakes ausgetauschten Pakete verschlüsselt. Dies erschwert die Inspektion durch Middleboxen, bietet zusätzlichen Datenschutz und reduziert Man-in-the-Middle-Angriffe. Die HTTP/3-Unterstützung von CloudFront baut auf s2n-quic und Rust auf, die einen Schwerpunkt auf Effizienz und Performance legen.
    

Sie können HTTP/3 für neue und bestehende Amazon-CloudFront-Verteilungen über die CloudFront-Konsole, die UpdateDistribution-API-Aktion oder über eine Cloudformation-Vorlage einschalten. Navigieren Sie in der Konsole zu der Seite mit der Verteilungskonfiguration und suchen Sie den Bereich "Unterstützte HTTP-Versionen". Dort können Sie „HTTP/3“, „HTTP/2“ oder „HTTP/1.1“ oder „HTTP/1.0“ auswählen.

Wenn Sie HTTP/3 auf Ihrer CloudFront-Verteilung aktivieren, fügt CloudFront automatisch den Alt-Svc-Header hinzu, mit dem es ankündigt, dass HTTP/3-Unterstützung verfügbar ist und Sie müssen den Alt-Svc-Header nicht manuell hinzufügen. Wir erwarten, dass Sie in Ihren Anwendungen die Unterstützung für mehrere Protokolle aktivieren, so dass die Anwendung, wenn sie keine HTTP/3-Verbindung herstellen kann, auf HTTP/1.1 oder HTTP/2 zurückgreift. D.h., Clients, die HTTP/3 nicht unterstützen, können weiterhin mit HTTP/3-fähigen CloudFront-Verteilungen über HTTP/1.1 oder HTTP/2 kommunizieren. Die Fallback-Unterstützung ist ein erforderlicher Bestandteil der HTTP/3-Spezifikation und wird von allen wichtigen Browsern, die HTTP/3 unterstützen, implementiert.

CloudFront unterstützt derzeit HTTP/3 für die Kommunikation zwischen den Clients/Browsern Ihrer Betrachter und den CloudFront-Edge-Standorten. Für die Kommunikation zwischen Edge-Standorten und Ihren Ursprungsservern verwendet CloudFront weiterhin HTTP/1.1.

HTTP/3 verwendet QUIC, das TLSv1.3 erfordert. Daher können unabhängig von der von Ihnen gewählten Sicherheitsrichtlinie nur TLSv1.3 und die unterstützten TLSv1.3 Cipher Suites zum Aufbau von HTTP/3-Verbindungen verwendet werden. Weitere Einzelheiten finden Sie im Abschnitt „Unterstützte Protokolle und Verschlüsselungen zwischen Viewern und CloudFront“ im CloudFront-Entwicklerhandbuch.

Nein, für die Aktivierung von HTTP/3 auf Amazon-CloudFront-Verteilungen fallen keine gesonderten Kosten an. HTTP/3-Anfragen werden zu den Tarifen Ihres Preisplans abgerechnet.

WebSocket ist ein Protokoll für die Echtzeitkommunikation, das eine bidirektionale Kommunikation zwischen einem Client und einem Server über eine lange ausgeführte TCP-Verbindung ermöglicht. Durch die Verwendung einer persistenten offenen Verbindung können sich der Client und der Server Daten in Echtzeit senden, ohne dass der Client häufig Verbindungen neu initiieren muss, um Prüfungen auf neue Daten zum Austausch auszuführen. WebSocket-Verbindungen werden häufig für Chat-Anwendungen, Plattformen für die Zusammenarbeit, Multiplayer-Spiele und Plattformen für Finanztransaktionen verwendet. Lesen Sie unsere Dokumentation, um mehr über die Verwendung des WebSocket-Protokolls mit Amazon CloudFront zu erfahren. 

Sie können WebSockets global verwenden. Es ist kein zusätzlicher Konfigurationsaufwand erforderlich, um das WebSocket-Protokoll innerhalb Ihrer CloudFront-Ressource zu aktivieren, da es nun standardmäßig unterstützt wird.

Amazon CloudFront stellt WebSocket-Verbindungen nur dann her, wenn der Client den Header 'Upgrade: Websocket' enthält und der Server mit dem HTTP-Statuscode 101 antwortet, der bestätigt, dass er zum WebSocket-Protokoll wechseln kann.

Ja. Amazon CloudFront unterstützt verschlüsselte WebSocket-Verbindungen (WSS) mit dem SSL/TLS-Protokoll.

Standardmäßig können Sie Ihren Betrachtern Inhalte über HTTPS bereitstellen, indem Sie den Domain-Namen Ihrer CloudFront-Verteilung in Ihren URLs verwenden, zum Beispiel "https://dxxxxx.cloudfront.net/image.jpg". Wenn Sie Ihre Inhalte über HTTPS unter Verwendung Ihres eigenen Domain-Namens und Ihres eigenen SSL-Zertifikats bereitstellen möchten, stehen Ihnen unsere Funktionen zur Unterstützung benutzerdefinierter SSL-Zertifikate zur Verfügung. Weitere Informationen.

Die Verschlüsselung auf Feldebene ist eine Funktion in CloudFront, mit der Sie von Benutzern eingesendete Daten wie Kreditkartennummern sicher auf Ihre Ursprungsserver hochladen können. Mit dieser Funktion können Sie sensible Daten zusätzlich in einem HTTPS-Formular mit feldspezifischen Verschlüsselungsschlüsseln (die Sie angeben) verschlüsseln, bevor eine PUT/POST-Anforderung an Ihren Ursprung weitergeleitet wird. Dadurch wird sichergestellt, dass vertrauliche Daten nur von bestimmten Komponenten oder Services in Ihrem Anwendungs-Stack entschlüsselt und angezeigt werden können. Weitere Informationen zur Verschlüsselung auf Feldebene finden Sie in unserer Dokumentation im Abschnitt Verschlüsselung auf Feldebene.

Viele Webanwendungen sammeln vertrauliche Daten von Benutzern wie Kreditkartennummern, die dann von Anwendungs-Services verarbeitet werden, die auf der Ursprungsinfrastruktur ausgeführt werden. Alle diese Webanwendungen verwenden SSL/TLS-Verschlüsselung zwischen dem Endbenutzer und CloudFront sowie zwischen CloudFront und Ihrem Ursprung. Ihr Ursprung könnte mehrere Microservices haben, die auf der Basis von Benutzereingaben kritische Vorgänge ausführen. Sensible Informationen müssen jedoch nur von einer geringen Anzahl dieser Microservices genutzt werden und trotzdem haben die meisten Komponenten direkten Zugriff auf diese Daten, obwohl sie diese gar nicht benötigen. Ein einfacher Programmierfehler, wie zum Beispiel das Protokollieren einer falschen Variable, kann bereits dazu führen, dass die Kreditkartennummer eines Kunden in eine Datei geschrieben wird.

Mit der Verschlüsselung auf Feldebene können die Edge-Standorte von CloudFront die Kreditkartendaten verschlüsseln. Ab diesem Zeitpunkt können nur Anwendungen mit den privaten Schlüsseln die vertraulichen Felder entschlüsseln. Der Auftragsbearbeitungsservice kann also nur verschlüsselte Kreditkartennummern anzeigen, aber die ZahlungsServices können Kreditkartendaten entschlüsseln. Dies stellt ein höheres Sicherheitsniveau sicher, da die Daten auch dann kryptografisch geschützt bleiben, wenn einer der AnwendungsServices Chiffriertext ausgibt.

Zur Bereitstellung Ihrer SSL-Inhalte an allen CloudFront-Edge-Standorten weist Dedicated IP Custom SSL feste IP-Adressen zu. Da es eine 1:1-Zuordnung zwischen IP-Adressen und SSL-Zertifikaten gibt, funktioniert "Dedicated IP Custom SSL" mit Browsern und anderen Clients, die SNI nicht unterstützen. Aufgrund der derzeitigen Preise für IP-Adressen, betragen die Kosten für "Dedicated IP Custom SSL" auf Stunden umgelegt 600 USD pro Monat.

SNI Custom SSL setzt auf der SNI-Erweiterung des TLS-Protokolls (Transport Layer Security). Diese ermöglicht mehreren Domains die Unterstützung von SSL-Datenverkehr über dieselbe IP-Adresse, indem der Name des Hosts einbezogen wird, mit dem die Betrachter versuchen, eine Verbindung herzustellen. Wie bei "Dedicated IP Custom SSL" stellt CloudFront Inhalte von jedem Amazon CloudFront-Edge-Standort mit derselben Sicherheit bereit. "SNI Custom SSL" funktioniert in den meisten modernen Browsern wie Chrome ab Version 6 (unter Windows XP und höher bzw. OS X 10.5.7 und höher), Safari ab Version 3 (unter Windows Vista und höher bzw. Mac OS X 10.5.6. und höher), Firefox ab Version 2.0 und Internet Explorer ab Version 7 (unter Windows Vista und höher). Ältere Browser ohne SNI-Unterstützung können keine Verbindung mit CloudFront aufbauen, um die HTTPS-Version Ihrer Inhalte zu laden. Für "SNI Custom SSL" fallen neben den standardmäßigen CloudFront-Gebühren für Datenübertragungen und Anforderungen keine weiteren Kosten an.

Server Name Indication (SNI) ist eine Erweiterung des TLS-Protokolls (Transport Layer Security). Dieser Mechanismus bestimmt die Domain (bzw. den Servernamen) der dazugehörigen SSL-Anforderung, damit das ordnungsgemäße Zertifikat beim SSL-Handshake verwendet werden kann. Dadurch kann eine einzelne IP-Adresse auf mehreren Servern genutzt werden. Für SNI muss der Browser den Servernamen hinzufügen können, was von den meisten modernen Browsern unterstützt wird, von wenigen älteren Versionen jedoch nicht. Weitere Informationen finden Sie im CloudFront-Entwicklerhandbuch im Abschnitt „SNI“ oder im Wikipedia-Artikel zu SNI.

Ja. Sie können SSL-/TLS-Zertifikate nun innerhalb weniger Minuten bereitstellen und CloudFront-Verteilungen zuordnen. Verwenden Sie den neuen AWS Certificate Manager (ACM), um ein Zertifikat mit nur wenigen Klicks für Ihre CloudFront-Verteilung bereitzustellen. Danach verwaltet ACM alle Zertifikatverlängerungen für Sie. Mithilfe von ACM können Sie das Zertifikat ohne zusätzliche Gebühren bereitstellen und verwalten.

Die Verwendung von Zertifikaten, die Sie von einer Zertifizierungsstelle eines anderen Anbieters bezogen und in den IAM-Zertifikatspeicher hochgeladen haben, wird von CloudFront weiterhin unterstützt.

Ja. Amazon CloudFront verfügt über eine optionale Funktion für private Inhalte. Wenn diese Option aktiviert ist, überträgt Amazon CloudFront nur dann Dateien, wenn Sie Ihr Einverständnis geben, indem Sie Ihre Anforderungen sicher signieren. Weitere Informationen zu diesem Feature finden Sie im CloudFront-Entwicklerhandbuch.

Als AWS-Kunde erhalten Sie AWS Shield Standard ohne zusätzliche Kosten. AWS Shield ist ein verwalteter Service, der Schutz vor DDoS-Angriffen für Webanwendungen bietet, die unter AWS ausgeführt werden. AWS Shield Standard bietet Schutz für alle AWS Kunden vor verbreiteten und am häufigsten vorkommenden Infrastruktur-Angriffe (Ebene 3 und 4) wie SYN/UDP Floods, Reflection-Angriffe und andere, um die hohe Verfügbarkeit Ihrer Anwendungen unter AWS zu unterstützen.

AWS Shield Advanced ist ein optionaler bezahlter Service, der allen Kunden von AWS Business Support und AWS Enterprise Support zur Verfügung steht. AWS Shield Advanced bietet zusätzlichen Schutz vor größeren und anspruchsvolleren Angriffen für Ihre Anwendungen, die unter Elastic Load Balancing (ELB), Amazon CloudFront und Route 53 ausgeführt werden.

Sie können Ihre CloudFront-Verteilung mit AWS WAF integrieren, einer Firewall für Webanwendungen, die Ihnen auf Grundlage von Regeln zu IP-Adressen, HTTP-Headern und benutzerdefinierten URI-Zeichenfolgen hilft, Ihre Webanwendungen vor Angriffen zu schützen. Anhand dieser Regeln kann AWS WAF Webanforderungen an Ihre Webanwendung blockieren, zulassen oder überwachen (zählen). Weitere Informationen finden Sie im AWS-WAF-Entwicklerhandbuch.

Ja. Sie können Amazon CloudFront so konfigurieren, dass kundenspezifische Header zu Anforderungen, die an Ihren Ursprung weitergeleitet werden, hinzugefügt werden bzw. den Wert vorhandener Header überschreiben. Sie können mithilfe dieser Header prüfen, ob Anforderungen an Ihren Ursprung von CloudFront gesendet wurden. Sie können Ihren Ursprung auch so konfigurieren, dass nur Anforderungen erlaubt sind, die den von Ihnen festgelegten kundenspezifischen Header enthalten. Wenn Sie mehrere CloudFront-Verteilungen mit demselben Ursprung verwenden, können Sie benutzerdefinierte Header auch verwenden, um Ursprungsanforderungen der einzelnen Verteilungen zu unterscheiden. Kundenspezifische Header können außerdem verwendet werden, um zu ermitteln, ob die richtigen CORS-Header für Ihre Abfragen zurückgegeben wurden. Sie können kundenspezifische Header über die CloudFront API und die AWS-Managementkonsole konfigurieren. Für diese Funktion fallen keine zusätzlichen Gebühren an. Weitere Informationen zur Einrichtung kundenspezifischer Header finden Sie hier.

Amazon CloudFront unterstützt die Bereitstellung von dynamischen Inhalten, die mit HTTP-Cookies individuell gestaltet und angepasst werden. Um diese Funktion zu verwenden, geben Sie an, ob Amazon CloudFront einige oder alle Ihrer Cookies an Ihren benutzerdefinierten Ursprungsserver weiterleiten soll. Amazon CloudFront berücksichtigt dann die Werte der weitergeleiteten Cookies bei der Identifikation einzigartiger Objekte in seinem Cache. Auf diese Weise erhalten Ihre Endbenutzer sowohl den Nutzen von für sie mit einem Cookie individuell angepasste Inhalte als auch die Leistungsvorteile von Amazon CloudFront. Sie können auch die Option wählen, die Cookie-Werte in den Amazon CloudFront-Zugriffsprotokollen aufzuzeichnen.

Eine Abfragezeichenfolge kann optional als Teil des Cache-Schlüssels zum Identifizieren von Objekten im Amazon CloudFront-Cache verwendet werden. Dies dient zum Erstellen dynamischer Webseiten (z. B. Suchergebnisse), die ggf. am Edge-Standort für einen bestimmten Zeitraum im Cache zwischengespeichert werden.

Ja. Mithilfe der Positivliste für Abfragezeichenfolgen können Sie Amazon CloudFront ganz einfach so konfigurieren, dass im Cache-Schlüssel nur bestimmte Parameter verwendet werden. Gleichzeitig werden alle Parameter weiterhin an den Ursprung weitergeleitet.

Ja. Sie können Amazon CloudFront so konfigurieren, dass bis zu zehn Abfrageparameter auf die Positivliste gesetzt werden.

Amazon CloudFront unterstützt URI-Abfrageparameter, die in Abschnitt 3.4 des RFC3986 definiert sind. Insbesondere werden Abfrageparameter in HTTP GET-Zeichenfolgen unterstützt, die auf das Zeichen "?" folgen und durch das Zeichen "&" getrennt sind.

Ja. CloudFront kann automatisch Ihre Text- oder Binärdaten komprimieren. Um diese Funktion einzusetzen, geben Sie in den Einstellungen für das Cache-Verhalten an, dass CloudFront Objekte automatisch komprimieren soll, und stellen Sie sicher, dass Ihr Client Accept-Encoding hinzufügt: "gzip" in der Kopfzeile der Anforderung (die meisten modernen Browser tun dies standardmäßig). Weitere Informationen zu diesem Feature finden Sie im Entwicklerhandbuch.

Unter Streaming ist im Allgemeinen die Zustellung von Audio- und Videoinhalten an Endbenutzer über das Internet zu verstehen, ohne dass die Mediendatei vor der Wiedergabe heruntergeladen werden muss. Für das Streaming werden unter anderem Protokolle verwendet, die für die Zustellung HTTP verwenden, beispielsweise HTTP Live Streaming (HLS) von Apple, MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH), HTTP Dynamic Streaming (HDS) von Adobe und Smooth Streaming von Microsoft. Diese Protokolle unterscheiden sich von den denjenigen, die zur Bereitstellung von Webseiten und anderen Online-Inhalten verwendet werden, da Streaming-Protokolle Medien in Echtzeit zustellen – der Betrachter sieht die Bytes, während sie übertragen werden. Das Streaming von Inhalten bietet einige potenzielle Vorteile für Sie und Ihre Endanwender:

• Durch Streaming erhalten Betrachter mehr Kontrolle über das, was sie sehen. Beispielsweise ist es für einen Betrachter bei einem Video mit Streaming einfacher, vorwärts und rückwärts zu spulen, als bei einer herkömmlichen Download-Übertragung.
• Durch Streaming erhalten Sie mehr Kontrolle über Ihre Inhalte, da keine Dateien auf dem Client oder lokalen Laufwerk der Betrachter verbleiben, wenn sie das Video zu Ende gesehen haben.
• Streaming kann Ihnen bei der Kostensenkung helfen, da nur die Teile einer Mediendatei übertragen werden, die sich der Betrachter gerade ansieht. Im Vergleich dazu wird bei herkömmlichen Downloads häufig die gesamte Mediendatei an die Betrachter übermittelt, auch wenn er sich nur einen Teil der Datei ansieht.

Ja. Amazon CloudFront bietet mehrere Optionen für die Übertragung von Videoinhalten auf Abruf. Wenn Sie Mediendateien haben, die beispielsweise mit AWS Elemental MediaConvert vor dem Speichern in Amazon S3 (oder an einem kundenspezifischen Ursprung) in HLS, MPEG-DASH oder Microsoft Smooth Streaming umgewandelt wurden, können Sie mithilfe einer Amazon-CloudFront-Web-Verteilung ein Streaming in diesem Format ausführen, ohne Medienserver betreiben zu müssen.

Alternativ dazu können Sie auch einen Streaming-Server eines anderen Anbieters (z. B. den im AWS Marketplace erhältlichen Wowza Media Server) in Amazon EC2 verwenden, der eine Mediendatei in das gewünschte HTTP-Streaming-Format umwandeln kann. Dieser Server kann anschließend als Ursprung einer Amazon CloudFront-Web-Verteilung zugewiesen werden.

Weitere Informationen finden Sie auf der Seite Video on Demand (VOD) in AWS.

Ja. Sie können das Live-Streaming von Amazon CloudFront mit jedem Service für die Generierung von Live-Videos verwenden, der HTTP-basierte Streams ausgibt, etwa mit AWS Elemental MediaPackage oder AWS Elemental MediaStore. MediaPackage ist ein Videogenerierungs- und Just-in-Time-Paketerstellungsservice, mit dem Vertreiber von Videos unter Verwendung mehrerer Standards für die Bereitstellung und den Schutz von Inhalten auf sichere und zuverlässige Weise Inhalte im großen Stil streamen können. MediaStore ist ein HTTP-Ursprungs- und Speicherservice, der genau die Leistungsstärke, sofortige Konsistenz und vorhersehbare niedrige Latenz bietet, die für Live-Medien erforderlich ist, und sich darüber hinaus durch die Sicherheit und Beständigkeit des Amazon-Speichers auszeichnet.

Weitere Informationen finden Sie auf der Seite Live-Video-Streaming in AWS.

Origin Shield ist eine zentralisierte Cache-Ebene, die Ihnen hilft, Ihre Cache-Trefferrate zu erhöhen, um die Ursprungsserverlast zu reduzieren. Origin Shield verringert ebenfalls Ihre Ursprungsserver-Betriebskosten, indem Anfragen aus mehreren Regionen zusammengefasst werden, sodass nur bis zu eine Anfrage an Ihr Origin pro Objekt geleitet wird. Nach der Aktivierung leitet CloudFront alle Abrufe vom Ursprungsserver über Origin Shield und leitet nur eine Anfrage an Ihren Ursprungsserver, wenn der Inhalt nicht bereits im Origin Shield-Cache gespeichert wird.

Origin Shield ist ideal für Workloads mit Betrachtern in verschiedenen geografischen Regionen oder Workloads, die Just-in-Time-Packaging für Videostreaming, Echtzeit-Bildverarbeitung oder ähnliche Prozesse benötigen. Die Verwendung von Origin Shield vor Ihrem Ursprungsserver reduziert die Anzahl redundanter Ursprungsserverabrufe, indem zunächst der zentrale Cache geprüft wird und konsolidierte Abrufe vom Ursprungsserver nur für Inhalte vorgenommen werden, die nicht bereits im Origin Shield-Cache liegen. Auf ähnliche Weise kann Origin Shield in einer Multi-CDN-Architektur verwendet werden, um die Anzahl doppelter Abrufe vom Ursprungsserver auf mehreren CDNs zu reduzieren, indem Amazon CloudFront als Ursprung für andere CDNs positioniert wird. Weitere Informationen darüber und zu anderen Origin-Shield-Anwendungsfällen finden Sie im Amazon-CloudFront-Entwicklerhandbuch.

Amazon CloudFront bietet Origin Shield in AWS-Regionen, in denen CloudFront einen regionalen Edge-Cache bietet. Wenn Sie Origin Shield aktivieren, sollten Sie die AWS-Region für Origin Shield wählen, die die niedrigste Latenz zu Ihrem Ursprungsserver aufweist. Sie können Origin Shield mit Ursprungsservern verwenden, die sich in AWS-Region befinden oder nicht. Weitere Informationen finden Sie unter Wahl der AWS-Region für Origin Shield im Amazon CloudFront-Entwicklerhandbuch.

Ja. Alle Origin Shield-Regionen bauen auf eine hochverfügbare Architektur auf, die mehrere Verfügbarkeitszonen umfasst, mit Flotten von autoskalierenden Amazon EC2-Instances. Verbindungen von CloudFront-Standorten zu Origin Shield verwenden ebenfalls aktive Fehlernachverfolgung für jede Anforderung, um die Anforderung automatisch an einen sekundären Origin Shield-Standort zu leiten, wenn der primäre Origin Shield-Standort nicht verfügbar ist.

Ja. Füllen Sie hier die Anforderung für höhere Grenzwerte aus und wir versehen Ihr Konto binnen zwei Arbeitstagen mit mehr Kapazität.

Den aktuellen Grenzwert für die Anzahl der Distributionen, die Sie für jedes AWS-Konto erstellen können, finden Sie in der allgemeinen Referenz der Amazon Web Services unter Grenzwerte in Amazon CloudFront. Zur Anforderung eines höheren Grenzwerts füllen Sie bitte das Formular zum Erhöhen des CloudFront-Grenzwerts aus.

Über Amazon CloudFront können Dateien mit einer Maximalgröße von jeweils 30 GB bereitgestellt werden. Diese Größenbeschränkung gilt für alle Amazon CloudFront-Verteilungen.

Beim Erstellen oder Ändern einer CloudFront-Verteilung können Sie die Zugriffsprotokollierung aktivieren. CloudFront bietet zwei Möglichkeiten zur Protokollierung der Anforderungen, die von Ihren Distributionen geliefert werden: Standard-Protokolle und Echtzeit-Protokolle.

CloudFront-Standard-Protokolle werden an den Amazon-S3-Bucket Ihrer Wahl geliefert (Protokoll-Datensätze werden innerhalb von Minuten nach einer Betrachteranfrage geliefert). Wenn aktiviert, veröffentlicht CloudFront automatisch detaillierte Loginformationen in einem erweiterten W3C-Format in einem von Ihnen festgelegten Amazon S3-Bucket. Zugriffslogs enthalten detaillierte Informationen über jede Anforderung nach Ihren Inhalten, unter anderem auch das beantragte Objekt, das Datum und die Zeit der Anforderung, den Edge-Standort, der die Anforderung erfüllt, die Client IP-Adresse, den Verweiser, den Benutzeragent, die Kopfzeile des Cookies und den Ergebnistyp (z. B. Cache-Treffer/Fehlversuch/Fehler). CloudFront erhebt keine Gebühren für Standardlogs, obwohl Ihnen Amazon S3 Gebühren für die Speicherung und den Zugriff auf die Logdateien berechnet.

CloudFront-Echtzeitprotokolle werden an den Datenstrom Ihrer Wahl in Amazon Kinesis Data Streams geliefert (Protokoll-Datensätze werden innerhalb von Sekunden nach einer Betrachteranfrage geliefert). Sie können die Abtastrate für Ihre Echtzeit-Logs wählen, d. h. den Prozentsatz der Anfragen, für die Sie Echtzeit-Logsinträge erhalten möchten. Sie können auch die spezifischen Felder auswählen, die Sie in den Logsätzen erhalten möchten. Die CloudFront-Echtzeitlogs enthalten dieselben Datenpunkte wie die Standardlogs und enthalten darüber hinaus bestimmte zusätzliche Informationen zu jeder Anfrage, wie z. B. die Kopfzeilen der Zuschaueranfragen und den Ländercode, in einem erweiterten W3C-Format. CloudFront Gebühren für Echtzeit-Logs, zusätzlich zu den Gebühren, die Ihnen für die Nutzung von Kinesis Data Streams entstehen.

Sie können je nach Anwendungsfall ein Ziel wählen. Wenn Sie zeitkritische Anwendungsfälle haben und Zugriffsprotokolldaten schnell innerhalb weniger Sekunden benötigen, dann wählen Sie die Echtzeit-Protokolle. Wenn Ihre Echtzeit-Protokoll-Pipeline billiger sein soll, können Sie die Protokolldaten filtern, indem Sie Protokolle nur für bestimmte Cache-Verhalten aktivieren oder eine niedrigere Abtastrate wählen. Die Echtzeit-Protokoll-Pipeline ist für eine schnelle Datenlieferung ausgelegt. Daher können Protokollaufzeichnungen bei Datenverzögerungen entfallen. Wenn Sie andererseits eine kostengünstige Protokollverarbeitungslösung benötigen, die keine Echtzeitdaten erfordert, ist die aktuelle Standardprotokolloption ideal für Sie. Die Standardprotokolle in S3 sind der Vollständigkeit halber erstellt und die Protokolle sind in der Regel in wenigen Minuten verfügbar. Diese Protokolle können für die gesamte Verteilung und nicht für bestimmte Cache-Verhalten aktiviert werden. Wenn Sie also Protokolle für Ad-hoc-Untersuchungen, Audits und Analysen benötigen, können Sie sich dafür entscheiden, nur die Standardprotokolle in S3 zu aktivieren. Sie könnten sich für eine Kombination beider Protokolle entscheiden. Verwenden Sie eine gefilterte Liste von Echtzeit-Protokollen für betriebliche Sichtbarkeit und verwenden Sie dann die Standardprotokolle für die Prüfung.
 

CloudFront Standardprotokolle werden zu Ihrem S3 Bucket geliefert. Sie können auch die Integrationserstellung von Drittanbieter-Lösungen wie DataDog und Sumologic verwenden, um Dashboards aus diesen Protokollen zu erstellen.

Die Echtzeit-Protokolle werden an Ihren Kinesis-Datenstream geliefert. Von Kinesis-Datenstreams können die Protokolle in Amazon Kinesis Data Firehose veröffentlicht werden. Amazon Kinesis Data Firehose unterstützt die einfache Datenübermittlung an Amazon S3, Amazon Redshift, Amazon Elasticsearch Service und Service-Anbieter wie Datadog, New Relic und Splunk. Kinesis Firehose unterstützt auch die Datenlieferung an einen generischen HTTP-Endpunkt.

Verwenden Sie die folgenden Schritte, um die Anzahl der benötigten Shards abzuschätzen:

1. Berechnen (oder schätzen) Sie die Anzahl der Anfragen pro Sekunde, die Ihre CloudFront-Distribution erhält. Sie können die CloudFront-Nutzungsberichte oder die CloudFront-Kennzahlen verwenden, um Ihre Anfragen pro Sekunde zu berechnen.
2. Bestimmen Sie die typische Größe eines einzelnen Echtzeit-Protokollsatzes. Ein typischer Datensatz, der alle verfügbaren Felder enthält, beträgt etwa 1 KB. Wenn Sie nicht sicher sind, wie groß Ihre Log-Datensatzgröße ist, können Sie Echtzeitprotokolle mit einer niedrigen Abtastrate (z. B. 1 %) aktivieren und dann die durchschnittliche Datensatzgröße anhand von Überwachungsdaten in Kinesis-Datenströmen berechnen (Gesamtzahl der Datensätze geteilt durch die Gesamtzahl der eingehenden Bytes).
3. Multiplizieren Sie die Anzahl der Anfragen pro Sekunde (aus Schritt 1) mit der Größe eines typischen Echtzeit-Protokolldatensatzes (aus Schritt 2), um die Datenmenge pro Sekunde zu bestimmen, die Ihre Echtzeit-Protokollkonfiguration wahrscheinlich an den Kinesis-Datenstream senden wird.
4. Berechnen Sie anhand der Daten pro Sekunde die Anzahl der Shards, die Sie benötigen. Ein einzelner Shard kann nicht mehr als 1 MB pro Sekunde und 1.000 Anfragen (Log-Einträge) pro Sekunde verarbeiten. Bei der Berechnung der Anzahl von Shards, die Sie benötigen, empfehlen wir, bis zu 25 % als Puffer zu addieren.

Nehmen Sie beispielsweise an, dass Ihre Distribution 10.000 Anfragen pro Sekunde erhält und dass die Größe Ihrer Echtzeit-Protokolleinträge normalerweise 1 KB beträgt. Das bedeutet, dass Ihre Echtzeit-Protokollkonfiguration 10.000.000 Bytes (10.000 multipliziert mit 1.000) oder 9,53 MB pro Sekunde erzeugen könnte. In diesem Szenario würden Sie nur 10 Kinesis-Shards benötigen. Sie sollten erwägen, mindestens 12 Shards zu erstellen, um einen Puffer zu haben.

Ja. Ganz gleich, ob es sich um detaillierte Cache-Statistikberichte, Überwachung Ihrer CloudFront-Nutzung, um die Analyse, von wo aus Ihre Kunden Ihre Inhalte betrachten, oder um das Festlegen von Fast-Echtzeit-Alarmen für betriebliche Kennzahlen handelt, Amazon CloudFront bietet eine Vielzahl von Lösungen für ihre Berichtsanforderungen. Sie können auf alle Berichtsoptionen zugreifen, indem Sie das Dashboard "Amazon CloudFront Reporting & Analytics" in der AWS Management Console aufrufen. Weitere Informationen zu unseren Berichtsoptionen finden Sie auf der Seite Berichte und Analysen zu Amazon CloudFront.

Ja. Amazon CloudFront unterstützt die Kostenzuordnungsmarkierung. Mit Tags bzw. Markierungen können Sie Kosten einfacher zuordnen und Ausgaben durch Kategorisieren und Gruppieren von AWS-Ressourcen optimieren. Sie können Tags beispielsweise verwenden, um Ressourcen nach Administrator, Anwendungsname, Kostenstelle oder einem speziellen Projekt zu gruppieren. Weitere Informationen zur Kostenzuordnungs-Tags finden Sie im Abschnitt Verwenden von Kostenzuordnungs-Tags. Genaue Details zum Hinzufügen von Tags zu Ihren CloudFront-Distributionen finden Sie auf der Seite „Hinzufügen von Amazon-CloudFront-Tags“.

Ja. Zum Abrufen eines Verlaufs aller Aufrufe der Amazon CloudFront-API, die für Ihr Konto erfolgt sind, aktivieren Sie AWS CloudTrail in der AWS-Managementkonsole von CloudTrail. Weitere Informationen finden Sie auf der Startseite von AWS CloudTrail.

Sie können die Betriebsleistung Ihrer Amazon CloudFront-Verteilungen überwachen, entsprechende Alarme ausgeben und Benachrichtigungen empfangen – bereits wenige Minuten nach der Betrachteranforderung mit Amazon CloudWatch. CloudFront veröffentlicht automatisch sechs Betriebsmetriken mit einer Granularität von jeweils eine Minute in Amazon CloudWatch. Sie können daraufhin mit CloudWatch Alarme über abnormale Muster in Ihrem CloudFront-Datenverkehr einrichten. Anleitungen zur Überwachung der CloudFront-Aktivität und zur Einrichtung von Alarmen über CloudWatch finden Sie in der Anleitung im Entwicklerhandbuch für Amazon CloudFront-, oder rufen Sie die Amazon-CloudFront-Managementkonsole auf und wählen Sie im Navigationsbereich „Überwachung und Alarmierung“ aus.

CloudFront Functions ist eine serverlose Edge-Rechenfunktion, die es Ihnen erlaubt JavaScript Code an den CloudFront-Edge-Standorten für leichte HTTP(s)-Transformationen und -Manipulationen durchzuführen. CloudFront Functions wurde speziell dafür entwickelt, Kunden die Flexibilität einer voll programmierbaren Umgebung zu geben und dabei die Leistung und Sicherheit zu gewährleisten, die moderne Web-Anwendungen benötigen. Kunden können zu einem Bruchteil des Preises von AWS Lambda@Edge direkt skalieren, um Millionen von Aufforderung pro Sekunde zu unterstützen.

CloudFront Functions ist ein nativer Bestandteil von CloudFront und erlaubt es Ihnen somit Funktionen innerhalb des Services leicht zu erstellen, zu testen und anzuwenden. Sie können CloudFront KeyValueStore auch mit CloudFront Functions verwenden, um Suchdaten zu speichern und abzurufen, um Ihre Funktionslogik zu ergänzen. Mit unserem GitHub-Repository können Entwickler ganz einfach auf eine große Sammlung von Beispiel-Codes zugreifen, die als Ausgangspunkt für die Erstellung von Funktionen genutzt werden können. Mit Hilfe der IDE oder der CloudFront APIs/CLI können Sie Funktionen auf der CloudFront-Konsole erstellen. Nachdem der Code erstellt ist, können Sie die Funktion im Vergleich zum CloudFront-Produktionsverteiler testen, um das korrekte Ausführen der Funktion in seiner Anwendung sicherzustellen. Die Test-Funktion in der Konsole bietet einen visuellen Editor, um kurzfristige Test-Events zu erstellen und die Funktion zu bewerten. Sobald der Code mit einem CloudFront-Verteiler assoziiert ist, wird er, für die Ausführung durch CloudFront-Anforderungen, den Edge-Standorten im globalen Verteilernetzwerk von AWS hinzugefügt.

CloudFront Functions ist ideal für leichte, kurzfristige Funktionen. Folgend finden Sie einige Beispiele:

• Cache-Key-Normalisierung: Sie können HTTP-Anfrageeigenschaften (Header, Abfragezeichenfolgen, Cookies und sogar den relativen Pfad der Anfrage-URL) umwandeln und die Cache-Trefferquote mit dem optimalen Cache-Key verbessern.
• Header-Manipulation: HTTP-Header in der Anfrage oder Antwort können eingefügt, verändert oder gelöscht werden. Zum Beispiel können Sie HTTP-Strict-Transport-Security (HSTS) oder Cross-Origin-Resource-Sharing (CORS) zu Kopfzeilen mit jeder Rückmeldung hinzufügen.
• URL kann weiterleiten oder umschreiben: Sie können Betrachter auf andere Seiten anhand der Anfrageinformationen weiterleiten oder alle Anfragen von einem Pfad zu einem anderen weiterleiten.
• Anfrageberechtigung: Sie können Autorisierungs-Token wie JSON-Web-Tokens (JWT) bewerten, indem Sie Autorisierungs-Header oder andere Anfrage-Metadaten prüfen.

CloudFront KeyValueStore ist ein globaler, vollständig verwalteter Schlüsselwert-Datenspeicher mit geringer Latenz. KeyValueStore ermöglicht den Abruf von Schlüsselwertdaten innerhalb von CloudFront-Funktionen, wodurch die Funktionen besser angepasst werden können, da unabhängige Datenaktualisierungen möglich sind. Die Schlüsselwertdaten sind über alle CloudFront-Edge-Standorte hinweg zugänglich und bieten einen hocheffizienten In-Memory-Schlüsselwertspeicher mit schnellen Lesevorgängen innerhalb der CloudFront-Funktionen.

CloudFront KeyValueStore ist ideal für häufige Lesevorgänge an den Edge-Standorten und seltene Updates wie:

• Behalten Sie URL-Umschreibungen und -Weiterleitungen bei: Leiten Sie Benutzer basierend auf ihrer geografischen Position zu einer bestimmten Länderseite weiter. Das Speichern und Aktualisieren dieser geobasierten URLs in KeyValueStore vereinfacht die Verwaltung von URLs.
• A/B-Tests und Feature-Flags: Führen Sie Experimente durch, indem Sie einer Version Ihrer Website einen Prozentsatz des Datenverkehrs zuweisen. Sie können die Gewichtungen von Experimenten aktualisieren, ohne den Funktionscode oder Ihre CloudFront-Verteilung zu aktualisieren.
• Zugriffsautorisierung: Implementieren Sie die Zugriffskontrolle und Autorisierung für die über CloudFront bereitgestellten Inhalte, indem Sie benutzergenerierte Token wie HMAC-Token oder JSON-Web-Token (JWT) erstellen und validieren, um Anfragen zuzulassen oder abzulehnen. 

Nein – CloudFront Functions soll Lambda@Edge ergänzen, nicht ersetzen. Die Kombination aus Lambda@Edge und CloudFront Functions macht es einfacher das richtige Tool auszuwählen. Sie können in verschiedenen Event-Triggern innerhalb des gleichen Cache-Verhalten im CloudFront-Verteiler zwischen der Nutzung von CloudFront Functions und Lambda@Edge wählen. Als Beispiel können Sie Lambda@Edge für die spontane Manipulation von Streaming-Manifest-Dateien nutzen, um für einen sicheren Live-Stream angepasste Tokens einzuspeisen. Sie können CloudFront Functions nutzen, um diese Tokens zu bewerten, sobald ein Nutzer eine Anfrage für ein Segments des Manifests stellt.

Die Kombination aus CloudFront Functions und Lambda@Edge bietet Ihnen zwei starke und flexible Optionen, um Code als Reaktion zu CloudFront-Events durchzuführen. Beide bieten sichere Möglichkeiten, um Code als Antwort auf CloudFront-Events auszuführen, ohne die Infrastruktur zu regeln. CloudFront Functions wurde speziell für einfache, hoch anpassende und latenz-sensible Anfrage-/Antwort-Transformationen und -Manipulationen entwickelt. Lambda@Edge nutzt Universallaufzeiten die ein breites Spektrum an Rechenbedürfnissen und Anpassungen unterstützen. Lambda@Edge eignet sich am besten für rechenintensive Operationen. Dies können Berechnungen sein, deren Abschluss länger dauert (einige Millisekunden bis Sekunden), die von externen Bibliotheken von Drittanbietern abhängig sind, die Integration mit anderen AWS-Services (z. B. S3, DynamoDB) erfordern oder Netzwerkaufrufe für die Datenverarbeitung erfordern. Zu den gängigen fortgeschrittenen Anwendungsfällen von Lambda@Edge gehören die Manipulation von HLS-Streaming-Manifesten, die Integration in Autorisierungs- und Bot-Erkennungsdienste von Drittanbietern, das serverseitige Rendern (SSR) von Single-Page-Apps (SPA) an Edge und vieles mehr. Weitere Informationen finden Sie auf der Lambda@Edge-Seite für Anwendungsfälle.

CloudFront Functions liefert die Leistung, Ausmaß und Kosteneffektivität die man erwartet – mit einem einzigartigen Sicherheitsmodell das strikte Isolationsgrenzen zwischen den Funktions-Codes bietet. Wenn man einen spezifischen Code in einer gemeinsamen Umgebung mit mehreren Parteien durchführt, ist es entscheidend eine hoch-sichere Ausführungsumgebung zu bewahren. Es könnte versucht werden Fehler in der Runtime, den Bibliotheken oder dem CPU auszunutzen, um sensible Daten vom Server oder von Funktionen anderer Kunden zu leaken. Ohne eine strenge Isolationssperre zwischen Funktions-Codes, sind solche Taten möglich. Sowohl AWS Lambda als auch Lambda@Edge haben diese Sicherheitsisolation durch die auf Firecracker basierende VM-Isolation erzielt. Mit CloudFront Functions haben wir ein prozess-basiertes Modell entwickelt, das die gleichen Sicherheitsmaßstäbe gegen Side-Channel-Attacken wie Spectre und Meltdown, zeit-basierte Attacken oder andere Code-Schwachstellen bietet. CloudFront Functions kann keine Daten anderer Kunden abrufen oder verändern. Dies ist möglich, indem wir Functions in einem fest zugeordneten Prozess auf einem fest zugeordneten CPU laufen lassen. CloudFront wird auf Prozessarbeitern ausgeführt, welche nur einen Kunden auf einmal bedienen. Außerdem werden alle Kundenspezifischen Daten zwischen Ausführungen gereinigt (flushed).

In CloudFront Functions wird keine V8 als JavaScript-Engine verwendet. Das Sicherheitsmodell von Functions ist verschieden und wird als sicherer angesehen als das isolationsbasierte v8-Modell das von einigen anderen Anbietern vertrieben wird.

Sie können sämtliche Funktionen mit der eingebauten Test-Funktionalität prüfen. Dieser Funktionstest führt den Code im Vergleich mit einem CloudFront-Verteiler aus, um das erwartete Resultat zu bestätigen. Zusätzlich zur Durchführungsüberprüfung des Codes erhalten sie eine Rechenauslastungsmetrik. Diese Rechenauslastungsmetrik gibt prozentuell an, wie nah die Funktion am Durchführungszeitlimit liegt. Beispielsweise bedeutet eine Rechenauslastung von 30, dass die Funktion 30 % der erlaubten Durchführungszeit nutzt. Mit einem visuellen Editor können Testobjekte geschaffen werden, was es einfach macht Query-Strings, Kopfzeilen, URLs und HTTP-Methoden für jedes Objekt hinzuzufügen. Testobjekte können auch mit einer JSON-Repräsentation der Anfrage oder Antwort geschaffen werden. Die Testresultate und die Rechenauslastungsmetrik können nach Beendigung des Tests entweder im selben visuellen Editor oder durch Ansehen der JSON-Response eingesehen werden. Läuft die Funktion erfolgreich und hat eine Rechenauslastungsmetrik entfernt von 100, können Sie sicher sein, dass die Funktion auch in einem zugewiesenen CloudFront-Verteiler funktioniert.

CloudFront Functions gibt Metrik- und Ausführungsprotokolle aus, um die Anwendung und die Leistung einer Funktion zu kontrollieren. Für jeden Aufruf einer Funktion werden Metriken generiert, die Sie einzeln für jede Funktion in CloudFront oder in der CloudWatch-Konsole einsehen können. Metriken beinhalten die Anzahl der Aufrufe, Rechenauslastung, Prüfungsfehler und Ausführungsfehler. Püfungs- und Ausführungsfehlermeldungen einer Funktion erscheinen zudem im Zugangsprotokoll von CloudFront, um eine bessere Einsicht in die Auswirkung der Funktion auf den CloudFront-Verkehr zu geben. Zudem können Sie auch Ausführungsprotokolle generieren, indem Sie eine console.log()-Anweisung innerhalb ihres Funktions-Codes einfügen. Jede Log-Anweisung generiert einen CloudWatch-Protokolleintrag der zu CloudWatch gesendet wird. Protokolle und Metriken sind im Preis von CloudFront-Funktionen enthalten. 

Lambda@Edge ist eine Erweiterung von AWS Lambda, die es ermöglicht, Codes ohne die Bereitstellung und Verwaltung von Servern an globalen Edge-Standorten auszuführen. Lambda@Edge bietet leistungsstarke und flexible serverlose Datenverarbeitung für komplexe Funktionen und eine komplette Anwendungslogik die besser auf Ihre Zuschauer eingeht. Lambda@Edge-Funktionen laufen in Node.js- oder Python-Umgebungen. Wenn Sie Funktionen in einer einzelnen AWS-Region publizieren und die Funktion einem CloudFront-Verteiler zuordnen, kopiert Lambda@Edge den Code automatisch weltweit. Lambda@Edge skaliert automatisch zwischen wenigen Anforderungen pro Tag bis hin zu Tausenden pro Sekunde.

Lambda@Edge verknüpft Funktionen im Vergleich mit spezifischen Cache-Verhaltensweisen in CloudFront. Sie können außerdem festlegen, zu welchem Zeitpunkt – während der CloudFront-Anforderung oder der Antwortverarbeitung – die Funktion ausgeführt werden soll (z. B.: wenn eine Viewer-Anforderung eingeht, wenn eine Anforderung vom Ursprung erhalten oder dahin weitergeleitet wird oder direkt vor der Rückmeldung zum End-Viewer). Sie können Codes mit Node.js oder Python von der Lambda-Konsole, API oder mithilfe von Frameworks, wie das Serverless Application Model (SAM), erstellen. Nachdem Sie die Funktion getestet haben, verknüpfen Sie sie mit dem ausgewählten CloudFront-Cache-Verhalten und Event-Trigger. Wenn diese Einstellungen gespeichert sind, wird die Funktion bei der nächsten Anforderung an Ihren CloudFront-Verteiler an die CloudFront-Edge propagiert und nach Bedarf skaliert und ausgeführt. Weitere Informationen finden Sie in unserer Dokumentation.

Ihre Lambda@Edge-Funktionen werden automatisch als Reaktion auf die folgenden Amazon CloudFront-Ereignisse ausgelöst:

• Betrachter-Anforderung – Dieses Ereignis tritt ein, wenn ein Endbenutzer oder ein Gerät im Internet eine HTTP(S)-Anforderung an CloudFront richtet und die Anforderung beim Benutzer eintrifft, der dem Edge-Standort am nächsten liegt.
• Betrachter-Antwort – Dieses Ereignis tritt ein, wenn der CloudFront-Server bei der Edge zur Antwort an den Endbenutzer bzw. das Gerät bereit ist, von dem die Anforderung ausging.
• Ursprungsanforderung – Dieses Ereignis tritt ein, wenn der CloudFront-Edge-Server das angeforderte Objekt noch nicht in seinem Cache abgelegt hat und die Betrachter-Anforderung zum Versenden an Ihren Ursprungs-Webserver im Backend (z. B. Amazon EC2, Application Load Balancer oder Amazon S3) bereit ist.
• Ursprungsantwort – Dieses Ereignis tritt ein, wenn der CloudFront-Server an der Edge eine Antwort von Ihrem Ursprungs-Webserver im Backend erhält.

Die kontinuierliche Bereitstellung auf CloudFront bietet die Möglichkeit, die Konfigurationsänderungen mit einem Teil des Live-Datenverkehrs zu testen und zu validieren, bevor die Änderungen für alle Betrachter bereitgestellt werden.

Die kontinuierliche Bereitstellung mit CloudFront bietet Ihnen ein hohes Maß an Sicherheit bei der Bereitstellung. Sie können jetzt zwei getrennte, aber identische Umgebungen bereitstellen – eine blaue und eine grüne – und eine einfache Integration in Ihre Continuous-Integration-and-Delivery-Pipelines (CI/CD) mit der Möglichkeit des schrittweisen Rollouts von Versionen ohne Änderungen am Domain Name System (DNS) ermöglichen. Es stellt sicher, dass Ihr Betrachter eine konsistente Erfahrung durch Sitzungsgebundenheit erhält, indem es die Betrachtersitzung an dieselbe Umgebung bindet. Außerdem können Sie die Leistung Ihrer Änderungen durch die Überwachung von Standard- und Echtzeitprotokollen vergleichen und schnell zur vorherigen Konfiguration zurückkehren, wenn sich eine Änderung negativ auf einen Service auswirkt. 

Sie können eine kontinuierliche Bereitstellung einrichten, indem Sie eine Staging-Distribution über die CloudFront-Konsole, das SDK, die Befehlszeilenschnittstelle (CLI) oder die CloudFormation-Vorlage mit einer primären Distribution verknüpfen. Sie können dann Regeln definieren, um den Datenverkehr aufzuteilen, indem Sie den Client-Header konfigurieren oder einen Prozentsatz des Datenverkehrs zum Testen mit der Staging-Distribution einwählen. Sobald die Konfiguration eingerichtet ist, können Sie die Staging-Konfiguration mit den gewünschten Änderungen aktualisieren. CloudFront verwaltet die Aufteilung des Datenverkehrs auf die Benutzer und stellt entsprechende Analysen zur Verfügung, damit Sie entscheiden können, ob Sie die Bereitstellung fortsetzen oder zurücksetzen möchten. Sobald die Tests mit den Staging-Distributionen validiert sind, können Sie die Änderungen in die Hauptdistribution einbringen.

Bitte besuchen Sie die Dokumentation, um mehr über diese Feature zu erfahren.

Die kontinuierliche Bereitstellung ermöglicht eine echte Benutzerüberwachung durch echten Webverkehr. Sie können jede der vorhandenen Überwachungsmethoden – CloudFront-Konsole, CloudFront-API, CLI oder CloudWatch – verwenden, um die Betriebskennzahlen der primären und der Staging-Distribution individuell zu messen. Sie können die Erfolgskriterien Ihrer spezifischen Anwendung messen, indem Sie Durchsatz-, Latenz- und Verfügbarkeitsmetriken zwischen den beiden Verteilungen messen und vergleichen.

Ja, Sie können alle vorhandenen Distributionen als Basis verwenden, um eine Staging-Distribution zu erstellen und Änderungen einzuführen und zu testen.

Bei der kontinuierlichen Bereitstellung können Sie der primären und der Staging-Distribution unterschiedliche Funktionen zuordnen. Sie können die gleiche Funktion auch für beide Distributionen verwenden. Wenn Sie eine Funktion aktualisieren, die von beiden Distributionen verwendet wird, erhalten beide Distributionen die Aktualisierung.

Jede Ressource in Ihrem CloudFormation-Stack wird einer bestimmten AWS-Ressource zugeordnet. Eine Staging-Distribution hat ihre eigene Ressourcen-ID und funktioniert wie jede andere AWS-Ressource. Sie können CloudFormation zum Erstellen/Aktualisieren dieser Ressource verwenden.

Wenn Sie eine gewichtsbasierte Konfiguration verwenden, um den Datenverkehr an eine Staging-Distribution weiterzuleiten, können Sie auch die Sitzungsstabilität aktivieren, die sicherstellt, dass CloudFront Anfragen vom selben Betrachter als eine einzige Sitzung behandelt. Wenn Sie die Sitzungsgebundenheit aktivieren, setzt CloudFront ein Cookie, so dass alle Anfragen desselben Betrachters in einer einzigen Sitzung von einer Verteilung, entweder der primären oder der Staging-Distribution, bedient werden.

Die Funktion zur kontinuierlichen Bereitstellung ist an allen CloudFront-Edge-Standorten ohne zusätzliche Kosten verfügbar.

Jeder Server und jedes Gerät, der bzw. das mit dem Internet verbunden ist, muss eine numerische IP-Adresse (Internet Protocol, Internetprotokoll) haben. Mit wachsender Größe des Internets und steigender Anzahl an Benutzern nimmt auch der Bedarf an IP-Adressen zu. IPv6 ist eine neue Version des Internetprotokolls und verfügt über einen größeren Adressraum als die Vorgängerversion IPv4. Unter IPv4 war jede IP-Adresse 32 Bit lang, wodurch 4,3 Milliarden eindeutige Adressen möglich waren. Ein Beispiel für eine IPv4-Adresse wäre 192.0.2.1. IPv6-Adressen dagegen sind 128 Bit lang, was rund dreihundertvierzig Sextillionen eindeutige IP-Adressen erlaubt. Ein Beispiel für eine IPv6-Adresse wäre 2001:0db8:85a3:0:0:8a2e:0370:7334

Dank IPv6-Unterstützung für Amazon CloudFront können Ihre Anwendungen Verbindungen zu Amazon CloudFront-Edge-Standorten herstellen, ohne Software oder Systeme für die Umsetzung von IPv6 zu IPv4 zu benötigen. Sie können die von Regierungen festgelegten Anforderungen für die Einführung von IPv6 erfüllen – einschließlich der U.S.- Bundesregierung – und können darüber hinaus die Vorteile von IPv6 nutzen, wie Erweiterbarkeit, unkomplizierte Netzwerkverwaltung und integrierte Unterstützung für erweiterte Sicherheit.

Nein, Sie werden mit IPv6 die gleiche Leistung in Amazon CloudFront haben wie mit IPv4.

Alle in Amazon CloudFront vorhandenen Funktionen werden mit IPv6 weiter funktionieren. Allerdings gibt es zwei Änderungen, die Sie bei der internen Verarbeitung von IPv6-Adressen vornehmen müssen, bevor Sie IPv6 für Ihre Distributionen aktivieren.

1. Wenn Sie die Amazon-CloudFront-Feature für den Zugriff auf Protokolle aktiviert haben, werden Ihnen die IPv6-Adressen Ihrer Betrachter im Feld „c-ip“ angezeigt. Allerdings sollten Sie die einwandfreie Funktion Ihrer Protokollverarbeitungssysteme mit IPv6 überprüfen.
2. Wenn Sie für Ihre Amazon CloudFront-Verteilung IPv6 aktivieren, werden Ihnen in den X-Forwarded-For-Headern, die an die Ursprünge gesendet werden, IPv6-Adressen angezeigt. Wenn Ihre Ursprungssysteme nur IPv4-Adressen verarbeiten können, müssen Sie möglicherweise überprüfen, dass Ihre Ursprungssysteme auch unter IPv6 weiter funktionieren.

Außerdem sollten Sie, wenn Sie IP-Whitelists für vertrauenswürdige Aussteller verwenden, eine IPv4-Verteilung für URLs Ihrer vertrauenswürdigen Aussteller mit IP-Whitelists und eine IPv4/IPv6-Verteilung für alle anderen Inhalte verwenden. Dieses Model umgeht ein Problem, das auftreten würde, wenn die über eine IPv4-Adresse eingegangene und als solche signierte Signieranforderung nur als Anforderung für über eine andere IPv6-Adresse eingehendene Inhalte dient, wobei diese IPv6-Adresse nicht auf der Whitelist aufgeführt ist.

Weitere Informationen zum IPv6-Support in Amazon CloudFront finden Sie im Amazon CloudFront-Entwicklerhandbuch unter IPv6-Support in Amazon CloudFront.

Nein. Wenn Sie IPv6 und URLs vertrauenswürdiger Aussteller mit einer IP-Whitelist verwenden möchten, sollten Sie zwei separate Verteilungen verwenden. Eine Verteilung sollten Sie exklusiv für URLs Ihrer vertrauenswürdigen Aussteller mit IP-Whitelist vorsehen und IPv6 für diese Verteilung deaktivieren. Die andere Distribution, die sowohl mit IPv4 als auch mit IPv6 funktioniert, können Sie dann für alle anderen Inhalte verwenden.

Ja. Die IPv6-Adressen der Betrachter werden nicht im Feld "c-ip" der Zugriffsprotokolle angezeigt, wenn die Amazon CloudFront-Funktion für den Zugriff auf Protokolle aktiviert ist. Bevor Sie IPv6 für Ihre Verteilungen aktivieren, müssen Sie möglicherweise überprüfen, dass Ihre Protokollverarbeitungssysteme auch mit IPv6-Adressen weiter funktionieren. Wenden Sie sich an den Entwickler-Support, wenn Ihre Tools oder Software ein Problem damit haben, IPv6-Adressen in Zugriffsprotokollen zu verarbeiten. Weitere Informationen finden Sie in der Dokumentation Amazon CloudFront – Zugriff auf Protokolle.

Ja, über die Amazon CloudFront-Konsole oder -API können Sie IPv6 für jede einzelne Distribution (ob neu oder schon vorhanden) aktivieren oder deaktivieren.

Bei dem einzigen Fall, von dem uns Kunden berichtet haben, ging es um die interne Verarbeitung von IP-Adressen. Wenn Sie IPv6 für Ihre Amazon CloudFront-Verteilung aktivieren, erhalten Sie IPv6-Adressen nicht nur in Ihren detaillierten Zugriffsprotokollen angezeigt, sondern die IPv6-Adressen stehen auch in den X-Forwarded-For-Headern, die an Ihre Ursprünge gesendet werden. Wenn Ihre Ursprungssysteme nur IPv4-Adressen verarbeiten können, müssen Sie vor Aktivierung von IPv6 für Ihre Distribution überprüfen, dass Ihre Ursprungssysteme auch mit IPv6-Adressen funktionieren.

Amazon CloudFront ist weltweit auf die verschiedensten Weisen angebunden, aber es gibt immer noch Netzwerke, die keine universelle IPv6-Konnektivität besitzen. Auch wenn die Zukunft des Internets ganz klar bei IPv6 liegt, wird in der näheren Zukunft noch jeder Endpunkt über IPv4-Konnektivität verfügen. Wenn wir im Internet auf Stellen treffen, deren Konnektivität über IPv4 besser als die über IPv6 ist, ziehen wir IPv4 vor.

Ja. Sie können Route 53-Aliaseinträge für Ihre Amazon CloudFront-Verteilung erstellen, um sowohl IPv4 als auch IPv6 über einen Eintrag vom Typ "A" bzw. "AAAA" zu unterstützen. Wenn Sie nur IPv4 aktivieren möchten, brauchen Sie nur einen Aliaseintrag vom Typ "A" zu erstellen. Details zu Aliasressourcen-Datensätzen finden Sie im Entwicklerhandbuch zu Amazon Route 53.

Ab 1. Dezember 2021 erhalten alle AWS-Kunden monatlich kostenlos 1 TB ausgehende Datenübertragung, 10 000 000 http/https-Anfragen und zusätzlich 2 000 000 CloudFront-Funktionsaufrufe. Alle Nutzungsarten (z. B. Ungültigkeitserklärungen, Proxy-Anfragen, Lambda@Edge, Origin Shield, Datenübertragung an Origin usw.) sind vom kostenlosen Kontingent ausgeschlossen.  

Nein, Kunden, die die konsolidierte Fakturierung zur Erstellung einer Sammelrechnung für mehrere Konten verwenden, haben nur Zugriff auf ein kostenloses Kontingent pro Unternehmen.

Die 1 TB Datenübertragung und 10 Millionen Get-Anfragen sind die Grenze des monatlichen kostenlosen Kontingents aller Edge-Standorte. Wenn Ihre Nutzung das monatliche kostenlose Kontingent übersteigt, zahlen Sie einfach für jede Region die On-Demand-Standardtarife für AWS-Services. Vollständige Preisdetails finden Sie auf der AWS-CloudFront-Preisseite.

Sie können die aktuellen und bisherigen Nutzungsaktivitäten nach Region aufgeschlüsselt ansehen, indem Sie sich am Konto anmelden und zum Fakturierungs- und Kostenmanagement-Dashboard gehen. Von dort aus können Sie Ihre Kosten und Nutzung mit AWS Budgets verwalten, Ihre Kostentreiber und Nutzungstrends mit dem Cost Explorer visualisieren und mit den Kosten- und Nutzungsberichten Ihre Kosten genauer analysieren. Wenn Sie mehr darüber erfahren möchten, wie Sie die AWS-Kosten im Griff behalten, sehen Sie sich das 10-minütige Tutorial Bessere Kostenkontrolle mit AWS an.

Kunden, die das CloudFront-Sicherheitssparpaket abonniert haben, profitieren ebenfalls vom kostenlosen Kontingent. Falls Sie das Bedürfnis haben, Ihr Commitment an das CloudFront Security Savings Bundle in Hinsicht auf das kostenlose Kontingent zu verringern, setzen Sie sich bitte mit unserem Kundenservice in Verbindung und wir werden Ihre Änderungswünsche prüfen. Wir werden hierzu in den kommenden Tagen genauere Details bereitstellen. Bitte bleiben Sie dran. 

Für weitere Fragen, siehe https://aws.amazon.com/free/free-tier-faqs/.

Die Gebühren für Amazon CloudFront basieren auf der tatsächlichen Nutzung des Dienstes in fünf Bereichen: Datenübertragungen, HTTP/HTTPS-Anfragen, Invalidierungsanfragen, Echtzeit-Protokollanfragen und Dedicated-IP-Custom-SSL-Zertifikate in Verbindung mit einer CloudFront-Verteilung.

Mit dem kostenlosen AWS-Nutzungskontingent können Sie Amazon CloudFront zum Einstieg kostenlos verwenden und Ihren Tarif für wachsende Nutzung gering halten. Alle Kunden von CloudFront erhalten kostenlos 1 TB ausgehende Datenübertragung und 10 000 000 http und https-Anfragen für Amazon CloudFront, sogar wenn die Grenzen überschritten sind. Falls 

• Ausgehende Datenübertragung ins Internet
  Ihnen wird das ausgehende Datenvolumen von Amazon CloudFront-Edge-Standorten, gemessen in GB, in Rechnung gestellt. Die Tarife für Amazon CloudFront-Datenübertragungen ins Internet finden Sie hier. Beachten Sie, dass die Datenübertragungsnutzung für bestimmte geografische Regionen separat abgerechnet wird. Die Kosten werden dann basierend auf den Preisstufen für jeden Bereich berechnet. Wenn Sie andere AWS-Services als die Ursprünge Ihrer Dateien nutzen, wird Ihnen die Nutzung dieser Services, einschließlich Speicherung und Rechenzeiten, separat in Rechnung gestellt. Wenn Sie einen AWS-Ursprungsserver (wie z. B. Amazon S3, Amazon EC2, usw.) verwenden, werden ab dem 1. Dezember 2014 keine Gebühren für die ausgehende Datenübertragung aus Amazon CloudFront erhoben. Dies gilt für Datenübertragungen aus allen AWS-Regionen an alle weltweiten CloudFront-Edge-Standorte.
• Ausgehende Datenübertragung zum Ursprung
  Ihnen wird das ausgehende Datenvolumen (gemessen in GB) von Amazon CloudFront-Edge-Standorten zu Ihrem Ursprungsserver in Rechnung gestellt (sowohl AWS-Ursprungsserver als auch andere Ursprungsserver). Die Tarife für Amazon CloudFront-Datenübertragungen zum Ursprungsserver finden Sie hier.
• HTTP/HTTPS-Anforderungen
  Die Anzahl der an Amazon CloudFront gerichteten HTTP/HTTPS-Anforderungen Ihrer Inhalte wird Ihnen in Rechnung gestellt. Die Tarife für HTTP/HTTPS-Anforderungen finden Sie hier.
• Aufhebungsanforderungen
  Die Gebühren in Ihrer Aufhebungsanforderung werden pro Pfad berechnet. Ein in Ihrer Aufhebungsanforderung aufgeführter Pfad stellt die URL (oder mehrere URLs, falls der Pfad Platzhalter enthält) des Objekts dar, das Sie aus dem CloudFront-Cache entfernen möchten. Sie können jeden Monat bis zu 1 000 Pfade gebührenfrei von Amazon CloudFront entfernen. Nach den ersten 1 000 Pfaden wird für jeden Pfad in Ihrer Aufhebungsanforderung eine Gebühr berechnet. Die Tarife für Aufhebungsanforderungen finden Sie hier.
• Echtzeit-Protokollanforderungen
  Echtzeit-Protokolle werden auf der Grundlage der Anzahl der erzeugten Protokollzeilen berechnet; Sie zahlen 0,01 USD für jede 1.000.000 Protokollzeilen, die CloudFront an Ihrem Protokollziel veröffentlicht.
• Dedizierte IP Custom SSL
  Für jedes benutzerdefinierte SSL-Zertifikat, das einer oder mehreren CloudFront-Verteilungen zugeordnet ist, zahlen Sie monatlich 600 USD. Dabei nutzen Sie die Version "Dedicated IP" der Unterstützung benutzerdefinierter SSL-Zertifikate. Diese monatliche Gebühr wird auf Stunden umgelegt. Wenn Sie beispielsweise Ihr benutzerdefiniertes SSL-Zertifikat mindestens einer CloudFront-Verteilung im Monat Juni nur 24 Stunden (d. h. 1 Tag) zugeordnet haben, fallen für dieses benutzerdefinierte SSL-Zertifikat im Juni (1 Tag : 30 Tage) x 600 USD = 20 USD an. Wenn Sie die Unterstützung des Dedicated IP Custom SSL-Zertifikats nutzen wollen, laden Sie ein SSL-Zertifikat hoch und weisen Sie es mithilfe der AWS-Managementkonsole Ihren CloudFront-Verteilungen zu. Wenn Sie Ihrer CloudFront-Distribution mehr als zwei benutzerdefinierte SSL-Zertifikate zuweisen müssen, geben Sie im Formular zum Erhöhen des CloudFront-Grenzwerts bitte Details zu Ihrem Anwendungsfall sowie die Anzahl der benötigten benutzerdefinierten Zertifikate an.

Nutzungsstufen für Datenübertragungen werden für jede geografische Region gesondert gemessen. Die angegebenen Preise verstehen sich gegebenenfalls zuzüglich anfallender Steuern, Gebühren oder ähnlicher Abgaben, sofern nicht anders angegeben.

Falls nicht anders angegeben, gelten unsere Preise zuzüglich anfallender Steuern und Abgaben, u. a. MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechnungsadresse unterliegt die Nutzung von AWS-Services der japanischen Verbrauchssteuer. Weitere Informationen.

Wenn Sie eine Verteilung haben, die 1.000 Anfragen pro Sekunde mit einer Log-Größe von 1 KB bedient, und einen Kinesis-Datenstream in USA Ost (Ohio) mit 2 Shards erstellen:

Monatliche Kosten für Kinesis-Datenstreams: 47,74 USD pro Monat, berechnet mit dem Kinesis-Rechner hier.

Monatliche Kosten für CloudFront-Echtzeitprotokolle: Anfragen pro Monat X Kosten für Echtzeit-Protokolle = 1.000 * (60 Sek. * 60 Min. *24 Std. * 30 Tage) X (0,01 USD/1.000.000) = 25,92 USD/Monat

Eine 304 ist eine Antwort auf eine konditionale GET-Anforderung. Ihnen wird die HTTP/HTTPS-Anforderung und die Datenübertragung ins Internet (Data Transfer Out to Internet) in Rechnung gestellt. Eine 304-Antwort enthält keinen Text. Die HTTP-Header belegen jedoch eine gewisse Bandbreite, für die Standard-CloudFront-Datenübertragungsgebühren berechnet würden. Die übertragene Datenmenge richtet sich nach den Ihrem Objekt zugewiesenen Headern.

Ja. Mithilfe dieser Funktion können Sie die Preise für die Inhaltsbereitstellung aus Amazon CloudFront senken. Standardmäßig minimiert Amazon CloudFront die Endbenutzerlatenz, indem Inhalte aus seinem gesamten globalen Netzwerk aus Edge-Standorten bereitgestellt werden. Da wir jedoch an Standorten, an denen unsere Kosten höher sind, mehr berechnen, bedeutet dies, dass Sie an einigen Standorten mehr zahlen, um Ihre Inhalte mit kurzer Latenz an Endbenutzer zu übermitteln. Mit Preisklassen reduzieren Sie die Bereitstellungspreise, indem Sie die teureren Amazon CloudFront-Edge-Standorte aus Ihrer Amazon CloudFront-Verteilung ausschließen. In solchen Fällen wird Amazon CloudFront Ihre Inhalte von Edge-Standorten innerhalb der Standorte der gewählten Preisklasse übermitteln und Ihnen die Datenübertragungs- und Anforderungspreise des tatsächlichen Standorts berechnen, an den die Inhalte übermittelt wurden.

Wenn Leistung für Sie ausschlaggebend ist, müssen Sie nichts weiter tun. Ihre Inhalte werden aus unserem gesamten Standortnetzwerk zugestellt. Wenn Sie jedoch eine andere Preisklasse wünschen, können Sie Ihre Verteilung von Inhalten über die AWS-Managementkonsole oder Amazon CloudFront-API konfigurieren. Wenn Sie eine Preisklasse wählen, die nicht alle Standorte enthält, können einige Ihrer Betrachter, vor allem diejenigen, die sich an geografischen Standorten außerhalb Ihrer Preisklasse befinden, höhere Latenzzeiten haben, als wenn Ihre Inhalte von allen Amazon CloudFront-Standorten übermittelt werden.

Bitte beachten Sie, dass Amazon CloudFront dennoch gelegentlich Anforderungen Ihrer Inhalte von einem Edge-Standort an einem Ort erfüllt, der nicht in Ihrer Preisklasse enthalten ist. Wenn dies der Fall ist, wird Ihnen nur der Tarif für den kostengünstigsten Standort in Ihrer Preisklasse berechnet.

Eine Liste der Standorte in jeder Preisklasse finden Sie hier.

Das CloudFront-Sicherheitssparpaket ist ein flexibler Selbstbedienungs-Preisplan, mit dem Sie bis zu 30 % Ihrer CloudFront-Rechnung sparen können, wenn Sie sich im Gegenzug zu einer gleichbleibenden monatlichen Nutzungsmenge (z. B. 100 USD/Monat) für eine Laufzeit von 1 Jahr verpflichten.  Als zusätzlicher Vorteil ist die Nutzung der AWS WAF (Web Application Firewall) zum Schutz der CloudFront-Ressourcen in Höhe von bis zu 10 % Ihres zugesagten Planbetrags ohne zusätzliche Kosten enthalten.  Wenn Sie sich zum Beispiel zu einer Nutzung von CloudFront im Wert von 100 USD pro Monat verpflichten, entspricht dies einem Wert von 142,86 USD und einer Ersparnis von 30 % im Vergleich zu den Standardtarifen. Zusätzlich sind bis zu 10 USD AWS WAF-Nutzung enthalten, um Ihre CloudFront-Ressourcen ohne zusätzliche Kosten pro Monat zu schützen (bis zu 10 % Ihrer CloudFront-Verpflichtung).  Die Standardgebühren für CloudFront und AWS WAF gelten für jede Nutzung, die über das hinausgeht, was durch Ihre monatliche Ausgabenverpflichtung abgedeckt ist.  Wenn Ihr Verbrauch wächst, können Sie zusätzliche Sparpakete kaufen, um Rabatte für den zusätzlichen Verbrauch zu erhalten. 

Durch den Kauf eines CloudFront-Sicherheitssparpakets erhalten Sie eine Ersparnis von 30 %, die auf dem CloudFront-Serviceanteil Ihrer monatlichen Rechnung erscheint und alle von CloudFront in Rechnung gestellten Nutzungstypen ausgleicht, einschließlich Datentransfer nach außen, Datentransfer zum Ursprung, HTTP/S-Anfragegebühren, Verschlüsselungsanfragen auf Feldebene, Origin Shield, Ungültigkeitserklärungen, dedizierte IP Custom SSL und Lambda@Edge-Gebühren.  Außerdem erhalten Sie zusätzliche Leistungen, die die AWS WAF-Nutzung im Zusammenhang mit Ihren CloudFront-Distributionen abdecken. 

Sie können mit dem CloudFront-Sicherheitssparpaket beginnen, indem Sie die CloudFront-Konsolebesuchen, um Empfehlungen zum Verpflichtungsbetrag auf Basis Ihrer historischen CloudFront- und AWS WAF-Nutzung zu erhalten, oder indem Sie Ihre eigene geschätzte monatliche Nutzung eingeben. Sie erhalten einen Vergleich zwischen den monatlichen Kosten für das CloudFront-Sicherheitssparpaket und den On-Demand-Kosten und sehen die geschätzten Einsparungen, um Ihnen die Entscheidung für den richtigen Plan für Ihre Bedürfnisse zu erleichtern.  Sobald Sie sich für ein Sparpaket angemeldet haben, wird Ihnen Ihre monatliche Verpflichtung in Rechnung gestellt und es erscheinen Gutschriften, die Ihre CloudFront- und WAF-Nutzungsgebühren ausgleichen.  Für jede Nutzung, die über das hinausgeht, was durch Ihre monatliche Ausgabenverpflichtung abgedeckt ist, fallen die üblichen Servicegebühren an. 

Sobald die Laufzeit Ihres CloudFront-Sicherheitssparpakets abläuft, fallen die üblichen Servicegebühren für Ihre CloudFront- und AWS WAF-Nutzung an.   Die monatliche Sparparketverpflichtung wird nicht mehr in Rechnung gestellt und die Sparparketvorteile entfallen.  Sie können sich jederzeit vor Ablauf der Laufzeit Ihres Bundles dafür entscheiden, das CloudFront-Sicherheitssparpaket automatisch um ein weiteres Jahr zu verlängern.

Das CloudFront-Sicherheitssparpaket kann in jedem Konto innerhalb einer AWS Organization/Consolidated Billing Familie erworben werden.   Die Vorteile des CloudFront-Sicherheitssparpakets werden als Gutschrift auf Ihrer Rechnung verrechnet. Die Vorteile des Sparpakets gelten standardmäßig für die Nutzung aller Konten innerhalb einer AWS-Organisation/konsolidierten Abrechnungsfamilie (Guthabenfreigabe ist aktiviert) und sind davon abhängig, wann das abonnierende Konto einer Organisation beitritt oder diese verlässt.  Unter AWS-Guthaben erfahren Sie mehr darüber, wie AWS-Guthaben für einzelne und mehrere Konten gelten.

Ja, Sie können zusätzliche CloudFront-Sicherheitssparpakete erwerben, wenn Ihre Nutzung wächst, um Rabatte auf die zusätzliche Nutzung zu erhalten.   Alle aktiven CloudFront-Sicherheitssparpakete werden bei der Berechnung Ihrer AWS-Rechnung berücksichtigt.

Ihre monatlichen Bereitstellungsgebühren werden in einem separaten Abschnitt des CloudFront-Sicherheitspakets auf Ihrer Rechnung angezeigt.  Die von Ihrem CloudFront-Sicherheitspaket abgedeckte Nutzung wird sowohl im CloudFront- als auch im WAF-Teil Ihrer Rechnung als Guthaben zum Ausgleich Ihrer Standardnutzungsgebühren ausgewiesen.  

Ja, mit AWS Budgets können Sie Kosten- und Nutzungsschwellenwerte festlegen und Benachrichtigungen per E-Mail oder Amazon SNS-Thema erhalten, wenn Ihre tatsächlichen oder prognostizierten Kosten den Schwellenwert überschreiten.  Sie können ein benutzerdefiniertes AWS-Budget erstellen, das für den CloudFront-Service gefiltert wird, und den Budget-Schwellenwert auf die CloudFront-On-Demand-Nutzung festlegen, die von Ihrem CloudFront-Sicherheitssparpaket abgedeckt wird, um benachrichtigt zu werden, sobald dieser Schwellenwert überschritten wurde.   Weitere Informationen zu Budgets finden Sie unter Verwalten Ihrer Kosten mit AWS Budgets und Erstellen eines Budgets im Benutzerhandbuch für AWS-Fakturierung und -Kostenmanagement. 

Als zusätzlicher Vorteil des CloudFront-Sicherheitssparpakets ist die Nutzung von AWS WAF zum Schutz von CloudFront-Ressourcen in Höhe von bis zu 10 % Ihrer zugesagten Planmenge ohne zusätzliche Kosten enthalten. Die Standardgebühren für CloudFront und AWS WAF gelten für jede Nutzung, die über das CloudFront-Sicherheitssparpaket hinausgeht.  Verwaltete WAF-Regeln, die über den AWS Marketplace abonniert wurden, sind nicht durch das CloudFront-Sicherheitssparpaket abgedeckt. 

Sie können nur das eine oder andere abonniert haben.  Bitte wenden Sie sich an Ihren AWS Account Manager, wenn Sie Fragen zu Ihrer individuellen Preisvereinbarung haben.

Sie können das CloudFront-Sicherheitssparpaket nur über die CloudFront-Konsole abonnieren.  Wir werden in Erwägung ziehen, diese Funktion über eine API als zukünftige Erweiterung verfügbar zu machen.