Amazon CloudFront – Häufig gestellte Fragen

Der Web-Service Amazon CloudFront bietet Unternehmen und Web-Anwendungsentwicklern eine einfache und günstige Methode, Inhalte mit geringer Latenz und hohen Datenübertragungsraten bereitzustellen. Wie auch alle anderen AWS-Services ist Amazon CloudFront ein Angebot, das eigenständig genutzt werden kann und bei dem nur für die tatsächliche Nutzung gezahlt wird – ohne Langzeitverpflichtungen oder Mindestgebühren. Mit CloudFront werden Ihre Dateien den Endbenutzern über ein globales Netzwerk aus Edge-Standorten bereitgestellt.

Mit der einfachen API von Amazon CloudFront können Sie:

• Inhalte mit geringer Latenz und hohen Datentransferraten verteilen, da Anforderungen über ein weltweites Netzwerk an Edge-Standorten bedient werden.
• Einfach loslegen, ohne Verträge und Mindestvereinbarungen auszuhandeln.

Klicken Sie auf der Detailseite zu Amazon CloudFront auf „Kostenloses Konto erstellen“. Wenn Sie einen anderen AWS-Service als Ursprung für die über Amazon CloudFront bereitgestellten Dateien verwenden möchten, müssen Sie sich vor dem Erstellen von CloudFront-Verteilungen für diesen Service anmelden.

So verwenden Sie Amazon CloudFront:

• Speichern Sie bei statischen Dateien die definitiven Versionen Ihrer Dateien auf einem oder mehreren Ursprungsservern. Dies können Amazon S3-Buckets sein. Für Ihre dynamisch generierten Inhalte, die personalisiert oder angepasst werden, können Sie Amazon EC2 oder einen beliebigen anderen Webserver als Ursprungsserver verwenden. Diese Ursprungsserver dienen zum Speichern oder Generieren Ihrer Inhalte, die über Amazon CloudFront verteilt werden.
• Registrieren Sie Ihre Ursprungsserver bei Amazon CloudFront über einen einfachen API-Aufruf. Dieser Aufruf gibt einen "CloudFront.net"-Domain-Namen zurück, den Sie zur Verteilung von Inhalten vom Ursprungsserver über den Amazon CloudFront-Service verwenden können. Sie können beispielsweise den Amazon S3-Bucket "bucketname.s3.amazonaws.com" als Ursprung aller Ihrer statischen Inhalte und die Amazon EC2-Instance "dynamic.myoriginserver.com" für alle Ihre dynamischen Inhalte verwenden. Anschließend können Sie über die API oder AWS-Managementkonsole eine Amazon CloudFront-Verteilung erstellen, die ggf. "abc123.cloudfront.net" als Domain-Namen der Verteilung zurückgibt.
• Fügen Sie den Domain-Namen "cloudfront.net" oder einen CNAME-Alias, den Sie erstellen, in Ihre Webanwendung, Website oder Ihren Media Player ein. Jede Anforderung, die über den Domain-Namen "CloudFront.net" (oder den eingerichteten CNAME) erfolgt, wird an den Edge-Standort weitergeleitet, der am besten zur Inhaltsbereitstellung bei höchster Leistung geeignet ist. Der Edge-Standort versucht, die Anforderung mit einer lokalen Kopie der Datei zu erfüllen. Wenn keine lokale Kopie verfügbar ist, erhält Amazon CloudFront eine Kopie vom Ursprung. Diese Kopie ist dann für weitere Anforderungen am Edge-Standort verfügbar.

Amazon CloudFront verwendet ein globales Netzwerk von Edge-Standorten und regionalen Edge-Caches, die Kopien Ihrer Inhalte möglichst nahe bei den Betrachtern zwischenspeichern. Amazon CloudFront stellt sicher, dass die Anforderungen der Endbenutzer vom nächstgelegenen Edge-Standort erfüllt werden. Als Ergebnis müssen die Anforderungen der Betrachter nur eine kurze Distanz zurücklegen, sodass die Leistung für die Betrachter verbessert wird. Für Dateien, die nicht im Cache der Edge-Standorte und den regionalen Edge-Caches zwischengespeichert werden, hält Amazon CloudFront eine Dauerverbindung mit Ihren Ursprungsservern aufrecht, damit diese Dateien so schnell wie möglich von den Ursprungsservern abgerufen werden können. Schlussendlich nutzt Amazon CloudFront zusätzliche Optimierungen, z. B. Vergrößerung des anfänglichen TCP-Überlastungsfensters, um Ihren Website-Besuchern Inhalte mit höchster Leistung bereitzustellen.

Wie auch bei anderen AWS-Services gibt es bei Amazon CloudFront keine Mindestvereinbarungen, und Sie zahlen nur für das, was Sie auch tatsächlich nutzen. Verglichen mit dem selbständigen Hosten von Dateien fallen bei Amazon CloudFront nicht die Ausgaben und die Komplexität des Betriebs eines Netzwerks aus Cache-Servern an mehreren Standorten im Internet an. Sie müssen auch keine Überkapazität bereitstellen, um eventuelle Datenverkehrsspitzen bewältigen zu können. Amazon CloudFront arbeitet auch mit Verfahren wie dem Zusammenführen gleichzeitiger Betrachteranforderungen an einem Edge-Standort derselben Datei zu einer einzelnen Anforderung, die an Ihren Ursprungsserver gesendet wird. Dadurch verringert sich die Verarbeitungslast Ihrer Ursprungsserver, sodass Ihre Ursprungsinfrastruktur weniger skaliert werden muss, was zu weiteren Kosteneinsparungen führt.

Wenn Sie darüber hinaus einen AWS-Ursprung verwenden (z. B. Amazon S3, Amazon EC2 usw.), erheben wir seit dem 1. Dezember 2014 keine Gebühren mehr für aus AWS ausgehende Datenübertragungen in Amazon CloudFront. Dies gilt für Datenübertragungen aus allen AWS-Regionen an alle weltweiten CloudFront-Edge-Standorte.

Amazon CloudFront nutzt standardmäßige Cache-Steuerungskopfzeilen, die Sie für Ihre Dateien zum Bestimmen statischer oder dynamischer Inhalte festlegen. Durch die Bereitstellung Ihres gesamten Inhalts in einer einzigen Amazon CloudFront-Verteilung stellen Sie sicher, dass Leistungsoptimierungen für Ihre gesamte Website oder Webanwendung gelten. Bei Verwenden von AWS-Ursprüngen profitieren Sie von der optimierten Leistung, Zuverlässigkeit und Benutzerfreundlichkeit, was aus der Fähigkeit von AWS resultiert, Ursprungsrouten nachzuverfolgen und anzupassen, den Systemstatus zu überwachen und schnell auf auftretende Probleme zu reagieren. Weiter ins Gewicht fällt die Integration von Amazon CloudFront mit anderen AWS-Services. Sie profitieren ferner vom Verwenden verschiedener Ursprünge für unterschiedliche Inhaltstypen für eine einzelne Website, z. B. Amazon S3 für statische Objekte, Amazon EC2 für dynamische Inhalte und benutzerdefinierte Ursprünge für Inhalte anderer Anbieter, wobei Sie stets nur dafür zahlen, was Sie nutzen.

Für die Verteilung von Inhalten, auf die häufig und regelmäßig zugegriffen wird und die von der Bereitstellung am Edge profitieren (z. B. beliebte Website-Images, Videos, Mediendateien oder Software-Downloads), ist Amazon CloudFront eine gute Wahl.

Bei Amazon CloudFront können Sie schnell von den Vorteilen der Inhaltsbereitstellung im Hochleistungsbereich profitieren, ohne Verträge oder hohe Preise aushandeln zu müssen. Entwickler haben dank des Selbstnutzungsmodells mit Amazon CloudFront Zugang zu niedrigen, auf Leistung basierten Preisen. Außerdem profitieren die Entwickler von der engen Integration mit anderen Amazon Web Services. Die Lösung lässt sich einfach mit Amazon S3, Amazon EC2 und Elastic Load Balancing als Ursprungsserver verwenden, wodurch Entwickler eine leistungsstarke Kombination aus beständigem Speicher und Inhaltsbereitstellung im Hochleistungsbereich erhalten. Amazon CloudFront ist auch mit Amazon Route 53 und AWS CloudFormation integriert, um die Leistung weiter zu optimieren und die Konfiguration zu vereinfachen.

Amazon CloudFront unterstützt Inhalte, die über die Protokolle HTTP oder WebSocket gesendet werden können. Dazu gehören dynamische Webseiten und Anwendungen, wie z.B. HTML- oder PHP-Seiten oder WebSocket-basierte Anwendungen, sowie alle populären statischen Dateien, die Teil Ihrer Webanwendung sind, wie z. B. Website-Bilder, Audio-, Video-, Mediendateien oder Software-Downloads. Amazon CloudFront unterstützt auch das Streamen von Live- oder On-Demand-Medien über HTTP.

Ja. Amazon CloudFront arbeitet mit beliebigen Ursprungsservern zusammen, die die ursprünglichen, definitiven Versionen Ihrer Inhalte, ob statisch oder dynamisch, enthalten. Bei Verwenden eines benutzerdefinierten Ursprungs fallen keine Zusatzgebühren an.

Für jeden Ursprung, den Sie zu einer CloudFront-Verteilung hinzufügen, können Sie einen Backup-Ursprung zuweisen, der verwendet werden kann, um Ihren Datenverkehr automatisch zu bedienen, wenn der primäre Ursprung nicht verfügbar ist. Sie können eine Kombination von HTTP 4xx/5xx-Status-Codes wählen, die bei der Rückkehr vom primären Ursprung den Failover zum Backup-Ursprung auslösen. Die beiden Ursprünge können eine beliebige Kombination von AWS- und Nicht-AWS-Ursprüngen sein.

Ja. Wenn in einem Abrechnungszeitraum die monatliche Betriebszeit kürzer als von der SLA (Service Level Agreement) zugesagt ist, bietet Amazon CloudFront eine Service-Gutschrift. Weitere Informationen finden Sie hier.

Ja. Mit der AWS-Managementkonsole können Sie Amazon CloudFront über eine einfache Point-and-Click-Webschnittstelle konfigurieren und verwalten. Die AWS-Managementkonsole unterstützt alle Features von Amazon CloudFront. So profitieren Sie von einer Inhaltsbereitstellung bei geringster Latenz, ohne Code schreiben oder Software installieren zu müssen. Zugriff auf die AWS-Managementkonsole erhalten Sie kostenfrei unter https://console.aws.amazon.com.

In unserem Ressourcenzentrum finden Sie verschiedene Tools zur Verwaltung Ihrer Amazon-CloudFront-Verteilungen und Bibliotheken für verschiedene Programmiersprachen.

Ja. Sie können Ihre Zone-Apex (example.com) auf zwei Arten auf Ihre Amazon-CloudFront-Verteilung verweisen.

Mit Amazon Route 53, dem autoritativen DNS-Service von AWS, können Sie einen ALIAS-Eintrag konfigurieren, mit dem Sie den Apex oder Root (example.com) Ihres DNS-Namens Ihrer Amazon CloudFront-Verteilung zuordnen können. Amazon Route 53 antwortet dann auf jede Anfrage nach einem ALIAS-Eintrag mit der/den richtigen IP-Adresse(n) für Ihre CloudFront-Verteilung. Route 53 erhebt keine Gebühren für Abfragen an ALIAS-Einträge, die einer CloudFront-Verteilung zugeordnet sind.

Alternativ können Sie mit den statischen Anycast-IPs von CloudFront Ihre Apex-Domain über einen beliebigen DNS-Anbieter auf Ihre CloudFront-Verteilung verweisen. Erstellen Sie einfach Standard-A-Einträge mit den 3 statischen IP-Adressen, die von CloudFront bereitgestellt werden. Mit diesem Feature wird die Unterstützung für Apex-Domains über Route 53 hinaus erweitert, während Ihr Datenverkehr weiterhin automatisch an die nächstgelegenen Edge-Standorte weitergeleitet wird, damit Inhalte weltweit mit hoher Leistung bereitgestellt werden können.

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 Regionale 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 die Verwendung dieses Features 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 des Features der Geo-Einschränkung 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-Status-Code 403 (Unzulässig).

Die Genauigkeit der Datenbank zur Zuordnung von IP-Adressen zu Ländern variiert je nach Region. Basierend auf aktuellen Tests liegt unsere Gesamtgenauigkeit bei der Zuordnung von IP-Adressen zu Ländern bei 99,8 %.

Ja, Sie können benutzerdefinierte Fehlermeldungen (z. B. eine HTML-Datei oder eine JPG-Grafik) mit Ihren eigenen Markenzeichen und Inhalten für eine Vielzahl von HTTP-4xx- und 5xx-Fehlerantworten 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.

Standardmäßig überprüft jeder Edge-Standort, wenn kein Cache-Steuerungskopfzeile festgelegt ist, bei jeder Anfrage, die mehr als 24 Stunden nach der letzten Überprüfung des Ursprungs auf Änderungen an dieser Datei eingeht, ob eine aktualisierte Version Ihrer Datei vorliegt. 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 Gebühren 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-Aufhebungsanforderungen 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 System für Versionsverwaltung 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. CloudFront-POPs sind hingegen darauf ausgelegt 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 Verteilung speziell für eingebettete POPs erstellen. Wenn Ihr Workload geeignet ist, aktiviert CloudFront auf Anfrage eingebettete PoPs für Ihre bestehende Verteilung.

Sie müssen sich nicht zwischen eingebetteten CloudFront-POPs oder CloudFront-POPs für die Inhaltsbereitstellung entscheiden. Sobald Ihre CloudFront-Verteilung für eingebettete POPs aktiviert ist, verwendet das Weiterleitungssystem 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 eingebettete 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 die Anforderung neuer Geräte, die Verfolgung des Bearbeitungsstatus von Anfragen, die Überwachung von Leistungsstatistiken und die Anforderung 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 unter HIPAA-Compliance im Entwicklerhandbuch.

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 unter Compliance mit AWS SOC im Entwicklerhandbuch.

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 AWS-SOC-3-Bericht ist öffentlich 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.

Wenn Sie bereits über eine Amazon-CloudFront-Verteilung verfügen, können Sie HTTP/2 über die API oder die Managementkonsole 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 Besucher. Für die Kommunikation zwischen Edge-Standorten und Ihren Ursprungsservern 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, ausfallsicheren und zuverlässigen 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 in dem 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. Verbesserte Web-Leistung – 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 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/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. Fallback-Unterstützung ist ein erforderlicher Bestandteil der HTTP/3-Spezifikation und wird von allen gängigen 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 Informationen finden Sie im Abschnitt „Unterstützte Protokolle und Verschlüsselungen zwischen Betrachtern und CloudFront“ im CloudFront-Entwicklerhandbuch.

