Amazon CloudFront sert aujourd’hui de porte d’entrée à des millions de sites web, d’API et de flux vidéo en Europe. Mal configuré, ce CDN devient pourtant une faille ouverte : bucket S3 exposé publiquement, certificat TLS obsolète, absence totale de pare-feu applicatif. Ce tutoriel détaille, étape par étape, comment verrouiller une distribution CloudFront de bout en bout, depuis l’Origin Access Control jusqu’à la conformité RGPD, avec les commandes et le code nécessaires pour tout reproduire dans votre propre compte AWS.

Pourquoi la sécurité CloudFront est redevenue prioritaire en 2026

Le marché des CDN reste dominé par une poignée d’acteurs, mais les méthodologies de mesure divergent fortement selon la source consultée. Le cabinet IDC situe la part de CloudFront entre 19 et 21 % du trafic mondial, contre 17 à 19 % pour Cloudflare. Le cabinet 6sense, qui mesure la présence technologique détectée sur le web plutôt que les revenus publicitaires, attribue au contraire 40,79 % à Cloudflare et seulement 26,81 % à CloudFront. Ces écarts rappellent qu’aucun chiffre de part de marché ne doit être lu sans connaître sa méthode de calcul.

Pour les équipes qui opèrent déjà sur AWS, CloudFront reste malgré tout le choix par défaut. Il s’intègre nativement à S3, Lambda, ACM et AWS WAF, sans dépendre d’un tiers externe. En avril 2026, AWS a ajouté la prise en charge de SHA-256 pour les URLs et cookies signés, qui reposaient jusque-là sur SHA-1, un algorithme de hachage affaibli face aux attaques par collision depuis des années. Ce changement concerne directement toute distribution qui protège du contenu privé.

Autre évolution à connaître : les plans à tarif fixe de CloudFront regroupent désormais le CDN, AWS WAF, la protection DDoS Shield, le DNS Route 53 et le calcul en edge dans une seule facture, avec jusqu’à 10 % du montant engagé consommé gratuitement en règles WAF. Pour une entreprise française qui distribue du contenu vers plusieurs pays européens, cette bascule pèse directement sur le coût total d’une architecture CDN sécurisée.

La question de la souveraineté des données reste un angle mort pour beaucoup d’équipes françaises qui déploient CloudFront sans y penser. Le choix d’une région AWS européenne pour l’origine (Paris, Francfort, Dublin, Stockholm) ne garantit pas automatiquement que l’ensemble de la chaîne reste en Europe : le réseau de points de présence CloudFront est mondial par nature, même si le trafic d’un visiteur français est quasiment toujours servi depuis un point de présence européen pour des raisons de latence. Pour les organisations soumises à des exigences de souveraineté renforcées, l’AWS European Sovereign Cloud répond à un périmètre différent de celui d’une simple région européenne classique, et le choix entre les deux doit être documenté séparément selon le niveau de garantie réellement requis par votre secteur d’activité.

Ce tutoriel part du principe que vous disposez déjà d’un compte AWS actif et d’un contenu à distribuer, qu’il s’agisse d’un site statique, d’une API ou de fichiers média. Il couvre treize étapes concrètes, du bucket d’origine jusqu’à la supervision en temps réel, avec à chaque fois la commande exacte à exécuter plutôt qu’une description théorique.

Prérequis : comptes, versions et outils nécessaires

Avant de lancer la première commande, vérifiez que vous disposez de l’ensemble des éléments suivants. La configuration décrite ici fonctionne aussi bien en ligne de commande qu’avec un outil d’Infrastructure as Code, mais elle suppose un accès administrateur (ou un rôle IAM dédié) sur le compte AWS cible.

Outil ou compteVersion requiseRôle dans le tutoriel
Compte AWSActif, facturation configuréeCréer et gérer les ressources CloudFront, S3, WAF et ACM
AWS CLIv2 (dernière version stable)Piloter CloudFront, S3, WAF et ACM en ligne de commande
Python3.11 ou supérieurGénérer les URLs et cookies signés en SHA-256
Bibliothèque Python cryptographyDernière version stableSigner les URLs CloudFront avec une clé privée RSA
Terraform ou AWS CDKDernière version stable (facultatif)Automatiser le déploiement en Infrastructure as Code
Certificat TLS dans AWS Certificate ManagerRégion us-east-1 obligatoireAttacher un certificat personnalisé à la distribution

