FAQ sur Amazon CloudFront

Amazon CloudFront est un service web qui permet aux entreprises et aux développeurs d'applications web de distribuer facilement et d’une manière économique du contenu avec une faible latence et des vitesses de transfert de données élevées. Comme tous les autres services AWS, Amazon CloudFront est une offre en libre-service, à la carte, ne nécessitant pas d'engagement à long terme ou de frais minimum. Avec CloudFront, vos fichiers sont transmis aux utilisateurs finaux par le biais d'un réseau mondial d'emplacements périphériques.

Amazon CloudFront fournit une API simple qui vous permet de :

• Distribuer le contenu avec une faible latence et des vitesses élevées de transfert de données en servant les demandes grâce à un réseau d'emplacements périphériques dans le monde entier.
• Commencer sans négocier de contrats et sans engagement minimum.

Cliquer sur le bouton « Créer un compte gratuit » sur la page de présentation détaillée d'Amazon CloudFront. Si vous choisissez d’utiliser un autre service AWS comme origine pour les fichiers diffusés par le biais d’Amazon CloudFront, vous devez vous inscrire à ce service pour pouvoir créer des distributions Amazon CloudFront.

Pour utiliser Amazon CloudFront, vous :

• Pour les fichiers statiques, conservez les versions définitives de vos fichiers sur un ou plusieurs serveurs d'origine, par exemple, dans des compartiments Amazon S3. Pour votre contenu généré dynamiquement qui est personnalisé ou customisé, vous pouvez utiliser Amazon EC2, ou tout autre serveur Web, en tant que serveur d'origine. Ces serveurs d'origine conservent ou génèrent votre contenu qui est ensuite diffusé via Amazon CloudFront.
• Enregistrer vos serveurs d'origine avec Amazon CloudFront par le biais d'un simple appel d'API. Cet appel renvoie un nom de domaine CloudFront.net que vous pouvez utiliser pour distribuer le contenu depuis vos serveurs d'origine via le service Amazon CloudFront. Ainsi, vous pouvez enregistrer un compartiment Amazon S3 (nomcompartiment.s3.amazonaws.com) comme origine pour l'ensemble de votre contenu statique et une instance Amazon EC2 (dynamique.monserveurdorigine.com) pour la totalité de votre contenu dynamique. À l'aide de l'API ou d'AWS Management Console, vous pouvez ensuite créer une distribution Amazon CloudFront qui renvoie, par exemple, abc123.cloudfront.net comme nom de domaine de la distribution.
• Incluez le nom de domaine cloudfront.net, ou un alias CNAME que vous créez, dans votre application Web, votre lecteur multimédia ou votre site Web. Chaque requête réalisée à l'aide du nom de domaine cloudfront.net (ou l'alias CNAME que vous avez configuré) est acheminée vers l'emplacement périphérique le plus approprié pour diffuser le contenu avec le plus haut niveau de performances. L'emplacement périphérique tente alors de répondre à la requête avec une copie locale du fichier. Si aucune copie locale n'est disponible, Amazon CloudFront obtient une copie auprès de l'origine. Cette copie sera ensuite disponible dans cet emplacement périphérique pour les demandes futures.

Amazon CloudFront emploie un réseau mondial d'emplacements périphériques et de caches périphériques régionaux qui mettent en cache des copies de votre contenu à proximité de vos utilisateurs. Amazon CloudFront veille à ce que les requêtes des utilisateurs finaux soient servies par l'emplacement périphérique le plus proche. Les requêtes des utilisateurs ont ainsi moins de distance à parcourir, et les performances s'en trouvent améliorées côté utilisateur. Pour les fichiers non mis en cache sur les emplacements périphériques et les caches périphériques régionaux, Amazon CloudFront maintient une connexion persistante à vos serveurs d'origine afin que ces fichiers puissent en être extraits au plus vite. Enfin, Amazon CloudFront réalise certaines optimisations supplémentaires, notamment une fenêtre de congestion initiale TCP plus large, afin de fournir un plus haut niveau de performances lors de la diffusion de votre contenu.

Comme les autres services AWS, Amazon CloudFront ne requiert aucun engagement minimum et ne vous facture que les ressources utilisées. Comparé à un hébergement en interne, Amazon CloudFront vous évite les dépenses et les tâches complexes liées à l'exploitation d'un réseau de serveurs de cache sur des sites multiples via Internet et vous permet de ne pas avoir à surdimensionner vos capacités afin de faire face à d'éventuels pics de trafic. Amazon CloudFront utilise également des techniques telles que le regroupement des demandes simultanées concernant un même fichier à un emplacement périphérique donné en une seule requête vers votre serveur d'origine. Une telle technique permet de réduire la charge sur vos serveurs d'origine, ce qui vous évite d'avoir à mettre à l'échelle votre infrastructure d'origine et vous permet d'économiser encore sur les coûts.

En outre, depuis le 1er décembre 2014, si vous utilisez une source AWS (Amazon S3, Amazon EC2, etc.), le transfert de données AWS vers Amazon CloudFront ne vous est plus facturé. Cela concerne tous les transferts de données à partir de l'ensemble des Régions AWS et vers n'importe quel emplacement périphérique CloudFront dans le monde.

Amazon CloudFront utilise les en-têtes de contrôle du cache standard que vous configurez dans vos fichiers pour déterminer s'il s'agit d'un contenu statique ou dynamique. En diffusant la totalité de votre contenu via une distribution Amazon CloudFront unique, vous pouvez plus facilement garantir l'optimisation des performances pour l'ensemble de votre site Web ou de votre application Internet. De plus, avec des origines AWS, vous tirez profit des performances accrues, de la fiabilité et de la simplicité d'utilisation résultant de la capacité d'AWS à assurer le suivi et le réacheminement des demandes en transit vers les origines, à surveiller l'état de santé du système et à répondre rapidement en cas de problème. Vous bénéficiez ainsi des avantages de l'intégration d'Amazon CloudFront avec les autres services AWS. Vous pouvez également utiliser différentes origines pour vos différents types de contenu sur un même site. Par exemple, vous utilisez Amazon S3 pour vos objets statiques, Amazon EC2 pour le contenu dynamique et des origines personnalisées pour le contenu tiers, le tout en payant uniquement en fonction de votre utilisation.

Amazon CloudFront est un bon choix pour la distribution de tout contenu statique consulté fréquemment via une diffusion périphérique, notamment pour les images de sites web, les vidéos, les fichiers multimédia ou les téléchargements de logiciels populaires.

Amazon CloudFront vous permet de profiter rapidement des avantages d'une diffusion de contenu haute performance sans contrats négociés ni prix élevés. Amazon CloudFront permet à tous les développeurs d'avoir accès à des tarifs peu élevés, payables à l'utilisation, avec un modèle en libre-service. Les développeurs profitent également d'une étroite intégration avec les autres Amazon Web Services. La solution est simple à utiliser avec Amazon S3, Amazon EC2 et Elastic Load Balancing en tant que serveurs d'origine, offrant ainsi aux développeurs une combinaison puissante de stockage durable et de diffusion haute performance. Amazon CloudFront s'intègre également à Amazon Route 53 et AWS CloudFormation pour accroître encore les performances et faciliter la configuration.

Amazon CloudFront prend en charge le contenu qui peut être envoyé en utilisant les protocoles HTTP ou WebSocket. Cela inclut les pages Web et les applications dynamiques, telles que les pages HTML ou PHP ou les applications WebSocket, et tous les fichiers statiques courants qui font partie de votre application Web, tels que les images de sites Web, les fichiers audio, vidéo, média ou les téléchargements de logiciels. Amazon CloudFront prend également en charge la diffusion de contenu multimédia en direct ou à la demande via HTTP.

Oui. Amazon CloudFront fonctionne avec tous les serveurs d'origine qui renferment les versions définitives d'origine de votre contenu, qu'il soit statique ou dynamique. Aucuns frais supplémentaires ne sont appliqués si vous utilisez une origine personnalisée.

Pour chaque origine que vous ajoutez à une distribution CloudFront, vous pouvez affecter une origine de secours utilisée pour diffuser automatiquement votre trafic en cas d’indisponibilité de l’origine principale. Vous pouvez choisir une combinaison de codes d'état HTTP 4xx/5xx qui, lorsqu'ils sont renvoyés de l'origine principale, déclenchent le basculement vers l'origine de secours. Les deux origines peuvent être n'importe quelle combinaison d'origines AWS et non-AWS.

Oui. Le SLA d'Amazon CloudFront fournit un crédit de service si le pourcentage de durée de fonctionnement mensuelle d'un client est inférieur à notre engagement de service au cours de n'importe quel cycle de facturation. Vous trouverez davantage d’informations ici.

Oui. Vous pouvez utiliser AWS Management Console pour configurer et gérer Amazon CloudFront par le biais d'une interface Web pointer-et-cliquer simple. La Console de gestion AWS prend en charge la plupart des fonctionnalités d'Amazon CloudFront et vous permet de bénéficier de la faible latence d'Amazon CloudFront sans écrire de code ou installer de logiciel. L’accès à la Console de gestion AWS est gratuit à l’adresse https://console.aws.amazon.com.

Vous trouverez différents outils permettant de gérer votre distribution et vos bibliothèques Amazon CloudFront pour divers langages de programmation dans notre centre de ressources.

Oui. Vous pouvez pointer votre zone apex (example.com) vers votre distribution Amazon CloudFront de deux manières.

À l'aide d'Amazon Route 53, le service DNS faisant autorité d'AWS, vous pouvez configurer un enregistrement ALIAS qui vous permet de mapper le sommet ou la racine (example.com) de votre nom DNS à votre distribution Amazon CloudFront. Amazon Route 53 répondra ensuite à chaque demande d'enregistrement ALIAS avec la ou les bonnes adresses IP pour votre distribution CloudFront. Route 53 ne facture pas les requêtes vers des enregistrements ALIAS mappés à une distribution CloudFront.

Alternativement, avec les adresses IP statiques Anycast de CloudFront, vous pouvez faire pointer votre domaine apex vers votre distribution CloudFront en utilisant n'importe quel fournisseur DNS. Créez simplement des enregistrements A standard à l'aide des 3 adresses IP statiques fournies par CloudFront. Cette fonctionnalité étend la prise en charge des domaines Apex au-delà de Route 53, tandis que votre trafic est toujours automatiquement acheminé vers les emplacements périphériques les plus proches pour une diffusion de contenu haute performance dans le monde entier.

CloudFront diffuse votre contenu au travers d'un réseau mondial de centres de données appelés emplacements périphériques. Les caches périphériques régionaux se trouvent entre votre serveur Web d'origine et les emplacements périphériques mondiaux diffusant le contenu directement auprès de vos utilisateurs. Les performances s'en trouvent améliorées côté utilisateur, et votre charge opérationnelle ainsi que le coût de mise à l'échelle de vos ressources d'origine sont réduits.

Amazon CloudFront dispose de plusieurs caches régionaux périphériques (REC) dispersés dans le monde entier, fournissant une couche de mise en cache supplémentaire à proximité de vos utilisateurs finaux. Ces emplacements se situent entre votre serveur web d'origine et les emplacements périphériques AWS qui diffusent le contenu directement à vos utilisateurs. À mesure que certains objets mis en cache perdent en popularité, les emplacements périphériques individuels peuvent les supprimer pour faire de la place à des objets plus fréquemment sollicités. Les caches périphériques régionaux ont une largeur de cache plus importante que tout emplacement périphérique individuel afin que les objets restent en cache plus longtemps. Ceci permet de conserver davantage de votre contenu plus près de vos utilisateurs, ce qui réduit le besoin de CloudFront de retourner à votre serveur Web d'origine et d'améliorer les performances globales pour les utilisateurs. Par exemple, les emplacements périphériques CloudFront situés en Europe accèdent désormais au cache périphérique régional de Francfort pour récupérer un objet avant de tenter de revenir à votre serveur d'origine. Les périphéries régionales peuvent être utilisées avec n'importe quelle origine, comme S3, EC2 ou des origines personnalisées. Les REC sont ignorés dans les régions qui hébergent actuellement les origines de la candidature.

Oui. Vous n'avez aucune modification à apporter à vos distributions CloudFront. Cette fonction est activée par défaut pour toutes les distributions CloudFront, nouvelles ou existantes. L'utilisation de cette fonctionnalité est sans frais supplémentaires.

Amazon CloudFront utilise un réseau mondial d'emplacements périphériques et de caches périphériques régionaux pour la diffusion de contenu. La liste complète des emplacements Amazon CloudFront peut être consultée ici.

Oui, la fonctionnalité de restriction géographique vous permet de spécifier une liste de pays dans lesquels les utilisateurs peuvent accéder à votre contenu. Vous pouvez également indiquer les pays dans lesquels les utilisateurs ne peuvent pas accéder à votre contenu. Dans les deux cas, CloudFront répond à la requête d'un utilisateur d'un pays soumis à cette restriction avec le code de statut HTTP 403 (Interdit).

La précision de la base de données de recherche du pays au moyen de l'adresse IP varie d'une région à l'autre. Selon des tests récents, le degré d'exactitude de notre conversion d'adresse IP en pays est de 99,8 %.

Oui, vous pouvez créer des messages d'erreur personnalisés (un fichier HTML ou un fichier graphique .jpg) avec vos propres logo/nom et contenu pour une multitude de réponses aux erreurs HTTP 4xx et 5xx. Puis, vous pouvez configurer Amazon CloudFront de sorte qu'il transmette ces messages d'erreur personnalisés aux utilisateurs lorsque votre contenu d'origine renvoie l'une des erreurs spécifiées à CloudFront.

