View a markdown version of this page

CloudFront für E-Commerce- und Marktplatz-Anwendungen - Amazon CloudFront

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

CloudFront für E-Commerce- und Marktplatz-Anwendungen

Eine E-Commerce- oder Marketplace-Anwendung bietet drei verschiedene Inhaltstypen über eine einzige CloudFront Distribution: statische Inhalte (Produktbilder, CSS, JavaScript), dynamische Seiten (Produktangebote, Suchergebnisse) und API-Antworten (Warenkorb, Inventar, Preise). Jeder Inhaltstyp erfordert ein anderes Cacheverhalten, eine andere TTL- und Quellkonfiguration, um ein ausgewogenes Verhältnis zwischen Aktualität und Leistung herzustellen.

Die Sicherheitskontrollen, die für Marketplace- und E-Commerce-Distributionen gelten, finden Sie unter. Sicherheitscheckliste für Marketplace-Distributionen

Übersicht über die Architektur

Eine CloudFront Marketplace-Distribution verwendet mehrere Cache-Verhaltensweisen, um Anfragen anhand von URL-Pfadmustern an den richtigen Ursprung weiterzuleiten. Statische Ressourcen werden vom Amazon Simple Storage Service (Amazon S3) bereitgestellt, während dynamische Inhalte und API-Anfragen an ein Elastic Load Balancing (Application Load Balancer) weitergeleitet werden, das sich vor Ihren Anwendungsservern befindet. Ein ElastiCache (Valkey-) Cluster bietet einen Cache auf Anwendungsebene zwischen dem ALB und Ihrer Datenbank für Produktdaten, auf die häufig zugegriffen wird.

Komponenten der Distributionsarchitektur
Komponente Bereitgestellter Inhalt Zweck

CloudFront Verteilung

Alle Inhalte (einzelne Domain)

Globales Edge-Caching, TLS-Terminierung, Anforderungsrouting unter Verwendung des Cache-Verhaltens

Amazon S3-Ursprung (statische Ressourcen)

Produktbilder, CSS, JS, Schriftarten

Dauerhafter Objektspeicher mit Origin Access Control (OAC). Unveränderlicher Inhalt mit langen TTLs.

ALB-Ursprung (dynamischer Inhalt)

Produktseiten, Suche, API-Endpunkte

Routen zu Anwendungsservern. Kurze TTLs oder kein Caching für personalisierte Inhalte.

ElastiCache Cluster (Valkey)

Produktkatalog, Inventarzahlen, Sitzungsdaten

Application-level Cache zwischen ALB und Datenbank. Sub-millisecond liest Daten, auf die häufig zugegriffen wird.

Verhalten für E-Commerce zwischenspeichern

Das Cache-Verhalten bestimmt, wie Anfragen auf der Grundlage von URL-Pfadmustern CloudFront behandelt werden. Konfigurieren Sie für einen Marktplatz separate Verhaltensweisen für jeden Inhaltstyp mit den entsprechenden Cache-Richtlinien und TTLs.

Empfohlenes Cache-Verhalten
Pfadmuster Origin TTL Cache-Richtlinie Begründung