Deux points méritent une attention particulière. D’abord, AWS CLI version 1 est entrée en mode maintenance le 5 août 2026, avec une fin de support programmée au 15 juillet 2027 : toute nouvelle configuration doit démarrer directement sur la version 2. Ensuite, la documentation officielle d’AWS Certificate Manager précise que tout certificat destiné à CloudFront doit être demandé dans la région us-east-1 (Virginie du Nord), quelle que soit la région où vivent vos utilisateurs finaux. C’est une source d’erreur fréquente chez les équipes qui débutent sur CloudFront.

Vérifiez aussi vos versions installées avant de reproduire les commandes de ce tutoriel, puisque la compatibilité entre l’AWS CLI et certains paramètres récents de CloudFront (comme les champs liés à SHA-256) dépend d’une version suffisamment à jour.

aws --version
python3 --version
pip show cryptography | grep Version
terraform --version

Étapes 1 et 2 : préparer le bucket S3 et créer la distribution CloudFront

Commencez par créer un bucket S3 dédié à l’origine, dans la région où se trouve la majorité de vos utilisateurs. Bloquez immédiatement tout accès public : CloudFront, et lui seul, doit pouvoir lire ce contenu. Cette règle paraît évidente sur le papier, mais reste l’une des causes les plus citées d’exposition accidentelle de données sur AWS, bien au-delà du seul périmètre CloudFront.

aws s3 mb s3://mon-site-prod-eu --region eu-west-3

aws s3api put-public-access-block \
  --bucket mon-site-prod-eu \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Créez ensuite la distribution CloudFront elle-même. Un fichier de configuration JSON est plus lisible qu’une longue ligne de paramètres en ligne de commande, et il se versionne facilement dans votre dépôt Git.

aws cloudfront create-distribution \
  --distribution-config file://distribution-config.json

# Exemple de sortie (extrait) :
# {
#   "Distribution": {
#     "Id": "E1A2B3C4D5E6F7",
#     "Status": "InProgress",
#     "DomainName": "d111111abcdef8.cloudfront.net",
#     "DistributionConfig": { "Enabled": true, ... }
#   }
# }

La propagation d’une nouvelle distribution sur l’ensemble des points de présence CloudFront prend généralement entre 5 et 20 minutes. Tant que le champ Status affiche InProgress, évitez de modifier la configuration : les changements concurrents sont une cause classique d’erreurs de synchronisation. Si vous hébergez votre origine sur une instance EC2 plutôt que sur S3, la logique de sécurisation du serveur en amont reste comparable à celle décrite dans notre tutoriel sur la sécurisation d’un serveur AWS EC2.

Étape 3 : basculer de l’OAI vers Origin Access Control (OAC)

L’ancien mécanisme Origin Access Identity (OAI) a longtemps servi à restreindre l’accès à un bucket S3 au seul trafic CloudFront. Origin Access Control (OAC) l’a remplacé comme mécanisme recommandé pour toute nouvelle distribution : il repose sur des identifiants de courte durée, régulièrement renouvelés, là où OAI utilisait un principal statique plus simple à détourner. Pour une configuration qui démarre aujourd’hui, choisissez OAC sans hésiter. Si vous migrez depuis une ancienne distribution en OAI, planifiez le basculement en dehors des heures de forte charge.

aws cloudfront create-origin-access-control \
  --origin-access-control-config \
  Name="oac-mon-site-prod",SigningProtocol=sigv4,SigningBehavior=always,OriginAccessControlOriginType=s3

Une fois l’OAC créé, associez-le à l’origine de votre distribution, puis mettez à jour la politique du bucket S3 pour n’autoriser que le principal de service CloudFront, restreint à l’ARN exact de votre distribution. La documentation AWS sur la restriction d’accès à S3 détaille la syntaxe exacte de cette politique selon que votre bucket utilise ou non le chiffrement SSE-KMS.

Migrer une distribution existante sans coupure de service

