Intermédiaire

Architectures distribuées

Bases de données managées, répartition de charge, diffusion mondiale et observabilité

Module 5

Bases RDS, Aurora et DynamoDB

Relationnel managé contre NoSQL serverless : choisir le bon moteur du premier coup.

1. RDS : le relationnel sans l'administration

  • Moteurs : MySQL, PostgreSQL, MariaDB, Oracle, SQL Server. AWS gère OS, patchs, sauvegardes automatiques (rétention 0-35 jours) et snapshots manuels.
  • Multi-AZ : standby synchrone dans une autre AZ, bascule automatique (même endpoint DNS) = haute disponibilité.
  • Read Replicas : copies asynchrones pour la scalabilité en lecture (jusqu'à 5, voire inter-régions). Un replica peut être promu.
  • RDS Proxy : pool de connexions pour les applications à forte concurrence.
Pourquoi c'est important : Une base MySQL autogérée sur EC2 tombe un soir de patch et il faut rejouer les sauvegardes à la main, puis le Black Friday multiplie les lectures par dix et le primaire s'écroule. En tant qu'architecte, passer sur RDS Multi-AZ pour la disponibilité et ajouter des replicas de lecture ou DynamoDB pour la charge, c'est transformer une panne certaine en simple bascule invisible.
L'analogie qui aide : Pensez cuisine de restaurant : RDS Multi-AZ est le chef avec un second prêt à prendre la main en cas de malaise, les Read Replicas sont les commis qui distribuent des copies du plat sans déranger le chef, et DynamoDB est le distributeur automatique qui sert en quelques millisecondes sans cuisinier.

2. Aurora : le moteur cloud-natif

Compatible MySQL/PostgreSQL, stockage distribué répliqué sur 3 AZ (6 copies), jusqu'à 15 replicas en lecture, endpoints lecteur/écrivain, backtrack, Aurora Serverless v2 (capacité auto-ajustée) et Global Database (secondaire inter-région à moins d'une seconde de retard).

3. DynamoDB : NoSQL à l'échelle

  • Clé-valeur et document, latence à un chiffre en millisecondes, tables globales multi-régions actives-actives.
  • Capacité provisionnée (avec auto scaling) ou on-demand ; DAX : cache en mémoire (microsecondes) ; Streams + TTL pour l'expiration et les réactions.
  • ElastiCache (Redis/Memcached) devant RDS pour le cache ; Redshift pour l'analytique, Neptune pour les graphes.
Démonstration pas à pas : Besoin : boutique relationnelle critique avec paniers ultra-rapides. Étape 1 : Aurora MySQL Multi-AZ avec endpoint écrivain pour les commandes et endpoint lecteur pour le catalogue. Étape 2 : deux Aurora Replicas pour absorber les lectures, plus RDS Proxy devant pour les pics de connexions. Étape 3 : paniers et sessions sur DynamoDB on-demand avec TTL. Pourquoi pas EC2 autogéré : patchs et bascule à la main. Pourquoi pas Redshift : c'est de l'analytique, pas de l'OLTP.
aws rds create-db-instance --db-instance-identifier prod-mysql --db-instance-class db.t3.micro --engine mysql --master-username admin --master-user-password MotDePasse123 --allocated-storage 50 --multi-az
aws rds describe-db-instances --db-instance-identifier prod-mysql
aws rds create-db-read-replica --db-instance-identifier prod-replica --source-db-instance-identifier prod-mysql
aws dynamodb create-table --table-name sessions --attribute-definitions AttributeName=userId,AttributeType=S --key-schema AttributeName=userId,KeyType=HASH --billing-mode PAY_PER_REQUEST
aws dynamodb put-item --table-name sessions --item '{"userId":{"S":"u1"}}'
aws rds create-db-snapshot --db-instance-identifier prod-mysql --db-snapshot-identifier snap-01
Points d'examen :
  • Disponibilité = Multi-AZ ; lecture massive = Read Replicas / Aurora Replicas.
  • Latence extrême clé-valeur = DynamoDB + DAX ; multi-région actif-actif = tables globales.
  • OLTP relationnel critique = Aurora ; entrepôt analytique = Redshift.
  • Chiffrement au repos via KMS, SSL en transit, IAM auth sur RDS/Aurora.
Pièges classiques : Multi-AZ sert la disponibilité avec bascule automatique, Read Replicas sert la scalabilité en lecture, jamais l'inverse. RDS contre Aurora : Aurora apporte stockage sur 3 AZ, 15 replicas et Global Database à moins d'une seconde. DynamoDB avec DAX pour la microseconde et tables globales pour l'actif-actif multi-région, ElastiCache devant RDS pour le cache relationnel.
À vous de jouer : 100 000 lectures par seconde en clé-valeur sous 10 millisecondes, en actif-actif sur deux continents. Que choisissez-vous ?
Voir la réponse

DynamoDB avec tables globales et DAX en cache. RDS même avec replicas ne tient pas cette latence mondiale en actif-actif, et Aurora Global reste à primaire unique avec secondaire en lecture.

Module 6

ELB et Auto Scaling

Répartir la charge et ajuster la capacité automatiquement : le coeur de l'élasticité AWS.

1. Les trois répartiteurs

  • ALB (couche 7) : HTTP/HTTPS, routage par chemin, hôte, en-têtes et query string, groupes cibles (instances, IP, Lambda, conteneurs), WAF intégrable, sticky sessions.
  • NLB (couche 4) : TCP/UDP/TLS, performance extrême, IP statique/EIP par AZ, préservation de l'IP source, cibles hors VPC.
  • GWLB : chaînage d'appliances tierces (pare-feu) via GENEVE. Le CLB est l'ancêtre à éviter.
  • Les ELB sont multi-AZ par conception ; les health checks éjectent les cibles défaillantes ; le drainage (deregistration delay) finit les requêtes en cours.
Pourquoi c'est important : Une seule EC2 sans répartiteur tombe et tout le site est hors ligne, puis un passage télé multiplie le trafic par vingt et le serveur sature sans pouvoir grandir. Avec un ELB multi-AZ couplé à un Auto Scaling Group qui ajoute des instances quand le CPU grimpe, la panne d'une machine et le pic de charge deviennent des non-événements.
L'analogie qui aide : Voyez l'ALB comme l'aiguilleur d'un péage intelligent qui lit votre destination et vous envoie vers la bonne file selon le chemin ou l'hôte, et le NLB comme un péage ultrarapide qui ne regarde que la plaque et laisse passer des millions de voitures. L'ASG est le chef de gare qui ouvre ou ferme des guichets selon la longueur de la file.