Nein, für die Aktivierung von HTTP/3 in Amazon-CloudFront-Verteilungen fallen keine gesonderten Kosten an. HTTP/3-Anfragen werden gemäß den Preisen Ihres Preispakets berechnet.

CloudFront SaaS Manager, ein neues Feature von Amazon CloudFront, das Anbietern von Software-as-a-Service (SaaS) und Web-Entwicklungsplattformen dabei hilft, die Bereitstellung von Inhalten über mehrere Websites hinweg effizient zu verwalten. CloudFront SaaS Manager vereinfacht die Bereitstellung und Sicherung von Multi-Tenant-Anwendungen in großem Maßstab für Unternehmen. Durch die Einführung wiederverwendbarer Konfigurationen und Parameter reduziert CloudFront SaaS Manager den Betriebsaufwand. Es eliminiert redundante Konfigurationsarbeiten und ermöglicht es Kunden, einheitliche Einstellungen auf allen ihren Websites beizubehalten. Darüber hinaus bietet CloudFront SaaS Manager die optionale Flexibilität, Sicherheitseinstellungen anzupassen und die Erneuerung von Zertifikaten für jede Website bei Bedarf zu automatisieren.

CloudFront SaaS Manager wurde für Unternehmen entwickelt, die vor der Herausforderung stehen, mehrere Websites effizient zu verwalten. Anbieter von Software-as-a-Service (SaaS) und Webentwicklungsplattformen profitieren besonders davon, da sie damit einheitliche Einstellungen für die Websites ihrer Tenants gewährleisten können. Ebenso können Unternehmen, die mehrere Unternehmens-Websites verwalten, damit ihre Webpräsenz standardisieren und gleichzeitig die Flexibilität zur individuellen Anpassung einzelner Websites bewahren. Wenn Sie nur über einige wenige Websites verfügen oder jede Website unterschiedliche CloudFront-Konfigurationen enthält, ist die Single-Tenant-Verteilung (herkömmlich) wahrscheinlich besser geeignet.

CloudFront ist über die AWS-Konsole und APIs als Option verfügbar für Kunden, die gemeinsame Einstellungen über mehrere Domänengruppen hinweg verwalten möchten. Erste Schritte: 1/Gemeinsame Einstellungen definieren: Erstellen Sie eine Multi-Tenant-Verteilung mit gemeinsam genutzten Einstellungen, die als Vorlage für Domain-Gruppen dienen. 2/Verteilungs-Tenants erstellen: Erstellen Sie Verteilungs-Tenants, mit denen Sie Domains und deren TLS-Zertifikate einer Multi-Tenant-Verteilung zuordnen können. 3/Feinabstimmung der Steuerung: Optional können Sie die Einstellungen für Verteilungs-Tenants anpassen, indem Sie Überschreibungen anwenden.

Eine Multi-Tenant-Verteilung definiert die Basiskonfiguration, die Domain-übergreifend gemeinsam genutzt wird. Es enthält gemeinsame Konfigurationseinstellungen wie Ursprungskonfigurationen, Cache-Verhalten und Sicherheitseinstellungen. Im Gegensatz zu einer Standardverteilung kann eine Multi-Tenant-Verteilung den Datenverkehr nicht direkt bedienen. Sie bietet anpassbare, parametrisierte Felder, um den individuellen Anforderungen jeder Domain gerecht zu werden. Beispiel: Domain-spezifische Ursprungspfade oder Ursprungsdomain-Namen.

Ein Verteilungs-Tenant stellt eine bestimmte Domain unter Verwendung einer Multi-Tenant-Verteilung dar. Es übernimmt die Grundkonfiguration aus der Multi-Tenant-Verteilung und muss mindestens eine Domain oder Unter-Domain mit einem gültigen TLS-Zertifikat haben.
Jeder Verteilungs-Tenant kann die folgenden Anpassungen enthalten:

• Eindeutige Ursprungspfade und/oder Ursprungsdomainnamen (definiert durch Parameterwerte in der Multi-Tenant-Verteilung)
• Benutzerdefinierte TLS-Zertifikate
• Web-ACL-Überschreibungen
• Außerkraftsetzung von Geobeschränkungen
  

Ja. CloudFront arbeitet jedoch mit AWS Certificate Manager (ACM) zusammen, um eine nahtlose Validierung der Domain-Kontrolle zu ermöglichen. Die Integration mit ACM nimmt Ihnen die Last der Zertifikatsausstellung und -verwaltung ab und bietet ein automatisiertes Lebenszyklus-Management für Ihre von Amazon ausgestellten SSL/TLS-Zertifikate. Wenn Sie eine andere Zertifizierungsstelle für die Ausstellung von Zertifikaten verwenden, unterstützt ACM Zertifikate, die von Drittanbietern ausgestellt wurden. In solchen Fällen sind Sie für den Lebenszyklus des Zertifikats verantwortlich (erstmaliges Hochladen, Verlängerung, nachfolgendes Hochladen). ACM benachrichtigt den AWS-Kontobesitzer über CloudWatch und per E-Mail, wenn das Ablaufdatum des Zertifikats näher rückt. Weitere Informationen finden Sie unter https://aws.amazon.com/certificate-manager/faqs/.

Ja, CloudFront unterstützt Apex- oder Root-Domains (z. B. example.com statt www.example.com). Kunden können Route 53 verwenden, um DNS zu verwalten und einen ALIAS-Eintrag für ihre Apex-Domain hinzuzufügen, der auf eine von CloudFront bereitgestellte Domain verweist. Für Kunden, die Route 53 nicht zur Verwaltung benutzerdefinierter Domains verwenden können, bietet Anycast Static IPs einen dedizierten Satz von IP-Adressen, die anstelle von CNAME-/ALIAS-Einträgen verwendet werden können. Weitere Informationen finden Sie hier.

Ja. Die Gebühren für CloudFront richten sich nach der Anzahl der von Ihnen erstellten Verteilungs-Tenant-Ressourcen. Verteilungs-Tenants sind neue Ressourcen, die die Konfigurationseinstellungen von einer CloudFront-Multi-Tenant-Verteilung übernehmen. Weitere Informationen finden Sie auf der Seite mit den CloudFront-Preisen.

WebSocket ist ein Protokoll für die Echtzeit-Kommunikation, 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 nur dann WebSocket-Verbindungen her, wenn der Client die Kopfzeile „Upgrade: websocket“ enthält und der Server mit dem HTTP-Status-Code 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.

gRPC ist ein modernes Open-Source-RPC-Framework (Remote Procedure Call), das die bidirektionale Kommunikation zwischen einem Client und einem Server über eine lange bestehende HTTP/2-Verbindung ermöglicht. Durch die Verwendung einer dauerhaften 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. gRPC eignet sich gut für Anwendungsfälle, in denen niedrige Latenz und hohe Übertragungsgeschwindigkeiten entscheidend sind, wie z. B. Kommunikationsanwendungen in Echtzeit und Online-Spiele.

gRPC ist bei jedem Cache-Verhalten in Ihren CloudFront-Verteilungen aktiviert. Durch die Aktivierung von gRPC wird sichergestellt, dass sowohl HTTP/2 als auch die Unterstützung für POST-Anfragen auch in Ihrer Verteilung aktiviert sind. gRPC unterstützt nur die POST-Methode über HTTP/2.

Amazon CloudFront kommuniziert über gRPC, wenn die folgenden Bedingungen erfüllt sind:

1. HTTP/2 ist in Ihrer Verteilung aktiviert
2. POST-Anfragen und gRPC sind bei einem Cache-Verhalten aktiviert
3. Ein Client sendet einen „Inhaltstyp“-Header mit dem Wert „application/grpc“ über eine HTTP/2-Verbindung

