CloudFront pour les applications de commerce électronique et de place de marché

Une application de commerce électronique ou de place de marché propose trois types de contenu distincts via une seule CloudFront distribution : des actifs statiques (images de produits, CSS JavaScript), des pages dynamiques (listes de produits, résultats de recherche) et des réponses d'API (panier, inventaire, prix). Chaque type de contenu nécessite un comportement de cache, un TTL et une configuration d'origine différents pour trouver un équilibre entre fraîcheur et performances.

Pour les contrôles de sécurité qui s'appliquent aux distributions de sites de vente et de commerce électronique, consultezListe de contrôle de sécurité pour les distributions Marketplace.

Présentation de l’architecture

Une CloudFront distribution Marketplace utilise plusieurs comportements de cache pour acheminer les demandes vers la bonne origine en fonction des modèles de chemin d'URL. Les ressources statiques sont diffusées depuis Amazon Simple Storage Service (Amazon S3), tandis que le contenu dynamique et les demandes d'API sont transférés vers un Elastic Load Balancing (Application Load Balancer) situé devant vos serveurs d'applications. Un cluster ElastiCache (Valkey) fournit un cache au niveau de l'application entre l'ALB et votre base de données pour les données de produit fréquemment consultées.

Composants de l'architecture de distribution

Composant	Contenu diffusé	Objectif
CloudFront distribution	Tout le contenu (domaine unique)	Mise en cache périphérique globale, terminaison TLS, routage des demandes à l'aide de comportements de cache
Origine d'Amazon S3 (actifs statiques)	Images de produits, CSS, JS, polices	Stockage d'objets durable avec contrôle d'accès à l'origine (OAC). Contenu immuable avec de longs TTL.
Origine ALB (contenu dynamique)	Pages de produits, recherche, points de terminaison d'API	Routes vers les serveurs d'applications. TTL courts ou absence de mise en cache pour le contenu personnalisé.
ElastiCache cluster (Valkey)	Catalogue de produits, inventaire, données de session	Application-level cache entre ALB et la base de données. Sub-millisecond lit les données fréquemment consultées.

Comportements du cache pour le commerce électronique

Les comportements du cache déterminent la manière dont CloudFront les requêtes sont traitées en fonction des modèles de chemin d'URL. Pour une place de marché, configurez des comportements distincts pour chaque type de contenu avec des politiques de cache et des TTL appropriés.

Comportements de cache recommandés