Par défaut, si aucun en-tête de contrôle de cache n'est défini, chaque emplacement périphérique vérifie s'il y a une version mise à jour de votre fichier à chaque fois qu'il reçoit une demande plus de 24 heures après la vérification précédente de l'origine, afin de détecter tout changement de ce fichier. C'est ce que l'on appelle la « période d'expiration ». Vous pouvez définir cette période d'expiration sur 0 seconde, ou sur une période aussi longue que vous le souhaitez, en paramétrant les en-têtes de contrôle de la mémoire cache de vos fichiers à votre emplacement d'origine. Amazon CloudFront utilise ces en-têtes pour déterminer la fréquence à laquelle il doit vérifier l'origine pour détecter une version mise à jour du fichier. Dans le cas d'une période d'expiration de 0 seconde, Amazon CloudFront revalide chaque demande auprès du serveur d'origine. Si vos fichiers ne changent pas très souvent, il est recommandé de définir une longue période d'expiration et d'implémenter un système de gestion des versions pour gérer les mises à jour de vos fichiers.

Il existe plusieurs options pour supprimer un fichier au sein des emplacements périphériques. Vous pouvez simplement supprimer le fichier de votre origine et lorsque le contenu sur les emplacements périphériques atteint la période d'expiration définie dans l'en-tête HTTP de chaque objet, il est supprimé. Dans le cas où des documents offensants ou potentiellement nocifs doivent être supprimés avant le moment d'expiration spécifié, vous pouvez utiliser l'API d'invalidation pour supprimer l'objet de tous les emplacements périphériques Amazon CloudFront. Vous pouvez consulter les frais liés aux demandes d’invalidation ici.

Si vous invalidez des objets individuellement, il est possible que des demandes d'invalidation concernant jusqu'à 3 000 objets par distribution soient en cours en même temps. Il peut s'agir d'une demande d'invalidation concernant jusqu'à 3 000 objets, de 3 000 demandes concernant chacune un objet, ou d'une autre combinaison ne dépassant pas 3 000 objets.

Si vous utilisez le caractère générique *, vous pouvez lancer en même temps des demandes concernant jusqu'à 15 chemins d'invalidation. Vous pouvez également lancer en même temps des demandes d'invalidation concernant jusqu'à 3 000 objets individuels par distribution, la limite concernant les demandes d'invalidation avec caractères génériques étant indépendante de la limite applicable à l'invalidation d'objets individuels. Si vous dépassez cette limite, les autres demandes d'invalidation recevront une réponse d'erreur jusqu'à ce que l'une des demandes précédentes soit terminée.

Vous devez utiliser l'invalidation uniquement dans des circonstances imprévues ; si vous savez à l'avance que vos fichiers devront être fréquemment supprimés du cache, il est recommandé de mettre en place un système de gestion des versions pour vos fichiers et/ou de définir une période d'expiration courte.

Les points de présence (POP) intégrés de CloudFront constituent un type d'infrastructure CloudFront déployée au plus près des utilisateurs finaux, sur les réseaux des fournisseurs de services Internet (FSI) et des opérateurs de réseaux mobiles (MNO). Les POP intégrés sont conçus sur mesure pour diffuser des événements en direct à grande échelle, des vidéos à la demande (VOD) et des téléchargements de jeux. Ces POP intégrés sont détenus et gérés par Amazon et déployés sur le dernier kilomètre des réseaux FSI/MNO afin d'éviter les problèmes de capacité sur les réseaux encombrés qui connectent les utilisateurs finaux aux sources de contenu, améliorant ainsi les performances.

Les POP intégrés à CloudFront diffèrent des POP CloudFront en fonction de l'endroit où ils sont déployés et du contenu qu'ils diffusent. Les POP intégrés à CloudFront sont déployés directement sur les réseaux des FSI et des MNO, contrairement aux POP CloudFront déployés au sein du réseau AWS. Les POP intégrés sont spécialement conçus pour fournir un trafic pouvant être mis en cache à grande échelle, tel que des flux vidéo et des téléchargements de jeux, tandis que les POP CloudFront sont conçus pour fournir une variété de charges de travail, y compris du contenu mis en cache et du contenu dynamique.

Les POP intégrés à CloudFront sont conçus pour fournir du contenu pouvant être mis en cache et accessible simultanément à de nombreux utilisateurs finaux, comme le streaming vidéo en direct à grande échelle, la vidéo à la demande et le téléchargement de jeux.

Non, l'utilisation des POP intégrés à CloudFront est gratuite.

Les POP intégrés sont une fonctionnalité à base d'inscription destinée à la fourniture d'un trafic pouvant être mis en cache à grande échelle. Contactez votre représentant commercial AWS pour déterminer si les POP intégrés sont adaptés à vos charges de travail.

Non, il n'est pas nécessaire de créer une nouvelle distribution spécifiquement pour les POP intégrés. Si votre charge de travail est éligible, CloudFront activera les POP intégrés pour votre distribution existante sur demande.

Vous n'avez pas à choisir entre les POP intégrés à CloudFront ou les POP CloudFront pour la diffusion de contenu. Une fois que votre distribution CloudFront est activée pour les POP intégrés, le système de routage de CloudFront utilise dynamiquement à la fois les POP CloudFront et les POP intégrés pour diffuser du contenu, garantissant ainsi des performances optimales aux utilisateurs finaux.

Veuillez nous contacter pour commencer à déployer des POP intégrés au sein de votre réseau.

Vous pouvez utiliser le portail POP intégré pour gérer les POP intégrés déployés au sein de votre réseau. Le portail POP intégré fait partie du portail AWS Interconnect et fournit une interface unifiée permettant de gérer facilement en libre-service diverses tâches associées à l'ensemble du cycle de vie de ces POP. Cela inclut la demande de nouveaux appareils, le suivi de la progression des demandes, la surveillance des statistiques de performance et la demande d'assistance. Vous pouvez accéder au portail en vous authentifiant à l’aide de l’authentification unique (SSO) avec votre compte PeeringDB.

Amazon CloudFront [sauf la diffusion de contenu via les POP intégrés CloudFront] est intégré à l'ensemble de services conformes à la norme PCI DSS (Payment Card Industry Data Security Standard) Commerçant de niveau 1, le niveau de conformité le plus élevé pour les prestataires de services. Pour en savoir plus, consulter notre guide du développeur.

AWS a étendu son programme de conformité à la loi HIPAA pour inclure Amazon CloudFront [à l'exception de la diffusion de contenu via les POP intégrés CloudFront] en tant que service éligible à la loi HIPAA. Si vous avez signé un accord de partenariat commercial (BAA) avec AWS, vous pouvez utiliser Amazon CloudFront [à l'exception de la diffusion de contenu via les POP intégrés CloudFront] pour accélérer la diffusion d'informations protégées sur la santé (PHI). Pour en savoir plus, consulter la section Conformité à la loi HIPAA et notre guide du développeur.