1. Sicherheit – gRPC verwendet HTTP/2, wodurch sichergestellt wird, dass der Datenverkehr vom Client zu Ihren Ursprungsservern durchgehend verschlüsselt wird. Wenn Sie gRPC verwenden, erhalten Sie außerdem AWS Shield Standard ohne zusätzliche Kosten. AWS WAF kann so konfiguriert werden, dass der gRPC-Datenverkehr vor Angriffen geschützt wird.
2. Bessere Leistung – gRPC nutzt ein binäres Nachrichtenformat, sogenannte Protokoll-Buffer, die kleiner sind als herkömmliche Nutzdaten wie JSON, das mit RESTful-APIs verwendet wird. Das Parsen von Protokoll-Buffern ist weniger CPU-intensiv, da die Daten in einem binären Format vorliegen, wodurch Nachrichten schneller ausgetauscht werden können. Dies führt zu einer besseren Gesamtleistung.
3. Integrierte Streaming-Unterstützung – Streaming ist ein integrierter Bestandteil des gRPC-Frameworks und unterstützt sowohl clientseitige als auch serverseitige Streaming-Semantik. Dies macht es viel einfacher, Streaming-Services oder -Clients zu erstellen. gRPC auf CloudFront unterstützt die folgenden Streaming-Kombinationen:
   • Unär (kein Streaming)
   • Client-zu-Server-Streaming
   • Server-zu-Client-Streaming
   • Bidirektionales Streaming

Derzeit nicht. CloudFront unterstützt nur gRPC über HTTP/2.

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 ein Feature 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 Web-Anwendungen erfassen 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 gewährleistet ein höheres Maß an Sicherheit, da die Daten auch dann kryptografisch geschützt bleiben, wenn einer der Anwendungsservices den Geheimtext preisgibt.

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) auf. 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 bereit und mit derselben Sicherheit wie das Feature Dedicated IP Custom SSL. "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 Server-Namen 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-Zertifikatsspeicher hochgeladen haben, wird von CloudFront weiterhin unterstützt.

Ja. Amazon CloudFront verfügt über ein optionales Feature für private Inhalte. Wenn diese Option aktiviert ist, stellt Amazon CloudFront nur dann Dateien bereit, wenn Sie durch sichere Signatur Ihrer Anforderungen Ihr Einverständnis gegeben haben. 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 Web-Anwendungen 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-Angriffen (Ebene 3 und 4), wie SYN/UDP-Floods, Reflexionsangriffen und anderen, um für eine hohe Verfügbarkeit Ihrer Anwendungen unter AWS zu sorgen.

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 Web-Anwendungen, die Ihnen auf Grundlage von Regeln zu IP-Adressen, HTTP-Kopfzeilen und benutzerdefinierten URI-Zeichenfolgen hilft, Ihre Web-Anwendungen vor Angriffen zu schützen. Anhand dieser Regeln kann AWS WAF Web-Anforderungen an Ihre Web-Anwendung blockieren, zulassen oder überwachen (zählen). Weitere Informationen finden Sie im AWS-WAF-Entwicklerhandbuch.

CloudFront bietet zwei vollständig verwaltete Möglichkeiten, Ihre Ursprünge zu schützen:

1. Origin Access Control (OAC): CloudFront Origin Access Control (OAC) ist ein Sicherheits-Feature, das den Zugriff auf Ihre Amazon Simple Storage Service (S3) Origins, AWS Elemental Origins und Lambda-Funktions-URLs einschränkt und sicherstellt, dass nur CloudFront auf den Inhalt zugreifen kann.
2. VPC-Ursprünge: Mit CloudFront Virtual Private Cloud (VPC) Origins können Sie Amazon CloudFront verwenden, um Inhalte von Anwendungen bereitzustellen, die in einem privaten VPC-Subnetz gehostet werden. Sie können Application Load Balancer (ALB), Network Load Balancer (NLB) und EC2-Instances in privaten Subnetzen als VPC-Ursprünge mit CloudFront verwenden

Wenn verwaltete CloudFront-Lösungen Ihre Anwendungsfall-Anforderungen nicht erfüllen, finden Sie im Folgenden einige der verfügbaren alternativen Ansätze:

1. Benutzerdefinierte Origin-Kopfzeilen: Mit CloudFront können Sie benutzerdefinierte Kopfzeilen an Ihre eingehenden Anfragen anfügen und dann Ihren Ursprung so konfigurieren, dass diese spezifischen Kopfzeilenwerte überprüft werden, wodurch der Zugriff effektiv nur auf die Anfragen beschränkt wird, die über CloudFront weitergeleitet werden. Diese Methode schafft eine zusätzliche Authentifizierungsebene, wodurch das Risiko eines unbefugten direkten Zugriffs auf Ihren Ursprung erheblich reduziert wird.
2. IP-Zulassungsliste: Sie können die Sicherheitsgruppe oder Firewall Ihres Ursprungs so konfigurieren, dass ausschließlich eingehender Datenverkehr aus den IP-Bereichen von CloudFront zugelassen wird. AWS verwaltet und aktualisiert diese IP-Bereiche regelmäßig für Sie. Detaillierte Informationen zur Implementierung von IP-Zulassungslisten finden Sie in unserer umfassenden Dokumentation unter: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list. Diese Ressource bietet schrittweise Anleitungen zur Nutzung der verwalteten Präfixlisten von AWS für eine optimale Sicherheitskonfiguration.
3. SSL/TLS-Verschlüsselung: Sie können CloudFront so konfigurieren, dass ausschließlich HTTPS-Verbindungen mit Ihrem Ursprung verwendet werden, um einen durchgängigen Datenschutz durch verschlüsselte Kommunikation zwischen Ihrer CloudFront-Verteilung und Ihrem Ursprung zu erreichen.

CloudFront Virtual Private Cloud (VPC) Origins ist ein neues Feature, mit der Sie CloudFront verwenden können, um Inhalte von Anwendungen bereitzustellen, die in einem privaten VPC-Subnetz gehostet werden. Mit VPC Origins können Sie Ihre Anwendungen in einem privaten Subnetz in Ihrer VPC halten, auf das nur über Ihre CloudFront-Verteilungen zugegriffen werden kann. Dadurch entfällt die Anforderung, dass der Ursprung einen extern auflösbaren DNS-Namen (Domain Name Service) haben muss. Sie können VPC Origins mit Anwendungen einrichten, die in Application Load Balancer (ALB), Network Load Balancer (NLB) und EC2-Instances ausgeführt werden. VPC-Ursprünge sind nur in kommerziellen AWS-Regionen verfügbar. Die vollständige Liste der unterstützten AWS-Regionen finden Sie hier.

Sie sollten VPC Origins mit CloudFront verwenden, wenn Sie die Sicherheit Ihrer Web-Anwendungen verbessern und gleichzeitig eine hohe Leistung und globale Skalierbarkeit beibehalten möchten. Mit VPC Origins können Sie den Zugriff auf Ihre Ursprünge in einer VPC nur auf Ihre CloudFront-Verteilungen beschränken, ohne komplexe Konfigurationen wie geheime Kopfzeilen oder Zugriffskontrolllisten zu haben. Mit VPC Origins können Sie auch Ihre IPv4-Kosten optimieren, indem Sie die Weiterleitung zu Ursprüngen in einem privaten Subnetz mit internen IPv4-IP-Adressen kostenlos ermöglichen. VPC Origins ist perfekt, wenn Sie Ihr Sicherheitsmanagement optimieren möchten, sodass Sie sich mehr auf das Wachstum Ihres Kerngeschäfts konzentrieren können, anstatt komplizierte Sicherheitsmaßnahmen zu verwalten.