Pour une distribution déjà en production sous OAI, la bascule vers OAC se fait en trois temps. Créez d’abord l’OAC sans encore y toucher, puis mettez à jour la politique du bucket pour accepter simultanément l’ancien principal OAI et le nouveau principal OAC pendant une courte fenêtre de transition. Basculez ensuite l’origine de la distribution vers l’OAC et observez les journaux d’accès pendant quelques heures. Une fois confirmé qu’aucune requête n’échoue, retirez la référence à l’OAI de la politique du bucket. Cette approche en trois temps évite la coupure sèche que beaucoup d’équipes redoutent lors de ce type de migration.

Étapes 4 et 5 : imposer HTTPS et choisir la bonne politique TLS

Par défaut, une distribution CloudFront accepte encore le trafic HTTP. Configurez le comportement de cache par défaut pour rediriger systématiquement HTTP vers HTTPS (ViewerProtocolPolicy: redirect-to-https), puis choisissez une politique de sécurité qui fixe la version TLS minimale acceptée côté client. Le tableau suivant liste les politiques actuellement proposées par CloudFront.

Politique de sécuritéTLS minimalStatut recommandé
TLSv1.3_2025TLS 1.3À privilégier pour une distribution neuve
TLSv1.2_2025TLS 1.2Bon compromis compatibilité / sécurité
TLSv1.2_2021TLS 1.2Acceptable, suites de chiffrement plus anciennes
TLSv1.2_2019 / TLSv1.2_2018TLS 1.2À migrer vers une politique plus récente
TLSv1.1_2016 / TLSv1_2016TLS 1.1 / 1.0Héritée, à éviter sur une nouvelle configuration
TLSv1TLS 1.0Héritée, réservée aux clients legacy documentés

Pour une distribution créée en 2026, il n’existe aucune raison technique de conserver une politique antérieure à TLSv1.2_2021, sauf contrainte documentée avec un client tiers qui ne supporte pas encore TLS 1.2 correctement négocié. La liste complète des politiques et des suites de chiffrement associées se trouve dans la documentation AWS CloudFront. Côté origine, appliquez la même rigueur : CloudFront accepte de parler en HTTP à votre serveur d’origine par défaut, ce qui expose le trafic interne si l’origine n’est pas dans le même VPC.

Ce choix de politique TLS a aussi un impact direct sur la facture, puisqu’il détermine indirectement le volume de négociations SSL que CloudFront doit traiter par seconde. Avant d’aller plus loin dans la configuration, il est utile de regarder où se situent les principaux postes de coût d’une distribution sécurisée, région par région.

Poste de coûtTarif (région Europe, Israël, Türkiye)Franchise gratuite
Transfert de données sortant0,085 $ / Go1 To / mois
Requêtes HTTP(S)0,0120 $ / 10 000 requêtes10 millions de requêtes / mois
CloudFront Functions0,10 $ / million d’invocationsAucune franchise dédiée
Chiffrement au niveau des champs0,02 $ / 10 000 requêtes chiffréesAucune franchise dédiée
Journaux temps réel0,01 $ / million de lignesJournaux standards gratuits
AWS WAF (hors plan à tarif fixe)Variable selon Web ACL, règles et requêtes inspectéesJusqu’à 10 % inclus dans certains plans CloudFront

Ces tarifs correspondent à la grille publique AWS pour la région Europe, Israël et Türkiye, et restent sujets à modification : vérifiez la page tarifaire officielle CloudFront avant toute estimation budgétaire définitive. Pour un site à fort trafic, le poste transfert de données reste presque toujours le plus significatif, largement devant les fonctionnalités de sécurité elles-mêmes.

Étape 6 : attacher AWS WAF et bloquer les attaques courantes

AWS WAF s’associe à une distribution CloudFront pour filtrer le trafic malveillant avant qu’il n’atteigne votre origine. Sans cette couche, chaque requête malveillante consomme à la fois de la bande passante CloudFront et des ressources de calcul côté origine, ce qui peut transformer une simple campagne de scan automatisé en incident de disponibilité. Créez un Web ACL avec les groupes de règles managés AWS (protection contre l’injection SQL, les attaques XSS, les mauvais robots connus), puis ajoutez une règle de limitation de débit pour contenir les tentatives de bourrage de requêtes, qu’il s’agisse d’une attaque par force brute sur un formulaire de connexion ou d’un robot d’extraction agressif.

aws wafv2 create-web-acl \
  --name "waf-mon-site-prod" \
  --scope CLOUDFRONT \
  --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName="wafMonSiteProd" \
  --rules file://waf-rules.json \
  --region us-east-1