Amazon CloudFront [à l'exception de la diffusion de contenu via les POP intégrés CloudFront] est conforme aux mesures SOC (System & Organization Control). Les rapports SOC sont des comptes rendus rédigés suite à un audit indépendant réalisé par un tiers et indiquant comment AWS parvient à mettre en œuvre ses principaux contrôles et objectifs en termes de conformité. Pour en savoir plus, consulter la page sur la conformité AWS SOC et notre guide du développeur.

Les rapports AWS SOC 1 et SOC 2 sont disponibles pour les clients utilisant AWS Artifact, un portail en libre-service qui permet d'accéder sur demande aux rapports de conformité d'AWS. Connectez‑vous à AWS Artifact dans la Console de gestion AWS, ou obtenez davantage d’informations sur la page Commencer avec AWS Artifact. Le dernier rapport AWS SOC 3 est publiquement disponible sur le site web AWS.

Amazon CloudFront prend actuellement en charge les requêtes GET, HEAD, POST, PUT, PATCH, DELETE et OPTIONS.

Amazon CloudFront ne met pas en cache les réponses aux requêtes POST, PUT, DELETE et PATCH. Celles-ci sont renvoyées au serveur d'origine. Vous pouvez activer la mise en cache des réponses aux requêtes OPTIONS.

Si vous possédez déjà une distribution Amazon CloudFront, vous pouvez activer HTTP/2 à l'aide de l'API ou de la console de gestion. Dans la console, accédez à la page « Distribution Configuration », puis à la section « Supported HTTP Versions ». Sélectionnez alors l'option « HTTP/2 », « HTTP/1.1 » ou « HTTP/1.0 ». HTTP/2 est automatiquement activé pour toutes les nouvelles distributions CloudFront.

Amazon CloudFront prend actuellement en charge HTTP/2 pour diffuser du contenu vers les clients et navigateurs de vos utilisateurs. Pour assurer la communication entre l'emplacement périphérique et vos serveurs d'origine, Amazon CloudFront continuera d'utiliser HTTP/1.1.

Pas à l'heure actuelle. Cependant, la plupart des navigateurs modernes prennent en chargent le protocole HTTP/2 uniquement via une connexion chiffrée. Cliquer ici pour en savoir plus sur l’utilisation de SSL avec Amazon CloudFront.

HTTP/3 est la troisième version principale du protocole de transfert d'hypertexte. Le protocole HTTP/3 utilise QUIC, un protocole de transport sécurisé basé sur le protocole de datagramme utilisateur (UDP), et à flux multiplexé, qui combine et améliore les capacités du protocole de contrôle de transmission (TCP) existant, du protocole TLS et du protocole HTTP/2. HTTP/3 offre plusieurs avantages par rapport aux versions précédentes de HTTP, notamment des temps de réponse plus rapides et une sécurité renforcée.

HTTP/3 est alimenté par QUIC, un nouveau protocole de transport sécurisé, de haute performance et résistant. La prise en charge du protocole HTTP/3 par CloudFront repose sur s2n-quic, une nouvelle implémentation open source du protocole QUIC dans Rust. Pour en savoir plus sur QUIC, consulter l’article de blog « Présentation de s2n-quic ». 

Les clients cherchent constamment à fournir des applications plus rapides et plus sûres à leurs utilisateurs finaux. Alors que le taux de pénétration de l'internet augmente dans le monde entier et que de plus en plus d'utilisateurs se connectent via leur appareil mobile et à partir de réseaux distants, la nécessité d'améliorer les performances et la fiabilité est plus grande que jamais. HTTP/3 permet cela étant donné qu'il offre plusieurs améliorations des performances des précédentes versions HTTP :

1. Des connexions plus rapides et plus fiables : CloudFront utilise 1‑RTT pour l’établissement d’une liaison pour HTTP/3, ce qui réduit le temps de connexion et le taux d’échec de négociation par rapport aux précédentes versions HTTP.
2. De meilleures performances web : l’implémentation HTTP/3 de CloudFront prend en charge les migrations de connexion côté client, ce qui permet aux applications client de se rétablir d’une mauvaise connexion avec un minimum d’interruptions. Contrairement à TCP, QUIC n'est pas sans perte, ce qui le rend plus adapté pour les réseaux encombrés avec des pertes de paquets importants. De plus, QUIC permet des reconnexions plus rapides après des transferts de Wifi ou de réseaux mobiles.
3. Sécurité : HTTP/3 offre une sécurité plus complète par rapport aux précédentes versions de HTTP grâce au chiffrement des paquets échangés durant l’établissement d’une liaison TLS. Cela rend l'inspection par les middlebox plus difficiles renforçant ainsi la vie privée et réduisant les attaques de l'homme du milieu. La prise en charge de HTTP/3 par CloudFront repose sur s2n-quic et Rust qui mettent l'accent sur l'efficacité et les performances.
    

Vous pouvez activer HTTP/3 pour les distributions existantes Amazon CloudFront et celles nouvellement créées à l'aide de la console CloudFront, l'action API UpdateDistribution ou un modèle Cloudformation. Dans la console, accédez à la page « Distribution Configuration », puis à la section « Supported HTTP Versions ». Sélectionnez alors l'option « HTTP/3, HTTP/2, HTTP/1.1 ou HTTP/1.0 ».

Lorsque vous activez HTTP/3 sur vos distributions CloudFront, CloudFront ajoute automatiquement l'en-tête Alt-Svc utilisée pour prévenir que la prise en charge HTTP/3 est disponible. Vous n'avez pas besoin d'ajouter manuellement l'en-tête Alt-Svc. Vous devez autoriser la prise en charge de différents protocoles au sein de vos applications pour qu'en cas d'échec de connexion HTTP/3, l'application puise se rabattre sur les protocoles HTTP/1.1 et HTTP/2. En d'autres termes, les clients qui ne prennent pas en charge le protocole HTTP/3 seront toujours à même de communiquer avec le CloudFront HTTP/3 en utilisant les protocoles HTTP/1.1 ou HTTP/2. La prise en charge de secours est indispensable pour la spécification HTTP/3. Elle est implémentée par tous les navigateurs principaux qui prennent en charge HTTP/3.

CloudFront prend actuellement en charge HTTP/3 pour la communication entre les clients/navigateurs de vos lecteurs et les emplacements périphériques CloudFront. Pour assurer la communication entre l'emplacement périphérique et vos serveurs d'origine, CloudFront continuera d'utiliser HTTP/1.1.

HTTP/3 utilise QUIC qui nécessite TLSv1.3. Par conséquent, indépendamment de la politique de sécurité que vous avez choisie, seuls TLSv1.3 et les suites de chiffrements TLSv1.3 prises en charge peuvent être utilisés pour établir des connections HTTP/3. Pour plus de détails, reportez-vous à la section des protocoles et chiffrements pris en charge entre les spectateurs et CloudFront du guide des développeurs de CloudFront.

Non, il n'existe aucun frais supplémentaire pour l'activation de HTTP/3 sur les distributions d'Amazon CloudFront. Les requêtes HTTP/3 seront facturées au prix des requêtes selon votre grille de tarification.

Le gestionnaire SaaS CloudFront est une nouvelle fonctionnalité Amazon CloudFront qui aide les fournisseurs de logiciels en tant que service (SaaS) et de plateformes de développement web à gérer efficacement la diffusion de contenu sur plusieurs sites web. Le gestionnaire SaaS CloudFront simplifie la manière dont les entreprises fournissent et sécurisent des applications mutualisées à grande échelle. En introduisant des configurations et des paramètres réutilisables, le gestionnaire SaaS CloudFront réduit les frais opérationnels. Il élimine les tâches de configuration redondantes et permet aux clients de conserver des paramètres cohérents sur l'ensemble de leurs sites web. En outre, le gestionnaire SaaS CloudFront offre la flexibilité optionnelle nécessaire pour personnaliser les paramètres de sécurité et automatiser les renouvellements de certificats pour chaque site web en cas de besoin.

CloudFront SaaS Manager est conçu pour les entreprises confrontées au défi de gérer efficacement plusieurs sites web. Les fournisseurs de logiciels en tant que service (SaaS) et de plateformes de développement web le trouveront particulièrement utile, car il leur permet de maintenir des paramètres cohérents sur les sites web de leurs locataires. De même, les entreprises qui gèrent plusieurs sites web d'entreprise peuvent l'utiliser pour normaliser leur présence sur le web tout en préservant la flexibilité nécessaire pour personnaliser des sites individuels. Si vous ne possédez que quelques sites web ou si chaque site web contient différentes configurations CloudFront, la distribution à locataire unique (traditionnelle) est probablement la meilleure solution.

CloudFront est disponible en option via la console AWS et les API pour les clients qui souhaitent gérer les paramètres partagés entre des groupes de domaines. Voici comment commencer : 1/Définir les paramètres partagés : créer une distribution mutualisée contenant des paramètres partagés qui serviront de modèle pour les groupes de domaines. 2/Créer des locataires de distribution : créer des locataires de distribution qui vous permettent d'associer des domaines et leur certificat TLS à une distribution multi-locataires. 3/Contrôle précis : vous pouvez éventuellement personnaliser les paramètres pour les locataires de distribution en appliquant des dérogations.

Une distribution multi-locataires définit la configuration de base qui sera partagée entre les domaines. Elle contient des paramètres de configuration partagés tels que les configurations d'origine, les comportements du cache et les paramètres de sécurité. Contrairement à une distribution standard, une distribution multi-locataires ne peut pas desservir le trafic directement. Elle propose des champs paramétrés et personnalisables pour répondre aux besoins uniques de chaque domaine. Par exemple : chemins d'origine spécifiques à un domaine ou noms de domaine d'origine.

Un locataire de distribution représente un domaine spécifique utilisant une distribution à locataires multiples. Il hérite de la configuration de base de la distribution mutualisée et doit disposer d'au moins un domaine ou sous-domaine avec un certificat TLS valide.
Chaque locataire de distribution peut inclure les personnalisations suivantes :

• Chemins d'origine et/ou noms de domaine d'origine uniques (définis par des valeurs de paramètres dans la distribution multi-locataires)
• Certificats TLS personnalisés
• Remplacements de l'ACL web
• Dérogations à la restriction géographique
  

Oui. CloudFront travaille toutefois avec AWS Certificate Manager (ACM) pour fournir une expérience de validation du contrôle de domaine fluide. L'intégration à ACM simplifie l'émission et la gestion des certificats et permet une gestion automatisée du cycle de vie de vos certificats SSL/TLS émis par Amazon. Si vous utilisez une autre autorité de certification pour émettre des certificats, ACM prend en charge les certificats émis par des autorités de certification tierces. Dans de tels cas, vous serez responsable du cycle de vie du certificat (téléchargement initial, renouvellement, téléchargement ultérieur) et ACM enverra des notifications au propriétaire du compte AWS à l'approche de l'expiration des certificats via CloudWatch et par e-mail. Pour plus de détails, vous pouvez consulter le site https://aws.amazon.com/certificate-manager/faqs/.

Oui, CloudFront autorise la prise en charge des domaines apex ou racine (par exemple, example.com contre www.example.com). Les clients peuvent utiliser Route 53 pour gérer le DNS et ajouter un enregistrement ALIAS pour leur domaine apex afin de pointer vers un domaine fourni par CloudFront. Pour les clients qui ne peuvent pas utiliser Route53 pour gérer des domaines personnalisés, les adresses IP statiques Anycast peuvent fournir un ensemble d'adresses IP dédiées pouvant être utilisées à la place des enregistrements CNAME/ALIAS. En savoir plus ici.

Oui. CloudFront facture en fonction du nombre de ressources de distribution que vous créez. Les locataires de distribution sont de nouvelles ressources qui héritent des paramètres de configuration d'une distribution multi-locataires CloudFront. Consulter la de tarification de CloudFront pour plus de détails.

WebSocket est un protocole de communication en temps réel qui permet une communication bidirectionnelle entre un client et un serveur via une connexion TCP longue durée. L'utilisation d'une connexion ouverte persistante permet au client et au serveur de s'envoyer mutuellement des données en temps réel sans qu'il soit nécessaire pour le client de relancer fréquemment les connexions afin de vérifier s'il existe de nouvelles données à échanger. Les connexions WebSocket sont souvent utilisées dans les applications de discussion instantanée, les plateformes de collaboration, les jeux multijoueurs et les plateformes de négociations financières. Consultez notre documentation pour en savoir plus sur l’utilisation du protocole WebSocket avec Amazon CloudFront. 

Vous pouvez utiliser WebSocket à l'échelle mondiale. Aucune configuration supplémentaire n'est nécessaire pour activer le protocole WebSocket dans votre ressource CloudFront, étant donné qu'il est désormais pris en charge par défaut.

Amazon CloudFront établit des connexions WebSocket uniquement lorsque le client inclut l'en-tête "Upgrade: websocket" et que le serveur répond avec le code d'état HTTP 101 confirmant qu'il peut passer au protocole WebSocket.

Oui. Amazon CloudFront prend en charge les connexions chiffrées WebSocket (WSS) en utilisant le protocole SSL/TLS.

gRPC est un cadre d’appel de procédure à distance (RPC) moderne et open source qui permet une communication bidirectionnelle entre un client et un serveur via une connexion HTTP/2 de longue durée. En utilisant une connexion ouverte persistante, le client et le serveur peuvent s’envoyer des données en temps réel sans que le client ait à relancer fréquemment les connexions pour vérifier les nouvelles données à échanger. gRPC convient parfaitement aux cas d’utilisation où une faible latence et des vitesses de transfert élevées sont cruciales, tels que les applications de communication en temps réel et les jeux en ligne.

gRPC est activé pour chaque comportement de cache de vos distributions CloudFront. L’activation de gRPC garantit que HTTP/2 et la prise en charge des requêtes POST sont également activés sur votre distribution. gRPC ne prend en charge que la méthode POST sur HTTP/2.

Amazon CloudFront communique via gRPC lorsque les conditions suivantes sont remplies :

1. HTTP/2 est activé sur votre distribution
2. Les requêtes POST et gRPC sont activées sur un comportement de cache
3. Un client envoie un en-tête « content-type » avec la valeur « application/grpc » via une connexion HTTP/2

1. Sécurité : gRPC utilise le protocole HTTP/2, qui garantit que le trafic est chiffré de bout en bout entre le client et vos serveurs d’origine. En outre, lorsque vous utilisez gRPC, vous bénéficiez d’AWS Shield Standard sans frais supplémentaires et AWS WAF peut être configuré pour protéger le trafic gRPC contre les attaques.
2. Meilleures performances : gRPC exploite un format de message binaire, appelé Protocol Buffers, qui est plus petit que les données utiles traditionnelles, comme le JSON utilisé avec les API RESTful. L’analyse des Protocol Buffers est moins gourmande en ressources processeur, car les données sont au format binaire, ce qui signifie que les messages sont échangés plus rapidement. Cela se traduit par une meilleure performance globale.
3. Support de streaming intégré : la diffusion en continu fait partie intégrante du cadre gRPC et prend en charge la sémantique de diffusion en continu côté client et côté serveur. Cela simplifie considérablement la création de services ou de clients de diffusion en continu. gRPC sur CloudFront prend en charge les combinaisons de diffusion en continu suivantes :
   • Unaire (pas de diffusion en continu)
   • Diffusion en continu du client au serveur
   • Diffusion en continu du serveur au client
   • Diffusion en continu bidirectionnelle

Pas à l'heure actuelle. CloudFront ne prend en charge que le gRPC sur HTTP/2.

Par défaut, il est possible de diffuser votre contenu aux lecteurs via HTTPS en intégrant le nom de votre domaine de distribution CloudFront dans vos URL, par exemple : https://dxxxxx.cloudfront.net/image.jpg. Si vous souhaitez diffuser votre contenu via HTTPS en utilisant votre propre nom de domaine et votre propre certificat SSL, vous pouvez utiliser l’une de nos fonctionnalités de prise en charge des certificats SSL personnalisés. En savoir plus.

Le chiffrement au niveau du champ est une fonctionnalité de CloudFront qui vous permet de télécharger en toute sécurité des données soumises par l'utilisateur, telles que des numéros de carte de crédit, sur vos serveurs d'origine. À l'aide de cette fonctionnalité, vous pouvez apporter un niveau supplémentaire de chiffrement des données sensibles dans un formulaire HTTPS à l'aide de clés de chiffrement définies par vous et spécifiques au champ, avant qu'une requête PUT/POST soit transmise à votre origine. Ainsi, les données sensibles ne peuvent être déchiffrées et consultées que par certains composants ou services de votre pile d'applications. Pour en savoir plus sur le chiffrement au niveau des champs, consulter la section Chiffrement au niveau des champs dans notre documentation.

De nombreuses applications web collectent des données sensibles comme les renseignements de cartes de crédit auprès des utilisateurs. Ces données sont ensuite traitées par les services applicatifs exécutés sur l'infrastructure d'origine. L'ensemble de ces applications web utilisent le chiffrement SSL/TLS entre l'utilisateur final et CloudFront, et entre CloudFront et votre origine. Votre origine peut disposer de différents micro-services qui exécutent des opérations critiques d'après les saisies utilisateur. Cependant, des informations typiquement sensibles ne doivent être utilisées que par un petit sous-ensemble de ces micro-services, ce qui signifie que la plupart des composants ont un accès direct à ces données sans raison. Une simple erreur de programmation, telle que l'enregistrement de la mauvaise variable, peut entraîner l'écriture du numéro de carte de crédit d'un client dans un fichier.

Avec le chiffrement au niveau du champ, les emplacements périphériques de CloudFront peuvent chiffrer les données des cartes de crédit. À partir de là, seules les applications qui détiennent les clés privées peuvent déchiffrer les champs sensibles. Le service de traitement des commandes a donc uniquement accès aux numéros de carte de crédit chiffrés. Les services de paiement, quant à eux, peuvent déchiffrer les données des cartes de crédit. Vous bénéficiez ainsi d'un niveau supérieur de sécurité : même en cas de fuite de texte chiffré par un des services applicatifs, les données restent protégées par chiffrement.

L’option certificats SSL personnalisés à IP dédiée attribue des adresses IP dédiées pour la diffusion de votre contenu SSL à chaque emplacement périphérique CloudFront. Dans la mesure où il n'y a qu'un seul mappage entre les adresses IP et les certificats SSL, cette option fonctionne avec les navigateurs et autres clients qui ne prennent pas en charge l'extension SNI. En raison des coûts actuels liés aux adresses IP, la fonction certificats SSL personnalisés à IP dédiée est facturée 600 USD/mois, avec ajustement au prorata du nombre d'heures.

L’option certificats SSL personnalisés SNI repose sur l’extension SNI du protocole TLS qui permet d’utiliser plusieurs domaines pour diffuser le trafic SSL via la même adresse IP en incluant le nom de l’hôte auquel les utilisateurs essaient de se connecter. CloudFront diffuse le contenu depuis chaque emplacement périphérique Amazon CloudFront et avec un niveau de sécurité identique à celui des certificats SSL personnalisés à IP dédiée. L'option SSL personnalisé SNI est prise en charge par la plupart des navigateurs modernes, dont Chrome version 6 et ultérieures (avec Windows XP et versions ultérieures ou Mac OS X 10.5.7 et versions ultérieures), Safari version 3 et ultérieures (avec Windows Vista et versions ultérieures ou Mac OS X 10.5.6. et versions ultérieures), Firefox 2.0 et versions ultérieures ainsi qu'Internet Explorer 7 et versions ultérieures (avec Windows Vista et versions ultérieures). Les navigateurs plus anciens qui ne prennent pas en charge l'extension SNI ne peuvent pas établir de connexion à CloudFront pour charger la version HTTPS de votre contenu. Les certificats SSL personnalisés SNI sont disponibles sans frais supplémentaires ; seuls les frais standard associés aux requêtes et transferts de données CloudFront vous seront facturés.

L'indication du nom du serveur (SNI) est une extension du protocole TLS (Transport Layer Security). Ce mécanisme identifie le domaine (nom de serveur) de la requête SSL associée pour permettre l'utilisation du bon certificat lors d'une négociation SSL. Il est alors possible d'utiliser une seule adresse IP pour plusieurs serveurs. La SNI nécessite la prise en charge du navigateur pour ajouter le nom du serveur. Si la plupart des navigateurs actuels le prennent en charge, d’anciens navigateurs ne le prennent pas en charge. Pour plus d’informations, consulter la section SNI du guide du développeur CloudFront ou l’article Wikipédia consacré à la SNI.

Oui, vous pouvez désormais allouer des certificats SSL/TLS et les associer à des distributions CloudFront en quelques minutes seulement. Pour cela, il vous suffit d'allouer un certificat avec le nouveau service AWS Certificate Manager (ACM) et de le déployer sur votre distribution CloudFront en quelques clics. ACM s'occupe alors de la gestion des renouvellements de certificat à votre place. ACM vous permet d'allouer, de déployer et de gérer vos certificats sans frais supplémentaires.

Notez que CloudFront prend toujours en charge les certificats obtenus auprès d'une autorité de certification tierce et envoyés au magasin de certificats IAM.

Oui, Amazon CloudFront possède une fonctionnalité facultative de contenu privé. Lorsque cette option est activée, Amazon CloudFront ne diffuse les fichiers que lorsque vous donnez votre approbation en signant vos demandes de manière sécurisée. Pour en savoir plus sur cette fonctionnalité, consulter le guide du développeur CloudFront.

En tant que client AWS, vous bénéficiez du service AWS Shield Standard sans frais supplémentaires. AWS Shield est un service opéré qui protège les applications Web s'exécutant sur AWS des attaques par déni de service distribué (DDoS). AWS Shield Standard protège tous les clients AWS des attaques ciblant l'infrastructure (couches 3 et 4) courantes et les plus fréquentes, telles que des flux UDP/SYN, des attaques par réflexion ou autres afin de prendre en charge la haute disponibilité de vos applications sur AWS.

AWS Shield Advanced est une option de service payante disponible pour les clients AWS Business Support et AWS Enterprise Support. AWS Shield Advanced fournit des protections supplémentaires contre les attaques de plus grande ampleur et plus sophistiquées pour vos applications s'exécutant sur Elastic Load Balancing (ELB), Amazon CloudFront et Route 53.

Vous pouvez intégrer votre distribution CloudFront à AWS WAF, un pare‑feu qui protège vos applications Web contre les attaques en vous permettant de définir des règles selon les adresses IP, les en‑têtes HTTP et les URI personnalisés. En utilisant ces règles, AWS WAF peut bloquer, autoriser ou suivre (compter) les requêtes Web envoyées à votre application Web. Pour en savoir plus, consulter le guide du développeur AWS WAF.

CloudFront propose deux méthodes entièrement gérées pour protéger vos origines :

1. Contrôle d’accès à l’origine (OAC) : le contrôle d’accès à l’origine (OAC) de CloudFront est une fonctionnalité de sécurité qui restreint l’accès à vos origines Amazon Simple Storage Service (S3), vos origines AWS Elemental et vos URL de la fonction Lambda, garantissant que seul CloudFront peut accéder au contenu.
2. Origines de VPC : les origines de cloud privé virtuel (VPC) CloudFront vous permettent d’utiliser Amazon CloudFront pour diffuser du contenu à partir d’applications hébergées dans un sous-réseau privé VPC. Vous pouvez utiliser des Application Load Balancer (ALB), des Network Load Balancer (NLB) et des instances EC2 dans des sous-réseaux privés comme origines de VPC avec CloudFront

Si les solutions gérées CloudFront ne répondent pas aux exigences de votre cas d’utilisation, voici quelques-unes des approches alternatives disponibles :

1. En-têtes d’origine personnalisés : avec CloudFront, vous pouvez ajouter des en-têtes personnalisés à vos demandes entrantes, puis configurer votre origine pour valider ces valeurs d’en-tête spécifiques, limitant ainsi l’accès aux seules demandes acheminées via CloudFront. Cette méthode crée une couche d’authentification supplémentaire, ce qui réduit considérablement le risque d’accès direct non autorisé à votre origine.
2. Liste d’adresses IP autorisées : vous pouvez configurer le groupe de sécurité ou le pare-feu de votre origine pour autoriser exclusivement le trafic entrant provenant des plages IP de CloudFront. AWS gère et met régulièrement à jour ces plages d’adresses IP pour votre commodité. Pour des informations détaillées sur la mise en œuvre de la liste des adresses IP autorisées, veuillez consulter notre documentation complète à l’adresse suivante : https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list. Cette ressource fournit des conseils étape par étape sur l’utilisation des listes de préfixes gérées par AWS pour une configuration de sécurité optimale.
3. Chiffrement SSL/TLS : vous pouvez configurer CloudFront pour utiliser exclusivement des connexions HTTPS avec votre origine afin d’assurer une protection des données de bout en bout grâce à une communication chiffrée entre votre distribution CloudFront et votre origine.

Les origines de cloud privé virtuel (VPC) CloudFront sont une nouvelle fonctionnalité qui vous permet d’utiliser CloudFront pour diffuser du contenu à partir d’applications hébergées dans un sous-réseau privé VPC. Avec les origines de VPC, vous pouvez placer vos applications dans un sous-réseau privé de votre VPC, accessible uniquement via vos distributions CloudFront. Cela supprime l’obligation pour l’origine de disposer d’un nom de service de noms de domaine (DNS) pouvant être résolu de manière externe. Vous pouvez configurer des origines de VPC avec des applications exécutées sur des Application Load Balancer (ALB), Network Load Balancer (NLB) et instances EC2. Les origines de VPC ne sont disponibles que dans les régions commerciales AWS, et la liste complète des Régions AWS prises en charge est disponible ici.

Vous devez utiliser les origines de VPC avec CloudFront si vous souhaitez améliorer la sécurité de vos applications Web tout en maintenant des performances élevées et une capacité de mise à l’échelle globale. Avec les origines de VPC, vous pouvez restreindre l’accès à vos origines dans un VPC à vos distributions CloudFront uniquement sans avoir à recourir à des configurations complexes telles que des en-têtes secrets ou des listes de contrôle d’accès. Les origines de VPC vous permettent également d’optimiser vos coûts IPv4 en vous permettant d’acheminer gratuitement vers des origines dans un sous-réseau privé avec des adresses IP IPv4 internes. Les origines de VPC sont parfaites si vous souhaitez rationaliser la gestion de votre sécurité, en vous permettant de vous concentrer davantage sur la croissance de votre activité principale plutôt que sur la gestion de mesures de sécurité complexes.

1. Sécurité : avec les origines de VPC, vous pouvez améliorer la sécurité de votre application en plaçant vos équilibreurs de charge et vos instances EC2 dans des sous-réseaux privés, faisant de CloudFront le seul point d’entrée. Les demandes des utilisateurs sont transmises de CloudFront aux origines de VPC via une connexion privée et sécurisée, ce qui renforce la sécurité de vos applications.
2. Gestion : les origines de VPC réduisent la charge opérationnelle requise pour une connectivité sécurisée entre CloudFront et l’origine en vous permettant de déplacer vos origines vers des sous-réseaux privés sans accès public, et sans avoir à implémenter des listes de contrôle d’accès, des en-têtes partagés secrets ou d’autres mécanismes visant à restreindre l’accès aux origines. Cela vous permet de sécuriser facilement leurs applications Web, avec CloudFront, sans avoir à investir dans des travaux de développement indifférenciés.
3. Mise à l’échelle et performance : avec les origines de VPC, les clients peuvent utiliser les emplacements périphériques mondiaux de CloudFront et les réseaux dorsaux AWS, tout en bénéficiant d’une mise à l’échelle et de performances similaires à celles des autres méthodes de diffusion de contenu existantes, tout en bénéficiant d’une posture de sécurité améliorée. La solution rationalise la gestion de la sécurité tout en fournissant des applications globales aux clients, ce qui facilite l’utilisation de CloudFront comme porte d’entrée unique pour vos applications.

Les origines de cloud privé virtuel (VPC) CloudFront vous permettent d’utiliser CloudFront pour diffuser du contenu à partir d’applications hébergées dans un sous-réseau privé VPC avec des Application Load Balancer, des Network Load Balancer et des instances EC2. Amazon VPC Block Public Access (VPC BPA) est un contrôle déclaratif simple qui bloque de manière autorisée le trafic VPC entrant (entrée) et sortant (sortie) via les chemins Internet fournis par AWS. Lorsque VPC BPA est activé sur un sous-réseau de l’origine du VPC, les connexions actives depuis CloudFront sont interrompues vers ce sous-réseau. Aucune nouvelle connexion n’est envoyée vers le sous-réseau et est soit acheminée vers un autre sous-réseau où réside l’origine de VPC et où BPA n’est pas activé, soit abandonnée si BPA est activé dans tous les sous-réseaux où réside l’origine de VPC.

Les origines de VPC prennent en charge les Application Load Balancer, les Network Load Balancer et les instances EC2.

Non, IPv6 n’est pas pris en charge pour les origines privées de VPC. Avec les origines de VPC, vous avez besoin d’adresses IPv4 privées, qui sont gratuites et n’entraînent pas de frais IPv4.

Oui, vous pouvez configurer Amazon CloudFront pour ajouter des en-têtes personnalisés ou remplacer la valeur d'en-têtes existants, pour des requêtes transmises à votre serveur d'origine. Vous pouvez utiliser ces en-têtes pour vérifier que les requêtes transmises à votre serveur d'origine ont été envoyées depuis CloudFront ; vous pouvez même configurer votre serveur d'origine pour autoriser uniquement les requêtes contenant les valeurs d'en-tête personnalisé que vous spécifiez. De plus, si vous utilisez plusieurs distributions CloudFront avec la même origine, vous pouvez vous servir des en-têtes pour identifier la requête d'origine envoyée par chaque distribution. Enfin, les en-têtes personnalisés peuvent être utilisés pour déterminer les en-têtes CORS appropriés renvoyés pour vos requêtes. Vous pouvez configurer des en-têtes personnalisés via l'API CloudFront et AWS Management Console. Cette fonctionnalité est disponible sans frais additionnels. Pour en savoir plus sur la configuration des en-têtes personnalisés, cliquer ici.

Amazon CloudFront prend en charge la diffusion de contenu dynamique personnalisé ou adapté à l'aide de cookies HTTP. Pour bénéficier de cette fonctionnalité, vous devez spécifier si vous souhaitez qu'Amazon CloudFront transmette tout ou partie de vos cookies vers votre serveur d'origine personnalisé. Amazon CloudFront prend ensuite en compte les valeurs des cookies transmis pour identifier un objet unique dans son cache. De cette manière, les utilisateurs finaux bénéficient à la fois d'un contenu hautement personnalisé à l'aide de cookies et des performances d'Amazon CloudFront. Vous pouvez également choisir de consigner les valeurs de cookie dans les journaux d'accès d'Amazon CloudFront.

Il est possible de configurer une chaîne d'interrogation afin qu'elle soit incluse dans la clé du cache pour identifier les objets dans le cache Amazon CloudFront. Vous pouvez ainsi développer des pages web dynamiques (incluant des résultats de recherche, par exemple) qui peuvent être mises en cache sur l'emplacement périphérique durant un certain temps.

Oui, la fonctionnalité de liste de blanche de chaînes de requête vous permet de configurer facilement Amazon CloudFront de façon à n’utiliser que certains paramètres dans la clé de cache, tout en continuant de transmettre tous les paramètres à l’origine.

Oui, vous pouvez configurer Amazon CloudFront de façon à placer jusqu'à 10 paramètres de requête sur liste blanche.

Amazon CloudFront prend en charge les paramètres de requête URI définis dans la section 3.4 de la norme RFC3986. Plus précisément, le service prend en charge les paramètres de requête intégrés à une chaîne HTTP GET placés entre les caractères « ? » et « & ».

Oui, CloudFront peut compresser automatiquement votre texte ou vos données binaires. Pour utiliser cette fonctionnalité, spécifier dans les paramètres de comportement du cache que vous souhaitez utiliser CloudFront pour la compression automatique des objets. Assurez-vous aussi que votre client ajoute Accept-Encoding: gzip dans l'en-tête de demande (la plupart des navigateurs Internet actuels le font par défaut). Pour plus d’informations sur cette fonctionnalité, consulter notre guide du développeur.

En général, le streaming fait référence à la diffusion de contenu audio et vidéo aux utilisateurs finaux sur Internet sans qu'il soit nécessaire de télécharger le fichier multimédia pour le lire. Les protocoles utilisés pour le streaming comprennent ceux utilisant HTTP pour le déploiement comme HTTP Live Streaming (HLS) 'Apple, MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH), HTTP Dynamic Streaming (HDS) d'Adobe et Smooth Streaming de Microsoft. Contrairement au protocole utilisé pour diffuser des pages Web et d'autres contenus en ligne, ces protocoles distribuent du contenu multimédia en temps réel ; les utilisateurs voient les octets au fur et à mesure qu'ils sont distribués. Le streaming présente plusieurs avantages potentiels pour vous et vos utilisateurs finaux :