1. Sicherheit – Mit VPC Origins können Sie den Sicherheitsstatus Ihrer Anwendung verbessern, indem Sie Ihre Load Balancer und EC2-Instances in privaten Subnetzen platzieren, sodass CloudFront zum einzigen Eingangspunkt wird. Benutzeranfragen werden über eine private, sichere Verbindung von CloudFront zu den VPC-Ursprüngen übertragen, was zusätzliche Sicherheit für Ihre Anwendungen bietet.
2. Verwaltung – VPC Origins reduziert den Betriebsaufwand, der für eine sichere CloudFront-Origin-Konnektivität erforderlich ist, indem Sie Ihre Ursprünge in private Subnetze ohne öffentlichen Zugriff verschieben können und ohne Zugriffskontrolllisten, geheime gemeinsame Kopfzeilen oder andere Mechanismen implementieren zu müssen, um den Zugriff auf Ursprünge einzuschränken. Dies vereinfacht die Sicherung Ihrer Web-Anwendungen mit CloudFront, ohne dass Sie in undifferenzierte Entwicklungsarbeit investieren müssen.
3. Skalierbar und leistungsstark – Mit VPC Origins können Kunden die globalen Edge-Standorte und AWS-Backbone-Netzwerke von CloudFront nutzen. Sie profitieren von einer ähnlichen Skalierung und Leistung wie andere bestehende Methoden zur Inhaltsbereitstellung, während sie gleichzeitig einen verbesserten Sicherheitsstatus erhalten. Die Lösung optimiert das Sicherheitsmanagement bei gleichzeitiger globaler Anwendungsbereitstellung für Kunden, sodass Sie CloudFront ganz einfach als zentrale Anlaufstelle für Ihre Anwendungen verwenden können.

Mit CloudFront Virtual Private Cloud (VPC) Origins können Sie CloudFront verwenden, um Inhalte von Anwendungen bereitzustellen, die in einem privaten VPC-Subnetz mit Application Load Balancern, Network Load Balancern und EC2-Instances gehostet werden. Amazon VPC Block Public Access (VPC BPA) ist eine einfache, deklarative Kontrollfunktion, die den eingehenden (Ingress) und ausgehenden (Egress) VPC-Datenverkehr über von AWS bereitgestellte Internetpfade zuverlässig blockiert. Wenn VPC BPA in einem Subnetz mit VPC-Ursprung aktiviert ist, werden aktive Verbindungen von CloudFront zu diesem Subnetz beendet. Es werden keine neuen Verbindungen an das Subnetz gesendet und entweder in ein anderes Subnetz weitergeleitet, in dem sich der VPC-Ursprung befindet, in dem BPA nicht aktiviert ist, oder sie werden gelöscht, wenn in allen Subnetzen, in denen sich der VPC-Ursprung befindet, BPA aktiviert ist.

VPC Origins unterstützt Application Load Balancer, Network Load Balancer und EC2-Instances.

Nein, IPv6 wird von privaten VPC-Ursprüngen nicht unterstützt. Bei VPC Origins benötigen Sie private IPv4-Adressen, die kostenlos sind und für die keine IPv4-Gebühren anfallen.

Ja. Sie können Amazon CloudFront so konfigurieren, dass kundenspezifische Kopfzeilen zu Anforderungen, die an Ihren Ursprung weitergeleitet werden, hinzugefügt werden bzw. den Wert vorhandener Kopfzeilen ü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 Kopfzeilen 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, mit dem Positivliste-Feature für Abfragezeichenfolgen können Sie Amazon CloudFront problemlos so konfigurieren, dass nur bestimmte Parameter im Cache-Schlüssel verwendet werden, während alle Parameter weiterhin an den Ursprung weitergeleitet werden.

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 unterstützt, die in einer HTTP-GET-Zeichenfolge nach dem Zeichen „?“ eingebettet und durch das Zeichen „&“ getrennt sind.

Ja. CloudFront kann automatisch Ihre Text- oder Binärdaten komprimieren. Um dieses Feature 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-Webverteilung 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 AWS-Seite Video on Demand (VOD).

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-Generierungs- 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“.

Media-Quality Aware Resiliency (MQAR) ist eine integrierte Funktion zwischen Amazon CloudFront und AWS Media Services, die eine automatische regionsübergreifende Quellauswahl und einen Failover basierend auf einer dynamisch generierten Videoqualitätsbewertung ermöglicht. Mit MQAR können Sie einen redundanten AWS-Medien-Services-Workflow in zwei verschiedenen AWS-Regionen bereitstellen, um eine ausfallsichere Live-Übertragung von Veranstaltungen zu gewährleisten. Wenn Sie das MQAR-Feature für Ihre Verteilung aktivieren, autorisieren Sie CloudFront, automatisch den Ursprung auszuwählen, der den höchsten Qualitätsfaktor hat. Der Qualitätsfaktor steht für wahrgenommene Qualitätsprobleme beim Medienstreaming von Ihrem Ursprung, z. B. schwarze Bilder, eingefrorene oder ausgelassene Bilder oder wiederholte Frames. Wenn Ihre AWS-Elemental-MediaPackage-v2-Ursprünge beispielsweise in zwei verschiedenen AWS-Regionen bereitgestellt werden und eine einen höheren Wert für die Medienqualität meldet als die andere, wechselt CloudFront automatisch zu dem Ursprung, der den höheren Wert meldet. Dieses Feature simuliert ständig eingeschaltete „menschliche Überwachung“, um Live-Veranstaltungen und Rund-um-die-Uhr-Programmkanäle bereitzustellen, und wurde entwickelt, um Ihren Zuschauern ein qualitativ hochwertiges Erlebnis zu bieten. Weitere Informationen zu MQAR finden Sie im CloudFront-Entwicklerhandbuch.

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 Einzelheiten dafür 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 anbietet. 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.

Statische Anycast-IPs von Amazon CloudFront sind eine Reihe statischer IP-Adressen, mit denen Sie eine Verbindung zu allen CloudFront-Edge-Standorten weltweit herstellen können. Sie bieten eine kleine, statische Liste von IP-Adressen, die für Anwendungsfälle wie Nulltarif, bei der Netzwerkanbieter für bestimmte IP-Adressen mit entsprechenden Vereinbarungen auf Datengebühren verzichten, und für clientseitige Zulassungslisten zur Verbesserung des Sicherheitsstatus verwendet werden können. Durch die Verwendung statischer Anycast-IPs entfällt die betriebliche Herausforderung, Zulassungslisten oder IP-Zuordnungen ständig zu aktualisieren, da dieselben IPs für das gesamte globale Netzwerk von CloudFront funktionieren und dennoch alle Features von CloudFront nutzen können.

Um statische Anycast-IPs zu aktivieren, müssen Sie zunächst eine statische Anycast-IP-Liste in Ihrem AWS-Konto anfordern und erstellen. Sobald die Liste erstellt ist, können Sie Ihre CloudFront-Verteilung(en) mit der statischen Anycast-IP-Liste verknüpfen. Dies kann entweder über den Abschnitt statische Anycast-IP in der AWS-Konsole erfolgen oder indem Sie jede Verteilung bearbeiten und die gewünschte statische Anycast-IP-Liste aus dem Dropdown-Menü auswählen. Nachdem Sie diese Änderungen gespeichert haben, können Sie die spezifischen statischen IP-Adressen, die mit Ihren Verteilungen verknüpft sind, aus der in der AWS-Konsole oder über die APIs angezeigten Liste kopieren oder herunterladen