Notez que le scope CLOUDFRONT impose de créer le Web ACL dans la région us-east-1, même si votre distribution sert majoritairement des utilisateurs européens : c’est une contrainte propre à l’architecture globale de CloudFront, pas une option. Une fois le Web ACL créé, associez-le à la distribution via le paramètre WebACLId de sa configuration, puis surveillez les métriques CloudWatch pendant les premiers jours pour ajuster les règles qui génèrent trop de faux positifs. La documentation AWS WAF détaille l’ensemble des groupes de règles managés disponibles.

Groupes de règles managés à activer en priorité

Toutes les règles managées AWS ne se valent pas au démarrage. Le groupe AWSManagedRulesCommonRuleSet couvre les attaques génériques (traversée de répertoire, injection de commande) et constitue une base raisonnable pour n’importe quel site. Le groupe AWSManagedRulesSQLiRuleSet cible spécifiquement l’injection SQL, pertinent dès qu’un formulaire interagit avec une base de données en amont. Le groupe AWSManagedRulesKnownBadInputsRuleSet bloque des motifs de requêtes déjà identifiés comme malveillants par AWS sur l’ensemble de sa clientèle. Déployez ces trois groupes en mode Count pendant 48 à 72 heures, analysez les faux positifs dans CloudWatch, puis basculez en Block une fois le comportement validé sur votre trafic réel.

Étape 7 : générer des URLs signées avec l’algorithme SHA-256

Les URLs signées protègent un fichier précis pendant une durée limitée : un PDF payant, une vidéo réservée aux abonnés, un export de données sensible. Depuis avril 2026, CloudFront accepte SHA-256 pour cette signature, en plus de l’ancien SHA-1 conservé pour compatibilité ascendante. Pour toute nouvelle intégration, utilisez SHA-256 sans exception.

import datetime
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import padding
import base64
import json

def generer_url_signee(url, cle_privee_path, key_pair_id, duree_minutes=15):
    expiration = int((datetime.datetime.utcnow() +
                       datetime.timedelta(minutes=duree_minutes)).timestamp())
    policy = json.dumps({
        "Statement": [{
            "Resource": url,
            "Condition": {"DateLessThan": {"AWS:EpochTime": expiration}}
        }]
    }).encode("utf-8")

    with open(cle_privee_path, "rb") as f:
        cle_privee = serialization.load_pem_private_key(f.read(), password=None)

    signature = cle_privee.sign(policy, padding.PKCS1v15(), hashes.SHA256())
    signature_b64 = base64.b64encode(signature).decode("utf-8")

    return (f"{url}?Expires={expiration}"
            f"&Signature={signature_b64}&Key-Pair-Id={key_pair_id}")

Ce script suppose qu’une paire de clés RSA a déjà été générée et que la clé publique a été chargée dans un groupe de clés (key group) CloudFront, référencé par votre comportement de cache en tant que trusted key group. Si ce n’est pas encore fait, générez la paire de clés localement et enregistrez la clé publique avant de référencer le groupe dans votre distribution.

openssl genrsa -out cle-privee.pem 2048
openssl rsa -pubout -in cle-privee.pem -out cle-publique.pem

aws cloudfront create-public-key \
  --public-key-config Name="cle-signature-prod",CallerReference="2026-10-08",EncodedKey="$(cat cle-publique.pem)"

aws cloudfront create-key-group \
  --key-group-config Name="groupe-cles-prod",Items="K2XXXXXXXXXXX"

La durée de validité de l’URL (ici 15 minutes) doit rester courte : une URL signée interceptée reste utilisable jusqu’à son expiration, quelle que soit la robustesse de l’algorithme de signature. Conservez la clé privée exclusivement dans un gestionnaire de secrets comme AWS Secrets Manager ou AWS Systems Manager Parameter Store, jamais dans votre dépôt de code.

Étape 8 : déployer des cookies signés pour un accès multi-ressources

Contrairement à l’URL signée, qui n’autorise qu’une ressource précise, le cookie signé couvre un ensemble de fichiers partageant un chemin commun. C’est le mécanisme adapté à un espace membre qui donne accès à des dizaines de documents sans générer une URL distincte pour chacun. Le principe de signature est identique à celui des URLs : même policy JSON, même algorithme SHA-256, mais le résultat est déposé dans trois cookies (CloudFront-Policy, CloudFront-Signature, CloudFront-Key-Pair-Id) plutôt que dans la chaîne de requête.

