تصميم معماريّة HA + DR: Application Load Balancer متعدّد AZ، Auto Scaling Group، RDS Multi-AZ، ElastiCache replication group، S3 + CloudFront، Route 53 health checks و failover. استراتيجيّات DR (backup-restore، pilot light، warm standby، multi-site active-active).

للسياق: الدليل الرئيسي AWS SAA-C03 · كلّ دروس AWS السابقة.

المقدّمة

معماريّة HA + DR هي قلب المجال 2 Resilient Architectures (26% من اختبار SAA-C03). هذا الدرس يبني المعماريّة المرجعيّة ويُوضّح استراتيجيّات DR الأربع من Well-Architected Framework.

المتطلّبات

كلّ دروس AWS السابقة مكتملة.
VPC + EC2 + S3 + RDS مُتقَنة.
المستوى المتوسّط-المؤكَّد.
الوقت: 3 ساعات.

الخطوة 1 — المعماريّة المستهدفة HA الكلاسيكيّة

                          Route 53 (DNS)
                              │
                              ▼
                  CloudFront (CDN، edge عالميّ)
                              │
                              ▼
                    Application Load Balancer
                    (متعدّد 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)

         الأصول الساكنة: S3 (versioning + replication)
         Backups       : AWS Backup → S3 + Glacier
         Monitoring    : CloudWatch + CloudTrail + Config

هذه المعماريّة تنجو من خسارة AZ كاملة دون انقطاع مرئيّ.

الخطوة 2 — Application Load Balancer (ALB)

ALB = load balancer L7، يدعم HTTP/HTTPS/WebSockets/gRPC. متعدّد AZ بحكم البناء.

# إنشاء 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

# إنشاء 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 مع 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: path-based routing، host-based routing، HTTP redirect (HTTP←HTTPS)، sticky sessions، OIDC/Cognito auth.

الخطوة 3 — Auto Scaling Group مع 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 متعدّد 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 يستبدل تلقائياً instances تموت (health check ELB)، يحافظ على desired-capacity، scale up/down حسب CPU.

الخطوة 4 — استراتيجيّات DR (Disaster Recovery)

الاستراتيجيّات الأربع بترتيب RTO/RPO/تكلفة متزايدة:

1. Backup & Restore       (RTO ساعات، RPO ساعات، تكلفة منخفضة)
   - بيانات backup نحو S3 cross-region
   - البنية تُعاد إنشاؤها عند الكارثة
   - لـ workloads غير حرجة

2. Pilot Light            (RTO دقائق-1h، RPO دقائق، تكلفة متوسّطة)
   - بنية أدنى running في backup region (DB مُكرَّر)
   - Compute scaled-down، scale up عند DR
   - لـ workloads مهمّة

3. Warm Standby           (RTO دقائق، RPO ثوان، تكلفة عالية)
   - Stack كامل running في backup region، سعة مُخفَّضة
   - Promote عند DR (scale up سريعاً)
   - لـ workloads حرجة

4. Multi-Site Active-Active (RTO ~0، RPO ~0، تكلفة فائقة)
   - منطقتان running بالتوازي، الـ traffic مُوزَّع بـ Route 53
   - Failover فوريّ
   - لـ workloads tier-0 (دفع، trading)

في الاختبار: اختر حسب RTO/RPO/ميزانيّة العميل. سؤال نموذجيّ: «شركة تطلب RTO 30 دقيقة و RPO 5 دقائق، ميزانيّة متوسّطة» ← Pilot Light.

الخطوة 5 — RDS Multi-AZ و cross-region

# إنشاء 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: المُعادِل multi-region بـ lag < 1 ثانية، failover < 1 دقيقة.

الخطوة 6 — Route 53 health checks و failover

Routing policies:
  - Simple              : سجلّ واحد = IP واحدة
  - Weighted            : split traffic بـ % (canary deployment)
  - Latency             : routing نحو المنطقة الأقلّ latence للعميل
  - Failover            : primary + secondary مع health check
  - Geolocation         : routing حسب بلد/قارّة
  - Geoproximity        : routing حسب المسافة مع انحياز
  - Multivalue Answer   : يُرجع عدّة IPs healthy
  - Traffic Flow        : يدمج عدّة policies في شجرة

Health checks Route 53 تتحقّق من صحّة endpoint كلّ 30 ثانية، تُطلق failover نحو secondary إذا primary down.

في الاختبار: «Multi-region active-active routing بـ latence للعميل» ← Latency-based + health checks. «Backup region فقط عند عطل» ← Failover routing.

الخطوة 7 — Découplage بـ SQS/SNS/EventBridge