Sie erhalten 21 IP-Adressen für IPv4, wenn Sie statische CloudFront-Anycast-IP-Adressen aktivieren. Sie müssen all diese IP-Adressen zu allen relevanten Zulassungslisten hinzufügen.

Nein. CloudFront Anycast wird nur mit IP-Adressen verfügbar sein, die über geografische Regionen verteilt sind.

Wenn CloudFront neue Edge-Standorte hinzufügt, bleibt Ihre statische Anycast-IP-Liste weiterhin gültig. Wir werden gegebenenfalls Ihre IP-Adressen von den neuen Edge-Standorten bekannt geben.

Alle CloudFront-Features funktionieren mit Anycast, mit drei wichtigen Ausnahmen: 1/ Statische Anycast-IPs unterstützen keine älteren Clients, die SNI nicht unterstützen, 2/ Sie müssen die Preisklasse All verwenden, wenn Sie statische Anycast-IPs verwenden, und 3/ Sie müssen IPv6 deaktivieren, wenn Sie statische Anycast-IPs verwenden. Statische Anycast-IPs arbeitet in der Phase der DNS-Auflösung. Sobald die Anfrage einen Host erreicht, stehen Ihren Verteilungen weiterhin alle vorhandenen Features und Integrationen mit anderen AWS-Services zur Verfügung.

Sie können die statischen Anycast-IPs mit mehreren Verteilungen verwenden. Sie müssen sich jedoch im selben Konto befinden. Statische CloudFront-Anycast-IPs können mehreren Verteilungen im Konto zugeordnet werden. Die statische CloudFront-Anycast-IP unterstützt Server Name Indication (SNI), sodass das richtige Zertifikat von einer beliebigen Anzahl von Distributionen zurückgegeben wird, die mit ihrer statischen Anycast-IP-Richtlinie verknüpft sind. Wenn Sie unterschiedliche statische IPs für mehrere Verteilungen in Ihrem Konto haben möchten, können Sie eine zusätzliche statische Anycast-IP-Liste erstellen und diese bestimmten Verteilungen zuordnen.

Wenn Sie eine neue Verteilung in einem Konto mit aktivierten statischen Anycast-IPs erstellen, müssen Sie die neue Verteilung explizit Ihrer vorhandenen statischen Anycast-IP-Liste zuordnen. Standardmäßig verwendet sie dynamische IP-Adressen, bis Sie sie mit Ihrer statischen IP-Liste verknüpfen.

Ja. Füllen Sie hier den Antrag auf höhere Grenzwerte aus und wir versehen Ihr Konto binnen zwei Arbeitstagen mit mehr Kapazität.

Den aktuellen Grenzwert für die Anzahl der Verteilungen, die Sie für jedes AWS-Konto erstellen können, finden Sie in der allgemeinen Referenz von Amazon Web Services unter Amazon-CloudFront-Grenzwerte. Zur Beantragung eines höheren Grenzwerts füllen Sie bitte das Formular zur Erhöhung 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.

1. Standardprotokolle (Zugriffsprotokolle) CloudFront-Standardprotokolle enthalten detaillierte Datensätze zu jeder Anfrage, die an eine Verteilung gestellt wird. Diese Protokolle sind für viele Szenarien nützlich, einschließlich Sicherheits- und Zugriffsprüfungen.
2. EchtzeitprotokolleCloudFront-Echtzeitprotokolle liefern Informationen über Anfragen, die an eine Verteilung gestellt wurden, in Echtzeit (Protokolldatensätze werden innerhalb von Sekunden nach Erhalt der Anfragen übermittelt). Sie können die Abtastrate für Ihre Echtzeitprotokolle wählen, d. h. den Prozentsatz der Anfragen, für die Sie Protokolldatensätze in Echtzeit erhalten möchten.
3. Edge-Funktionen protokollieren: Sie können Amazon CloudWatch Logs verwenden, um Protokolle für Ihre Edge-Funktionen, sowohl Lambda@Edge als auch CloudFront-Funktionen, abzurufen. Sie können mit der CloudWatch-Konsole oder der CloudWatch-Logs-API auf die Protokolle zugreifen. Weitere Informationen finden Sie unter Edge-Funktionsprotokolle.
4. Protokollieren der Service-Aktivitäten: Sie können AWS CloudTrail verwenden, um die CloudFront-Service-Aktivität (API-Aktivität) in Ihrem AWS-Konto zu protokollieren. CloudTrail bietet eine Aufzeichnung der API-Aktionen, die von einem Benutzer, einer Rolle oder einem AWS-Service in CloudFront ausgeführt wurden. Anhand der von CloudTrail erfassten Informationen können Sie die API-Anfrage, die an CloudFront gestellt wurde, die IP-Adresse, von der aus die Anfrage gestellt wurde, wer die Anfrage gestellt hat, wann sie gestellt wurde und weitere Details ermitteln. Weitere Informationen finden Sie unter Protokollieren von Amazon-CloudFront-API-Aufrufen mithilfe von AWS CloudTrail.

• CloudFront-Standardprotokolle werden an den Amazon-S3-Bucket Ihrer Wahl, Amazon-CloudWatch-Protokolle und Amazon Data Firehose geliefert. Weitere Informationen finden Sie unter Verwenden von Standardprotokollen (Zugriffsprotokolle).
• CloudFront-Echtzeitprotokolle werden im Datenstrom Ihrer Wahl in Amazon Kinesis Data Streams bereitgestellt. CloudFront Gebühren für Echtzeitprotokolle, zusätzlich zu den Gebühren, die Ihnen für die Nutzung von Kinesis Data Streams entstehen. Weitere Informationen finden Sie unter Verwenden von Echtzeitprotokollen.
• CloudFront-Edge-Funktionsprotokolle (Lambda@Edge und CloudFront-Funktionen) werden an Amazon CloudWatch Logs übermittelt

CloudFront-Standard-Zugriffsprotokolle können an Amazon S3, Amazon CloudWatch und Amazon Data Firehose übermittelt werden. Sie können das Ausgabeprotokollformat auswählen (Plain, W3C, JSON, CSV und Parquet). Sie können auswählen, welche Felder Sie protokollieren möchten und in welcher Reihenfolge diese Felder in die Protokolle aufgenommen werden sollen. Für an S3 übermittelte Protokolle können Sie auch die Partitionierung für an S3 übermittelte Protokolle aktivieren, d. h. Protokolle so konfigurieren, dass sie stündlich oder täglich automatisch partitioniert werden. Sie können auch Standard-Zugriffsprotokolle für Ihre S3-Buckets in Opt-in-AWS-Regionen bereitstellen. Weitere Informationen finden Sie im Abschnitt Standard-Zugriffsprotokolle im CloudFront-Entwicklerhandbuch.