En pratique, choisissez l’URL signée pour un téléchargement ponctuel partagé par email ou intégré dans une application mobile, et le cookie signé pour une session web authentifiée qui navigue entre plusieurs pages protégées. Mélanger les deux approches sur une même distribution est possible, mais complique le débogage : documentez clairement, comportement de cache par comportement de cache, lequel des deux mécanismes s’applique.

Un point souvent oublié concerne la propagation du cookie sur plusieurs sous-domaines. Si votre application sert du contenu protégé depuis media.exemple.fr et app.exemple.fr, le cookie signé doit être posé avec un attribut de domaine suffisamment large (.exemple.fr) pour voyager entre les deux, sans pour autant devenir si permissif qu’il expose le cookie à des sous-domaines non maîtrisés. Testez systématiquement ce comportement avec les outils de développement du navigateur avant de considérer la fonctionnalité comme opérationnelle, car une erreur de portée de cookie ne génère pas toujours un message d’erreur explicite côté utilisateur.

Étapes 9 et 10 : renforcer les en-têtes de sécurité et chiffrer les champs sensibles

Une Response Headers Policy permet d’injecter des en-têtes de sécurité à chaque réponse servie par CloudFront, sans toucher au code de votre application d’origine. Les en-têtes à évaluer en priorité restent Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy et, selon le contexte applicatif, Content-Security-Policy et Permissions-Policy.

aws cloudfront create-response-headers-policy \
  --response-headers-policy-config file://headers-policy.json

# headers-policy.json (extrait) :
# {
#   "Name": "headers-securite-prod",
#   "SecurityHeadersConfig": {
#     "StrictTransportSecurity": {
#       "Override": true, "IncludeSubdomains": true,
#       "Preload": true, "AccessControlMaxAgeSec": 63072000
#     },
#     "ContentTypeOptions": { "Override": true },
#     "ReferrerPolicy": {
#       "Override": true, "ReferrerPolicy": "strict-origin-when-cross-origin"
#     }
#   }
# }

Pour les champs réellement sensibles transmis via un formulaire (numéro de carte, identifiant national), le chiffrement au niveau des champs ajoute une couche supplémentaire : CloudFront chiffre le champ désigné avec une clé publique dès la réception, avant même que la requête n’atteigne votre origine, pour un coût facturé par requête chiffrée en plus du HTTPS standard. Cette fonctionnalité reste pertinente lorsque plusieurs systèmes internes traitent la requête et que seul le dernier d’entre eux doit voir la donnée en clair.

Concrètement, cela signifie que même un administrateur système ayant accès aux journaux applicatifs intermédiaires ne verra jamais la valeur en clair du champ protégé, seule l’application finale détentrice de la clé privée correspondante peut le déchiffrer. Cette approche s’avère particulièrement utile dans une architecture où un prestataire de paiement tiers ou un service de traitement de documents intervient entre CloudFront et votre backend principal, puisqu’elle réduit la surface de confiance accordée à chaque intermédiaire.

Étape 11 : restreindre l’accès géographique pour la conformité RGPD

La restriction géographique de CloudFront bloque ou autorise les visiteurs selon le pays estimé par géolocalisation IP, en liste blanche ou en liste noire. C’est un outil utile pour limiter la surface d’attaque ou respecter une obligation contractuelle de diffusion régionale, mais il faut rester précis sur sa portée légale : une restriction géographique ne constitue pas, à elle seule, une conformité RGPD. Elle ne remplace ni la base légale du traitement, ni la minimisation des données, ni l’encadrement des transferts hors Union européenne tel que le décrit le règlement européen sur la protection des données présenté par la CNIL.

Concrètement, utilisez le géo-blocage CloudFront comme une mesure de défense en profondeur, en complément d’une politique de confidentialité à jour et d’une cartographie claire des flux de données entre vos origines et vos prestataires. Configurez-le depuis la section Restrictions de votre distribution, en choisissant soit une liste blanche de pays autorisés, soit une liste noire de pays bloqués, jamais les deux simultanément sur un même comportement de cache. Si votre architecture distribue aussi du contenu depuis une origine hors AWS, pensez à documenter ce flux séparément : la restriction géographique CloudFront ne couvre que le trafic qui transite par le CDN lui-même, pas les appels directs qui contourneraient éventuellement cette couche.

