0Pricing
AWS Solutions Architect · Lektion

Cache-Verhalten und TTL-Einstellungen

Definieren Sie pfadbasierte Cache-Verhaltensweisen, legen Sie minimale, standardmäßige und maximale TTLs fest und verwenden Sie Cache-Control-Header zur Feinabstimmung des Cachings.

Cache-Verhalten und TTL-Einstellungen ist eine kostenlose AWS Solutions Architect-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des AWS Solutions Architect-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der AWS Solutions Architect-Kurs umfasst insgesamt 4 Lektionen.

Cache-Verhalten: Was ist das?

Cache-Verhalten sind Regeln, die CloudFront mitteilen, wie Anfragen für unterschiedliche URL-Pfadmuster verarbeitet werden sollen. Jedes Cache-Verhalten ordnet ein Pfadmuster (z. B. /images/*, /api/*, *.css) einem bestimmten Origin und einer bestimmten Caching-Konfiguration zu.

Eine Distribution verfügt über ein Standard-Cache-Verhalten (für alle Pfade, die nicht von spezifischeren Verhaltensregeln erfasst werden) sowie über bis zu 25 zusätzliche pfadbasierte Verhaltensregeln. CloudFront wertet die Verhaltensregeln in der Reihenfolge vom spezifischsten zum allgemeinsten aus und verwendet anschließend das Standardverhalten.

Abgleich von Pfadmustern

Pfadmuster unterstützen Platzhalter: * entspricht einer beliebigen Zeichenfolge einschließlich Schrägstrichen, und ? entspricht genau einem beliebigen Zeichen. Beispiele:

  • /images/* — alle URLs, die mit /images/ beginnen
  • *.jpg — alle Anfragen, die unabhängig von ihrer Position im Pfad mit .jpg enden
  • /api/v2/* — alle API-v2-Routen
  • /static/??.css — statische CSS-Dateien mit genau zwei Zeichen vor .css

Die Verhaltensregeln werden in der Reihenfolge ausgewertet, in der sie in der Distributionskonfiguration aufgeführt sind. Platzieren Sie spezifischere Muster an erster Stelle. Das Standardverhalten (*) wird immer zuletzt angewendet.

Cache-Richtlinie im Vergleich zur Origin-Request-Richtlinie

CloudFront trennt die Caching-Logik in zwei Richtlinientypen:

  • Cache-Richtlinie: definiert, welche Komponenten CloudFront als Cache-Schlüssel verwendet – die Kombination aus Headern, Query-Strings und Cookies, anhand derer bestimmt wird, ob ein gecachtes Objekt zu einer Anfrage passt. Legt außerdem die TTL-Grenzen fest.
  • Origin-Request-Richtlinie: definiert, welche Header, Query-Strings und Cookies an den Origin weitergeleitet werden, auch wenn sie nicht Bestandteil des Cache-Schlüssels sind (so können Authentifizierungsheader an den Origin gesendet werden, ohne den Cache für jedes Token getrennt zu führen)

AWS stellt verwaltete Richtlinien (z. B. CachingOptimized, CachingDisabled) für die meisten Anwendungsfälle bereit. Alternativ können Sie eigene Richtlinien erstellen.

TTL-Einstellungen in CloudFront

CloudFront berücksichtigt drei TTL-Werte aus der Cache-Richtlinie:

  • Minimale TTL: die kürzeste Zeit, für die CloudFront ein Objekt unabhängig von den Headern des Origins cached (Standard: 0)
  • Standard-TTL: die Zeit, für die CloudFront ein Objekt cached, wenn der Origin keinen Cache-Control- oder Expires-Header sendet (Standard: 86.400 Sekunden = 1 Tag)
  • Maximale TTL: die längste Zeit, für die CloudFront ein Objekt cached; begrenzt die Cache-Control max-age-Direktive des Origins (Standard: 31.536.000 Sekunden = 1 Jahr)

Diese drei Werte begrenzen die tatsächliche Cache-Dauer, die von den Origins über Cache-Control-Header vorgegeben wird.

Cache-Control-Header von Origins

Wenn Ihr Origin einen Header Cache-Control: max-age=3600 sendet, cached CloudFront das Objekt 3.600 Sekunden lang, sofern dieser Wert innerhalb der Grenzen für minimale und maximale TTL der Cache-Richtlinie liegt. Sendet der Origin Cache-Control: no-cache oder Cache-Control: no-store, prüft CloudFront jedes Mal beim Ausliefern der gecachten Kopie beim Origin nach.

Für statische Assets, die sich selten ändern, sollten Sie einen langen Wert für max-age festlegen (z. B. 31536000 = 1 Jahr) und Cache Busting verwenden – nehmen Sie einen Content-Hash in die Dateinamen auf (z. B. app.a3f4b5.js) –, damit sich die URL bei einer Inhaltsänderung ändert und die alte gecachte Version automatisch ungültig wird.

# S3 object metadata with long cache TTL
aws s3 cp app.a3f4b5.js s3://my-bucket/ \
  --cache-control 'max-age=31536000, immutable' \
  --content-type 'application/javascript'

Statische und dynamische Verhaltensregeln trennen

Ein leistungsfähiges Muster für Cache-Verhalten trennt statische und dynamische Inhalte:

  • /static/*, *.css, *.js, *.jpg → S3-Origin, Richtlinie CachingOptimized (hohe TTL, keine Cookies oder Query-Strings im Cache-Schlüssel)
  • /api/* → ALB-Origin, Richtlinie CachingDisabled (wird immer vom Origin abgerufen, alle Header und Cookies werden weitergeleitet)
  • /* (Standard) → ALB-Origin, moderates Caching

Dadurch wird die gut cachebare statische Ebene von der dynamischen API-Ebene getrennt. So werden die Cache-Trefferquoten für statische Inhalte maximiert, während API-Antworten stets aktuell bleiben.

Cache-Invalidierung

Wenn Sie Inhalte in S3 oder auf Ihrem Origin aktualisieren und die neue Version sofort über CloudFront bereitstellen möchten, ohne den Ablauf der TTL abzuwarten, erstellen Sie eine Cache-Invalidierung. Geben Sie die zu invalidierenden Pfade an (z. B. /images/logo.png oder /images/*); CloudFront entfernt diese Objekte aus allen Edge-Caches.

Invalidierungen verursachen Kosten: Die ersten 1.000 Pfade pro Monat sind kostenlos, für zusätzliche Pfade wird jeweils eine Gebühr erhoben. Wildcard-Invalidierungen (z. B. /*) zählen als ein Pfad. Als Best Practice sollten Sie für statische Assets versionierte Dateinamen (Cache Busting) statt häufiger Invalidierungen verwenden, um Kosten und Verzögerungen zu reduzieren.

# Create a cache invalidation for updated images
aws cloudfront create-invalidation \
  --distribution-id EDFDVBD6EXAMPLE \
  --paths '/images/logo.png' '/css/main.css'

Bestandteile des Cache-Schlüssels

Der Cache-Schlüssel ist die eindeutige Kennung, mit der CloudFront nach einer gecachten Antwort sucht. Standardmäßig besteht der Cache-Schlüssel nur aus dem URL-Pfad. Werden zusätzliche Bestandteile aufgenommen, erhöht sich die Anzahl unterschiedlicher Cache-Einträge:

  • Query-Strings: /search?q=aws und /search?q=s3 sind separate Cache-Einträge, wenn q Bestandteil des Cache-Schlüssels ist
  • Header: Durch die Aufnahme von Accept-Encoding kann CloudFront gzip- und Nicht-gzip-Versionen getrennt cachen
  • Cookies: Die Aufnahme von Sitzungscookies erzeugt benutzerspezifische Cache-Einträge und deaktiviert das Caching praktisch

Minimieren Sie die Bestandteile des Cache-Schlüssels, um die Cache-Effizienz zu maximieren. Nehmen Sie nur Bestandteile auf, die tatsächlich unterschiedliche Antwortinhalte erzeugen.

Komprimierung am Edge

CloudFront kann textbasierte Objekte (HTML, CSS, JavaScript, JSON) vor der Auslieferung an Viewer automatisch mit gzip oder Brotli komprimieren. Dadurch wird die Nutzlast um 60–80 % reduziert und die Ladezeit von Seiten verbessert, ohne dass Änderungen an Ihrem Origin erforderlich sind.

So aktivieren Sie die Komprimierung: Stellen Sie sicher, dass die Cache-Richtlinie Accept-Encoding im Cache-Schlüssel enthält (CloudFront muss gzip- und Nicht-gzip-Versionen getrennt cachen), und aktivieren Sie Compress Objects Automatically im Cache-Verhalten. CloudFront komprimiert Objekte mit einer Größe von mehr als 1.000 Bytes und weniger als 10 MB.

Cache-Trefferquote und Monitoring

Die Cache-Trefferquote ist der Prozentsatz der Anfragen, die aus dem CloudFront-Cache bedient werden, ohne den Origin aufzurufen. Eine hohe Trefferquote (80 % oder mehr) bedeutet geringere Origin-Kosten und bessere Performance. Überwachen Sie sie über den Bericht Cache Statistics in der CloudFront-Konsole oder über die CloudWatch-Metrik CacheHitRate.

Folgende Maßnahmen verbessern die Cache-Trefferquote: Erhöhen Sie die TTL-Werte, reduzieren Sie die Anzahl der Header und Cookies im Cache-Schlüssel, verwenden Sie eine Normalisierung von Query-Strings (leiten Sie nur die Query-Strings weiter, die Ihre Anwendung tatsächlich verwendet) und setzen Sie am Origin passende Cache-Control-Header.

# Get CloudFront metrics for cache hit rate
aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront \
  --metric-name CacheHitRate \
  --dimensions Name=DistributionId,Value=EDFDVBD6EXAMPLE \
  --start-time 2026-06-19T00:00:00Z \
  --end-time 2026-06-20T00:00:00Z \
  --period 3600 \
  --statistics Average \
  --region us-east-1

Origin- und Protokolleinstellungen pro Verhalten

Jedes Cache-Verhalten kann auf einen anderen Origin verweisen. Dadurch kann eine einzelne CloudFront-Distribution Inhalte aus mehreren Backends bereitstellen. Zum Beispiel:

  • /static/* → S3-Origin (privater Bucket über OAC)
  • /api/* → ALB-Origin in us-east-1
  • /media/* → MediaPackage-CDN-Origin für Video-Streaming

Jedes Verhalten konfiguriert außerdem unabhängig die Viewer Protocol Policy, die Allowed HTTP Methods und die Funktionszuordnungen (CloudFront Functions oder Lambda@Edge). Dadurch wird eine einzelne Distribution zu einer flexiblen, vielseitig einsetzbaren Bereitstellungsschicht.

Schnelltest

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

Lektionszusammenfassung

In dieser Lektion haben Sie gelernt: Cache-Verhalten ordnen URL-Pfadmuster Origins und Caching-Regeln zu, die minimalen, standardmäßigen und maximalen TTL-Werte begrenzen, wie lange Inhalte gecached werden, wobei die Cache-Control-Header des Origins Vorrang haben, wenn sie vorhanden sind, und Cache-Invalidierungen entfernen veraltete Inhalte sofort aus allen Edge-Standorten. Minimieren Sie die Bestandteile des Cache-Schlüssels, um die Trefferquote zu maximieren. Als Nächstes sehen wir uns signierte URLs, signierte Cookies und geografische Einschränkungen an.

Häufig gestellte Fragen

Ist die Lektion „Cache-Verhalten und TTL-Einstellungen“ kostenlos?

Ja — der vollständige Text von „Cache-Verhalten und TTL-Einstellungen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des AWS Solutions Architect-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der AWS Solutions Architect-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Cache-Verhalten und TTL-Einstellungen“?

Definieren Sie pfadbasierte Cache-Verhaltensweisen, legen Sie minimale, standardmäßige und maximale TTLs fest und verwenden Sie Cache-Control-Header zur Feinabstimmung des Cachings. Du übst AWS Solutions Architect mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um AWS Solutions Architect zu starten?

Keine Vorkenntnisse erforderlich. AWS Solutions Architect auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „Cache-Verhalten und TTL-Einstellungen“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser AWS Solutions Architect-Lektion Code schreiben und ausführen?

Ja. Jede AWS Solutions Architect-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. CloudFront-Distributionen und Origins
  2. Cache-Verhalten und TTL-Einstellungen
  3. Signierte URLs, signierte Cookies und Geoblocking
  4. CloudFront mit WAF und Lambda@Edge
← Zurück zu AWS Solutions Architect