2. Auto Scaling Group

  • Basé sur un launch template, réparti sur plusieurs AZ, taille min/desired/max.
  • Politiques : target tracking (ex. : CPU à 50 %), step scaling, simple scaling, planifiées et prédictives.
  • Cooldown et warm-up pour éviter les oscillations ; hooks de cycle de vie et politiques de terminaison.
  • Scaling horizontal (plus d'instances) contre vertical (plus grosse instance).
Démonstration pas à pas : Besoin : API HTTP avec routage /images vers un service dédié et trafic TCP massif à IP fixe. Étape 1 : ALB avec deux groupes cibles et règle par chemin pour isoler les images, health checks sur /health et drainage pour finir les requêtes. Étape 2 : ASG sur deux AZ à partir d'un launch template, min 2 et max 6, target tracking à 50 pour cent de CPU. Pourquoi pas le CLB : génération précédente sans routage fin. Pourquoi pas une seule grosse instance : aucun plan de reprise ni élasticité.
aws elbv2 create-load-balancer --name web-alb --subnets subnet-a subnet-b --security-groups sg-111 --scheme internet-facing --type application
aws elbv2 create-target-group --name web-tg --protocol HTTP --port 80 --vpc-id vpc-1234 --health-check-path /health
aws elbv2 create-listener --load-balancer-arn arn-alb --protocol HTTP --port 80 --default-actions Type=forward,TargetGroupArn=arn-tg
aws autoscaling create-launch-template --launch-template-name web-lt --version-description v1 --launch-template-data '{"ImageId":"ami-0abc","InstanceType":"t3.micro"}'
aws autoscaling create-auto-scaling-group --auto-scaling-group-name web-asg --launch-template LaunchTemplateName=web-lt,Version=1 --min-size 2 --max-size 6 --desired-capacity 2 --vpc-zone-identifier "subnet-a,subnet-b"
aws autoscaling put-scaling-policy --auto-scaling-group-name web-asg --policy-name cpu50 --policy-type TargetTrackingScaling --target-tracking-configuration file://tracking.json
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web-asg
Points d'examen :
  • Routage HTTP intelligent = ALB ; TCP massif + IP fixe = NLB.
  • ASG multi-AZ + ELB = élasticité et tolérance de panne (question type).
  • Target tracking pour le scaling simple ; planifié pour les pics prévisibles.
  • Cross-zone load balancing : toujours actif sur ALB, à activer sur NLB/CLB.
Pièges classiques : Routage HTTP intelligent avec hôte et chemin égale ALB en couche 7, TCP et UDP massifs avec IP statique égale NLB en couche 4. Cross-zone toujours actif sur ALB mais à activer sur NLB. Target tracking pour le cas général, planifié pour les pics prévisibles, avec cooldown pour éviter les oscillations.
À vous de jouer : Une application bancaire en TCP exige 1 million de connexions et une IP fixe par AZ imposée par le pare-feu client. Que choisissez-vous ?
Voir la réponse

Un NLB avec EIP par AZ et préservation de l'IP source, couplé à un ASG multi-AZ. L'ALB ne gère pas le TCP pur à ce débit et ne fournit pas d'IP fixe.

Module 7

Route 53 et CloudFront

Diriger les utilisateurs et rapprocher le contenu : DNS intelligent et CDN mondial.

1. Route 53

  • DNS anycast mondial, zones hébergées publiques/privées, enregistrements Alias (gratuits, vers ALB/CloudFront/S3, au sommet de zone) contre CNAME.
  • Politiques de routage : simple, failover (actif-passif avec health checks), géolocalisation, latence, pondéré, géoproximité et multivaleur.
  • Health checks : surveillance HTTP/HTTPS/TCP qui déclenche le basculement.
Pourquoi c'est important : Votre région tombe un samedi soir et le DNS continue d'envoyer les clients vers le vide, pendant que les utilisateurs australiens attendent trois secondes chaque image. Avec un routage Route 53 à bascule sur health checks et un contenu rapproché par CloudFront, la panne régionale est absorbée et la latence mondiale s'effondre.
L'analogie qui aide : Route 53 est l'annuaire téléphonique mondial qui donne toujours le numéro du magasin ouvert le plus proche et raye celui en travaux, CloudFront est le réseau d'entrepôts de quartier qui garde une copie des best-sellers pour éviter l'aller-retour au dépôt central à chaque commande.

2. CloudFront

  • CDN : edge locations proches des utilisateurs, origines (S3, ALB, EC2), comportements de cache par chemin, TTL, invalidation.
  • OAC (Origin Access Control) : le bucket S3 n'accepte que CloudFront, jamais d'accès public direct.
  • URL et cookies signés pour le contenu privé payant ; classes de prix pour limiter les régions ; chiffrement TLS et AWS WAF en frontal.
  • Global Accelerator : deux IP anycast fixes vers les applications (TCP/UDP), complément du CDN pour le dynamique non cachable.
Démonstration pas à pas : Besoin : SaaS hébergé à Paris avec reprise à Dublin et vidéos pour le monde entier. Étape 1 : zone hébergée Route 53 avec enregistrement Alias vers l'ALB et routage failover sur health checks HTTP. Étape 2 : distribution CloudFront avec origine S3 privée verrouillée par OAC, TTL par chemin et URL signées pour le premium. Pourquoi pas un CNAME au sommet de zone : interdit par le DNS, seul l'Alias AWS le permet. Pourquoi pas un bucket public : fuite garantie.
aws route53 create-hosted-zone --name exemple.fr --caller-reference 2026-01
aws route53 change-resource-record-sets --hosted-zone-id Z1234 --change-batch file://alias-alb.json
aws route53 create-health-check --caller-reference check1 --health-check-config file://health.json
aws cloudfront create-distribution --distribution-config file://distrib.json
aws cloudfront create-invalidation --distribution-id E1234 --paths "/*"
aws route53 list-hosted-zones
aws cloudfront list-distributions
Points d'examen :
  • Sommet de zone vers AWS = enregistrement Alias (pas CNAME).
  • Bascule multi-région = Route 53 failover + health checks.
  • S3 privé + diffusion mondiale = CloudFront + OAC + URL signées.
  • IP fixes + performances UDP/TCP mondiales = Global Accelerator.
Pièges classiques : Sommet de zone vers AWS égale Alias gratuit, jamais CNAME. Bascule multi-région égale failover plus health checks, répartition de test égale pondéré, utilisateurs par pays égale géolocalisation. S3 privé plus CloudFront avec OAC et URL signées pour le contenu payant, Global Accelerator pour le dynamique non cachable en TCP et UDP.
À vous de jouer : Le domaine exemple.fr doit pointer son sommet vers un ALB. Quel enregistrement créez-vous ?
Voir la réponse

Un enregistrement Alias de type A vers l'ALB dans la zone hébergée. Un CNAME est interdit au sommet de zone et ne s'intègre pas aux health checks AWS natifs.

Module 8

Surveillance : CloudWatch et CloudTrail

Métriques et alarmes contre audit des API : savoir lequel répond à quelle question.

1. CloudWatch : que se passe-t-il sur mes ressources ?

  • Métriques (CPU, réseau, disque ; mémoire via l'agent unifié), alarmes (seuil + action : scaling, SNS, arrêt), Logs (centralisation, Insights, rétention), Events/EventBridge (réaction aux événements), tableaux de bord et Synthetics (canaris).
  • Granularité 1 minute (détaillée) contre 5 minutes (de base) ; métriques EC2 de base gratuites.
Pourquoi c'est important : Un bucket de production est supprimé à 3 heures du matin et personne ne sait qui a cliqué, pendant qu'une instance tourne à 95 pour cent de CPU depuis une semaine sans alerte. Sans CloudWatch pour la surcharge et CloudTrail pour l'audit, vous découvrez la panne par le client et la cause par hasard.
L'analogie qui aide : CloudWatch est le tableau de bord de la voiture qui affiche vitesse et température en direct et allume un voyant avant la surchauffe, CloudTrail est la boîte noire de l'avion qui enregistre chaque action du pilote pour l'enquête après incident.

2. CloudTrail : qui a fait quoi via l'API ?

  • Journalise chaque appel API (identité, action, paramètres, IP, heure). Historique d'événements (90 jours, gratuit) contre piste (trail) vers S3 (durable, multi-régions, validation des fichiers journaux, chiffrement KMS).
  • AWS Config : conformité des configurations dans le temps + remédiation ; X-Ray : tracing distribué des applications.
Démonstration pas à pas : Besoin : être alerté avant la saturation et savoir qui supprime quoi. Étape 1 : alarme CloudWatch sur CPU supérieur à 80 pour cent pendant 10 minutes avec action SNS et scaling. Étape 2 : logs centralisés avec rétention et métriques mémoire via l'agent unifié. Étape 3 : piste CloudTrail multi-régions vers un bucket S3 verrouillé avec validation des journaux, plus AWS Config pour la conformité. Pourquoi pas CloudTrail pour la charge CPU : il ne voit que les API. Pourquoi pas des logs locaux : perdus avec l'instance.
aws cloudwatch put-metric-alarm --alarm-name cpu-haute --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 80 --comparison-operator GreaterThanThreshold --evaluation-periods 2 --alarm-actions arn:aws:sns:eu-west-3:1234:alertes
aws cloudwatch describe-alarms --state-value ALARM
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization --start-time 2026-01-01T00:00:00Z --end-time 2026-01-02T00:00:00Z --period 3600 --statistics Average --dimensions Name=InstanceId,Value=i-1234
aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceName,AttributeValue=mon-bucket --max-results 20
aws cloudtrail create-trail --name piste-audit --s3-bucket-name logs-audit-2026 --is-multi-region-trail
aws cloudtrail start-logging --name piste-audit
Points d'examen :
  • « Qui a supprimé / modifié ? » = CloudTrail ; « L'instance est-elle surchargée ? » = CloudWatch.
  • Piste multi-régions + validation des logs pour l'audit conforme.
  • Mémoire EC2 = agent CloudWatch obligatoire (pas de métrique native).
  • Config = conformité (« cette ressource respecte-t-elle la règle ? »).
Pièges classiques : Question qui a fait quoi égale CloudTrail, question comment va la ressource égale CloudWatch, question est-elle conforme égale Config. La mémoire EC2 exige l'agent CloudWatch, aucune métrique native ne la fournit. Pour l'audit, exigez une piste multi-régions avec validation des journaux vers S3.
À vous de jouer : On vous demande qui a terminé l'instance i-1234 hier à 14 heures. Où cherchez-vous ?
Voir la réponse

Dans CloudTrail avec lookup-events sur TerminateInstances et la ressource visée. CloudWatch montre la chute de charge mais jamais l'identité de l'appelant.

Niveau précédent Niveau suivant : Expert