Étapes 12 et 13 : automatiser avec l’Infrastructure as Code et activer les journaux temps réel

Une fois la configuration validée manuellement, reproduisez-la en Terraform pour éviter toute dérive entre vos environnements de test et de production. L’extrait suivant pose le socle d’une distribution avec OAC et politique TLS modernisée.

resource "aws_cloudfront_distribution" "site_prod" {
  enabled             = true
  default_root_object = "index.html"

  origin {
    domain_name              = aws_s3_bucket.origine.bucket_regional_domain_name
    origin_id                = "origine-s3"
    origin_access_control_id = aws_cloudfront_origin_access_control.oac.id
  }

  default_cache_behavior {
    target_origin_id       = "origine-s3"
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods         = ["GET", "HEAD"]
    cached_methods          = ["GET", "HEAD"]
    response_headers_policy_id = aws_cloudfront_response_headers_policy.headers.id
  }

  viewer_certificate {
    acm_certificate_arn      = aws_acm_certificate.cert.arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2021"
  }

  web_acl_id = aws_wafv2_web_acl.waf.arn
}

Pour la dernière étape, activez les journaux temps réel afin de détecter une anomalie en quelques secondes plutôt qu’en consultant des fichiers de logs standards différés de plusieurs heures. Ces journaux sont facturés par million de lignes publiées vers la destination choisie (Kinesis Data Streams dans la configuration la plus courante).

aws cloudfront create-realtime-log-config \
  --name "logs-temps-reel-prod" \
  --end-points StreamType=Kinesis,KinesisStreamConfig="{RoleArn=arn:aws:iam::123456789012:role/CloudFrontRealtimeLogRole,StreamArn=arn:aws:kinesis:us-east-1:123456789012:stream/logs-cloudfront}" \
  --fields "timestamp" "c-ip" "sc-status" "cs-uri-stem" "x-edge-result-type" \
  --sampling-rate 100

Pièges fréquents à éviter avec CloudFront

La plupart des incidents CloudFront observés en production viennent de configurations oubliées plutôt que d’une vulnérabilité du service lui-même. Un audit de sécurité mené plusieurs mois après la mise en ligne révèle presque systématiquement au moins deux ou trois des points suivants, accumulés au fil des itérations rapides en début de projet.

  • Bucket S3 laissé accessible en public en parallèle de l’OAC, parce que l’ancienne politique n’a jamais été nettoyée après la migration.
  • Certificat ACM demandé dans la mauvaise région : seul us-east-1 fonctionne avec CloudFront, une erreur qui bloque l’attachement du certificat jusqu’à ce qu’elle soit corrigée.
  • Cache agressif sur du contenu dynamique, qui expose une page personnalisée (panier, compte utilisateur) à un autre visiteur à cause d’une clé de cache mal définie.
  • Oubli de restreindre l’origine HTTP entre CloudFront et le serveur d’origine, qui laisse transiter du trafic non chiffré sur ce segment.
  • Règles WAF trop permissives dès le lancement, en mode Count plutôt que Block, jamais réellement activées une fois la mise en production effectuée.
  • Clé privée de signature stockée dans le dépôt de code plutôt que dans un gestionnaire de secrets, ce qui annule tout l’intérêt des URLs signées en cas de fuite du dépôt.
  • Durée de validité des URLs signées trop longue, fixée à plusieurs heures ou jours par confort de développement, et jamais raccourcie avant la mise en production.
  • Absence totale de politique TLS côté origine, qui laisse le serveur d’origine négocier n’importe quelle version de TLS avec CloudFront, y compris des versions obsolètes si l’origine les accepte encore.

Dépannage : 8 problèmes courants et leurs solutions

