Architecture haute disponibilité multi-AZ AWS — tutoriel SAA-C03 2026

Concevoir une architecture HA + DR : Application Load Balancer multi-AZ, Auto Scaling Group, RDS Multi-AZ, ElastiCache replication group, S3 + CloudFront, Route 53 health checks et failover. Stratégies DR (backup-restore, pilot light, warm standby, multi-site active-active).

📍 À lire d’abord : Pilier AWS SAA-C03 · tous les tutoriels précédents AWS.

Introduction

L’architecture HA + DR est le cœur du domaine 2 Resilient Architectures (26 % de l’examen SAA-C03). Ce tutoriel construit l’architecture de référence et explique les 4 stratégies DR du Well-Architected Framework.

Prérequis

• Tous les tutoriels AWS précédents complétés.
• VPC + EC2 + S3 + RDS maîtrisés.
• Niveau intermédiaire-confirmé.
• Temps : 3 heures.

Étape 1 — Architecture cible HA classique

                          Route 53 (DNS)
                              │
                              ▼
                  CloudFront (CDN, edge global)
                              │
                              ▼
                    Application Load Balancer
                    (multi-AZ, health checks)
                  ┌───────────┼───────────┐
                  │           │           │
              EC2 ASG     EC2 ASG     EC2 ASG
            (eu-west-3a) (eu-west-3b) (eu-west-3c)
                  │           │           │
                  └───────────┼───────────┘
                              ▼
                    RDS Aurora Multi-AZ
                    (writer + 2 readers)
                              │
                              ▼
                    ElastiCache Redis
                    (replication multi-AZ)

         Static assets : S3 (versioning + replication)
         Backups       : AWS Backup → S3 + Glacier
         Monitoring    : CloudWatch + CloudTrail + Config

Cette architecture survit à la perte d’une AZ entière sans interruption visible.

Étape 2 — Application Load Balancer (ALB)

ALB = L7 load balancer, supporte HTTP/HTTPS/WebSockets/gRPC. Multi-AZ par construction.

# Créer ALB
aws elbv2 create-load-balancer \
  --name lab-alb \
  --subnets subnet-public-a subnet-public-b \
  --security-groups $SG_ALB \
  --scheme internet-facing \
  --type application

# Créer target group
aws elbv2 create-target-group \
  --name lab-tg \
  --protocol HTTP --port 80 \
  --vpc-id $VPC_ID \
  --health-check-path /health \
  --health-check-interval-seconds 30

# Listener HTTPS avec cert ACM
aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=$ACM_CERT_ARN \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN

ALB features : path-based routing, host-based routing, HTTP redirect (HTTP→HTTPS), sticky sessions, OIDC/Cognito auth.

Étape 3 — Auto Scaling Group avec Launch Template

# Launch template
aws ec2 create-launch-template \
  --launch-template-name lab-template \
  --version-description v1 \
  --launch-template-data '{
    "ImageId": "ami-xxx",
    "InstanceType": "t3.small",
    "SecurityGroupIds": ["sg-xxx"],
    "IamInstanceProfile": {"Name": "EC2-S3-ReadOnly"},
    "UserData": "'$(base64 -w0 user-data.sh)'"
  }'

# Auto Scaling Group multi-AZ
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name lab-asg \
  --launch-template "LaunchTemplateName=lab-template,Version=1" \
  --min-size 2 --desired-capacity 2 --max-size 10 \
  --vpc-zone-identifier "subnet-priv-a,subnet-priv-b,subnet-priv-c" \
  --target-group-arns $TG_ARN \
  --health-check-type ELB --health-check-grace-period 300

# Scaling policy target tracking
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name lab-asg \
  --policy-name cpu-target \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 60.0
  }'

ASG remplace automatiquement les instances qui meurent (health check ELB), maintient desired-capacity, scale up/down selon CPU.

Étape 4 — Stratégies DR (Disaster Recovery)