• Il peut donner aux utilisateurs plus de contrôle sur leur expérience de lecture de contenu. Par exemple, il est plus facile pour un utilisateur de faire une recherche en avant ou en arrière dans une vidéo en utilisant le streaming plutôt qu'avec la distribution traditionnelle par téléchargement.
• Le streaming peut vous donner plus de contrôle sur votre contenu, car il ne reste aucune trace du fichier sur l'ordinateur de l'utilisateur ou le disque local lorsque celui-ci a fini de regarder une vidéo.
• Il peut contribuer à réduire les coûts en vous permettant de ne diffuser que les portions d'un fichier multimédia que les utilisateurs regardent réellement. Avec les téléchargements traditionnels, le fichier multimédia entier est téléchargé par les utilisateurs, même s'ils ne regardent qu'une portion du fichier.

Oui, Amazon CloudFront fournit différentes options de diffusion de vidéo à la demande. Si vous disposez de fichiers multimédias qui ont été convertis au format HLS, MPEG-DASH ou Microsoft Smooth Streaming, par exemple à l’aide d’AWS Elemental MediaConvert, avant d’être stockés dans Amazon S3 (ou une origine personnalisée), vous pouvez utiliser une distribution web Amazon CloudFront pour diffuser votre contenu dans ce format, sans avoir à exécuter d’autres serveurs multimédias.

Autrement, vous pouvez également exécuter un serveur de streaming tiers (tel que Wowza Media Server, disponible sur AWS Marketplace) sur Amazon EC2, capable de convertir des fichiers multimédias au format de diffusion en continu HTTP requis. Ce serveur peut ensuite être désigné comme origine d'une distribution web Amazon CloudFront.

Consulter la page AWS Vidéo à la demande (VOD) pour en savoir plus.

Oui. Vous pouvez utiliser le streaming en direct d’Amazon CloudFront avec n’importe quel service de sourçage vidéo en direct produisant des flux HTTP, comme AWS Elemental MediaPackage ou AWS Elemental MediaStore. MediaPackage est un service de création vidéo et de conditionnement juste-à-temps permettant aux distributeurs de vidéos de déployer de manière fiable et sécurisée du contenu à l'échelle grâce à plusieurs normes protection de contenu et de déploiement. MediaStore est un service de sourçage et de stockage HTTP offrant les hautes performances, la cohérence immédiate et la latence faible et prévisible nécessaires pour le contenu multimédia direct combinés à la sécurité et la durabilité du stockage d'Amazon.