Voici les symptômes les plus fréquemment rencontrés lors de la sécurisation d’une distribution CloudFront, avec la cause probable et la correction à appliquer. Dans la majorité des cas, le diagnostic commence par les journaux d’accès standards de CloudFront et par la console AWS WAF, avant d’aller chercher plus loin côté origine.

  • Erreur 403 Access Denied sur tout le site : la politique du bucket S3 ne référence pas encore le bon ARN de distribution après la migration vers OAC. Vérifiez la condition AWS:SourceArn de la politique.
  • Le certificat ACM n’apparaît pas dans la liste CloudFront : il a été demandé dans une région autre que us-east-1. Recommencez la demande depuis cette région précise.
  • Les en-têtes de sécurité ne s’appliquent pas : la Response Headers Policy est créée mais n’a pas été associée au bon comportement de cache de la distribution.
  • Les URLs signées renvoient systématiquement une erreur 403 : l’horloge du serveur qui génère la signature est désynchronisée, ou le key group référencé ne contient pas la clé publique correspondante.
  • Le WAF bloque du trafic légitime : une règle managée trop stricte déclenche sur un paramètre d’URL courant. Passez temporairement la règle en mode Count pour analyser les faux positifs avant de la réactiver en Block.
  • Les modifications de distribution n’apparaissent pas immédiatement : la propagation mondiale prend plusieurs minutes. Attendez que Status repasse à Deployed avant de conclure à un échec.
  • Le géo-blocage ne filtre pas certains visiteurs attendus : la géolocalisation IP comporte une marge d’erreur, en particulier pour les utilisateurs derrière un VPN d’entreprise ou un proxy mobile.
  • Les journaux temps réel n’arrivent pas dans Kinesis : le rôle IAM associé ne dispose pas des permissions d’écriture sur le flux cible, une cause fréquente après une rotation de rôle.

Si un problème persiste après avoir vérifié ces huit points, activez temporairement les journaux d’accès standards sur un bucket S3 dédié, puis comparez un cas qui fonctionne et un cas qui échoue champ par champ. Dans l’immense majorité des incidents CloudFront observés sur le terrain, la cause se trouve dans une politique IAM, une politique de bucket ou une règle WAF, rarement dans le service CloudFront lui-même.

Astuces avancées et récapitulatif du projet complet

Une fois les treize étapes posées, quelques ajustements supplémentaires font la différence en production. D’abord, choisissez CloudFront Functions plutôt que Lambda@Edge pour une logique simple exécutée à chaque requête (réécriture d’URL, ajout d’un en-tête, redirection basée sur un cookie) : la facturation démarre à 0,10 $ par million d’invocations, avec un temps d’exécution plus court mais largement suffisant pour ces cas d’usage. Réservez Lambda@Edge aux traitements qui nécessitent un accès réseau sortant ou une logique plus lourde. Voici un exemple minimal qui bloque toute requête dépourvue d’un en-tête d’authentification attendu, directement en edge, avant même d’atteindre votre origine.

function handler(event) {
    var request = event.request;
    var headers = request.headers;

    if (!headers['x-api-key'] || headers['x-api-key'].value !== 'valeur-attendue') {
        return {
            statusCode: 403,
            statusDescription: 'Forbidden',
            body: { encoding: 'text', data: 'Accès refusé' }
        };
    }
    return request;
}

Ensuite, pensez à la gestion fine du cache. Séparez systématiquement une Cache Policy (ce que CloudFront met en cache et pendant combien de temps) d’une Origin Request Policy (ce que CloudFront transmet à l’origine). Cette séparation, introduite pour remplacer les anciens objets de configuration de cache monolithiques, évite qu’un en-tête d’authentification se retrouve accidentellement inclus dans la clé de cache et ne provoque une explosion du taux de cache miss.

Checklist finale avant mise en production

  • OAC actif sur l’origine, bucket S3 sans aucun accès public résiduel.
  • Politique TLS fixée à TLSv1.2_2021 minimum, redirection HTTPS forcée.
  • Web ACL AWS WAF associé, règles managées en mode Block validées.
  • URLs ou cookies signés en SHA-256 pour tout contenu privé.
  • Response Headers Policy appliquée sur chaque comportement de cache public.
  • Géo-restriction documentée et articulée avec la politique de confidentialité.
  • Configuration répliquée en Terraform ou CDK, versionnée dans Git.
  • Journaux temps réel actifs, avec une alerte CloudWatch sur le taux d’erreurs 5xx.