معماريّة HA = مكوّنات مستقلّة، تتواصل عبر رسائل غير متزامنة.

SQS (Simple Queue Service)
  - Standard queue : at-least-once، ordering best-effort
  - FIFO queue : exactly-once، ordering صارم
  - الاستخدام: decouple producers/consumers، retry logic، buffer ذروة الحمل

SNS (Simple Notification Service)
  - Pub/Sub fan-out : رسالة واحدة ← N subscribers (SQS، Lambda، email، SMS، HTTP)
  - الاستخدام: إشعارات، broadcast events

EventBridge
  - Event bus لتكامل AWS-services و SaaS partners
  - Filtering rules + targets (Lambda، SQS، Step Functions)
  - الاستخدام: معماريّة event-driven حديثة (موصى به 2026)

Step Functions
  - Orchestration لـ workflows (نمط saga)
  - State machine JSON
  - الاستخدام: process طويلة مع retry، error handling، parallel branches

في الاختبار: SQS لفصل workloads، SNS لـ fan-out، EventBridge لـ event-driven حديث، Step Functions للـ orchestration.

الخطوة 8 — تخزين HA

S3            : 99.999999999% متانة، 99.99% توفّر (Standard)
                Versioning + Cross-Region Replication = backup أقصى
EBS Multi-Attach: volume io2 قابل للإرفاق بـ multi instances في نفس AZ (نمط cluster)
EFS           : NFS متعدّد AZ، scale آليّ
FSx for NetApp: enterprise NFS/SMB cross-AZ
DynamoDB Global Tables: multi-region active-active NoSQL

في الاختبار: لتطبيق stateless = S3 + DynamoDB Global Tables = HA عالميّة بلا جهد.

الخطوة 9 — Monitoring HA

CloudWatch        : metrics + alarms + dashboards
                    Alarme على latency، error rate، CPU
                    Composite alarms (شروط متعدّدة)
CloudTrail        : تدقيق كلّ API calls AWS
                    Log مركّز في S3
AWS Config        : امتثال إعدادات (rules + remediation)
                    Snapshot configuration history
X-Ray             : distributed tracing
                    تحديد bottlenecks في microservices
CloudWatch Synthetics: canaries تختبر التطبيق كمستخدم
                       تنبيه إذا endpoint down أو شذوذ UI

الخطوة 10 — اختيار حسب السيناريو

السيناريو                                          الاختيار
-------------------------------------------------  ------------------------
تطبيق Web simple HA                                 ALB + ASG + RDS Multi-AZ
تجارة إلكترونيّة HA + DR cross-region              ALB + ASG + Aurora Global DB + S3 CRR
API microservices                                   API Gateway + Lambda + DynamoDB Global Tables
File processing asynchrone                          S3 + SQS + Lambda
Notifications fan-out                               SNS + SQS subscribers
Event-driven moderne                                EventBridge + Step Functions
Banque tier-0 paiement                              Multi-Site Active-Active 2 régions
Backup compliance long-terme                        AWS Backup → S3 Glacier Deep Archive

الأخطاء المتكرّرة

الخطأ	الحلّ
ALB unhealthy targets	Health check path inccorect أو SG bloque traffic ALB ← targets
ASG ne scale pas	CloudWatch alarms incorrectes، vérifier permissions IAM
RDS failover lent	Application doit gérer reconnect، utiliser connection pooling
Cross-region replication lag	Network throughput، taille des objets/transactions
Route 53 failover ne fonctionne pas	Health check endpoint return 200، not 401/403

اعتبارات إقليميّة

Banques régionales: HA multi-AZ مع eu-west-3 (Paris) + DR في eu-west-1 (Irlande). Aurora Global Database للـ critical workloads.

E-commerce panafricain: multi-region active-active eu-west-3 + af-south-1 + Route 53 latency-based pour servir LATAM/Afrique/Europe.

Startups: démarrer single-AZ pour économie، upgrade vers Multi-AZ quand révenu confirme. Aurora Serverless v2 pour DB.

أسئلة شائعة

Multi-AZ ou Multi-Region أساسيّ؟

Multi-AZ يكفي لـ 95% من حالات HA (panne AZ rare). Multi-Region لـ DR complet ou latency clientèle globale.

Coût Multi-AZ?

~2x coût Single-AZ pour RDS، ALB neutre، EC2 selon nb d’instances. ROI clairement positif si downtime coûte cher.

RTO أم RPO أكثر أهميّة؟

RTO = temps pour redevenir up. RPO = data loss tolérée. Les deux comptent، à pondérer selon business impact.

قراءات تكميليّة