Les 4 stratégies par RTO/RPO/coût croissants :

1. Backup & Restore       (RTO heures, RPO heures, coût bas)
   - Données backup vers S3 cross-region
   - Infrastructure réinstancie en cas de catastrophe
   - Pour workloads non-critiques

2. Pilot Light            (RTO minutes-1h, RPO minutes, coût moyen)
   - Infrastructure minimale running en backup region (DB répliqué)
   - Compute scaled-down, scale up en cas de DR
   - Pour workloads importants

3. Warm Standby           (RTO minutes, RPO secondes, coût élevé)
   - Stack complète running en backup region, capacité réduite
   - Promote en cas de DR (scale up rapidement)
   - Pour workloads critiques

4. Multi-Site Active-Active (RTO ~0, RPO ~0, coût très élevé)
   - 2 régions running en parallèle, traffic split par Route 53
   - Failover instantané
   - Pour workloads tier-0 (paiement, trading)

À l’examen : choisir selon RTO/RPO/budget client. Question typique : « Compagnie demande RTO 30 min et RPO 5 min, budget moyen » → Pilot Light.

Étape 5 — RDS Multi-AZ et cross-region

# Créer RDS Multi-AZ
aws rds create-db-instance \
  --db-instance-identifier lab-db \
  --db-instance-class db.t3.small \
  --engine postgres \
  --master-username admin --manage-master-user-password \
  --allocated-storage 20 \
  --multi-az \
  --vpc-security-group-ids $SG_DB \
  --db-subnet-group-name lab-db-subnet-group \
  --backup-retention-period 30 \
  --storage-encrypted

# Cross-region read replica
aws rds create-db-instance-read-replica \
  --db-instance-identifier lab-db-replica-paris \
  --source-db-instance-identifier arn:aws:rds:eu-west-1:xxx:db:lab-db \
  --db-instance-class db.t3.small

Aurora Global Database : équivalent multi-region avec lag < 1 sec, failover < 1 minute.

Étape 6 — Route 53 health checks et failover

Routing policies :
  - Simple              : 1 enregistrement = 1 IP
  - Weighted            : split traffic par % (canary deployment)
  - Latency             : routing vers region la moins latente client
  - Failover            : primary + secondary avec health check
  - Geolocation         : routing par pays/continent
  - Geoproximity        : routing par distance avec biais
  - Multivalue Answer   : retourne plusieurs IPs healthy
  - Traffic Flow        : combine plusieurs policies en arbre

Health checks Route 53 vérifient endpoint santé toutes les 30 sec, déclenchent failover sur secondary si primary down.

À l’examen : « Multi-region active-active routing par latence cliente » → Latency-based + health checks. « Backup region uniquement en cas de panne » → Failover routing.

Étape 7 — Découplage avec SQS/SNS/EventBridge

Architecture HA = composants indépendants, communicant via messages asynchrones.

SQS (Simple Queue Service)
  - Standard queue : at-least-once, ordering best-effort
  - FIFO queue : exactly-once, ordering strict
  - Use : decouple producers/consumers, retry logic, buffer pic charge

SNS (Simple Notification Service)
  - Pub/Sub fan-out : 1 message → N subscribers (SQS, Lambda, email, SMS, HTTP)
  - Use : notifications, broadcast events

EventBridge
  - Event bus pour intégration AWS-services et SaaS partenaires
  - Filtering rules + targets (Lambda, SQS, Step Functions)
  - Use : event-driven architecture moderne (recommandé 2026)

Step Functions
  - Orchestration de workflows (saga pattern)
  - State machine JSON
  - Use : process longs avec retry, error handling, parallel branches

À l’examen : SQS pour découpler workloads, SNS pour fan-out, EventBridge pour event-driven moderne, Step Functions pour orchestration.

Étape 8 — Stockage HA

S3            : 99.999999999 % durabilité, 99.99 % disponibilité (Standard)
                Versioning + Cross-Region Replication = backup ultime
