CloudFront-Distributionen und Origins

Amazon CloudFront ist das globale Content Delivery Network (CDN) von AWS, das Inhalte von Edge-Standorten in mehr als 400 Städten in über 90 Ländern zwischenspeichert und ausliefert. Wenn ein Benutzer Inhalte anfordert, liefert CloudFront sie vom nächstgelegenen Edge-Standort aus. Dadurch wird die Latenz im Vergleich zum Abruf vom Ursprungsserver erheblich reduziert.

CloudFront ist nicht nur für statische Dateien geeignet, sondern beschleunigt auch dynamische Inhalte, APIs und Videostreaming. Es lässt sich in andere AWS-Services wie S3, ALB, Lambda@Edge, WAF und Shield integrieren und ist damit die standardmäßige Distributionsebene moderner AWS-Architekturen.

Eine CloudFront-Distribution ist die zentrale Konfigurationseinheit. Sie definiert: einen oder mehrere Ursprünge (Speicherorte der Inhalte), Cache-Verhaltensweisen (wie verschiedene URL-Pfade zwischengespeichert werden), Sicherheitseinstellungen und Preisstufen. Sie greifen über den Domänennamen der Distribution (z. B. d1234abcdef.cloudfront.net) oder eine benutzerdefinierte Domäne (z. B. cdn.example.com) mithilfe eines CNAME- oder ALIAS-Datensatzes auf Ihre Inhalte zu.

Nach der Erstellung benötigen Distributionen 10–15 Minuten, um weltweit an allen Edge-Standorten bereitgestellt zu werden. Änderungen an einer bestehenden Distribution benötigen ebenfalls mehrere Minuten für die Verteilung. Historisch gab es zwei Distributionstypen, heute verwenden jedoch alle Distributionen eine einheitliche Konfigurationsoberfläche.

Die Verwendung eines S3-Buckets als CloudFront-Ursprung ist eines der häufigsten Muster. CloudFront ruft Objekte aus S3 ab, speichert sie an Edge-Standorten zwischen und liefert nachfolgende Anfragen aus dem Cache aus, ohne erneut auf S3 zuzugreifen. Dadurch werden die Kosten für S3-Anfragen gesenkt, die Latenz für globale Benutzer verbessert und die von S3 bereitgestellte Bandbreite entlastet.

Um eine von S3 unterstützte Website bereitzustellen, müssen Sie den Bucket nicht öffentlich machen. Verwenden Sie stattdessen Origin Access Control (OAC) – den modernen Ersatz für Origin Access Identity (OAI). OAC gewährt nur der CloudFront-Distribution die Berechtigung, aus dem Bucket zu lesen. Dadurch bleibt S3 privat, während CloudFront die Inhalte öffentlich bereitstellt.

CloudFront unterstützt auch benutzerdefinierte Ursprünge: beliebige über das Internet erreichbare HTTP- oder HTTPS-Server, darunter EC2-Instances, Application Load Balancer, API-Gateway-Endpunkte und lokale Server. Benutzerdefinierte Ursprünge ermöglichen das Zwischenspeichern und Beschleunigen dynamischer Anwendungen und APIs, nicht nur statischer Dateien.

Wenn Sie einen ALB als benutzerdefinierten Ursprung verwenden, konfigurieren Sie die Sicherheitsgruppe des ALB so, dass sie nur Verbindungen aus den CloudFront-IP-Bereichen akzeptiert. Dadurch wird der gesamte externe Datenverkehr durch CloudFront geleitet. So können WAF-Regeln und die TLS-Terminierung am Edge genutzt werden, während der ALB innerhalb von AWS bleibt.

Origin Access Identity (OAI) war die ursprüngliche Methode, um den Zugriff eines CloudFront-Service auf einen S3-Bucket zu beschränken. Dabei handelt es sich um eine spezielle CloudFront-Benutzeridentität, der in der S3-Bucket-Richtlinie Berechtigungen erteilt werden. OAI funktioniert weiterhin, gilt jedoch als veraltet.

Origin Access Control (OAC) ist der moderne Ersatz. OAC unterstützt alle S3-Bucket-Typen (einschließlich S3 in AWS-China-Regionen und mit SSE-KMS verschlüsselter Buckets), verwendet IAM-Service-Principals für eine granularere Kontrolle und signiert Anfragen an S3 automatisch mit SigV4. Verwenden Sie für neue Distributionen immer OAC anstelle von OAI.

Die Protokollrichtlinie für Betrachter steuert, wie CloudFront Verbindungen zwischen Benutzern (Betrachtern) und dem Edge-Standort verarbeitet:

• HTTP und HTTPS: Beide Protokolle zulassen; für vertrauliche Inhalte nicht empfohlen
• HTTP zu HTTPS umleiten: HTTP-Anfragen transparent an HTTPS umleiten; die häufigste Einstellung
• Nur HTTPS: HTTP-Verbindungen vollständig ablehnen; für eine strikte Durchsetzung von TLS verwenden