Consulter la page Streaming vidéo en direct sur AWS pour plus d’informations.

Media-Quality Aware Resiliency (MQAR) est une fonctionnalité intégrée entre Amazon CloudFront et AWS Media Services qui permet la sélection automatique de l'origine interrégionale et le basculement en fonction d'un score de qualité vidéo généré dynamiquement. Avec MQAR, vous pouvez déployer un flux de travail redondant de services multimédias AWS dans deux Régions AWS différentes pour une diffusion d'événements en direct résiliente. Lorsque vous activez la fonctionnalité MQAR pour votre distribution, vous autorisez CloudFront à sélectionner automatiquement l'origine considérée comme ayant le score de qualité le plus élevé. Le score de qualité représente les problèmes de qualité perçus en matière de diffusion multimédia depuis votre origine, tels que des images noires, des images bloquées ou supprimées, ou des images répétées. Par exemple, si vos origines AWS Elemental MediaPackage v2 sont déployées dans deux Régions AWS différentes et que l'une affiche un score de qualité multimédia supérieur à l'autre, CloudFront bascule automatiquement vers l'origine qui affiche le score le plus élevé. Cette fonctionnalité simule une « vision sur glace » permanente pour diffuser des événements en direct et des chaînes de programmation 24 heures sur 24, 7 jours sur 7, et est conçue pour offrir une expérience de haute qualité à vos spectateurs. Pour en savoir plus sur le MQAR, consulter le guide du développeur de CloudFront.

Origin Shield est une couche de mise en cache centralisée qui permet d'augmenter le taux de réussite de votre cache pour réduire la charge sur votre origine. Origin Shield réduit également vos coûts d'exploitation d'origine en regroupant les demandes entre les régions afin qu'une seule demande soit envoyée à votre origine par objet. Une fois activé, CloudFront acheminera toutes les récupérations d'origine via Origin Shield, et ne fera une demande à votre origine que si le contenu n'est pas déjà stocké dans le cache d'Origin Shield.

Origin Shield est idéal pour les charges de travail avec des utilisateurs répartis dans différentes régions géographiques ou les charges de travail qui impliquent un empaquetage juste à temps pour le streaming vidéo, la gestion d'images à la volée ou des processus similaires. L'utilisation d'Origin Shield devant votre origine réduira le nombre de demandes d’accès depuis l’origine redondantes en vérifiant d'abord le cache central et en effectuant uniquement un accès depuis l’origine consolidé pour le contenu qui ne se trouve pas déjà dans le cache d'Origin Shield. De même, Origin Shield peut être utilisé dans une architecture multi-CDN pour réduire le nombre d’accès depuis l’origine en double sur les CDN en positionnant Amazon CloudFront comme origine des autres CDN. Consulter le guide du développeur Amazon CloudFront pour en savoir plus sur les exemples ci‑dessus ou sur d’autres cas d’utilisation Origin Shield.

Amazon CloudFront propose Origin Shield dans les Régions AWS où CloudFront offre un cache régional en périphérie. Lorsque vous activez Origin Shield, vous devez choisir la Région AWS pour Origin Shield qui a la latence la plus faible par rapport à votre origine. Vous pouvez utiliser Origin Shield avec des origines qui se trouvent dans une Région AWS et avec des origines qui ne se trouvent pas dans AWS. Pour en savoir plus, consulter la section Choisir la Région AWS pour Origin Shield dans le guide du développeur Amazon CloudFront.

Oui. Toutes les régions Origin Shield sont créées à l'aide d'une architecture hautement disponible qui s'étend sur plusieurs zones de disponibilité avec des flottes d’instances Amazon EC2 à scalabilité automatique. Les connexions entre les emplacements CloudFront et Origin Shield utilisent également le suivi des erreurs actif pour chaque demande afin d’acheminer automatiquement la demande vers un emplacement secondaire Origin Shield si l'emplacement principal Origin Shield n'est pas disponible.

Les adresses IP statiques en unidiffusion d’Amazon CloudFront sont un ensemble d’adresses IP statiques qui vous permettent de vous connecter à tous les emplacements périphériques CloudFront dans le monde. Elles constituent une petite liste statique d’adresses IP qui peuvent être utilisées pour des cas d’utilisation tels que la facturation détaxée, dans le cadre de laquelle les fournisseurs de réseau annulent les frais de données pour des adresses IP spécifiques moyennant la mise en place d’accords appropriés, et la mise en place de listes d’autorisations côté client pour renforcer la sécurité. En utilisant les adresses IP statiques en unidiffusion, vous éliminez le défi opérationnel lié à la mise à jour constante des listes d’autorisation ou des mappages IP, car le même ensemble d’adresses IP fonctionne pour l’ensemble du réseau mondial de CloudFront tout en bénéficiant de toutes les fonctionnalités de CloudFront.

Pour activer les adresses IP statiques en unidiffusion, vous devez d’abord demander et créer une liste d’adresses IP statiques en unidiffusion dans votre compte AWS. Une fois la liste créée, vous pouvez associer vos distributions CloudFront à la liste d’adresses IP statiques en unidiffusion. Cela peut être fait soit via la section IP statique en unidiffusion sur la console AWS, soit en modifiant chaque distribution et en sélectionnant la liste d’adresses IP statiques en unidiffusion souhaitée dans le menu déroulant. Une fois ces modifications enregistrées, l’ensemble spécifique d’adresses IP statiques associé à votre/vos distribution(s) sera disponible pour que vous puissiez le copier ou le télécharger à partir de la liste affichée dans la console AWS ou via les API

Vous recevrez 21 adresses IP pour IPv4 lorsque vous activez les adresses IP statiques CloudFront en unidiffusion. Vous devrez ajouter toutes ces adresses IP dans toutes les listes d’autorisation pertinentes.

Non. CloudFront en unidiffusion ne sera disponible qu’avec des adresses IP réparties dans différentes régions géographiques.

Au fur et à mesure que CloudFront ajoute de nouveaux emplacements périphériques, votre liste d’adresses IP statiques en unidiffusion restera valide. Nous annoncerons vos adresses IP depuis les nouveaux emplacements périphériques, le cas échéant.

Toutes les fonctionnalités de CloudFront fonctionnent avec l’unidiffusion, à trois exceptions près : 1/ les adresses IP statiques en unidiffusion ne prennent pas en charge les anciens clients qui ne peuvent pas prendre en charge le SNI, 2/ vous devez utiliser Price Class All lorsque vous utilisez des adresses IP statiques en unidiffusion, et 3/ vous devez désactiver IPv6 lorsque vous utilisez des adresses IP statiques en unidiffusion. Les adresses IP statiques en unidiffusion fonctionnent au stade de la résolution DNS et une fois que la demande atteint un hôte, toutes les fonctionnalités et intégrations existantes avec les autres services AWS continueront d’être disponibles pour vos distributions.

Vous pouvez utiliser les adresses IP statiques en unidiffusion avec plusieurs distributions, mais elles doivent être associées au même compte. Les adresses IP statiques CloudFront en unidiffusion peuvent être associées à plusieurs distributions du compte. L’adresse IP statique CloudFront en unidiffusion prendra en charge l’indication du nom du serveur (SNI) afin que le certificat correct soit renvoyé par un certain nombre de distributions associées à leur politique d’IP statique en unidiffusion. Si vous souhaitez disposer d’adresses IP statiques distinctes pour plusieurs distributions au sein de votre compte, vous pouvez créer une liste d’adresses IP statiques en unidiffusion supplémentaire et les associer à des distributions spécifiques.

Lorsque vous créez une nouvelle distribution dans un compte avec les adresses IP statiques en unidiffusion activées, vous devez associer explicitement la nouvelle distribution à votre liste d’adresses IP statiques en unidiffusion existante. Par défaut, il utilisera des adresses IP dynamiques jusqu’à ce que vous le liez à votre liste IP statique.

Oui. Vous pouvez demander à augmenter les limites ici, et nous ajouterons plus de capacités à votre compte sous deux jours ouvrés.

Pour connaître le nombre maximal de distributions que vous pouvez actuellement créer pour chaque compte AWS, consulter Limite d’Amazon CloudFront dans la référence générale d’Amazon Web Services. Pour demander une limite supérieure, accédez au formulaire d’augmentation de limite CloudFront.

La taille maximum d'un fichier unique pouvant être distribué par le biais d'Amazon CloudFront est 30 Go. Cette limite s'applique à toutes les distributions d'Amazon CloudFront.

1. Journaux standard (journaux d’accès) Les journaux standard de CloudFront fournissent des enregistrements détaillés sur chaque demande adressée à une distribution. Ces journaux sont utiles pour de nombreux scénarios, notamment les audits de sécurité et d’accès.
2. Journaux en temps réel Les journaux en temps réel de CloudFront fournissent des informations sur les demandes adressées à une distribution, en temps réel (les enregistrements des journaux sont fournis quelques secondes après la réception des demandes). Vous pouvez choisir le taux d’échantillonnage de vos journaux en temps réel, c’est-à-dire le pourcentage de demandes pour lesquelles vous souhaitez recevoir des journaux en temps réel.
3. Journalisation des fonctions de périphérie : vous pouvez utiliser Amazon CloudWatch Logs pour obtenir les journaux de vos fonctions de périphérie, à la fois Lambda@Edge et les Fonctions CloudFront. Vous pouvez accéder aux journaux à l’aide de la console CloudWatch ou de l’API CloudWatch Logs. Pour plus d’informations, consulter Journaux des fonctions Edge.
4. Enregistrement de l’activité du service : vous pouvez utiliser AWS CloudTrail pour enregistrer l’activité du service CloudFront (activité de l’API) sur votre compte AWS. CloudTrail fournit un enregistrement des actions d’API effectuées par un utilisateur, un rôle ou un service AWS dans CloudFront. À l’aide des informations collectées par CloudTrail, vous pouvez déterminer la demande d’API qui a été envoyée à CloudFront, l’adresse IP à partir de laquelle la demande a été faite, qui l’a faite, quand elle a été faite et d’autres précisions. Pour plus d’informations, veuillez consulter la section Journalisation des appels d'API Amazon CloudFront à l'aide d'AWS CloudTrail.