EBS Multi-Attach : volume io2 attachable à multi instances même AZ (cluster pattern)
EFS           : NFS multi-AZ, scale auto
FSx for NetApp : enterprise NFS/SMB cross-AZ
DynamoDB Global Tables : multi-region active-active NoSQL

À l’examen : pour app stateless = S3 + DynamoDB Global Tables = HA mondiale sans effort.

Étape 9 — Monitoring HA

CloudWatch        : metrics + alarms + dashboards
                    Alarme sur latency, error rate, CPU
                    Composite alarms (multiple conditions)
CloudTrail        : audit toutes les API calls AWS
                    Log centralisé en S3
AWS Config        : conformité configuration (rules + remediation)
                    Snapshot configuration history
X-Ray             : distributed tracing
                    Identifier bottlenecks dans microservices
CloudWatch Synthetics : canaries qui testent l'app comme un user
                        Alerte si endpoint down ou anomalie UI

À l’examen : Synthetics pour tester user journey end-to-end, X-Ray pour tracer requête à travers microservices.

Étape 10 — Cost optimization HA

HA coûte cher. Réduire sans sacrifier résilience :

1. Spot Instances dans ASG (mix Spot + On-Demand pour 70 % off)
2. Reserved Instances pour baseline capacity (économie 50-72 %)
3. S3 Intelligent-Tiering pour stockage variable
4. Aurora Serverless v2 au lieu de provisioned
5. CloudFront pour cache statique (réduit charge origin EC2)
6. NAT Gateway = 32 USD/mois → utiliser VPC Endpoints quand possible
7. Auto Scaling pour ne payer que ce qui tourne
8. Idle EC2 / EBS détectés via Trusted Advisor + Cost Explorer

Erreurs fréquentes

Adaptation au contexte ouest-africain

Banques : architecture Pilot Light minimum. Cross-region eu-west-3 ↔ eu-west-1 pour DR. Conformité PCI DSS impose RTO ≤ 24h.

E-commerce continental : CloudFront partout en Afrique pour latence cliente. Multi-region pour résilience (eu-west-3 + af-south-1).

Startups : commencer Single-AZ. Migrer vers Multi-AZ quand business le justifie. Aurora Serverless v2 pour scale économique.

FAQ

Combien d’AZ utiliser ?

Minimum 2 pour HA. Idéal 3 pour quorum (databases distribuées). Au-delà = coût rarement justifié.

Multi-region toujours nécessaire ?

Non. Multi-AZ couvre 99 % des pannes (panne entière région = rare). Multi-region pour conformité réglementaire ou tier-0 critique.

Disaster recovery testé ?

Quarterly minimum. Tabletop + simulation réelle annuelle. Documenter RTO/RPO réels mesurés.

Pour aller plus loin

• 🔝 Pilier AWS SAA-C03
• ⬅️ Tous les tutoriels AWS du cluster (à lire dans l’ordre).
• ➡️ Suite : passer à Azure AZ-104 ou Solutions Architect Pro AWS.
• Documentation : AWS Well-Architected Framework, Disaster Recovery whitepaper.

Mots-clés : AWS HA Multi-AZ, Auto Scaling Group ALB, RDS Multi-AZ Aurora Global, Route 53 failover, DR strategies pilot light warm standby, CloudFront Route 53, EventBridge SQS découplage.

Approfondissement et cas pratiques

Études de cas réelles AWS en Afrique de l’Ouest

Cas 1 — Fintech mobile money, Dakar, 2025. Une fintech sénégalaise traite 4 millions de transactions/mois (Orange Money agrégé). Architecture AWS : ALB multi-AZ (eu-west-3) + ECS Fargate auto-scaling 8-50 tasks + Aurora Serverless v2 PostgreSQL (1-32 ACU) + DynamoDB pour ledger transactionnel + ElastiCache Redis pour sessions + S3 + CloudFront pour static. Coût mensuel 4 200 USD, soit 0.001 USD par transaction. Disponibilité mesurée 99,98 % sur 12 derniers mois. RTO 4 minutes via Multi-AZ failover Aurora.