CloudFront erhebt keine Gebühren für die Aktivierung von Standardprotokollen, allerdings fallen je nach Ziel der Protokollübermittlung Gebühren für die Bereitstellung, Speicherung und den Zugriff auf die Protokolle an. Weitere Informationen finden Sie im Abschnitt „Zusätzliche Features“ auf der Seite mit den CloudFront-Preisen.

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 Berichte und Analytik zu Amazon CloudFront in der AWS-Managementkonsole aufrufen. Weitere Informationen zu unseren Berichtsoptionen finden Sie auf der Seite Berichte und Analytik 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 Kennzeichnungen beispielsweise verwenden, um Ressourcen nach Administrator, Anwendungsname, Kostenstelle oder einem speziellen Projekt zu gruppieren. Weitere Informationen zur Kennzeichnung von Kostenzuordnungen finden Sie unter Verwendung von Kennzeichnungen für Kostenzuordnungen. Genaue Details zum Hinzufügen von Kennzeichnungen zu Ihren CloudFront-Verteilungen finden Sie auf der Seite „Amazon-CloudFront-Kennzeichnungen hinzufügen“.

Ja. Zum Abrufen eines Verlaufs aller Amazon-CloudFront-API-Aufrufe, 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. Anschließend können Sie 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 Amazon-CloudFront-Entwicklerhandbuch. Oder rufen Sie die Amazon-CloudFront-Managementkonsole auf und wählen Sie im Navigationsbereich „Überwachung und Alarme“ aus.

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 an Ihren S3-Bucket übermittelt. 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übertragung zu Amazon S3, Amazon Redshift, Amazon OpenSearch Service und Service-Anbietern wie Datadog, New Relic und Splunk. Kinesis Firehose unterstützt auch die Datenübertragung 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.

CloudFront-Funktionen sind eine Serverless Edge-Rechenfunktion, die es Ihnen erlaubt JavaScript Code an den CloudFront-Edge-Standorten für leichte HTTP(s)-Transformationen und -Manipulationen durchzuführen. CloudFront-Funktionen 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 Anfragen pro Sekunde zu unterstützen.

CloudFront-Funktionen 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-Funktionen 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. Mithilfe 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 einer CloudFront-Verteilung verknüpft ist, wird er im weltweit verteilten Netzwerk von Edge-Standorten von AWS bereitgestellt, um als Reaktion auf CloudFront-Anfragen ausgeführt zu werden.

CloudFront-Funktionen eignet sich ideal für leichte, kurzzeitige Funktionen wie die folgenden:

• Cache-Schlüssel-Normalisierung: Sie können HTTP-Anfrageeigenschaften (Kopfzeilen, Abfragezeichenfolgen, Cookies und sogar den relativen Pfad der Anfrage-URL) umwandeln und die Cache-Trefferquote mit dem optimalen Cache-Schlüssel verbessern.
• Kopfzeilenmanipulation: HTTP-Kopfzeilen 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-Weiterleitungen oder -Umschreibungen: Sie können Betrachter auf andere Seiten anhand der Anfrageinformationen umleiten oder alle Anfragen von einem zu einem anderen Pfad umleiten.
• Anfrageberechtigung: Sie können Autorisierungs-Token wie JSON-Web-Tokens (JWT) bewerten, indem Sie Autorisierungskopfzeilen 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 von CloudFront-Funktionen.

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

• URL-Umschreibungen und -Weiterleitungen beibehalten:  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-Funktionen 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-Funktionen verwenden, um diese Token zu validieren, sobald ein Benutzer eine Anfrage für ein Segment aus dem Manifest stellt.

Die Kombination aus CloudFront-Funktionen und Lambda@Edge bietet Ihnen zwei leistungsstarke und flexible Optionen für die Ausführung von Code als Reaktion auf CloudFront-Ereignisse. 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 Seite mit den Anwendungsfällen für Lambda@Edge.

CloudFront-Funktionen 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 erreichen diese Sicherheitsisolierung bereits durch die auf Firecracker basierende VM-Isolierung. Mit CloudFront Functions haben wir ein prozessbasiertes Isolationsmodell entwickelt, das denselben Sicherheitsstandard gegen Seitenkanalangriffe wie Spectre und Meltdown, zeitbasierte Angriffe 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 Funktionen 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. Wird die Funktion erfolgreich ausgeführt und liegt die Metrik „Compute Utilization“ nicht nahe bei 100, können Sie davon ausgehen, dass die Funktion in Verbindung mit einer CloudFront-Verteilung funktioniert.

CloudFront-Funktionen geben 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 Protokollanweisung generiert einen CloudWatch-Protokolleintrag, der an CloudWatch gesendet wird. Protokolle und Metriken sind in Preisen zu 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 Serverless 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 Betrachteranfrage eingeht, wenn eine Anfrage an den Ursprung weitergeleitet oder von diesem zurückgesendet wird oder unmittelbar vor der Antwort an den Endbetrachter). 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 Ihre Funktion getestet haben, verknüpfen Sie sie mit dem ausgewählten CloudFront-Cache-Verhalten und Ereignisauslöser. Nach dem Speichern wird die Funktion bei der nächsten Anfrage an Ihre CloudFront-Verteilung an den CloudFront-Edge weitergeleitet 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:

• Betrachteranforderung: Dieses Ereignis tritt ein, wenn ein Endbenutzer oder ein Gerät im Internet eine HTTP(S)-Anforderung an CloudFront richtet und die Anforderung am zum Benutzer nächstgelegenen Edge-Standort eintrifft.
• Betrachterantwort: 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 Betrachteranforderung 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 in 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-Verteilung über die CloudFront-Konsole, das SDK, die Befehlszeilenschnittstelle (CLI) oder eine CloudFormation-Vorlage mit einer primären Verteilung 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 Staging-Verteilungen validiert sind, können Sie die Änderungen in die Hauptverteilung übernehmen.

Weitere Informationen zu diesem Feature finden Sie in der Dokumentation.

Die kontinuierliche Bereitstellung ermöglicht eine echte Benutzerüberwachung durch echten Web-Datenverkehr. 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 Verteilungen als Basis verwenden, um eine Staging-Verteilung zu erstellen und Änderungen einzuführen und zu testen.

Bei der kontinuierlichen Bereitstellung können Sie der primären und der Staging-Verteilung unterschiedliche Funktionen zuordnen. Sie können die gleiche Funktion auch für beide Distributionen verwenden. Wenn Sie eine Funktion aktualisieren, die von beiden Verteilungen verwendet wird, erhalten beide Verteilungen 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 Datenverkehr an eine Staging-Verteilung weiterzuleiten, können Sie auch die Sitzungsbindung aktivieren. Dadurch wird sichergestellt, dass CloudFront Anfragen desselben Betrachters als eine einzige Sitzung behandelt. Wenn Sie die Sitzungsbindung aktivieren, setzt CloudFront ein Cookie, sodass alle Anfragen desselben Betrachters in einer einzigen Sitzung von einer einzigen Verteilung bedient werden, entweder der primären oder der Staging-Verteilung.

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 über eine numerische IP-Adresse (Internet Protocol) verfügen. 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 lautet: 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. Federal Government – vorgeschriebene Anforderung der Übernahme des IPv6-Standards 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 die gleiche Leistung erzielen, wenn Sie entweder IPv4 oder IPv6 mit Amazon CloudFront verwenden.

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

1. Wenn Sie das Feature „Amazon-CloudFront-Zugriffsprotokolle“ aktiviert haben, wird die IPv6-Adresse Ihrer Betrachter im Feld „c-ip“ angezeigt. Möglicherweise müssen Sie überprüfen, ob Ihre Protokoll-Verarbeitungssysteme weiterhin für IPv6 funktionieren.
2. Wenn Sie IPv6 für Ihre Amazon-CloudFront-Verteilung aktivieren, erhalten Sie IPv6-Adressen in der Kopfzeile „X-Forwarded-For“, die an Ihre Ursprünge gesendet wird. 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 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 vertrauenswürdige Signatur-URLs mit 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 Verteilung, 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 das Feature „Amazon-CloudFront-Zugriffsprotokolle“ 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 Sie Probleme mit IPv6-Datenverkehr haben, die sich auf die Fähigkeit Ihres Tools oder Ihrer Software auswirken, IPv6-Adressen in Zugriffsprotokollen zu verarbeiten. Weitere Einzelheiten finden Sie in der Dokumentation zu den Amazon-CloudFront-Zugriffsprotokollen.