• Les journaux standard CloudFront sont transmis au compartiment Amazon S3 de votre choix, à Amazon CloudWatch Logs et à Amazon Data Firehose. Pour plus d’informations, consulter la section Utiliser des journaux standard (journaux d'accès).
• Remarque : les journaux en temps réel CloudFront sont distribués vers le flux de données de votre choix dans Amazon Kinesis Data Streams. CloudFront facture les journaux en temps réel, ainsi que l’utilisation de Kinesis Data Streams. Pour plus d’informations, consulter la section Utiliser des journaux en temps réel.
• Les journaux des fonctions de périphérie CloudFront (Lambda@Edge et Fonctions CloudFront) sont transmis à Amazon CloudWatch Logs

Les journaux d’accès standard CloudFront peuvent être transmis à Amazon S3, Amazon CloudWatch et Amazon Data Firehose. Vous pouvez choisir le format du journal de sortie (texte brut, w3c, JSON, csv et parquet). Vous pouvez sélectionner les champs que vous souhaitez enregistrer et l’ordre dans lequel ces champs doivent être inclus dans les journaux. Pour les journaux envoyés à S3, vous pouvez également activer le partitionnement des journaux envoyés à S3, c’est-à-dire configurer les journaux pour qu’ils soient automatiquement partitionnés toutes les heures ou tous les jours. Vous pouvez également fournir des journaux d’accès standard à vos compartiments S3 dans les Régions AWS optionnelles. Consulter la section journaux d’accès standard du guide du développeur de CloudFront pour en savoir plus.

CloudFront ne facture pas l’activation des journaux standard, mais vous devrez payer des frais pour la livraison, le stockage et l’accès aux journaux en fonction de la destination de livraison des journaux. Consulter la section « Fonctionnalités supplémentaires » de la page de tarification CloudFront pour en savoir plus.

Oui. Amazon CloudFront offre diverses solutions pour répondre à vos besoins en matière de rapport, telles que la réception de rapports statistiques de mise en cache détaillés, la surveillance de votre utilisation de CloudFront, l'affichage de l'emplacement à partir duquel vos clients consultent votre contenu ou encore la définition d'alarmes en temps réel ou presque sur des mesures opérationnelles. Vous pouvez accéder à toutes nos options de génération de rapports en consultant le tableau de bord de génération de rapports et d'analytiques Amazon CloudFront dans la Console de gestion AWS. Vous pouvez également en savoir plus sur nos différentes options de génération de rapports en consultant la page Rapports et analytiques d’Amazon CloudFront.

Oui. Amazon CloudFront prend en charge le balisage dans la répartition des coûts. Les balises vous permettent de répartir facilement les coûts et d'optimiser vos dépenses en classant par catégories et en regroupant les ressources AWS. Par exemple, vous pouvez utiliser des balises pour regrouper les ressources par administrateur, nom d'application, centre de coûts ou projet. Pour en savoir plus sur le balisage de répartition des coûts, consulterUtilisation des balises de répartition des coûts. Si vous souhaitez ajouter des balises à vos distributions CloudFront, consulter Ajouter des balises Amazon CloudFront.

Oui. Pour obtenir l’historique de l’ensemble des appels d’API Amazon CloudFront réalisés sur votre compte, il vous suffit d’activer AWS CloudTrail dans la Console de gestion AWS CloudTrail. Pour en savoir plus, consulter la page d’accueil AWS CloudTrail.

Vous pouvez surveiller, configurer des alarmes et recevoir des notifications concernant les performances opérationnelles de vos distributions Amazon CloudFront dans les minutes qui suivent chaque requête utilisateur via le service Amazon CloudWatch. CloudFront publie automatiquement six métriques opérationnelles, chacune avec un niveau de précision d'une minute, dans Amazon CloudWatch. Vous pouvez utiliser CloudWatch pour configurer des alarmes qui se déclenchent en cas de schémas de trafic anormaux dans votre distribution CloudFront. Pour savoir comment surveiller l’activité CloudFront et définir des alarmes via CloudWatch, consulter notre procédure détaillée dans le guide du développeur Amazon CloudFront ou accéder simplement à la console de gestion Amazon CloudFront et sélectionner les options de surveillance et d’alarmes dans le volet de navigation.

Vous pouvez choisir une destination en fonction de votre cas d'utilisation. Si disposez de cas d'utilisation avec des contraintes de temps et que vous devez accéder rapidement aux données du journal en quelques secondes, choisissez les journaux en temps réel. Si vous devez réduire le coût de votre pipeline de journaux en temps réel, vous pouvez choisir de filtrer les données de journal en activant les journaux uniquement pour des comportements de cache spécifiques ou en choisissant un taux d'échantillonnage inférieur. Le pipeline de journaux en temps réel est conçu pour diffuser rapidement les données. Par conséquent, les enregistrements du journal peuvent être perdus s'il existe des retards de données. D'autre part, si vous avez besoin d'une solution de traitement de journaux économique sans nécessiter de données en temps réel, l'option de journal standard actuelle est idéale pour vous. Les journaux standard dans S3 sont des journaux complets, et sont généralement disponibles en quelques minutes. Ces journaux peuvent être activés pour l'ensemble de la distribution et non pour des comportements de cache spécifiques. Par conséquent, si vous avez besoin de journaux pour des investigations, des audits et des analyses ad hoc, vous pouvez choisir de n'activer que les journaux standard dans S3. Vous pouvez choisir d’utiliser une combinaison des deux journaux. Utilisez une liste filtrée de journaux en temps réel pour la visibilité opérationnelle, puis les journaux standard pour l'audit.
 

Les journaux standard CloudFront sont envoyés à votre compartiment S3. Vous pouvez également utiliser l’intégration de solutions tierces telles que DataDog et Sumologic pour créer des tableaux de bord à partir de ces journaux.

Les journaux en temps réel sont envoyés à Kinesis Data Stream. Depuis les Kinesis Data Streams, les journaux peuvent être publiés dans Amazon Kinesis Data Firehose. Amazon Kinesis Data Firehose facilite la diffusion de données vers Amazon S3, Amazon Redshift, Amazon OpenSearch Service et des fournisseurs de services tels que Datadog, New Relic et Splunk. Kinesis Firehose prend en charge également la distribution des données vers un point de terminaison HTTP générique.

Pour estimer le nombre de partitions dont vous avez besoin, procédez comme suit :

1. Calculez (ou estimez) le nombre de demandes par seconde que votre distribution CloudFront reçoit. Vous pouvez utiliser les rapports d'utilisation CloudFront ou les métriques CloudFront pour calculer vos demandes par seconde.
2. Déterminez la taille type d'un seul enregistrement en temps réel. Un enregistrement type qui contient tous les champs disponibles est d'environ 1 Ko. Si vous ne connaissez pas la taille de vos enregistrements, vous pouvez activer les journaux en temps réel avec un faible taux d'échantillonnage (par exemple, 1 %), puis calculer la taille moyenne des enregistrements en utilisant les données de surveillance dans Kinesis Data Streams (nombre total d'enregistrements divisé par le nombre total d'octets entrants).
3. Multipliez le nombre de demandes par seconde (à partir de l'étape 1) par la taille d'un enregistrement de journal en temps réel type (à partir de l'étape 2) pour déterminer la quantité de données par seconde que votre configuration de journal en temps réel est susceptible d'envoyer au Kinesis Data Stream.
4. En utilisant les données par seconde, calculez le nombre de partitions dont vous avez besoin. Une seule partition ne peut pas traiter plus de 1 Mo par seconde et 1 000 demandes (enregistrements de journal) par seconde. Pour calculer le nombre de tessons dont vous avez besoin, nous vous recommandons d'ajouter jusqu'à 25 % comme marge.

Supposons que votre distribution reçoive 10 000 demandes par seconde et que la taille de vos enregistrements de journal en temps réel est généralement de 1 Ko. Cela signifie que votre configuration de journal en temps réel pourrait générer 10 000 000 d'octets (10 000 multiplié par 1 000), soit 9,53 Mo, par seconde. Dans ce scénario, vous n'avez besoin que de 10 partitions Kinesis. Vous devez envisager de créer au moins 12 partitions pour avoir une marge.

Les Fonctions CloudFront sont une fonctionnalité de calcul en périphérique sans serveur vous permettant d'exécuter du code JavaScript sur des emplacements périphériques CloudFront pour des transformations et des manipulations HTTP(s) légères. Les Fonctions sont spécialement conçues pour offrir aux clients la flexibilité d'un environnement de programmation complet avec les performances et la sécurité requises par les applications web modernes. Pour une fraction du prix de AWS Lambda@Edge, les clients peuvent mettre à l’échelle instantanément et à moindre coût afin de prendre en charge des millions de requêtes par seconde.

Les Fonctions CloudFront sont intégrées de manière native à CloudFront, permettant aux clients de facilement créer, tester et déployer des fonctions au sein du même service. Vous pouvez également utiliser CloudFront KeyValueStore avec les Fonctions CloudFront pour stocker et récupérer des données de recherche afin de compléter la logique de votre fonction. Notre référentiel GitHub permet aux développeurs de démarrer facilement en proposant une grande collection d’exemples de code pouvant être utilisés comme point de départ pour la création de fonctions. Vous pouvez créer des fonctions sur la console CloudFront à l'aide de l'IDE ou des API/de l'interface de ligne de commande CloudFront. Une fois votre code créé, vous pouvez tester votre fonction par rapport à une distribution CloudFront de production, en vous assurant que votre fonction s'exécutera correctement une fois déployée. La fonctionnalité de test de la console propose un éditeur visuel pour créer rapidement des événements de test et valider des fonctions. Une fois associé à une distribution CloudFront, le code est déployé sur le réseau distribué au niveau mondial d'emplacements périphériques d'AWS, pour être exécuté en réponse aux demandes CloudFront.

Les Fonctions CloudFront sont idéales pour les fonctions légères et de courte durée, notamment :

• Normalisation de la clé de cache : vous pouvez transformer les attributs de requête HTTP (en‑têtes, chaînes de requête, cookies et même le chemin relatif de l’URL de la requête) pour créer une clé de cache optimale et améliorer les résultats de votre compteur cache hit ratio.
• Manipulation des en‑têtes : vous pouvez insérer, modifier ou supprimer des en‑têtes HTTP dans la requête ou la réponse. Par exemple, vous pouvez ajouter des en-têtes de sécurité de transport stricte HTTP (HTTP strict transport security/HSTS) ou de partage des ressources entre origines (Cross-origin Resource Sharing/CORS) à chaque réponse.
• Redirections ou réécriture d’URL : vous pouvez rediriger les utilisateurs vers d’autres pages en fonction des informations de la requête, ou rediriger toutes les requêtes d’un chemin vers un autre.
• Autorisation de requête : vous pouvez valider les jetons d’autorisation, tels que les jetons Web JSON (JWT), en inspectant les en‑têtes d’autorisation ou d’autres métadonnées de requête.

CloudFront KeyValueStore est un magasin de données clé-valeur mondial, à faible latence et entièrement géré. KeyValueStore permet la récupération de données clé-valeur à partir des fonctions CloudFront, ce qui rend ces dernières plus personnalisables grâce à des mises à jour indépendantes des données. Les données clé-valeur sont accessibles sur tous les emplacements périphériques de CloudFront et fournissent un stockage clé-valeur très efficace en mémoire ainsi qu'une grande vitesse de lecture des Fonctions CloudFront.

CloudFront KeyValueStore est idéal pour les lectures fréquentes sur les emplacements périphériques et les mises à jour peu fréquentes comme :

• Maintien des réécritures et redirections d’URL : redirigez les utilisateurs vers le site d’un pays spécifique en fonction de leur géolocalisation. Le stockage et la mise à jour de ces URL géolocalisées dans KeyValueStore simplifient la gestion des URL.
• Tests A/B et indicateurs de fonctionnalités : effectuez des tests en attribuant un pourcentage de trafic à une version de votre site Web. Vous pouvez mettre à jour les poids des expériences sans mettre à jour le code de fonction ou votre distribution CloudFront.
• Autorisation d’accès : implémentez le contrôle d’accès et l’autorisation pour le contenu diffusé via CloudFront en créant et en validant des jetons générés par les utilisateurs, tels que des jetons HMAC ou des jetons Web JSON (JWT), pour autoriser ou refuser les requêtes. 

Non. Les Fonctions CloudFront sont destinées à compléter Lambda@Edge, pas à le remplacer. Combiner les fonctions Lambda@Edge et CloudFront Functions vous permet de choisir l'outil adapté à la tâche. Vous pouvez choisir d'utiliser à la fois CloudFront Functions et Lambda@Edge sur différents déclencheurs d'événements au sein du même comportement de cache dans vos distributions CloudFront. Par exemple, vous pouvez utiliser Lambda@Edge en vue de manipuler à la volée la diffusion en continu des fichiers manifestes pour injecter des jetons personnalisés ; ce processus permet donc de sécuriser les flux en direct. Vous pouvez utiliser les Fonctions CloudFront pour valider ces jetons lorsqu'un utilisateur demande un segment à partir du manifeste.

Combiner les Fonctions CloudFront et Lambda@Edge vous offre deux options puissantes et flexibles pour exécuter du code en réponse aux événements CloudFront. Les deux options offrent des moyens sécurisés pour exécuter du code en réponse aux événements CloudFront sans gérer l'infrastructure. CloudFront Functions a été spécialement conçue pour les transformations et manipulations de requête/réponse légères, à grande échelle et sensibles à la latence. Lambda@Edge utilise des environnements d'exécution à usage général qui prennent en charge une vaste gamme de besoins informatiques et de personnalisations. Vous devez utiliser Lambda@Edge pour les opérations intensives de calcul. Il peut s'agir de calculs qui ont besoin de plus de temps avant d'être complétés (de plusieurs millisecondes à quelques secondes), qui prennent des dépendances sur des bibliothèques tierces externes, qui nécessitent des intégrations à d'autres services AWS (S3, DynamoDB, etc.), ou qui nécessitent des appels réseaux pour le traitement des données. Certains des cas d'utilisation avancés de Lambda@Edge les plus connus incluent la manipulation de manifeste HLS en streaming, les intégrations à l'autorisation tierce et aux services de détection de robots, le rendu côté serveur (SSR) des applications à page unique (SPA) à la périphérie, etc. Consulter la page des cas d’utilisation Lambda@Edge pour plus de détails.

Les Fonctions CloudFront fournissent les performances, l'évolutivité et la rentabilité que vous attendez, mais avec un modèle de sécurité unique qui offre des limites d'isolation strictes entre le code de fonctions. Lorsque vous exécutez du code personnalisé dans un environnement de calcul partagé et à locataires multiples, il est essentiel de maintenir un environnement d'exécution hautement sécurisé. Une personne mal intentionnée peut tenter d'exploiter les bogues présents dans l'environnement d'exécution, les bibliothèques ou le processeur, afin de divulguer des données sensibles à partir du serveur ou des fonctions d'un autre client. Sans une barrière d'isolation rigoureuse entre le code de fonction, ces codes malveillants sont possibles. AWS Lambda et Lambda@Edge réalisent déjà cet isolement de sécurité via l’isolation de machine virtuelle basée sur Firecracker. Avec les Fonctions CloudFront, nous avons développé un modèle d'isolation basé sur les processus qui fournit le même niveau de sécurité contre les attaques par canal auxiliaire comme Spectre et Meltdown, les attaques basées la temporisation ou d'autres vulnérabilités de code. CloudFront Functions ne peut pas accéder aux données appartenant à d'autres clients, ni les modifier. Nous faisons cela en exécutant des fonctions dans un processus dédié sur un processeur dédié. CloudFront Functions s'exécute sur les travailleurs de processus qui ne servent qu'un seul client à la fois, et toutes les données spécifiques au client sont effacées (purgées) entre les exécutions.

CloudFront Functions n'utilise pas V8 comme moteur JavaScript. Le modèle de sécurité des Fonctions est différent et considéré comme plus sécurisé que le modèle basé sur les isolats v8 proposé par certains autres fournisseurs.

Vous pouvez tester n'importe quelle fonction à l'aide de la fonctionnalité de test intégrée. Le test d'une fonction exécutera votre code sur une distribution CloudFront, afin de valider que la fonction produit le résultat attendu. Outre la validation de l’exécution du code, vous disposez également d’une métrique d’utilisation de calcul. La métrique d'utilisation du calcul vous indique en pourcentage à quel point votre fonction est proche de la limite de temps d'exécution. Par exemple, une utilisation de calcul de 30 signifie que votre fonction utilise 30 % du temps d'exécution total autorisé. Les objets de test peuvent être créés à l'aide d'un éditeur visuel, ce qui vous permet d'ajouter facilement des chaînes de requête, des en-têtes, des URL et des méthodes HTTP pour chaque objet ; vous pouvez aussi créer des objets de test à l'aide d'une représentation JSON de la requête ou de la réponse. Une fois le test exécuté, les résultats et la métrique d'utilisation du calcul peuvent être visualisés dans le même type d'éditeur visuel, ou en affichant la réponse JSON. Si la fonction s'exécute sans entrave et que la métrique d'utilisation du calcul n'est pas proche de 100, vous savez que la fonction opérera lorsqu'elle sera associée à une distribution CloudFront.

Les Fonctions CloudFront produisent à la fois des métriques et des journaux d'exécution pour surveiller l'utilisation et les performances d'une fonction. Des métriques sont générées pour chaque invocation d'une fonction et vous pouvez voir les métriques de chaque fonction individuellement sur la console CloudFront ou CloudWatch. Les métriques incluent le nombre d'invocations, l'utilisation du calcul, les erreurs de validation et les erreurs d'exécution. Si votre fonction entraîne une erreur de validation ou une erreur d'exécution, le message d'erreur apparaîtra également dans vos journaux d'accès CloudFront, vous donnant une meilleure visibilité sur l'impact de la fonction sur votre trafic CloudFront. En plus des métriques, vous pouvez également générer des journaux d'exécution en incluant une instruction console.log() dans votre code de fonction. Toute instruction de journal générera une entrée de journal CloudWatch qui sera envoyée à CloudWatch. Les journaux et les métriques sont inclus dans la tarification des Fonctions CloudFront. 

Lambda@Edge est une extension d’AWS Lambda qui vous permet d’exécuter du code à des emplacements périphériques mondiaux, sans provisionnement ni gestion de serveurs. Lambda@Edge offre un calcul sans serveur puissant et flexible pour des fonctions complexes et une logique d'application complète plus proche de vos utilisateurs. Les fonctions Lambda@Edge s'exécutent dans un environnement Node.js ou Python. Vous publiez des fonctions dans une seule région AWS, et lorsque vous associez la fonction à une distribution CloudFront, Lambda@Edge réplique automatiquement votre code dans le monde entier. Lambda@Edge évolue automatiquement, de quelques requêtes par jour à des milliers par seconde.

Lambda@Edge est exécutée en associant des fonctions à des comportements de cache spécifiques dans CloudFront. Vous pouvez également spécifier à quel moment pendant le traitement de la requête ou de la réponse CloudFront la fonction doit s'exécuter (c'est-à-dire lorsque la requête d'un utilisateur parvient, lorsqu'une requête est transférée ou reçue de l'origine, ou juste avant de répondre à l'utilisateur final). Vous pouvez écrire du code à l’aide de Node.js ou de Python depuis la console Lambda, l’API ou avec des cadres tels que le Modèle d’application sans serveur (SAM). Lorsque vous avez testé votre fonction, vous l'associez au comportement de cache CloudFront et au déclencheur d'événement sélectionnés. Une fois enregistrée, dès que la prochaine demande est envoyée à votre distribution CloudFront, la fonction est propagée jusqu'à l'emplacement périphérique CloudFront, s'ajuste et s'exécute en conséquence. Pour en savoir plus, consulter notre documentation.

Vos fonctions Lambda@Edge se déclenchent automatiquement suite aux événements Amazon CloudFront suivants :

• Requête utilisateur : cet événement se produit lorsqu’un utilisateur final ou un appareil sur Internet adresse une requête HTTP(S) à CloudFront et que celle‑ci arrive à l’emplacement périphérique le plus proche de cet utilisateur.
• Réponse utilisateur : cet événement se produit lorsque le serveur CloudFront en périphérie est prêt à répondre à l’utilisateur final ou à l’appareil ayant formulé la requête.
• Requête de l’origine : cet événement se produit lorsque le serveur CloudFront en périphérie n’a pas l’objet demandé en cache et que la requête utilisateur est prête à être envoyée à votre serveur web d’origine dorsal (par exemple Amazon EC2, Application Load Balancer ou Amazon S3).
• Réponse de l’origine : cet événement se produit lorsque le serveur CloudFront en périphérie reçoit une réponse de votre serveur web d’origine dorsal.

Le déploiement continu sur CloudFront permet de tester et de valider les changements de configuration avec une partie du trafic en direct avant de déployer les changements à tous les utilisateurs.

Le déploiement continu avec CloudFront vous offre un niveau élevé de sécurité de déploiement. Vous pouvez désormais déployer deux environnements distincts mais identiques, le bleu et le vert, et permettre une intégration simple dans vos pipelines d'intégration et de livraison continues (CI/CD) avec la possibilité de déployer des versions graduellement sans aucun changement de système de nom de domaine (DNS). Il garantit que votre spectateur bénéficie d'une expérience cohérente grâce à l'adhérence de la session en liant la session du spectateur au même environnement. En outre, vous pouvez comparer les performances de vos modifications en surveillant les journaux standard et en temps réel et revenir rapidement à la configuration précédente lorsqu'une modification a un impact négatif sur un service. 

Vous pouvez configurer le déploiement continu en associant une distribution de transition à une distribution primaire via la console CloudFront, le SDK, l’interface de ligne de commande (CLI) ou le modèle CloudFormation. Vous pouvez ensuite définir des règles pour diviser le trafic en configurant l’en-tête du client ou en composant un pourcentage du trafic à tester avec la distribution de transition. Une fois la configuration établie, vous pouvez la mettre à jour en y apportant les modifications souhaitées. CloudFront gérera la répartition du trafic vers les utilisateurs et fournira les analyses associées pour vous aider à décider si vous devez poursuivre le déploiement ou faire marche arrière. Une fois que les tests avec les distributions de transition ont été validés, vous pouvez fusionner les changements avec la distribution principale.

Pour en savoir plus sur cette fonctionnalité, consulter la documentation.

Le déploiement continu permet un suivi réel des utilisateurs grâce à un trafic web réel. Vous pouvez utiliser l’une des méthodes de surveillance existantes - console CloudFront, API CloudFront, CLI ou CloudWatch - pour mesurer individuellement les paramètres opérationnels de la distribution primaire et de la distribution de transition. Vous pouvez mesurer les critères de réussite de votre application spécifique en mesurant et en comparant les paramètres de débit, de latence et de disponibilité entre les deux distributions.

Oui, vous pouvez utiliser n’importe quelle distribution existante comme base de référence pour créer une distribution de transition et introduire et tester les changements.

Avec le déploiement continu, vous pouvez associer différentes fonctions aux distributions primaire et de transition. Vous pouvez également utiliser la même fonction avec les deux distributions. Si vous mettez à jour une fonction qui est utilisée par les deux distributions, elles reçoivent toutes deux la mise à jour.

Chaque ressource de votre pile CloudFormation correspond à une ressource AWS spécifique. Une distribution de transition aura son propre ID de ressource et fonctionnera comme toute autre ressource AWS. Vous pouvez utiliser CloudFormation pour créer/mettre à jour cette ressource.

Lorsque vous utilisez une configuration basée sur le poids pour acheminer le trafic vers une distribution de transit, vous pouvez également activer l’adhérence de session, qui permet de s’assurer que CloudFront traite les demandes provenant du même utilisateur comme une seule session. Lorsque vous activez l’adhérence de session, CloudFront définit un cookie afin que toutes les demandes provenant du même utilisateur dans une même session soient servies par une seule distribution, soit la distribution primaire, soit la distribution de secours.

La fonctionnalité de déploiement continu est disponible sur tous les emplacements périphériques de CloudFront sans coût supplémentaire.

Chaque serveur et appareil connecté à Internet doit disposer d'une adresse IP (Internet Protocol) numérique. Internet et le nombre de personnes l'utilisant s'étendent de façon exponentielle, et il en va de même pour la demande en adresses IP. IPv6 est une nouvelle version d'Internet Protocol, qui repose sur un espace d'adressage plus vaste que son prédécesseur, IPv4. Avec le protocole IPv4, chaque adresse IP se compose de 32 bits, soit 4,3 milliards d'adresses uniques possibles. Voici un exemple d'adresse IPv4 : 192.0.2.1. À titre de comparaison, les adresses IPv6 sont composées de 128 bits, ce qui permet d'obtenir environ 340 billions de billions d'adresses IP uniques. Voici un exemple d'adresse IPv6 : 2001:0db8:85a3:0:0:8a2e:0370:7334

Grâce à la prise en charge d'IPv6 pour Amazon CloudFront, les applications peuvent se connecter aux emplacements périphériques Amazon CloudFront sans passer par un logiciel ou système de traduction d'IPv6 vers IPv4. Vous pouvez répondre aux exigences relatives à l'adoption d'IPv6 définies par les gouvernements, y compris le gouvernement fédéral des États‑Unis, et bénéficier de l’extensibilité, de la simplicité de la gestion réseau et du support additionnel intégré pour la sécurité qu’offre le protocole IPv6.

Non. Vous obtiendrez les mêmes performances avec Amazon CloudFront, que vous utilisiez IPv4 ou IPv6.

Toutes les fonctionnalités existantes d'Amazon CloudFront continueront à fonctionner sur IPv6, mais deux modifications seront peut-être nécessaires pour le traitement des adresses IPv6 internes avant que vous activiez IPv6 pour vos distributions.

1. Si vous avez activé la fonctionnalité des journaux d’accès Amazon CloudFront, l'adresse IPv6 de votre utilisateur apparaîtra dans le champ « c-ip » et vous devrez peut-être vérifier que vos systèmes de traitement des journaux continuent de fonctionner pour IPv6.
2. Lorsque vous activez IPv6 pour votre distribution Amazon CloudFront, vous voyez les adresses IPv6 dans l'en-tête « X-Forwarded-For » qui est envoyé à vos origines. Si vos systèmes d'origine peuvent uniquement traiter les adresses IPv4, il peut être nécessaire de vérifier que vos systèmes d'origine continuent de fonctionner pour IPv6.

De plus, si vous utilisez des listes blanches d'IP pour les utilisateurs de confiance, vous pouvez uniquement avoir recours à une distribution IPv4 pour les URL des utilisateurs de confiance avec des listes blanches d'IP et une distribution IPv4/IPv6 pour tous les autres contenus. Ce modèle vous permet de contourner un problème qui se présenterait si la demande de signature arrivait via une adresse IPv4 et était signée comme telle, suivie d'une demande de contenu arrivant via une adresse IPv6 différente ne se trouvant pas sur la liste blanche.

Pour en savoir plus sur la prise en charge d'IPv6 dans Amazon CloudFront, consulter « Prise en charge d'IPv6 sur Amazon CloudFront » dans le guide du développeur Amazon CloudFront.

Si vous désirez utiliser IPv6 et des URL de signataire autorisé avec une liste blanche d'IP, vous devrez utiliser deux distributions indépendantes. L'une d'entre elles sera exclusivement dédiée à vos URL d'utilisateurs de confiance avec liste blanche d'IP, avec IPv6 désactivé. L'autre distribution sera utilisée pour tous les autres contenus et sera compatible avec IPv4 et IPv6.

Oui, les adresses IPv6 de l'utilisateur seront affichées dans le champ « c-ip » des journaux d'accès si les journaux d'accès Amazon CloudFront sont activés. Vous devrez peut-être vérifier que vos systèmes de traitement de journaux continuent de fonctionner pour les adresses IPv6 avant d'activer IPv6 pour vos distributions. En cas de difficulté liée à l'impact du trafic IPv6 sur votre outil ou logiciel de traitement des adresses IPv6 consignées dans les journaux d'accès, contactez le Support développeurs. Pour plus d’informations, consulter la documentation sur les journaux d’accès Amazon CloudFront.

Oui. La console ou l'API Amazon CloudFront peut être utilisée pour activer ou désactiver IPv6 pour chaque distribution nouvelle ou existante.

Lors des discussions avec les clients, le seul cas courant qui a été avancé était le traitement interne des adresses IP. Quand vous activez IPv6 pour votre distribution Amazon CloudFront, en plus d'une adresse IPv6 dans vos journaux d'accès détaillés, vous voyez les adresses IPv6 dans l'en-tête « X-Forwarded-For» qui est envoyé à vos origines. Si vos systèmes d'origine ne peuvent traiter que les adresses IPv4, vous devrez peut-être vous assurer qu'ils continuent de fonctionner avec des adresses IPv6 avant d'activer IPv6 dans vos distributions.

Amazon CloudFront dispose d'une connectivité très diverse autour du monde, mais certains réseaux ne proposent pas encore de connectivité IPv6 universelle. Le protocole IPv6 est indispensable à l'avenir d'Internet sur le long terme, mais dans un futur proche, chaque point de terminaison sur Internet sera doté d'une connectivité IPv4. Si certains secteurs d'Internet possèdent une connectivité IPv4 supérieure à leur connectivité IPv6, nous privilégierons la première.

Oui, vous pouvez créer des jeux d'enregistrement alias Route 53 donnant sur votre distribution Amazon CloudFront pour prendre en charge à la fois le protocole IPv4 et le protocole IPv6, en utilisant les types de jeux « A » et « AAAA », respectivement. Si vous ne souhaitez activer que l'IPv4, vous n'avez besoin que d'un jeu d'enregistrements alias de type « A ». Pour plus d’informations sur les ensembles d’enregistrements de ressources d’alias, consulter le guide du développeur Amazon Route 53.

À compter du 1er décembre 2021, tous les clients AWS bénéficieront gratuitement de 1 To de transfert de données sortantes, de 10 000 000 de requêtes HTTP/HTTPS et de 2 000 000 invocations des Fonctions CloudFront par mois. Toutes les autres types d’utilisation (invalidations, requêtes proxy, Lambda@Edge, Origin Shield, transfert de données vers l’origine, etc.) sont exclus de l’offre gratuite.  

Non, les clients qui utilisent la facturation consolidée pour regrouper le paiement de plusieurs comptes ne bénéficient que d'une seule offre gratuite par organisation.

L'offre gratuite se limite à 1 To de transfert de données et à 10 millions de requêtes Get par mois pour tous les emplacements périphériques. Si votre utilisation dépasse les limites mensuelles de l'offre gratuite, vous êtes soumis aux tarifs standard du service AWS à la demande pour chaque région. Pour obtenir des détails complets sur la tarification, consultez la page de tarification AWS CloudFront.

Vous pouvez consulter l'activité d'utilisation actuelle et passée par région en vous connectant à votre compte et en accédant au tableau de bord de gestion de la facturation et des coûts. À partir de là, vous pouvez gérer vos coûts et votre utilisation à l’aide d’AWS Budgets, visualiser vos inducteurs de coûts et vos tendances d’utilisation via l’Explorateur de coûts et analyser vos coûts grâce aux Rapports d’utilisation et de coût. Pour en savoir plus sur la manière de contrôler vos coûts AWS, consulter le didacticiel de 10 minutes intitulé Contrôlez vos coûts AWS.

Les clients souscrivant un forfait sécurité CloudFront ont également accès à l’offre gratuite. Si vous jugez préférable de réduire votre engagement envers le forfait sécurité CloudFront au profit de l'offre gratuite, contactez notre service clients afin que nous évaluions votre demande de modification. Nous vous fournirons des détails supplémentaires à ce sujet dans les prochains jours. Restez à l'écoute. 

Pour toute question supplémentaire, veuillez accéder à l’adresse suivante : https://aws.amazon.com/free/free-tier-faqs/.

Les frais Amazon CloudFront sont basés sur l'utilisation réelle du service dans cinq domaines : transfert de données sortantes, requêtes HTTP/HTTPS, demandes d'invalidation, demandes de journaux en temps réel et certificats SSL personnalisés à IP dédiée associés à une distribution CloudFront.

Avec le niveau d’offre gratuite d’AWS, vous pouvez démarrer avec Amazon CloudFront gratuitement et minimiser vos coûts à mesure que votre utilisation évolue. Tous les clients CloudFront bénéficient gratuitement de 1 To de transfert de données sortantes et de 10 000 000 de requêtes HTTP et HTTPS pour Amazon CloudFront, même lorsque ces limites sont dépassées. Si 

• Transfert de données sortantes vers Internet
  Le volume de données transféré, mesuré en Go, depuis les emplacements périphériques Amazon CloudFront, vous es facturé. Vous pouvez consulter les tarifs du transfert de données Amazon CloudFront vers Internet ici. Notez que votre utilisation du transfert de données est totalisée séparément pour des régions géographiques spécifiques. Le coût est ensuite calculé en fonction des niveaux de tarification de chaque zone. Si vous utilisez d’autres services AWS comme origines de vos fichiers, votre utilisation de ces services est facturée séparément, notamment le stockage et les heures de calcul. Si vous utilisez une origine AWS (comme Amazon S3 ou Amazon EC2), nous ne facturons plus le transfert de données AWS en dehors d’Amazon CloudFront depuis le 1er décembre 2014. Cela concerne le transferts de données à partir de l'ensemble des Régions AWS vers tous les emplacements périphériques CloudFront dans le monde.
• Transfert sortant de données vers le serveur d'origine
  Vous serez facturé pour le volume de données transférées sortant, mesuré en Go, des emplacements périphériques d'Amazon CloudFront vers votre serveur d'origine (serveurs d'origine AWS et autres serveurs d'origine). Vous pouvez consulter la tarification pour le transfert de données Amazon CloudFront vers l’origine ici.
• Requêtes HTTP/HTTPS
  Vous serez facturé en fonction du nombre de requêtes HTTP/HTTPS faites à Amazon CloudFront pour votre contenu. Vous pouvez consulter la tarification pour les demandes HTTP/HTTPS ici.
• Demandes d'invalidation
  Vous êtes facturé pour chaque chemin dans votre demande d'invalidation. Un chemin figurant dans votre demande d'invalidation désigne l'URL (ou plusieurs URL si le chemin contient un caractère générique) de l'objet que vous souhaitez invalider du cache CloudFront. Chaque mois, vous pouvez demander gratuitement jusqu'à 1 000 chemins à partir d'Amazon CloudFront. Au-delà de ce seuil, vous serez facturé pour chaque chemin figurant dans vos demandes d'invalidation. Vous pouvez consulter la tarification pour les demandes d’invalidation ici.
• Demandes de journaux en temps réel
  Les journaux en temps réel sont facturés en fonction du nombre de lignes de journal générées. Vous payez 0,01 USD pour chaque million de lignes de journal que CloudFront publie dans votre destination de journal.
• Certificats SSL personnalisés dédiés
  Chaque certificat SSL personnalisé associé à une ou plusieurs distributions CloudFront utilisant la variante IP dédiée de l'option de prise en charge des certificats SSL personnalisés coûte 600 USD. Ces frais mensuels sont calculés au prorata du nombre d'heures. Par exemple, si votre certificat SSL personnalisé a été associé avec au moins une distribution CloudFront pendant seulement 24 heures (c.-à-d. 1 jour) au cours du mois de juin, vos frais totaux pour l'utilisation de la fonctionnalité de certificat SSL personnalisé en juin s'élèveront à (1 jour / 30 jours) * 600 USD = 20 USD. Pour utiliser la fonctionnalité de prise en charge des certificats SSL personnalisés à IP dédiée, chargez un certificat SSL et associez-le à vos distributions CloudFront à l'aide de la Console de gestion AWS. Si vous devez associer plus de deux certificats SSL personnalisés à vos distributions CloudFront, incluez les informations relatives à votre cas d’utilisation ainsi que le nombre de certificats SSL personnalisés que vous souhaitez utiliser dans le formulaire d’augmentation de limite CloudFront.

Les niveaux d'offre pour le transfert de données sont mesurés séparément pour chaque région géographique. Les prix ci-dessus excluent les taxes, honoraires ou autres frais gouvernementaux applicables, le cas échéant, sauf mention contraire.

Sauf indication contraire, nos prix n'incluent pas les taxes et redevances applicables, y compris la TVA et les taxes sur les ventes applicables. Pour les clients dont l'adresse de facturation est située au Japon, l'utilisation de services AWS est soumise à la taxe sur la consommation applicable dans ce pays. En savoir plus.

Si votre distribution traite 1 000 demandes par seconde avec une taille de log de 1 Ko et que vous créez un Kinesis Data Stream dans la région USA Est (Ohio) avec 2 partitions :

Coût mensuel de Kinesis Data Stream : 47,74 USD/mois, calculé à l’aide du calculateur Kinesis ici.

Coût mensuel des journaux en temps réel CloudFront : demandes par mois X coût des journaux en temps réel = 1 000 x (60 sec x 60 min x 24 heures x 30 jours) X (0,01 USD/1 000 000) = 25,92 USD/mois

Une réponse 304 est une réponse à une demande GET conditionnelle, pour laquelle seuls la requête HTTP/HTTPS et le transfert sortant de données vers Internet vous seront facturés. Une réponse 304 ne contient pas de corps de message. Toutefois, les en-têtes HTTP consommeront de la bande passante, pour laquelle vous serez facturé au taux de transfert de données CloudFront standard. Le volume de transfert de données dépend des en-têtes associés à votre objet.

Oui, les « catégories de tarifs » vous donnent la possibilité de payer moins pour diffuser du contenu à partir d'Amazon CloudFront. Par défaut, Amazon CloudFront minimise la latence côté utilisateur en diffusant le contenu à partir de l'ensemble de son réseau mondial d'emplacements périphériques. Cependant, comme nous facturons un prix supérieur dans les régions où nos coûts sont plus élevés, il y a certains cas où vous payez plus cher pour diffuser votre contenu avec une faible latence pour les utilisateurs finaux. Les catégories de tarifs vous permettent de réduire vos frais de diffusion en excluant les emplacements périphériques Amazon CloudFront les plus chers de votre distribution Amazon CloudFront. Dans ce cas, Amazon CloudFront diffuse votre contenu à partir d'emplacements périphériques au sein des régions de la catégorie de tarif choisie ; les transferts et demandes de données vous sont facturés en fonction des tarifs de la région au sein de laquelle le contenu a effectivement été diffusé.

Si vous souhaitez avant tout privilégier les performances, aucune action n'est requise de votre part : votre contenu sera diffusé à partir de l'ensemble de nos emplacements. Toutefois, si vous souhaitez utiliser une autre catégorie de tarif, vous pouvez configurer votre distribution via AWS Management Console ou via l'API Amazon CloudFront. Si vous optez pour une catégorie de tarif qui n'inclut pas tous les emplacements, certains de vos utilisateurs, en particulier au niveau des emplacements géographiques non compris dans la catégorie choisie, peuvent rencontrer une latence supérieure à celle qu'ils auraient eue si votre contenu était diffusé à partir de tous les emplacements Amazon CloudFront.

Remarque : Amazon CloudFront peut, occasionnellement, traiter les demandes liées à votre contenu à partir d'un emplacement périphérique n'appartenant pas à votre catégorie de tarif. Dans ce cas, seuls les frais de l'emplacement le moins onéreux de votre catégorie de tarif vous seront facturés.

Pour consulter la liste des emplacements pour chaque catégorie de prix, cliquer ici.

Le forfait sécurité CloudFront est un plan de tarification en libre-service flexible pouvant réduire jusqu'à 30 % votre facture CloudFront, en contrepartie d'un engagement quant à un volume constant d'utilisation mensuelle (par exemple, 100 USD/mois) pour une période d'un an.  Qui plus est, une utilisation d'AWS WAF (Pare-feu de l'application Web), pour jusqu'à 10 % du montant de votre forfait engagé pour la protection des ressources CloudFront, est incluse sans frais supplémentaires.  Par exemple, un engagement de 100 USD d'utilisation de CloudFront par mois couvrirait 142,86 USD d'utilisation de CloudFront, soit une économie de 30 % par rapport aux tarifs standard. De plus, jusqu'à 10 USD d'utilisation d'AWS WAF sont inclus pour protéger vos ressources CloudFront sans frais supplémentaires chaque mois (jusqu'à 10 % de votre engagement CloudFront).  Des frais standard CloudFront et AWS WAF s'appliquent à toute utilisation supérieure à la couverture prévue par votre engagement de dépense mensuelle.  À mesure que votre utilisation augmente, vous pouvez acheter des forfaits groupés supplémentaires pour obtenir des réductions par rapport à une utilisation supplémentaire. 

En achetant un forfait sécurité CloudFront, vous bénéficiez d'une réduction de 30 % qui apparaîtra sur la partie de votre facture mensuelle consacrée au service CloudFront, qui compensera tous les types d'utilisation facturés par CloudFront, notamment le transfert de données vers l'origine, les frais de requête HTTP/S, les demandes de chiffrement sur le terrain, Origin Shield, les invalidations, le SSL personnalisé, l'IP dédiée, le SSL personnalisé, les adresses IP en unidiffusion, Lambda@Edge, les Fonctions CloudFront, les journaux en temps réel, l'utilisation du cache régional Edge, gRPC, WebSocket support et autres fonctionnalités de CloudFront. Vous recevrez également des avantages supplémentaires qui vous aideront à couvrir l'utilisation d'AWS WAF associée à vos distributions CloudFront.

Vous pouvez commencer à utiliser le forfait sécurité CloudFront en vous rendant sur la console CloudFront pour obtenir des recommandations sur le montant de l’engagement en fonction de votre historique d’utilisation de CloudFront et d’AWS WAF, ou en renseignant votre propre estimation d’utilisation mensuelle. Vous obtenez une comparaison entre les coûts mensuels du forfait sécurité CloudFront et les coûts à la demande vous permettant d'avoir une estimation des économies pour vous aider à décider du forfait le mieux adapté à vos besoins.  Une fois que vous aurez souscrit à une solution Savings Bundle, votre engagement mensuel vous sera facturé et vous verrez apparaître des crédits qui compenseront vos frais d'utilisation de CloudFront et de WAF.  Des frais de service standard s'appliquent à toute utilisation supérieure à la couverture prévue par votre engagement de dépense mensuelle. 

À l'expiration de la période de votre forfait sécurité CloudFront, des frais de service standard seront appliqués pour votre utilisation de CloudFront et d'AWS WAF.   L'engagement d'utilisation mensuelle de la solution Savings Bundle ne sera plus facturé et les avantages ne s'appliqueront plus.  À tout moment avant l'expiration de la durée de votre forfait, vous pouvez choisir de renouveler automatiquement le forfait sécurité CloudFront pour une nouvelle période d'un an.

Il est possible d'acheter un forfait sécurité CloudFront dans n'importe quel compte d'une famille AWS Organization/de facturation consolidée.   Les avantages de la solution CloudFront Security Savings Bundle sont appliqués sous la forme de crédits sur votre facture. Les avantages offerts par le forfait sécurité sont applicables à l'utilisation de tous les comptes au sein d'une famille AWS Organization/de facturation consolidée par défaut (le partage de crédits est activé) et dépendent du moment où le compte abonné rejoint ou quitte une organisation.  Consulter crédits AWS pour en savoir plus sur l’application des crédits AWS à des comptes uniques et multiples.

Oui, vous pouvez acheter des forfaits sécurité CloudFront supplémentaires à mesure que votre utilisation augmente pour ainsi obtenir des réductions sur toute utilisation supplémentaire.   Tous les forfaits sécurité CloudFront actifs seront pris en compte dans le calcul de votre facture AWS.

Vos frais d’engagement mensuel pour le forfait sécurité CloudFront apparaîtront sur votre facture dans une section distincte.  L’utilisation couverte par votre forfait sécurité CloudFront apparaîtra dans les rubriques CloudFront et WAF de votre facture sous forme de crédits pour compenser vos frais d’utilisation standard.  

Oui, AWS Budgets vous permet de fixer des seuils de coût et d’utilisation, mais aussi de recevoir des notifications par e‑mail ou par rubrique Amazon SNS lorsque vos frais réels ou prévus dépassent le seuil.  Vous pouvez créer un budget AWS personnalisé filtré pour le service CloudFront et fixer le montant du seuil de budget par rapport à l'utilisation à la demande de CloudFront couverte par votre forfait sécurité CloudFront, et ainsi être averti lorsque ce seuil a été dépassé.   Pour de plus amples informations sur les budgets, consulter Gérer vos coûts avec AWS Budgets et Créer un budget dans le guide de l'utilisateur de Facturation et gestion des coûts AWS. 

Le forfait sécurité CloudFront offre un avantage supplémentaire, à savoir l’inclusion sans frais supplémentaires d’une utilisation d’AWS WAF, s’élevant jusqu’à 10 % du montant de votre forfait engagé pour la protection des ressources CloudFront. Les frais standard de CloudFront et AWS WAF s'appliquent à toute utilisation allant au-delà de la couverture prévue par le forfait sécurité CloudFront.  Les règles WAF gérées souscrites par le biais d’AWS Marketplace ne sont pas couvertes par le forfait sécurité CloudFront. 

Vous ne pouvez souscrire qu’à l’une des deux offres.  Veuillez contacter votre gestionnaire de compte AWS si vous avez des questions concernant votre accord de tarification personnalisée.

Vous pouvez souscrire un forfait sécurité CloudFront uniquement via la console CloudFront.  Nous évaluerons prochainement une éventuelle mise à disposition du forfait via une API.