الدليل الرئيسي: AWS SAA-C03
كلّ دروس AWS السابقة.
التوثيق: Well-Architected Framework، Disaster Recovery.

الكلمات المفتاحيّة: AWS HA Multi-AZ، Auto Scaling Group، ALB، Route 53 failover، Aurora Global Database، Pilot Light Warm Standby، SQS SNS EventBridge، Step Functions.

دراسات حالات حقيقيّة في غرب إفريقيا

الحالة 1 — Fintech mobile money. 4 ملايين معاملة/شهر. 4 200 USD/شهر، 99.98% توفّر.
الحالة 2 — تجارة إلكترونيّة عابرة. 80 000 زائر/يوم. multi-region active-active. 8 500 USD/شهر، +23% تحويل.
الحالة 3 — هجرة بنك تقليديّ. 80% workloads في 14 شهراً. توفير 55% في السنة 3.

خمسة سيناريوهات SAA-C03

1: تجارة إلكترونيّة HA. ALB + ASG، CloudFront، Aurora Read Replicas، ElastiCache، SQS.
2: DR cross-region. Pilot Light، Aurora Global Database، Route 53 health checks.
3: تأمين بيانات. S3 SSE-KMS، RDS مُشفَّر، IAM least privilege، CloudTrail، GuardDuty.
4: تحسين تكلفة. Scheduler، RIs، Spot، Compute Savings Plans 3 سنوات. توفير 65-75%.
5: امتثال PCI DSS. تجزئة VPC، WAF + Shield، CloudHSM، AWS Config، Security Hub.

التكاليف بـ FCFA

PME 30 موظّفاً: ~225 USD/شهر ≈ 135 000 FCFA/شهر. مع RIs 3 سنوات: ~87 000 FCFA/شهر.

خطّة مهنة

0-12 شهراً: junior 800K-1.2M FCFA. 12-30: DevOps/Security 1.4M-2M. 30-60: SAP-C02 2.2M-3.5M. 60+: senior 400-800 USD/يوم.

أدوات تكميليّة

Terraform، AWS CDK، GitHub Actions، ECS/EKS/Fargate، CloudWatch + Datadog، Cost Explorer، Prowler + Security Hub + Wiz.

معماريّة AWS عالية التوفّر Multi-AZ — درس SAA-C03 2026

المقدّمة

المتطلّبات

الخطوة 1 — المعماريّة المستهدفة HA الكلاسيكيّة

الخطوة 2 — Application Load Balancer (ALB)

الخطوة 3 — Auto Scaling Group مع Launch Template

الخطوة 4 — استراتيجيّات DR (Disaster Recovery)

الخطوة 5 — RDS Multi-AZ و cross-region

الخطوة 6 — Route 53 health checks و failover

الخطوة 7 — Découplage بـ SQS/SNS/EventBridge

الخطوة 8 — تخزين HA

الخطوة 9 — Monitoring HA

الخطوة 10 — اختيار حسب السيناريو

الأخطاء المتكرّرة

اعتبارات إقليميّة

أسئلة شائعة

قراءات تكميليّة

دراسات حالات حقيقيّة في غرب إفريقيا

خمسة سيناريوهات SAA-C03

التكاليف بـ FCFA

خطّة مهنة

أدوات تكميليّة

مقالات ذات صلة

Site ou application web sur mesure

المقدّمة

المتطلّبات

الخطوة 1 — المعماريّة المستهدفة HA الكلاسيكيّة

الخطوة 2 — Application Load Balancer (ALB)

الخطوة 3 — Auto Scaling Group مع Launch Template

الخطوة 4 — استراتيجيّات DR (Disaster Recovery)

الخطوة 5 — RDS Multi-AZ و cross-region

الخطوة 6 — Route 53 health checks و failover

الخطوة 7 — Découplage بـ SQS/SNS/EventBridge

الخطوة 8 — تخزين HA

الخطوة 9 — Monitoring HA

الخطوة 10 — اختيار حسب السيناريو

الأخطاء المتكرّرة

اعتبارات إقليميّة

أسئلة شائعة

قراءات تكميليّة

دراسات حالات حقيقيّة في غرب إفريقيا

خمسة سيناريوهات SAA-C03

التكاليف بـ FCFA

خطّة مهنة

أدوات تكميليّة

مقالات ذات صلة

Site ou application web sur mesure

مقالات مشابهة

S3: versioning و lifecycle والأمن — درس AWS SAA-C03 2026

EC2 و EBS و AMI: نشر خادم AWS — درس SAA-C03 2026

IAM AWS: المستخدمون والأدوار والـ policies و MFA خطوة بخطوة — درس SAA-C03 2026