CloudFront per applicazioni di e-commerce e marketplace

Un'applicazione di e-commerce o marketplace serve tre tipi di contenuti distinti attraverso un'unica CloudFront distribuzione: risorse statiche (immagini dei prodotti, CSS JavaScript), pagine dinamiche (elenchi di prodotti, risultati di ricerca) e risposte API (carrello, inventario, prezzi). Ogni tipo di contenuto richiede un comportamento della cache, un TTL e una configurazione di origine diversi per bilanciare la freschezza con le prestazioni.

Per i controlli di sicurezza che si applicano alle distribuzioni dei marketplace e dell'e-commerce, consulta. Lista di controllo di sicurezza per le distribuzioni sui marketplace

Panoramica dell’architettura

Una CloudFront distribuzione di marketplace utilizza diversi comportamenti di cache per indirizzare le richieste all'origine corretta in base ai modelli di percorso degli URL. Le risorse statiche vengono gestite da Amazon Simple Storage Service (Amazon S3), mentre i contenuti dinamici e le richieste API vengono inoltrati a un Elastic Load Balancing (Application Load Balancer) davanti ai server delle applicazioni. Un cluster ElastiCache (Valkey) fornisce una cache a livello di applicazione tra l'ALB e il database per i dati di prodotto a cui si accede di frequente.

Componenti dell'architettura di distribuzione

Componente	Contenuti serviti	Scopo
CloudFront distribuzione	Tutti i contenuti (dominio singolo)	Edge caching globale, terminazione TLS, routing delle richieste utilizzando i comportamenti della cache
Origine Amazon S3 (risorse statiche)	Immagini dei prodotti, CSS, JS, caratteri	Storage durevole di oggetti con controllo dell'accesso all'origine (OAC). Contenuto immutabile con TTL lunghi.
Origine ALB (contenuto dinamico)	Pagine di prodotto, ricerca, endpoint API	Percorsi verso i server delle applicazioni. TTL brevi o nessuna memorizzazione nella cache per contenuti personalizzati.
ElastiCache cluster (Valkey)	Catalogo dei prodotti, conteggio delle scorte, dati delle sessioni	Application-level cache tra ALB e database. Sub-millisecond legge i dati a cui si accede di frequente.

Comportamenti della cache per l'e-commerce

I comportamenti della cache determinano il modo in cui vengono CloudFront gestite le richieste in base ai modelli di percorso degli URL. Per un marketplace, configura comportamenti separati per ogni tipo di contenuto con policy di cache e TTL appropriati.

Comportamenti della cache consigliati