Cas 2 — E-commerce panafricain, Abidjan/Dakar/Lagos, 2024. Plateforme avec 80 000 visiteurs/jour. Architecture multi-region active-active : eu-west-3 (Paris, principal pour AO/UE) + af-south-1 (Cape Town, secondaire pour Afrique australe) + Route 53 latency-based routing. Réplication Aurora Global Database, S3 Cross-Region Replication, DynamoDB Global Tables. CloudFront edge locations couvrant Lagos, Casablanca, Johannesburg. Coût 8 500 USD/mois, ROI prouvé par augmentation 23 % du taux conversion grâce à latence < 200ms partout en Afrique.

Cas 3 — Migration banque traditionnelle vers AWS, 2024-2025. Banque ivoirienne avec 18 ans d’historique on-prem (datacenter Plateau Abidjan + DR Yamoussoukro). Migration AWS lift-and-shift 80 % des workloads en 14 mois. Stack : VPC hub-and-spoke avec Transit Gateway, AWS Directory Service pour AD legacy, RDS pour Oracle SAP, EC2 dedicated hosts pour licences Microsoft, AWS Backup avec immutability pour conformité, AWS Control Tower pour gouvernance. Économie 40 % vs datacenter on-prem dès l’année 1, montée à 55 % en année 3.

Cinq scénarios SAA-C03 type examen détaillés

Scénario 1 : architecture e-commerce HA pour Black Friday. App attendue à 100x charge normale en 4h. Réponse : ALB + ASG avec scheduled scaling (lance 50 instances 30 min avant), CloudFront pour cache statique, Aurora Read Replicas pour scale read, ElastiCache Redis cluster mode pour sessions, SQS pour découpler order processing.

Scénario 2 : DR cross-region. Compagnie demande RTO 30 min, RPO 5 min. Réponse : Pilot Light pattern, primary eu-west-3, secondary eu-west-1 avec Aurora Global Database (lag < 1s) + AMI répliquées + Route 53 health checks failover automatique.

Scénario 3 : sécurisation données sensibles. Application stocke PII clients. Réponse : S3 SSE-KMS avec CMK, encryption EBS, RDS encrypted, KMS key rotation auto annuelle, IAM least privilege, CloudTrail logs vers S3 Object Lock immutable, GuardDuty actif, Macie pour découverte automatique PII.

Scénario 4 : optimisation coût legacy. Compte AWS avec 250 instances EC2 mostly idle nuit/weekend. Réponse : Instance Scheduler pour stop/start automatique, Reserved Instances 1 an pour baseline 24/7, Spot Instances pour batch processing, S3 Intelligent-Tiering, Compute Savings Plans 3 ans pour stack permanente. Économie attendue 65-75 %.

Scénario 5 : conformité PCI DSS. Architecture e-commerce processant cartes. Réponse : segmentation VPC stricte (CDE = Cardholder Data Environment isolé), AWS WAF + Shield Advanced, CloudHSM pour clés PCI, AWS Config rules pour conformité continue, AWS Inspector pour scan vuln, GuardDuty + Security Hub, CloudTrail multi-region, AWS Audit Manager pour rapports.

Architecture cloud-native moderne 2026

[Route 53 latency-based] → [CloudFront global edges]
                              ↓
                      [WAF + Shield Advanced]
                              ↓
              [API Gateway HTTP API ou Application Load Balancer]
                              ↓
       ┌────────────────────────┼────────────────────────┐
       ↓                        ↓                        ↓
  [Lambda functions]    [ECS Fargate tasks]     [EKS pods auto-scaled]
  pour serverless       pour containers         pour orchestration
       ↓                        ↓                        ↓
       └────────┬───────────────┴────────┬───────────────┘
                ↓                        ↓
         [Aurora Serverless v2]    [DynamoDB on-demand]
         pour relational           pour NoSQL haute scale
                ↓                        ↓
         [ElastiCache Redis cluster]
                ↓
         [S3 Intelligent-Tiering + Glacier lifecycle]
         pour archives
                ↓
