Amazon SAA-C03: Distribution de contenu, Edge et optimisation des performances — Guide d'étude

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fait partie du AWS SAA-C03 — Guide d’étude complet. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Amazon CloudFront : Qu’est-ce que c’est et pourquoi c’est utile

Amazon CloudFront est un réseau de diffusion de contenu (CDN) distribué à l’échelle mondiale, s’appuyant sur plus de 600 points de présence. Son rôle est de terminer la connexion TLS du visiteur au point de présence le plus proche et de servir immédiatement des réponses mises en cache, ou de transférer les requêtes en échec de cache (cache misses) via le réseau backbone privé d’AWS jusqu’à l’origine. Le gain de performance est double : les succès de cache (cache hits) réduisent le temps d’aller-retour à quelques millisecondes et déchargent complètement l’origine, tandis que les échecs de cache bénéficient tout de même d’une terminaison TLS/TCP optimisée en périphérie, du support HTTP/2 et HTTP/3, de la réutilisation des connexions persistantes (keep-alive) vers l’origine, et d’un transit sur le réseau backbone qui évite l’Internet public, plus sujet aux perturbations.

Une idée fausse courante est que CloudFront n’accélère que les ressources statiques. Placer un ALB derrière CloudFront avec une politique CachingDisabled améliore tout de même les performances des API dynamiques, car la poignée de main (handshake) du visiteur s’effectue au PoP local plutôt que de traverser l’Internet jusqu’à la région d’origine. Combinez cela avec une charge de travail mixte — par exemple, /static/* servi depuis S3 et /api/* servi depuis un ALB — et une seule distribution peut gérer les deux :

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

Les enregistrements d’alias Route 53 font ensuite pointer www.example.com vers le d123.cloudfront.net de la distribution — les enregistrements d’alias sont gratuits et se résolvent directement vers les adresses IP anycast de CloudFront.

Les certificats doivent être dans us-east-1

Pour toute distribution CloudFront servie sur un domaine personnalisé, le certificat TLS côté visiteur dans AWS Certificate Manager doit être émis dans la région us-east-1 (N. Virginia), peu importe où se trouvent le bucket d’origine, l’ALB ou les utilisateurs. CloudFront est un service mondial dont le plan de contrôle est ancré dans us-east-1 ; les points de présence périphériques récupèrent le certificat depuis cette région. Demander un certificat ACM dans eu-west-1 parce que votre bucket S3 s’y trouve est une mauvaise pratique — la distribution ne le verra jamais.

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

Si vous terminez le TLS une seconde fois entre CloudFront et une origine ALB, ce certificat côté origine réside dans la région de l’ALB. Seul le certificat côté visiteur est verrouillé sur us-east-1. La même règle s’applique aux domaines personnalisés optimisés en périphérie (edge-optimized) d’API Gateway (qui utilisent en interne une distribution CloudFront gérée par AWS) : le certificat doit être dans us-east-1. Les points de terminaison régionaux d’API Gateway, en revanche, prennent un certificat de la région de l’API elle-même.

Origin Access Control pour les origines S3

Placer un bucket S3 derrière CloudFront tout en le laissant public va à l’encontre de l’objectif : les visiteurs contournent CloudFront en accédant directement au point de terminaison REST de S3, échappant ainsi à WAF, aux géo-restrictions, aux URL signées et aux avantages du cache — et exposant potentiellement des données.

La solution moderne est l’Origin Access Control (OAC), qui remplace l’ancienne Origin Access Identity (OAI). OAC utilise la signature SigV4, prend en charge SSE-KMS, fonctionne dans toutes les régions S3 (y compris celles lancées après 2022) et prend en charge les requêtes dynamiques. Le blocage de l’accès public (Block Public Access) reste activé, aucune ACL n’est nécessaire, et la politique de bucket n’accorde l’accès en lecture qu’au principal de service CloudFront, restreint par l’ARN de la distribution spécifique :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

OAI fonctionne toujours mais doit être considéré comme obsolète — choisissez toujours OAC pour les nouveaux projets.

Exactitude de la mise en cache

L’efficacité du cache dépend des en-têtes Cache-Control et Expires que l’origine renvoie, combinés avec les TTL minimum/par défaut/maximum de la politique de cache de CloudFront. Les ressources immuables avec empreinte (fingerprinted) devraient être mises en cache de manière agressive ; les squelettes HTML qui y font référence devraient avoir une durée de vie courte pour que les déploiements se propagent ; le JSON authentifié ne devrait pas du tout être mis en cache sur le CDN partagé :

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

Deux pièges symétriques sont courants. Premièrement, si l’origine n’émet aucun en-tête de cache, CloudFront se rabat sur le TTL par défaut de la distribution et peut mettre en cache silencieusement des réponses dynamiques pendant des heures. Deuxièmement, un Cache-Control: no-cache généralisé sur des ressources qui devraient être mises en cache force chaque requête à retourner à l’origine et neutralise l’intérêt du CDN.

Le piège le plus dangereux est de mettre en cache des réponses personnalisées sans les en-têtes appropriés. Si /account/dashboard renvoie du HTML spécifique à l’utilisateur A mais que l’origine omet no-store et que la politique de cache n’inclut pas d’en-tête d’authentification ou de cookie dans la clé de cache, le point de présence servira volontiers la page de l’utilisateur A à l’utilisateur B. Soit vous marquez ces réponses avec private, no-store, soit vous incluez l’identifiant de session dans la clé de cache et acceptez un taux de succès (hit ratio) plus faible.

Dans un scénario d’optimisation des coûts où un groupe Auto Scaling d’instances EC2 à la demande sert du contenu statique, la refonte correcte consiste à déplacer les ressources vers S3, à placer CloudFront devant avec OAC, et à supprimer ou réduire l’ASG. Cela déplace le coût d’un calcul par heure vers une livraison par requête, ce qui est plusieurs ordres de grandeur moins cher pour les charges de travail statiques.

URL signées, cookies signés et géo-restriction

CloudFront prend en charge les URL signées (accès à un objet unique, limité dans le temps et éventuellement restreint par IP — un téléchargement de vidéo achetée, un lien PDF à usage unique) et les cookies signés (accès à de nombreux objets correspondant à un modèle de chemin — un abonné authentifié parcourant un catalogue). Les deux utilisent un groupe de clés de confiance (trusted key group) dont la clé publique est téléversée sur CloudFront ; la clé privée signe une politique spécifiant l’expiration, la plage d’adresses IP source ou le modèle d’URL.

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

Ceci est distinct d’une URL présignée S3, qui contourne CloudFront et accorde un accès direct au bucket. Associez les URL signées CloudFront à OAC et le bucket reste privé de bout en bout.

La géo-restriction applique des listes d’autorisation (allow-lists) ou de blocage (block-lists) au niveau des pays, au niveau de la distribution, avant que les requêtes n’atteignent le cache ou l’origine. Elle utilise la base de données GeoIP maintenue par CloudFront et constitue un mécanisme peu coûteux et à l’épreuve des contournements de cache pour appliquer des embargos de licence. Pour une logique plus fine (au niveau des états/régions, combinaisons d’en-têtes), utilisez une CloudFront Function ou Lambda@Edge ; pour un moteur de règles complet, utilisez WAF.

AWS Global Accelerator

Global Accelerator n’est pas un CDN et ne met pas en cache. Il fournit deux adresses IPv4 anycast statiques (ou BYOIP) annoncées depuis les emplacements périphériques (edge locations) d’AWS dans le monde entier. Les connexions TCP ou UDP des clients entrent dans le réseau backbone d’AWS au niveau de l’emplacement périphérique le plus proche et sont acheminées sur le réseau privé d’AWS vers le point de terminaison (endpoint) le plus sain (ALB, NLB, EC2 ou Elastic IP) dans une ou plusieurs régions, regroupés en groupes de points de terminaison (endpoint groups) avec des sélecteurs de trafic (traffic dials) et des pondérations (weights).

Les adresses IP statiques offrent trois avantages concrets : les listes d’autorisation (allowlists) des clients et des pare-feu ne changent jamais, même si le backend est réarchitecturé ; le basculement régional s’effectue en quelques secondes en déplaçant le trafic entre les groupes de points de terminaison lors des changements de bilan de santé (health-check), contournant entièrement la propagation des TTL DNS ; et la poignée de main TCP (handshake) se termine à la périphérie, le long trajet s’effectuant sur le réseau backbone d’AWS.

Choisissez Global Accelerator lorsque :

• Le protocole n’est pas HTTP : UDP pour les jeux ou la VoIP, MQTT, SIP, SFTP, TCP personnalisé.
• Vous avez besoin d’adresses IP statiques pour les listes d’autorisation d’entreprise ou les applications mobiles qui codent en dur les adresses.
• Vous avez besoin d’un basculement régional en moins d’une minute pour des déploiements actifs-actifs avec état (stateful).
• La charge de travail est dynamique et non cachable, donc un CDN offre peu de valeur.

Choisissez CloudFront lorsque :

• Le contenu est cachable (images, segments vidéo, HTML statique, réponses d’API avec des TTL).
• Vous souhaitez du calcul en périphérie (edge compute) via Lambda@Edge ou CloudFront Functions.
• Vous avez besoin de WAF, d’URL/cookies signés ou du chiffrement au niveau des champs (field-level encryption) à la périphérie.

Deux pièges à éviter. Choisir CloudFront pour « rendre nos serveurs de jeu plus rapides dans le monde » est une erreur car les jeux utilisent UDP et ne sont pas cachables — Global Accelerator est requis. Inversement, choisir Global Accelerator pour un site web statique est coûteux (frais horaires fixes plus frais par Go) et vous prive de la mise en cache — CloudFront réduirait considérablement les coûts de sortie de l’origine. Pour une API HTTP distribuée mondialement mais dans une seule région où les utilisateurs tolèrent la latence, un simple routage basé sur la latence de Route 53 peut être suffisant et moins cher que les deux autres options.

Stratégies de routage Route 53 pour le trafic mondial

Route 53 choisit le point de terminaison qu’un client résout ; CloudFront ou Global Accelerator gèrent ensuite la connexion. Trois stratégies dominent les architectures mondiales.

Le routage basé sur la latence mesure la latence réseau réelle entre l’emplacement du résolveur et chaque région, puis renvoie la plus rapide. Utilisez-le pour des piles identiques dans plusieurs régions lorsque vous souhaitez que les utilisateurs soient dirigés vers la région la plus rapide à un instant T.

Le routage par géoproximité est basé sur les coordonnées plutôt que sur la latence : vous déclarez l’emplacement (ou la région AWS) de chaque point de terminaison, et Route 53 envoie les utilisateurs vers le plus proche géographiquement. Sa caractéristique distinctive est une valeur de biais (de -99 à +99) qui étend ou réduit la zone de service effective — utile pour déplacer progressivement le trafic lors du lancement d’une région ou pour vider une région pour maintenance. La géoproximité nécessite Route 53 traffic flow (stratégies de trafic) et est généralement associée à un NLB ou un ALB régional dans chaque région.

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

Le routage par basculement (failover) utilise une paire primaire/secondaire liée à des bilans de santé (health checks). Il s’agit d’un basculement au niveau du DNS, soumis au TTL et à la mise en cache du résolveur, il est donc plus lent que le basculement au niveau du plan de données (data-plane) de Global Accelerator — choisissez le routage par basculement pour un simple déploiement actif-passif où une minute de propagation DNS est tolérable, et Global Accelerator lorsque vous avez besoin de quelques secondes.

Ces stratégies peuvent être combinées. Un modèle global courant : des enregistrements de latence ou de géoproximité Route 53 pointent vers Global Accelerator (pour TCP/UDP) ou CloudFront (pour HTTPS cachable), avec des enregistrements de basculement (failover) basés sur des bilans de santé en dessous comme filet de sécurité. La superposition est délibérée : Route 53 choisit la région, Global Accelerator ou CloudFront choisit l’emplacement périphérique et le chemin à travers le réseau backbone, et un équilibreur de charge régional choisit la cible à l’intérieur de la région.

Types de points de terminaison API Gateway et domaines personnalisés

API Gateway propose trois types de points de terminaison avec des topologies distinctes :

Les points de terminaison optimisés pour la périphérie enveloppent l’API dans une distribution CloudFront gérée par AWS que vous ne pouvez pas configurer directement. C’est pratique pour une portée mondiale rapide, mais limitant lorsque vous souhaitez vos propres comportements de cache, règles WAF ou stratégies de requête d’origine. Le modèle idiomatique pour un contrôle maximal est un point de terminaison régional précédé d’une distribution CloudFront gérée par le client.

Le placement des certificats suit la règle de CloudFront : les domaines personnalisés optimisés pour la périphérie nécessitent un certificat ACM dans la région us-east-1 ; les points de terminaison régionaux nécessitent le certificat dans la même région que l’API. Les API HTTP appliquent un minimum de TLS 1.2 ; les API REST prennent en charge des stratégies de sécurité jusqu’à TLS 1.3.

Certificats ACM : Émis, validés, importés

ACM émet et renouvelle automatiquement les certificats TLS publics sans frais et s’intègre directement avec CloudFront, API Gateway, ALB, NLB et d’autres services AWS. La validation se fait soit par validation DNS (ACM vous donne un CNAME à placer dans Route 53 ou tout autre fournisseur DNS ; tant que l’enregistrement persiste, ACM renouvelle automatiquement le certificat indéfiniment) soit par validation par e-mail (un clic manuel est requis à chaque renouvellement, ce qui est fragile pour l’automatisation). La validation DNS est le choix par défaut correct pour tout environnement de production.

Les certificats émis par ACM ne peuvent pas être exportés et ne peuvent pas être utilisés en dehors des services AWS intégrés. Lorsqu’une exigence réglementaire ou commerciale impose une autorité de certification (CA) tierce spécifique — par exemple, une API REST qui doit chaîner vers un émetteur commercial particulier et appliquer TLS 1.3 — vous ne pouvez pas utiliser un certificat émis par ACM. Obtenez le certificat auprès de la CA requise et importez-le dans ACM, puis attachez-le à un domaine personnalisé d’API Gateway régional avec une politique de sécurité TLS 1.3.

Le piège avec les importations est double : les certificats importés ne se renouvellent pas automatiquement (il faut les réimporter avant leur expiration, sinon le point de terminaison subira une défaillance majeure), et ACM ne valide pas la chaîne lors de l’importation — un certificat intermédiaire défectueux n’apparaîtra qu’au moment du handshake avec de vrais clients. Testez la chaîne complète avec un client strict avant le déploiement.

S3 Transfer Acceleration vs. CloudFront

CloudFront optimise les téléchargements (downloads) ; S3 Transfer Acceleration optimise les téléversements (uploads). Transfer Acceleration utilise le même réseau de points de présence (edge) de CloudFront en sens inverse : les requêtes PUT entrent par le point de présence le plus proche et empruntent le réseau principal (backbone) d’AWS jusqu’à la Région du bucket de destination. Cette fonctionnalité est particulièrement efficace lorsqu’un ensemble d’utilisateurs dispersés dans le monde téléverse des objets volumineux vers un bucket dans une seule Région — par exemple, des ingénieurs de terrain du monde entier qui téléversent des dessins de plusieurs gigaoctets vers us-east-1.

Les deux fonctionnalités peuvent coexister sur le même bucket : activez Transfer Acceleration et exposez une distribution CloudFront avec OAC pour les téléchargements. Pour les petits objets ou pour les clients déjà proches de la Région du bucket, Transfer Acceleration ajoute des coûts sans avantage — utilisez l’outil de comparaison de vitesse S3 Transfer Acceleration pour mesurer les performances avant de vous engager. Les clients doivent utiliser le point de terminaison s3-accelerate pour que l’accélération s’active.

AWS WAF pour la protection de la couche 7

AWS WAF inspecte les requêtes HTTP(S) avant qu’elles n’atteignent la ressource protégée. Il s’attache aux distributions CloudFront, aux ALB, aux stages d’API Gateway, aux API AppSync, aux pools d’utilisateurs Cognito, aux services App Runner et aux instances Verified Access. Une web ACL contient des règles qui effectuent des correspondances sur l’URI, les en-têtes, les chaînes de requête, le corps de la requête (jusqu’à 8 Ko par défaut, extensible à 64 Ko sur ALB/API Gateway), les ensembles d’adresses IP (IP sets) et la géolocalisation.

Les briques de base les plus courantes sont les Règles gérées par AWS (AWS Managed Rules) : AWSManagedRulesCommonRuleSet et AWSManagedRulesKnownBadInputsRuleSet couvrent les principaux exploits du top OWASP ; AWSManagedRulesSQLiRuleSet et les déclarations de correspondance XSS gèrent les injections. Les règles personnalisées ajoutent la correspondance géographique (listes d’autorisation/de blocage de pays pour la conformité), les correspondances d’ensembles d’IP et les règles basées sur le débit (rate-based rules) — qui comptent les requêtes par adresse IP source sur une fenêtre glissante de cinq minutes et bloquent une fois qu’un seuil est dépassé. Les règles basées sur le débit sont la première ligne de défense contre les inondations HTTP (HTTP floods) et le bourrage d’identifiants (credential stuffing) :

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

Les règles de Région sont importantes. Les web ACL pour CloudFront sont globales et doivent être créées dans la région us-east-1. Les web ACL pour les ressources régionales (ALB, API Gateway, etc.) sont créées dans la propre Région de la ressource.

Pour protéger un site statique sur S3, vous ne pouvez pas attacher WAF au bucket — S3 n’est pas une ressource prise en charge par WAF. Le modèle correct est CloudFront + OAC devant le bucket, avec la web ACL attachée à la distribution. Le fait que le bucket ne soit accessible que via CloudFront est ce qui rend l’affirmation « inspecter tout le trafic » vraie.

Firewall Manager pour la gouvernance WAF multi-comptes

La gestion de WAF compte par compte n’est pas une solution scalable. Au sein d’une Organisation, une équipe peut déployer un nouvel ALB sans y attacher les règles de base de l’entreprise, et la posture de conformité régresse silencieusement. AWS Firewall Manager résout ce problème avec des politiques à l’échelle de l’organisation appliquées aux comptes et ressources concernés.

Prérequis : AWS Organizations avec toutes les fonctionnalités activées, un compte administrateur Firewall Manager désigné, et AWS Config activé dans chaque compte membre. Les types de politiques couvrent AWS WAF, AWS Shield Advanced, les groupes de sécurité (audit et utilisation), Network Firewall, Route 53 Resolver DNS Firewall et les pare-feu tiers.

Une politique WAF peut appliquer un groupe de règles « premier » (évalué avant les règles propres à l’application), un groupe de règles « dernier » (après), ou remplacer entièrement la web ACL. Les nouveaux ALB ou distributions CloudFront correspondant à la portée des ressources reçoivent automatiquement l’ensemble de règles de l’entreprise, et les ressources non conformes sont signalées et — en fonction des paramètres de remédiation — corrigées automatiquement. Chaque fois qu’un scénario mentionne « plusieurs comptes », « gérer de manière centralisée » ou « des règles WAF cohérentes dans toute l’organisation », la réponse est Firewall Manager, et non une configuration WAF par compte.

Shield Standard vs Shield Advanced

Considérer que WAF seul peut arrêter les attaques DDoS est une erreur critique. WAF agit sur les requêtes qui l’atteignent — il est excellent contre les inondations au niveau de la couche applicative, le credential stuffing et les signatures d’exploits connues — mais les attaques volumétriques de grande ampleur aux couches 3/4 (inondations SYN, réflexion UDP) sont absorbées par AWS Shield.

Shield Standard est activé par défaut sans frais supplémentaires. Il protège automatiquement contre les attaques courantes des couches 3 et 4 (L3/L4) et s’applique à CloudFront, Route 53 et Global Accelerator, avec une protection de base pour les ELB, EC2 et autres ressources. Il ne fournit pas de visibilité spécifique aux attaques, d’intervention de la Shield Response Team, ni de protection contre les coûts.

Shield Advanced (3 000 $/mois par organisation, engagement d’un an) ajoute :

Supposer que Shield Standard est suffisant pour une « attaque DDoS à grande échelle avec protection des coûts et réponse d’experts » est une erreur, précisément parce que la version Standard ne dispose pas de la visibilité, de la protection des coûts et de l’accès à la SRT. Lorsque l’origine est une instance EC2 derrière un ELB et que le DNS est géré par un tiers (les astuces avec les alias Route 53 ne sont donc pas une option), le modèle recommandé est d’activer Shield Advanced sur l’ELB et de placer l’application derrière CloudFront (également protégé par Shield Advanced) pour déplacer le périmètre de mitigation en périphérie (edge) et réduire la surface d’attaque atteignant la Région.

La posture de défense en couches correcte est la suivante : Shield pour les attaques volumétriques L3/L4, WAF pour le filtrage L7, CloudFront ou Global Accelerator comme point d’entrée en périphérie auquel les deux services se rattachent, et Firewall Manager pour appliquer la politique sur l’ensemble des comptes.

← Réseau et connectivité · Tous les domaines · Bases de données et mise en cache →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →