- Mise en réseau et diffusion de contenu›
- Amazon CloudFront›
- Questions fréquentes (FAQ)
FAQ sur Amazon CloudFront
Sécurité
Comment puis-je sécuriser mes origines avec CloudFront ?
CloudFront propose deux méthodes entièrement gérées pour protéger vos origines :
- 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 fonction Lambda, garantissant que seul CloudFront peut accéder au contenu.
- 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 :
- 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.
- 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.thinkwithwp.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.
- 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.
Streaming
Qu'est-ce que Media-Quality Aware Resiliency ?
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, consultez le Guide du développeur de CloudFront.
Journalisation et génération de rapports
Quelles sont les fonctionnalités de journalisation disponibles avec Amazon CloudFront ?
- 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.
- 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.
- 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, veuillez consulter la section Edge function logs.
- 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 Logging Amazon CloudFront API calls using AWS CloudTrail.
Quelles destinations de livraison des journaux sont disponibles pour la livraison des journaux CloudFront ?
- Les journaux standard CloudFront sont transmis au compartiment Amazon S3 de votre choix, à Amazon CloudWatch Logs et à Amazon Data Firehose. Pour plus d’informations, veuillez consulter la section Use standard logs (access logs).
- 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, veuillez consulter la section Use real-time logs.
- Les journaux des fonctions de périphérie CloudFront (Lambda@Edge et Fonctions CloudFront) sont transmis à Amazon CloudWatch Logs.
Quelles fonctionnalités sont disponibles avec les journaux d’accès standard ?
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. Consultez la section relative aux journaux d’accès standard du guide du développeur de CloudFront pour en savoir plus.
L’activation du journal d’accès standard pour CloudFront est-elle facturée séparément ?
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. Consultez la section « Fonctionnalités supplémentaires » de la page de tarification de CloudFront pour en savoir plus.
Comment déterminer les journaux CloudFront adaptés à mon cas d’utilisation ?
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.
Quelles sont les différentes options de destination des journaux disponibles ?
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 permet d’envoyer aisément des données à Amazon S3, Amazon Redshift, Amazon Elasticsearch Service et à des fournisseurs de services comme 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.
De combien de partitions Kinesis ai‑je besoin dans Kinesis Data Stream ?
Pour estimer le nombre de partitions dont vous avez besoin, procédez comme suit :
- 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.
- 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).
- 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.
- 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.