[Observability : CloudWatch + X-Ray + EventBridge + Step Functions]
[Sécurité : IAM + KMS + Secrets Manager + GuardDuty + Security Hub]
[Gouvernance : Organizations + SCP + Control Tower + Config]

Cette architecture cloud-native moderne sert de référence pour les startups et scale-ups ouest-africaines qui veulent éviter le legacy ops.

Coûts détaillés en FCFA pour cas réel PME

PME 30 employés, 1 application web SaaS, 10 000 utilisateurs actifs/mois :

Service                                        Coût/mois
-------                                        ---------
EC2 t3.medium x2 (ALB + workers)              90 USD
RDS db.t3.micro Multi-AZ                      28 USD
S3 + CloudFront (50 Go transfer)              35 USD
ALB + Route 53                                25 USD
Backup + monitoring                           15 USD
NAT Gateway (alternative : NAT Instance)      32 USD (ou 8 USD)
                                              ---------
Total                                         225 USD/mois
                                              ≈ 135 000 FCFA/mois
                                              ≈ 1 620 000 FCFA/an

Vs hébergement OVH/Hetzner classique : ~80 USD/mois mais sans HA, sans CDN, sans backup automatisé. AWS premium justifié pour fiabilité + scaling.

Avec Reserved Instances 3 ans : 35 % économie → 145 USD/mois ≈ 87 000 FCFA/mois.

Plan de carrière post-AWS SAA détaillé

0-12 mois : décrocher poste cloud engineer junior dans ESN cloud (Smart Africa, ETRILABS, Kasi Insight, agences Microsoft/AWS partner) ou directement chez client final (banque, opérateur, fintech). Salaire 800 000-1 200 000 FCFA. Activités : provisioning Terraform, déploiement CI/CD, monitoring CloudWatch, support N1/N2.

12-30 mois : monter compétence DevOps + sécurité cloud. Certifications cibles : AWS DevOps Pro (DOP-C02) ou AWS Security Specialty (SCS-C02). Salaire 1 400 000-2 000 000 FCFA. Activités : automation IaC, optimisation coûts (FinOps), implémentation Zero Trust, gestion incidents production.

30-60 mois : positions architecte ou tech lead. Cert AWS Solutions Architect Professional (SAP-C02). Salaire 2 200 000-3 500 000 FCFA local, 4-7 millions FCFA en remote international.

60+ mois : Cloud Architect senior, Engineering Manager, Principal Engineer ou freelance/consulting. Plateformes remote : Toptal, Malt, A.Team, Andela. Tarifs day rate 400-800 USD pour profils seniors AWS+Kubernetes+AI/ML.

Outils et frameworks complémentaires

IaC : Terraform (cross-cloud, le plus utilisé en 2026), AWS CDK (Python/TypeScript), Pulumi (alternative moderne), CloudFormation (legacy mais utile pour AWS-specific).

CI/CD : GitHub Actions (le plus populaire), GitLab CI, AWS CodePipeline (intégré AWS), CircleCI, Jenkins (legacy).

Container orchestration : Amazon ECS (managed), Amazon EKS (Kubernetes), Fargate (serverless containers).

Observability : CloudWatch (de base), Datadog (premium SaaS), New Relic, Grafana Cloud avec Prometheus.

FinOps : AWS Cost Explorer + Budgets + Compute Optimizer, Vantage.sh (alternative), CloudHealth, Apptio Cloudability.

Security : Prowler (audit script open-source), Cloudsploit, AWS Security Hub, Wiz, Lacework.