/static/*

Amazon S3

365 Tage

CachingOptimized

Bei versionierten Dateinamen (z. B.app.a1b2c3.js) ist ein maximaler TTL-Wert zulässig. Eine Cache-Invalidierung ist nie erforderlich — stellen Sie neue Versionen mit neuen Dateinamen bereit.

/images/*

Amazon S3

30 Tage

CachingOptimized

Produktbilder ändern sich selten. Verwenden Sie die Cache-Tag-Invalidierung, wenn ein Verkäufer ein Bild aktualisiert. Niedrigerer TTL-Wert als bei statischen Assets, da Bild-URLs möglicherweise wiederverwendet werden.

/api/products/*

ALB

60 Sekunden

Benutzerdefiniert (einschließlich Abfragezeichenfolgen)

Produktlisten- und Such-APIs ändern sich häufig, tolerieren aber kurzzeitige Veraltbarkeit. Fügen Sie Abfragezeichenfolgenparameter für Paginierung und Filter in den Cache-Schlüssel ein.

/api/cart/*

ALB

0 (kein Cache)

CachingDisabled

Warenkorboperationen sind benutzerspezifisch und müssen immer den Ursprung erreichen. Deaktivieren Sie das Caching vollständig.

/api/inventory/*

ALB

5 Sekunden

Benutzerdefiniert (einschließlich Abfragezeichenfolgen)

Die Anzahl der Lagerbestände ändert sich bei Verkaufsveranstaltungen schnell. Ein sehr kurzes TTL verhindert Überverkäufe und reduziert gleichzeitig die Ursprungslast.

Default (*)

ALB

0 (kein Cache)

CachingDisabled

Das Standardverhalten leitet nicht zwischengespeicherte Anfragen zum serverseitigen Rendern an die Anwendung weiter. Seiten, die personalisierte Inhalte (Empfehlungen, Benutzername) enthalten, sollten nicht am Edge zwischengespeichert werden.

Anmerkung

Ordne das Verhalten im Cache von den spezifischsten bis hin zu den unspezifischsten an. CloudFront wertet Pfadmuster in der angegebenen Reihenfolge aus und verwendet die erste Übereinstimmung. Platziere /api/cart/* davor/api/*, um sicherzustellen, dass Warenkorbanfragen das Caching umgehen.

Weitere Informationen zu Cache-Verhalten finden Sie unter Einstellungen für das Cache-Verhalten.

TTL-Strategie für Marketplace-Inhalte

Die TTL-Konfiguration bestimmt, wie lange CloudFront zwischengespeicherte Inhalte bereitgestellt werden, bevor der Ursprung auf Aktualisierungen überprüft wird. E-commerce Anwendungen erfordern unterschiedliche TTL-Strategien, je nachdem, wie sich die Aktualität der Inhalte auf das Kundenerlebnis auswirkt.

Unveränderliche Ressourcen (CSS, JS, Schriftarten)

Stellen Sie die maximale TTL (365 Tage) ein. Verwenden Sie Dateinamen mit Inhalts-Hash, sodass bei jeder Bereitstellung neue URLs erstellt werden. Niemals ungültig machen — alte Versionen laufen auf natürliche Weise ab, wenn Benutzer die neuen Dateinamen laden. Cache-Control: public, max-age=31536000, immutableAm Ursprung festgelegt.

Bilder des Produkts

Stellen Sie TTL auf 30 Tage ein, wobei das Cache-Tag beim Update ungültig wird. Wenn ein Verkäufer ein neues Bild hochlädt, wird es anhand des Cache-Tags des Produkts ungültig gemacht und nicht anhand des Pfads. Dies zielt nur auf die betroffenen Objekte ab, ohne eine pauschale Invalidierung durch Platzhalter. Cache-Control: public, max-age=2592000Am Ursprung festgelegt.

Produktkatalog-API

Stellen Sie TTL auf 60 Sekunden ein. Produktangebote, Beschreibungen und Preise tolerieren kurzzeitige Veraltbarkeit. Dadurch wird die Quelllast bei Verkehrsspitzen (Blitzverkäufe, Produkteinführungen) reduziert und gleichzeitig die Daten einigermaßen aktuell gehalten. Wird so eingestelltCache-Control: public, max-age=60, stale-while-revalidate=30, dass veraltete Inhalte bereitgestellt werden, während im CloudFront Hintergrund eine neue Antwort abgerufen wird.

API für Inventar und Preisgestaltung

Stellen Sie TTL auf 5 Sekunden ein. Diese Werte ändern sich häufig und wirken sich auf Kaufentscheidungen aus. Durch sehr kurzes Caching wird die Ausgangslast bei Datenverkehrsspitzen immer noch um ein Vielfaches reduziert. Tausende von gleichzeitigen Benutzern erhalten dieselbe zwischengespeicherte Antwort von 5 Sekunden, anstatt dass jeder den Ursprung erreicht.

User-specific Inhalt (Warenkorb, Empfehlungen)

Deaktivieren Sie das Caching (TTL = 0). Inhalte, die je nach Benutzer unterschiedlich sind, müssen immer den Ursprung erreichen. Wenn Sie versehentlich benutzerspezifische Inhalte zwischenspeichern, werden CloudFront möglicherweise die Daten eines Benutzers an einen anderen Benutzer weitergegeben. Verwenden Sie die CachingDisabled verwaltete Richtlinie für diese Verhaltensweisen.

Origin-Konfiguration

Amazon S3-Ursprung für statische Assets

Verwenden Sie einen Amazon S3-Bucket als Ursprung für Produktbilder und statische Assets. Konfigurieren Sie Origin Access Control (OAC), um den direkten Zugriff auf den Bucket einzuschränken — alle Anfragen müssen CloudFront durchgehen.

Amazon S3-Ursprungseinstellungen
Einstellung Wert Begründung

Ursprungsdomäne

marketplace-assets.s3.amazonaws.com

Verwenden Sie den Amazon S3-REST-API-Endpunkt (nicht den Website-Endpunkt), um OAC zu unterstützen.

Ursprungszugriff

Origin Access Control (OAC)

Beschränkt den Bucket-Zugriff nur auf CloudFront . Verhindert den direkten S3-URL-Zugriff auf Ihre Assets.

Origin Shield

Aktiviert (Region, die dem Bucket am nächsten liegt)

Fügt eine zentrale Caching-Ebene zwischen den Kantenpositionen und dem Ursprung hinzu. Reduziert die Kosten für S3-Anfragen und verbessert die Cache-Trefferquote für Bilder.

Verbindungsversuche

3

Default (Standard). Wiederholungen bei vorübergehenden S3-Fehlern.

ALB-Ursprung für dynamische Inhalte

Verwenden Sie einen Application Load Balancer als Ursprung für dynamische Produktseiten, Such- und API-Endpunkte. Das ALB leitet mithilfe von Zielgruppen an Ihre Anwendungsserver weiter (Amazon EC2-Instances, Amazon ECS-Aufgaben oder Lambda-Funktionen).

ALB-Ursprungseinstellungen
Einstellung Wert Begründung

Ursprungsdomäne

ALB-DNS-Name

Verwenden Sie den ALB-DNS-Namen direkt. Verwenden Sie keine IP-Adresse — ALB-IPs ändern sich.

Protocol (Protokoll)

Nur HTTPS

Verschlüsselt den Verkehr zwischen CloudFront und dem Ursprung. Erforderlich für sensible Daten (Benutzersitzungen, Zahlungsinformationen).

Benutzerdefinierter Origin-Header

X-Origin-Verify: <secret-value>

Schränkt den ALB-Zugriff auf Anfragen von ein. CloudFront Das ALB sucht nach diesem Header und lehnt direkte Zugriffsversuche ab.

Verbindungstimeout

10 Sekunden

Kürzer als Standard (30 Sekunden). Versagen Sie schnell bei Problemen mit dem Ursprung, anstatt Edge-Verbindungen warten zu lassen.

Antwort-Timeout

30 Sekunden

Ermöglicht Zeit für komplexe Suchabfragen und Katalogoperationen. Erhöhen Sie den Wert, wenn Ihre API lang andauernde Operationen hat.

Keep-alive Zeitlimit

5 Sekunden

Verwendet Verbindungen zum ALB erneut. Reduziert den TLS-Handshake-Overhead für nachfolgende Anfragen.

Application-level Caching mit ElastiCache (Valkey)

CloudFront Zwischenspeicherung von Inhalten am Edge, aber Daten, auf die häufig zugegriffen wird und für die Datenbankabfragen erforderlich sind, profitieren von einem zusätzlichen Cache auf Anwendungsebene. Ein ElastiCache Cluster, auf dem Valkey ausgeführt wird, befindet sich zwischen Ihren Anwendungsservern und der Datenbank und ermöglicht Lesevorgänge im Sub-Millisekundenbereich für Produktkatalogdaten, Inventarzählungen und Sitzungsstatus.

Two-tier Caching-Strategie
Ebene Was es zwischenspeichert TTL Fehlverhalten beim Zwischenspeichern

CloudFront Rand

Vollständige HTTP-Antworten (API JSON, HTML-Seiten, Bilder)

5s — 365d (nach Verhalten)

Leitet die Anfrage an den ALB-Ursprung weiter

ElastiCache (Tal)

Anwendungsdatenobjekte (Produktdatensätze, Inventar, Sitzungen)

30 Sekunden — 5 Minuten (je nach Datentyp)

Die Anwendung fragt die Datenbank ab und schreibt das Ergebnis in den Cache

Bei einer Anfrage auf einer Produktseite:

  1. CloudFront überprüft seinen Edge-Cache. Gibt bei einem Treffer sofort die zwischengespeicherte Antwort zurück.

  2. Bei Fehlschlag CloudFront leitet er zur ALB weiter.

  3. Die Anwendung ElastiCache sucht nach den Produktdaten. Bei einem Treffer wird die Antwort aus zwischengespeicherten Daten (unter einer Millisekunde) erstellt.

  4. Bei ElastiCache Fehlschlag wird die Datenbank abgefragt, in die Datenbank geschrieben und die ElastiCache Antwort zurückgegeben.

  5. CloudFront speichert die Antwort gemäß der TTL-Einstellung des Verhaltens am Edge im Cache.

Wenn ein Verkäufer ein Produkt aktualisiert:

  1. Die Anwendung macht den Produktschlüssel ungültig. ElastiCache

  2. Die Anwendung sendet eine Cache-Tag-Invalidierung CloudFront für das Tag des Produkts an.

  3. Die nächste Anfrage löst eine neue Antwort durch beide Cache-Ebenen aus.

Häufig gestellte Fragen

In den folgenden Abschnitten werden häufig gestellte Fragen zu Caching-Strategien für E-Commerce- und Marketplace-Workloads beantwortet.

Wie gehe ich beim Caching mit personalisierten Inhalten um?

Trennen Sie personalisierte Elemente von zwischenspeicherbaren Inhalten. Stellen Sie die Seiten-Shell (Produktdetails, Bilder, Beschreibungen) aus dem CloudFront Cache bereit und laden Sie personalisierte Elemente (Empfehlungen, Anzahl der Einkaufswagen, Benutzername), indem Sie clientseitige API-Aufrufe verwenden, die das Caching umgehen. Mit diesem Ansatz können Sie das teure Rendern der Seite zwischenspeichern und die Personalisierung auf dem neuesten Stand halten.

Wie wähle ich zwischen Invalidierung und kurzen TTLs?

Verwenden Sie kurze TTLs (5—60 Sekunden) für Inhalte, die sich häufig und vorhersehbar ändern (Inventar, Preise). Verwende die Ungültigkeitserklärung für Inhalte, die sich selten ändern, aber sofort aktualisiert werden müssen, wenn sie sich ändern (Produktbilder nach einer Bearbeitung durch den Verkäufer, Produktbeschreibungen nach einer Konformitätsprüfung). Für eine Ungültigerklärung fallen Kosten pro Anfrage an und es gibt ein Limit für die Parallelität — verwenden Sie sie nicht als Ersatz für angemessene TTLs.

Wie bereite ich mich auf schnelle Verkäufe und Traffic-Spitzen vor?

CloudFront skaliert automatisch, um Verkehrsspitzen zu bewältigen. Um die Cache-Trefferquote während eines Verkaufs zu maximieren: Warmen Sie die Produktseiten vor, indem Sie sie vor Beginn des Events aufrufen, erhöhen Sie vorübergehend die API-TTLs (erhöhen Sie beispielsweise die TTL für Inventar von 5 Sekunden auf 15 Sekunden), um mehr Traffic am Edge abzufangen, und stellen Sie sicher, dass Ihr ElastiCache Cluster über genügend Speicherplatz für erhöhte Cache-Schreibvorgänge verfügt. Überwachen Sie die Metrik zur CloudFront Cache-Trefferquote während des Events.

Sollte ich Origin Shield für meinen Marktplatz verwenden?

Ja. Origin Shield fügt eine zentrale Cache-Ebene zwischen regionalen Edge-Caches und deinem Origin hinzu. Bei E-Commerce-Workloads reduziert es die Ursprungsanfragen für beliebte Produkte (weil ein Cache-Treffer bei Origin Shield alle Edge-Standorte bedient), reduziert die S3-GET-Kosten für Bilder und glättet Traffic-Spitzen zum ALB. Aktiviere es in der Region, die deinem Ursprung am nächsten liegt. Weitere Informationen finden Sie unter Verwenden Sie Amazon CloudFront Origin Shield.