Modello di percorso	Origin	TTL	Policy della cache	Rationale
/static/*	Simple Storage Service (Amazon S3)	365 giorni	CachingOptimized	I nomi di file con versione (ad esempioapp.a1b2c3.js) consentono un TTL massimo. L'invalidazione della cache non è mai necessaria: distribuisci nuove versioni con nuovi nomi di file.
/images/*	Simple Storage Service (Amazon S3)	30 giorni	CachingOptimized	Le immagini dei prodotti vengono modificate raramente. Usa l'invalidazione del cache-tag quando un venditore aggiorna un'immagine. TTL inferiore rispetto alle risorse statiche perché gli URL delle immagini potrebbero essere riutilizzati.
/api/products/*	ALB	60 secondi	Personalizzato (include stringhe di query)	L'elenco dei prodotti e le API di ricerca cambiano frequentemente ma tollerano brevi ritardi. Includi i parametri della stringa di query nella chiave della cache per l'impaginazione e i filtri.
/api/cart/*	ALB	0 (senza cache)	CachingDisabled	Le operazioni del carrello sono specifiche dell'utente e devono sempre arrivare all'origine. Disabilita completamente la memorizzazione nella cache.
/api/inventory/*	ALB	5 secondi	Personalizzato (include stringhe di interrogazione)	Il conteggio delle scorte cambia rapidamente durante gli eventi di vendita. Un TTL molto breve impedisce l'overselling riducendo al contempo il carico di origine.
Default (*)	ALB	0 (senza cache)	CachingDisabled	Il comportamento predefinito inoltra le richieste non memorizzate nella cache all'applicazione per il rendering lato server. Le pagine che includono contenuti personalizzati (consigli, nome utente) non devono essere memorizzate nella cache all'edge.

Nota

Ordina i comportamenti della cache dal più specifico al meno specifico. CloudFront valuta i modelli di percorso nell'ordine elencato e utilizza la prima corrispondenza. Inserisci /api/cart/* prima /api/* per assicurarti che le richieste del carrello bypassino la memorizzazione nella cache.

Per ulteriori informazioni sui comportamenti cache, consulta Cache Behavior Settings (Impostazioni del comportamento della cache).

Strategia TTL per i contenuti del marketplace

La configurazione TTL determina per quanto tempo CloudFront vengono pubblicati i contenuti memorizzati nella cache prima di verificare l'origine degli aggiornamenti. E-commerce le applicazioni richiedono strategie TTL diverse a seconda di come la freschezza dei contenuti influisce sull'esperienza del cliente.

Risorse immutabili (CSS, JS, caratteri)

Imposta il TTL massimo (365 giorni). Usa nomi di file con hash del contenuto in modo che ogni distribuzione crei nuovi URL. Non vengono mai invalidate: le vecchie versioni scadono naturalmente quando gli utenti caricano i nuovi nomi di file. Impostato all'origine. Cache-Control: public, max-age=31536000, immutable

Immagini del prodotto

Imposta il TTL su 30 giorni con invalidazione del cache-tag all'aggiornamento. Quando un venditore carica una nuova immagine, la invalida in base al tag cache del prodotto anziché in base al percorso. Ciò riguarda solo gli oggetti interessati senza invalidare genericamente i caratteri jolly. Impostato Cache-Control: public, max-age=2592000 all'origine.

API del catalogo prodotti

Imposta il TTL su 60 secondi. Le inserzioni, le descrizioni e i prezzi dei prodotti tollerano brevi ritardi. Ciò riduce il carico di origine durante i picchi di traffico (vendite flash, lanci di prodotti) mantenendo i dati ragionevolmente aggiornati. È impostato Cache-Control: public, max-age=60, stale-while-revalidate=30 per pubblicare contenuti CloudFront obsoleti mentre recupera una nuova risposta in background.

API di inventario e prezzi

Imposta il TTL su 5 secondi. Questi valori cambiano frequentemente e influiscono sulle decisioni di acquisto. La memorizzazione nella cache molto breve riduce comunque il carico di origine di ordini di grandezza durante i picchi di traffico: migliaia di utenti simultanei vedono la stessa risposta memorizzata nella cache di 5 secondi invece di digitare ciascuno l'origine.

User-specific contenuti (carrello, consigli)

Disabilita la memorizzazione nella cache (TTL = 0). I contenuti che variano a seconda dell'utente devono sempre raggiungere l'origine. Se per errore memorizzate nella cache contenuti specifici di un utente, è CloudFront possibile che i dati di un utente vengano trasmessi a un altro utente. Utilizza la policy CachingDisabled gestita per questi comportamenti.

Configurazione di origine

Origine Amazon S3 per asset statici

Usa un bucket Amazon S3 come origine per le immagini dei prodotti e le risorse statiche. Configura il controllo dell'accesso all'origine (OAC) per limitare l'accesso diretto al bucket: tutte le richieste devono fluire. CloudFront

Impostazioni di origine di Amazon S3

Impostazione	Valore	Rationale
Dominio origine	marketplace-assets.s3.amazonaws.com	Usa l'endpoint dell'API REST di Amazon S3 (non l'endpoint del sito Web) per supportare l'OAC.
Accesso all’origine	Origin Access Control (OAC)	Limita l'accesso al bucket solo a. CloudFront Impedisce l'accesso diretto agli URL S3 alle tue risorse.
Origin Shield	Abilitato (regione più vicina al bucket)	Aggiunge un livello di caching centralizzato tra le posizioni dei bordi e l'origine. Riduce i costi delle richieste S3 e migliora l'hit ratio della cache per le immagini.
Tentativi di connessione	3	Default (Impostazione predefinita). Riprova gli errori S3 transitori.

Origine ALB per contenuti dinamici

Utilizza un Application Load Balancer come origine per le pagine di prodotto dinamiche, la ricerca e gli endpoint API. L'ALB indirizza i tuoi server applicativi (istanze Amazon EC2, attività Amazon ECS o funzioni Lambda utilizzando gruppi target).

Impostazioni di origine ALB

Impostazione	Valore	Rationale
Dominio origine	Nome DNS ALB	Usa direttamente il nome DNS ALB. Non utilizzare un indirizzo IP: gli IP ALB cambiano.
Protocollo	Solo HTTPS	Crittografa il traffico tra CloudFront e l'origine. Necessario per i dati sensibili (sessioni utente, informazioni di pagamento).
Intestazione personalizzata Origin	X-Origin-Verify: <secret-value>	Limita l'accesso ALB alle richieste provenienti da. CloudFront L'ALB verifica questa intestazione e rifiuta i tentativi di accesso diretto.
Timeout di connessione	10 secondi	Più breve del valore predefinito (30 secondi). Fallisci rapidamente i problemi di origine invece di far aspettare le connessioni edge.
Timeout di risposta	30 secondi	Consente di dedicare tempo a interrogazioni di ricerca e operazioni di catalogo complesse. Aumenta se la tua API ha operazioni di lunga durata.
Keep-alive timeout	5 secondi	Riutilizza le connessioni all'ALB. Riduce il sovraccarico dell'handshake TLS per le richieste successive.

Application-level memorizzazione nella cache con (Valkey) ElastiCache

CloudFront memorizza nella cache i contenuti all'edge, ma i dati a cui si accede di frequente che richiedono interrogazioni sul database traggono vantaggio da una cache aggiuntiva a livello di applicazione. Un ElastiCache cluster che esegue Valkey si trova tra i server delle applicazioni e il database e fornisce letture inferiori al millisecondo per i dati del catalogo dei prodotti, i conteggi dell'inventario e lo stato della sessione.

Two-tier strategia di caching

Livello	Cosa memorizza nella cache	TTL	Comportamento della perdita della cache
CloudFront bordo	Risposte HTTP complete (API JSON, pagine HTML, immagini)	5s — 365d (in base al comportamento)	Inoltra la richiesta all'origine ALB
ElastiCache (Valle)	Oggetti di dati dell'applicazione (record di prodotto, inventario, sessioni)	30s — 5 min (per tipo di dati)	L'applicazione interroga il database e scrive il risultato nella cache

Su una richiesta di pagina del prodotto:

1. CloudFront controlla la sua cache perimetrale. In caso di risposta, restituisce immediatamente la risposta memorizzata nella cache.

2. In caso di mancata risposta, si CloudFront passa all'ALB.

3. L'applicazione verifica ElastiCache i dati del prodotto. In caso di risposta, crea la risposta dai dati memorizzati nella cache (inferiori al millisecondo).

4. In caso di ElastiCache errore, interroga il database, scrive e restituisce la risposta. ElastiCache

5. CloudFront memorizza nella cache la risposta all'edge in base all'impostazione TTL del comportamento.

Quando un venditore aggiorna un prodotto:

1. L'applicazione invalida il codice prodotto. ElastiCache

2. L'applicazione invia un tag di cache invalidato per il tag del prodotto. CloudFront

3. La richiesta successiva attiva una nuova risposta attraverso entrambi i livelli di cache.

Domande frequenti

Le sezioni seguenti rispondono a domande comuni sulle strategie di caching per i carichi di lavoro di e-commerce e marketplace.

Come posso gestire i contenuti personalizzati con la memorizzazione nella cache?

Separa gli elementi personalizzati dai contenuti memorizzabili nella cache. Utilizza la shell della pagina (dettagli del prodotto, immagini, descrizioni) dalla CloudFront cache e carica elementi personalizzati (consigli, numero di carrelli, nome utente) utilizzando chiamate API lato client che bypassano la memorizzazione nella cache. Con questo approccio, puoi memorizzare nella cache il costoso rendering delle pagine e mantenere aggiornata la personalizzazione.

Come faccio a scegliere tra TTL di invalidazione e TTL brevi?

Utilizza i TTL brevi (5—60 secondi) per i contenuti che cambiano frequentemente e in modo prevedibile (inventario, prezzi). Usa l'invalidazione per i contenuti che cambiano raramente ma devono essere aggiornati immediatamente in caso di modifiche (immagini dei prodotti dopo una modifica da parte del venditore, descrizioni dei prodotti dopo una verifica di conformità). L'invalidazione ha un costo per richiesta e un limite di concorrenza: non utilizzatela come sostituto dei TTL appropriati.

Come posso prepararmi alle vendite lampo e ai picchi di traffico?

CloudFront si ridimensiona automaticamente per gestire i picchi di traffico. Per massimizzare il tasso di accesso alla cache durante una vendita: preriscalda le pagine dei prodotti richiedendole prima dell'inizio dell'evento, aumenta temporaneamente i TTL delle API (ad esempio, aumenta il TTL dell'inventario da 5 a 15 secondi) per assorbire più traffico all'edge e assicurati che il ElastiCache cluster abbia spazio di memoria sufficiente per aumentare le scritture nella cache. Monitora la metrica dell'hit ratio della cache durante l'evento. CloudFront

Devo usare Origin Shield per il mio marketplace?

Sì. Origin Shield aggiunge un livello di cache centralizzato tra le cache edge regionali e la tua origine. Per i carichi di lavoro dell'e-commerce, riduce le richieste di origine per i prodotti più diffusi (perché un problema nella cache di Origin Shield serve tutte le edge location), riduce i costi di S3 GET per le immagini e attenua i picchi di traffico verso l'ALB. Attivalo nella regione più vicina alla tua origine. Per ulteriori informazioni, consulta Usa Amazon CloudFront Origin Shield.