Die Protokollrichtlinie für den Ursprung steuert unabhängig davon, wie CloudFront mit Ihrem Ursprung kommuniziert: nur HTTP, nur HTTPS oder Übereinstimmung mit dem Betrachter. Bei S3-Ursprüngen mit OAC verwendet CloudFront immer HTTPS.

Um Inhalte unter cdn.example.com statt unter der CloudFront-Domain bereitzustellen, konfigurieren Sie in der Distribution einen alternativen Domainnamen (CNAME) und verknüpfen ein SSL/TLS-Zertifikat aus dem AWS Certificate Manager (ACM). Das ACM-Zertifikat muss sich in der Region us-east-1 befinden (unabhängig davon, wo Ihre Distribution Datenverkehr bedient), da CloudFront ein globaler Service ist, der von us-east-1 aus verwaltet wird.

Erstellen Sie den Route-53-Eintrag als ALIAS-Eintrag, der auf den Domainnamen der CloudFront-Distribution verweist. CloudFront stellt Ihr Zertifikat automatisch für passende SNI-Anfragen bereit.

Die Preisklasse von CloudFront legt fest, welche Edge-Standorte für die Bereitstellung Ihrer Distribution verwendet werden. Höhere Preisklassen schließen teurere Edge-Standorte ein (in der Regel in Regionen mit höheren Bandbreitenkosten):

• Price Class 100: nur Nordamerika und Europa (niedrigste Kosten)
• Price Class 200: Nordamerika, Europa, Asien, Naher Osten und Afrika
• Price Class All: alle Edge-Standorte weltweit (beste Performance, höchste Kosten)

Verwenden Sie Price Class 100 für interne Tools oder Zielgruppen, die auf Nordamerika und Europa beschränkt sind. Verwenden Sie Price Class All für Anwendungen für Verbraucher mit tatsächlich globaler Zielgruppe.

Origin-Gruppen ermöglichen das Origin-Failover von CloudFront. Sie definieren in einer Gruppe einen primären und einen sekundären Origin. Gibt der primäre Origin einen bestimmten HTTP-Fehlercode zurück (z. B. 500, 502, 503 oder 504), wiederholt CloudFront die Anfrage automatisch beim sekundären Origin.

Origin-Failover eignet sich für die Notfallwiederherstellung: Verwenden Sie einen primären S3-Bucket in us-east-1 und ein repliziertes Backup in us-west-2 als sekundären Origin. Bei einem S3-Ausfall führt CloudFront transparent ein Failover durch, ohne dass DNS-Änderungen erforderlich sind. Dieses Muster ergänzt die S3 Cross-Region Replication.

CloudFront kann Zugriffsprotokolle an einen S3-Bucket übermitteln. Darin werden Details zu jeder Viewer-Anfrage aufgezeichnet: Zeitstempel, Edge-Standort, Statuscode, übertragene Bytes, Cache-Treffer oder -Fehler, User-Agent und weitere Informationen. Die Protokolle werden alle paar Minuten stapelweise übermittelt.

Verwenden Sie Zugriffsprotokolle, um Datenverkehrsmuster zu analysieren, stark nachgefragte Inhalte zu identifizieren, sicherheitsrelevante Felder (IP-Adresse, Referrer, User-Agent) zu überprüfen und Cache-Trefferquoten zu messen. Das Feld x-edge-result-type gibt an, ob die Anfrage am Edge ein Hit, Miss oder RefreshHit war.

CloudFront verfügt über eine zweistufige Caching-Infrastruktur:

• Edge-Standorte: weltweit Hunderte von PoPs in der Nähe der Endnutzer; stellen gecachte Inhalte mit minimaler Latenz bereit
• Regional Edge Caches (RECs): 13 größere Caches mit längerer Lebensdauer zwischen Edge-Standorten und Origins; stellen Inhalte bereit, die nicht beliebt genug sind, um in den kleinen Caches der Edge-Standorte zu bleiben

Wenn eine Anfrage im Cache des Edge-Standorts nicht gefunden wird, prüft CloudFront den REC, bevor die Anfrage bis zum Origin weitergeleitet wird. RECs arbeiten transparent – Sie konfigurieren sie nicht direkt –, verbessern jedoch die Cache-Trefferquoten für weniger häufig angeforderte Inhalte erheblich und reduzieren die Last auf dem Origin.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: CloudFront-Distributionen cachen Inhalte weltweit an Edge-Standorten, OAC hält S3-Buckets privat und ermöglicht CloudFront dennoch den Zugriff und benutzerdefinierte Origins unterstützen ALBs, API Gateway und beliebige HTTP-Server. ACM-Zertifikate für CloudFront müssen in us-east-1 bereitgestellt werden. Als Nächstes sehen wir uns Cache-Verhalten und TTL-Einstellungen an.