Pensez enfin à l’origine secondaire : un groupe d’origines CloudFront avec basculement automatique protège contre l’indisponibilité ponctuelle d’un bucket ou d’un serveur, sans intervention manuelle. Configurez ce groupe avec un critère de basculement basé sur les codes de statut HTTP (typiquement 500, 502, 503 et 504), pour que CloudFront redirige automatiquement le trafic vers l’origine de secours sans attendre une intervention humaine au milieu de la nuit. Si une partie de votre trafic passe aussi par un autre CDN pour des raisons de résilience ou de coût, la logique de configuration Zero Trust décrite dans notre tutoriel Cloudflare Tunnel s’applique avec les mêmes principes de moindre privilège. Pour le cycle de vie des certificats eux-mêmes, notre article sur le raccourcissement de la durée de vie des certificats SSL/TLS détaille pourquoi l’automatisation du renouvellement devient incontournable d’ici 2029, un enjeu qui touche directement les certificats ACM attachés à vos distributions CloudFront.

Pour aller plus loin que ce tutoriel, la section dédiée au cloud computing de ce site couvre d’autres briques AWS fréquemment associées à CloudFront, de la sécurisation d’un bucket S3 à la mise en place d’un pipeline de déploiement complet.

Questions fréquentes sur la sécurisation d’Amazon CloudFront

OAC remplace-t-il complètement OAI en 2026 ?
OAC est le mécanisme recommandé par AWS pour toute nouvelle distribution qui protège une origine S3. OAI reste techniquement disponible sur les anciennes configurations, mais aucune raison ne justifie de le choisir pour un nouveau projet.

Combien coûte une distribution CloudFront sécurisée pour un trafic européen moyen ?
Le transfert sortant facturé en Europe démarre à 0,085 $ par Go après le premier téraoctet gratuit chaque mois, et les requêtes HTTP(S) à 0,0090 $ par tranche de 10 000 après les 10 premiers millions gratuits. AWS WAF, les CloudFront Functions et les journaux temps réel s’ajoutent séparément selon l’usage réel.

Faut-il systématiquement activer AWS WAF sur une distribution CloudFront ?
Pour un site qui expose un formulaire, une API ou tout point d’entrée utilisateur, oui. Pour un contenu strictement statique et public sans aucune interaction, l’intérêt immédiat est plus limité, même si WAF reste une protection peu coûteuse en complément d’autres contrôles.

Le géo-blocage CloudFront suffit-il pour être conforme au RGPD ?
Non. Il bloque ou autorise du trafic selon le pays détecté, mais il ne remplace ni la base légale du traitement, ni la minimisation des données, ni l’encadrement contractuel des transferts hors Union européenne.

Quelle différence entre une URL signée et un cookie signé ?
L’URL signée autorise une ressource précise pendant une durée limitée, pratique pour un lien partagé ponctuellement. Le cookie signé autorise plusieurs ressources partageant un chemin commun, adapté à une session authentifiée qui navigue entre plusieurs pages protégées.

CloudFront ou Cloudflare : lequel choisir pour un projet basé en France ?
Le choix dépend surtout de votre infrastructure existante. Une équipe déjà sur AWS gagne en simplicité opérationnelle avec CloudFront, grâce à son intégration native à S3, Lambda et IAM, sans avoir à gérer un compte et une facturation supplémentaires chez un autre fournisseur. Une équipe multi-cloud ou qui veut un contrôle plus fin indépendant du fournisseur d’hébergement trouvera souvent plus de flexibilité chez Cloudflare, notamment sur la configuration des règles de pare-feu applicatif en self-service. Les estimations de part de marché divergent trop selon la source pour trancher sur ce seul critère : mieux vaut comparer les deux options sur votre propre cas d’usage, votre budget et vos contraintes de conformité avant de vous engager.

SHA-1 reste-t-il utilisable pour les URLs signées existantes ?
AWS conserve SHA-1 pour la compatibilité ascendante des intégrations existantes, mais toute nouvelle implémentation doit utiliser SHA-256, disponible depuis avril 2026.

Peut-on utiliser CloudFront sans certificat personnalisé dans AWS Certificate Manager ?
Oui, pour un domaine de test : CloudFront fournit un certificat par défaut sur son propre domaine *.cloudfront.net. Dès qu’un nom de domaine personnalisé entre en jeu, un certificat ACM demandé dans la région us-east-1 devient obligatoire, que votre audience soit en France, en Allemagne ou ailleurs en Europe.