Ja. Über die Amazon-CloudFront-Konsole oder -API können Sie IPv6 für jede einzelne Verteilung (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 zusätzlich zu einer IPv6-Adresse in Ihren detaillierten Zugriffsprotokollen auch IPv6-Adressen in der Kopfzeile „X-Forwarded-For“, der an Ihre Ursprünge gesendet wird. Wenn Ihre Ursprungssysteme nur IPv4-Adressen verarbeiten können, müssen Sie vor Aktivierung von IPv6 für Ihre Verteilung überprüfen, dass Ihre Ursprungssysteme auch mit IPv6-Adressen funktionieren.

Amazon CloudFront verfügt weltweit über eine sehr vielfältige Konnektivität, aber es gibt immer noch bestimmte Netzwerke, die nicht über eine flächendeckende IPv6-Konnektivität verfügen. 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, benötigen Sie nur einen Alias-Eintrag vom Typ „A“. Einzelheiten zu Alias-Ressourcen-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-Preisseite von CloudFront.

Sie können die aktuellen und bisherigen Nutzungsaktivitäten nach Region aufgeschlüsselt ansehen, indem Sie sich bei Ihrem 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 Ihre Kosten mit den Kosten- und Nutzungsberichten 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 CloudFront-Sicherheitssparpaket abonniert haben profitieren ebenfalls vom kostenlosen Kontingent. Wenn Sie aufgrund des kostenlosen Kontingents das Bedürfnis haben, Ihr Engagement für das CloudFront-Sicherheitssparpaket zu reduzieren, wenden Sie sich bitte an den Kundenserive. Wir werden Ihre Änderungswünsche prüfen. Wir werden hierzu in den kommenden Tagen genauere Details bereitstellen. Bitte bleiben Sie dran. 

Bei weiteren Fragen besuchen Sie https://aws.amazon.com/free/free-tier-faqs/.

Die Gebühren für Amazon CloudFront basieren auf der tatsächlichen Nutzung des Services in fünf Bereichen: Datenübertragungen, HTTP/HTTPS-Anfragen, Aufhebungsanfragen, Echtzeit-Protokollanfragen und dedizierte IP-Adressen sowie benutzerdefinierte SSL-Zertifikate, die mit einer CloudFront-Verteilung verbunden sind.

Mit dem kostenlosen Nutzungskontingent von AWS können Sie Amazon CloudFront zum Einstieg kostenlos nutzen und Ihre Gebühren für wachsende Nutzung gering halten. Alle CloudFront-Kunden erhalten 1 TB Datentransfer und 10 000 000 HTTP- und HTTPS-Anfragen für Amazon CloudFront kostenlos, auch wenn diese Grenzen überschritten werden. 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-Ursprungs-Server (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 Gebühren für Amazon-CloudFront-Datenübertragungen zum Ursprung finden Sie hier.
• HTTP-/HTTPS-Anfragen
  Die Anzahl der an Amazon CloudFront gerichteten HTTP-/HTTPS-Anfragen Ihrer Inhalte wird Ihnen in Rechnung gestellt. Die Gebühren für HTTP-/HTTPS-Anfragen finden Sie hier.
• Aufhebungsanfragen
  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 Gebühren für Aufhebungsanfragen finden Sie hier.
• Echtzeit-Protokollanfrageb
  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. Um die Unterstützung für dedizierte IP-Adressen und benutzerdefinierte SSL-Zertifikate zu nutzen, laden Sie ein SSL-Zertifikat hoch und verknüpfen Sie es über die AWS-Managementkonsole mit Ihren CloudFront-Verteilungen. Wenn Sie Ihrer CloudFront-Verteilung mehr als zwei benutzerdefinierte SSL-Zertifikate zuweisen müssen, geben Sie im Formular zum Erhöhen des CloudFront-Grenzwerts Details zu Ihrem Anwendungsfall sowie die Anzahl der benötigten benutzerdefinierten Zertifikate an.

Nutzungskontingente für Datenübertragungen werden für jede geografische Region separat 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, darunter MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechnungsadresse unterliegt die Nutzung von AWS-Services der japanischen Verbrauchssteuer. Weitere Informationen.

Wenn Sie über eine Verteilung verfügen, die 1 000 Anfragen pro Sekunde mit einer Protokollgröße von 1 KB bedient, und einen Kinesis-Datenstrom in USA Ost (Ohio) mit 2 Shards erstellen:

Monatliche Kosten für Kinesis-Datenstroms: 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

Ein 304 ist eine Antwort auf eine bedingte GET-Anfrage und führt zu einer Gebühr für die HTTP-/HTTPS-Anfrage und die Datenübertragung ins Internet. 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 Datenübertragungsmenge hängt von den mit Ihrem Objekt verbundenen Kopfzeilen ab.

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 stellt Amazon CloudFront Ihre Inhalte von Edge-Standorten der gewählten Preisklasse zu. Entsprechend werden nur die Datenbereitstellungs- und Anforderungspreise der Standorte berechnet, von denen die Inhalte übertragen 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 die Gebühr 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 Self-Service-Preispaket, mit dem Sie bis zu 30 % Ihrer CloudFront-Kosten einsparen können, wenn Sie sich für einen Zeitraum von einem Jahr zu einer konstanten monatlichen Nutzung (z. B. 100 USD/Monat) 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 ausgewiesen wird und alle in Rechnung gestellten CloudFront-Nutzungstypen ausgleicht. Dazu gehören Datenübertragungen aus dem CloudFront-Netzwerk, Datenübertragungen zum Ursprungsserver, HTTP/S-Anfragegebühren, Verschlüsselungsanfragen auf Feldebene, Origin Shield, Ungültigkeitserklärungen, dedizierte IP-Adressen, benutzerdefiniertes SSL, Anycast-statische IPs, Lambda@Edge, CloudFront-Funktionen, Echtzeitprotokolle, regionale Edge-Cache-Nutzung, gRPC, WebSocket-Unterstützung und andere CloudFront-Funktionen. Sie erhalten außerdem zusätzliche Vorteile, die Ihnen dabei helfen, die AWS-WAF-Nutzung im Zusammenhang mit Ihren CloudFront-Verteilungen abzudecken.

Sie können mit dem CloudFront-Sicherheitssparpaket beginnen, indem Sie die CloudFront-Konsole besuchen, um Empfehlungen zum Verpflichtungsbetrag basierend auf Ihrer bisherigen 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 das richtige Paket für Ihre Anforderungen auszuwählen.  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 Service-Gebühren an. 

Sobald die Laufzeit Ihres CloudFront-Sicherheitssparpakets abläuft, fallen die üblichen Service-Gebü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 Pakets dafür entscheiden, das CloudFront-Sicherheitssparpaket automatisch um ein weiteres Jahr zu verlängern.

Das CloudFront-Sicherheitssparpaket kann in jedem Konto innerhalb einer AWS-Organisation/konsolidierten Fakturierungsfamilie 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 Fakturierungsfamilie (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 abonnieren.  Bei Fragen zu Ihrer individuellen Preisvereinbarung wenden Sie sich bitte an Ihren AWS-Kundenbetreuer.

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