Modèle de chemin	Origin	TTL	Politique de cache	Justification
/static/*	Amazon S3	365 jours	CachingOptimized	Les noms de fichiers versionnés (par exempleapp.a1b2c3.js) autorisent un TTL maximal. L'invalidation du cache n'est jamais nécessaire : déployez de nouvelles versions avec de nouveaux noms de fichiers.
/images/*	Amazon S3	30 jours	CachingOptimized	Les images des produits changent rarement. Utilisez l'invalidation du cache-tag lorsqu'un vendeur met à jour une image. TTL inférieur à celui des actifs statiques car les URL des images peuvent être réutilisées.
/api/products/*	ALB	60 secondes	Personnalisé (inclure les chaînes de requête)	Les API de liste de produits et de recherche changent fréquemment mais tolèrent une brève obsolescence. Incluez les paramètres de chaîne de requête dans la clé de cache pour la pagination et les filtres.
/api/cart/*	ALB	0 (pas de cache)	CachingDisabled	Les opérations du panier sont spécifiques à l'utilisateur et doivent toujours atteindre l'origine. Désactivez complètement la mise en cache.
/api/inventory/*	ALB	5 secondes	Personnalisé (inclure les chaînes de requête)	Les inventaires changent rapidement pendant les événements de vente. Le TTL très court empêche les surventes tout en réduisant la charge d'origine.
Default (*)	ALB	0 (pas de cache)	CachingDisabled	Le comportement par défaut transmet les requêtes non mises en cache à l'application pour un rendu côté serveur. Les pages qui incluent du contenu personnalisé (recommandations, nom d'utilisateur) ne doivent pas être mises en cache en périphérie.

Note

Organisez les comportements du cache du plus spécifique au moins spécifique. CloudFront évalue les modèles de trajectoire dans l'ordre indiqué et utilise la première correspondance. Placez /api/cart/* avant /api/* pour vous assurer que les demandes de panier contournent la mise en cache.

Pour plus d'informations sur les comportements de cache, consultez Paramètres de comportement du cache.

Stratégie TTL pour le contenu du marché

La configuration TTL détermine la durée pendant laquelle le contenu mis en cache CloudFront est conservé avant de vérifier l'origine des mises à jour. E-commerce les applications nécessitent différentes stratégies TTL en fonction de l'impact de la fraîcheur du contenu sur l'expérience client.

Ressources immuables (CSS, JS, polices)

Définissez le TTL maximum (365 jours). Utilisez des noms de fichiers dont le contenu est haché afin que chaque déploiement crée de nouvelles URL. N'invalidez jamais : les anciennes versions expirent naturellement lorsque les utilisateurs chargent les nouveaux noms de fichiers. Fixé Cache-Control: public, max-age=31536000, immutable à l'origine.

Images du produit

Définissez le TTL sur 30 jours avec invalidation de la balise de cache lors de la mise à jour. Lorsqu'un vendeur télécharge une nouvelle image, invalidez-la par la balise cache du produit plutôt que par le chemin. Cela cible uniquement les objets concernés sans invalidation générale des caractères génériques. Fixé Cache-Control: public, max-age=2592000 à l'origine.

API du catalogue de produits

Réglez TTL sur 60 secondes. Les listes de produits, les descriptions et les prix tolèrent une brève obsolescence. Cela réduit la charge d'origine lors des pics de trafic (ventes flash, lancements de produits) tout en maintenant les données raisonnablement à jour. Cache-Control: public, max-age=60, stale-while-revalidate=30Paramétré pour diffuser du contenu obsolète tout en CloudFront récupérant une nouvelle réponse en arrière-plan.

API d'inventaire et de tarification

Réglez TTL sur 5 secondes. Ces valeurs changent fréquemment et influent sur les décisions d'achat. Une mise en cache très courte réduit toujours la charge d'origine de plusieurs ordres de grandeur lors des pics de trafic : des milliers d'utilisateurs simultanés voient la même réponse en cache de 5 secondes au lieu que chacun d'entre eux atteigne l'origine.

User-specific contenu (panier, recommandations)

Désactivez la mise en cache (TTL = 0). Le contenu qui varie d'un utilisateur à l'autre doit toujours atteindre son origine. Si vous mettez en cache par erreur du contenu spécifique à un utilisateur, CloudFront il est possible que les données d'un utilisateur soient transmises à un autre utilisateur. Utilisez la politique CachingDisabled gérée pour ces comportements.

Configuration d'origine

Amazon S3 Origin pour les actifs statiques

Utilisez un compartiment Amazon S3 comme source pour les images de produits et les ressources statiques. Configurez le contrôle d'accès à l'origine (OAC) pour restreindre l'accès direct au compartiment : toutes les demandes doivent y être CloudFront acheminées.

Paramètres d'origine d'Amazon S3

Paramètre	Value	Justification
Domaine de l’origine	marketplace-assets.s3.amazonaws.com	Utilisez le point de terminaison de l'API REST Amazon S3 (et non le point de terminaison du site Web) pour prendre en charge l'OAC.
Accès à l’origine	Contrôle d'accès à l'origine (OAC)	Limite l'accès au bucket CloudFront uniquement à. Empêche l'accès direct à vos ressources par URL S3.
Bouclier d'origine	Activé (région la plus proche du compartiment)	Ajoute une couche de mise en cache centralisée entre les emplacements périphériques et l'origine. Réduit les coûts des requêtes S3 et améliore le taux d'accès au cache pour les images.
Connection attempts (Tentatives de connexion)	3	Par défaut. Réessaie en cas d'erreurs S3 transitoires.

Origine ALB pour le contenu dynamique

Utilisez un équilibreur de charge d'application comme source pour les pages de produits dynamiques, les recherches et les points de terminaison d'API. L'ALB est acheminé vers vos serveurs d'applications (instances Amazon EC2, tâches Amazon ECS ou fonctions Lambda à l'aide de groupes cibles).

Paramètres d'origine ALB

Paramètre	Value	Justification
Domaine de l’origine	Nom DNS ALB	Utilisez directement le nom DNS ALB. N'utilisez pas d'adresse IP : les adresses IP ALB changent.
Protocole	HTTPS Only	Chiffre le trafic entre CloudFront et l'origine. Nécessaire pour les données sensibles (sessions utilisateur, informations de paiement).
En-tête personnalisé Origin	X-Origin-Verify: <secret-value>	Limite l'accès à ALB aux demandes provenant de. CloudFront L'ALB vérifie cet en-tête et rejette les tentatives d'accès direct.
Délai de connexion	10 secondes	Plus court que la valeur par défaut (30s). Échouez rapidement en cas de problèmes d'origine au lieu de faire attendre les connexions Edge.
Délai de réponse	30 secondes	Permet de consacrer du temps aux requêtes de recherche complexes et aux opérations de catalogue. Augmentez cette valeur si les opérations de votre API sont prolongées.
Keep-alive délai d'attente	5 secondes	Réutilise les connexions à l'ALB. Réduit les frais d'établissement de contacts TLS pour les demandes suivantes.

Application-level mise en cache avec ElastiCache (Valkey)

CloudFront met en cache le contenu à la périphérie, mais les données fréquemment consultées qui nécessitent des requêtes de base de données bénéficient d'un cache supplémentaire au niveau de l'application. Un ElastiCache cluster exécutant Valkey se trouve entre vos serveurs d'applications et la base de données, fournissant des lectures inférieures à la milliseconde des données du catalogue de produits, des inventaires et de l'état des sessions.

Two-tier stratégie de mise en cache

Couche	Ce qu'il met en cache	TTL	Comportement des erreurs de cache
CloudFront bord	Réponses HTTP complètes (API JSON, pages HTML, images)	5s — 365d (par comportement)	Transfère la demande à l'origine ALB
ElastiCache (Vallée)	Objets de données d'application (fiches produits, inventaire, sessions)	30 s à 5 min (par type de données)	L'application interroge la base de données et écrit le résultat dans le cache

Sur une demande de page produit :

1. CloudFront vérifie son cache périphérique. En cas d'activation, renvoie immédiatement la réponse mise en cache.

2. En cas d'échec, CloudFront il passe à l'ALB.

3. L'application vérifie ElastiCache les données du produit. En cas d'accès, génère la réponse à partir des données mises en cache (en dessous de la milliseconde).

4. En cas d' ElastiCache échec, interroge la base de données ElastiCache, écrit dans et renvoie la réponse.

5. CloudFront met en cache la réponse à la périphérie en fonction du paramètre TTL du comportement.

Lorsqu'un vendeur met à jour un produit :

1. L'application invalide la clé de produit dans. ElastiCache

2. L'application envoie un cache-tag d'invalidation à CloudFront pour le tag du produit.

3. La requête suivante déclenche une nouvelle réponse via les deux couches de cache.

Questions fréquentes (FAQ)

Les sections suivantes répondent aux questions courantes concernant les stratégies de mise en cache pour les charges de travail du commerce électronique et des places de marché.

Comment gérer le contenu personnalisé grâce à la mise en cache ?

Séparez les éléments personnalisés du contenu pouvant être mis en cache. Diffusez l'enveloppe de la page (détails du produit, images, descriptions) depuis le CloudFront cache et chargez des éléments personnalisés (recommandations, nombre de paniers, nom d'utilisateur) en utilisant des appels d'API côté client qui contournent la mise en cache. Avec cette approche, vous pouvez mettre en cache le rendu de page coûteux et maintenir la personnalisation à jour.

Comment choisir entre l'invalidation et les TTL courts ?

Utilisez des TTL courts (5 à 60 secondes) pour le contenu qui change fréquemment et de manière prévisible (inventaire, prix). Utilisez l'invalidation pour le contenu qui change rarement mais qui doit être mis à jour immédiatement lorsqu'il le fait (images de produits après modification par un vendeur, descriptions de produits après examen de conformité). L'invalidation a un coût par demande et une limite de simultanéité. Ne l'utilisez pas comme substitut aux TTL appropriés.

Comment me préparer aux ventes flash et aux pics de trafic ?

CloudFront évolue automatiquement pour gérer les pics de trafic. Pour optimiser le taux d'accès au cache pendant une vente : préchauffez les pages des produits en les demandant avant le début de l'événement, augmentez temporairement le TTL des API (par exemple, augmentez le TTL de l'inventaire de 5 à 15 s) pour absorber plus de trafic en périphérie, et assurez-vous que votre ElastiCache cluster dispose d'une marge de mémoire suffisante pour augmenter les écritures dans le cache. Surveillez la métrique du taux d'accès du CloudFront cache pendant l'événement.

Dois-je utiliser Origin Shield pour mon site de vente ?

Oui. Origin Shield ajoute une couche de cache centralisée entre les caches périphériques régionaux et votre origine. Pour les charges de travail du commerce électronique, elle réduit les demandes d'origine pour les produits les plus populaires (car un accès au cache d'Origin Shield dessert tous les emplacements périphériques), réduit les coûts S3 GET pour les images et atténue les pics de trafic vers l'ALB. Activez-le dans la région la plus proche de votre lieu d'origine. Pour plus d'informations, consultez Utiliser Amazon CloudFront Origin Shield.