Cloud & IT Cert Prep · Lektion

Scenarier for robuste arkitekturer med høj tilgængelighed

Arbejd med scenarier om databasefailover på tværs af AZ'er, automatisk skalering ved pludselig trafik og failover baseret på Route 53-tilstandstjek for at styrke dine begreber om pålidelighed

Lektion 2 af 413 trin

Scenarier for robuste arkitekturer med høj tilgængelighed er en gratis Cloud & IT Cert Prep-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Cloud & IT Cert Prep, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.

Scenarie 1: Webapplikation i flere AZ'er

Scenarie: En virksomhed kører en webapplikation i to lag (ALB → EC2 → RDS) og vil eliminere alle enkeltstående fejlpunkter i AWS-området. Løsning: Implementer EC2-instanser i en Auto Scaling Group, der spænder over mindst 2 Availability Zones, bag en ALB (som i sig selv dækker flere AZ'er). Aktivér RDS Multi-AZ til synkron standbyreplikering. Konfigurer sundhedstjek på ALB'en, så trafikken automatisk dirigeres væk fra instanser, der ikke er sunde. Med denne arkitektur medfører tabet af en enkelt AZ automatisk failover på hvert lag.

# Create RDS with Multi-AZ enabled
aws rds create-db-instance \
  --db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --engine mysql \
  --multi-az \
  --master-username admin \
  --master-user-password Pass123! \
  --allocated-storage 100

# Create ASG across 3 AZs
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --availability-zones us-east-1a us-east-1b us-east-1c \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-tg/abc

Scenarie 2: Skalering af RDS-læsning under belastning

Scenarie: En e-handelsapplikations RDS-instans rammer CPU-grænserne i spidsbelastningsperioder på grund af læsetunge analyseforespørgsler fra business intelligence-teamet. Løsning: Opret RDS Read Replicas, og send BI-forespørgsler til replikaens endpoint. Read Replicas bruger asynkron replikering — en mindre forsinkelse er acceptabel for analyser. Det aflaster læsetrafikken fra den primære RDS-instans, som er reserveret til skrivehandlinger og læsninger fra applikationen. Til arbejdsbelastninger med ekstremt mange læsninger kan du tilføje et ElastiCache-lag foran RDS til data, der tilgås ofte.

# Create a Read Replica from the primary RDS instance
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-replica \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --availability-zone us-east-1b

# Application code: use replica endpoint for reads
# Primary endpoint: prod-mysql.cluster.us-east-1.rds.amazonaws.com (writes)
# Replica endpoint: prod-mysql-replica.xyz.us-east-1.rds.amazonaws.com (reads)

Scenarie 3: Auto Scaling ved CPU-spidsbelastning

Scenarie: En tilstandsløs API kører på EC2 bag en ALB. CPU-forbruget stiger til 90 % i arbejdstiden og falder næsten til nul om natten. Virksomheden vil have, at instansflåden skaleres automatisk. Løsning: Konfigurer en Auto Scaling Group med en Target Tracking scaling policy, der sigter mod en gennemsnitlig CPU-udnyttelse på 60 %. ASG tilføjer automatisk instanser, når CPU-forbruget overstiger 60 %, og fjerner instanser, når det falder under målet. Tilføj en planlagt skaleringshandling for at forvarme minimumskapaciteten, før arbejdstiden begynder, så forsinkelse ved morgenens trafikstigning undgås.

# Target tracking policy: scale to keep CPU at 60%
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-asg \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 60.0,
    "DisableScaleIn": false
  }'

# Scheduled action: pre-warm to 5 instances at 8 AM weekdays
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name api-asg \
  --scheduled-action-name morning-scale-out \
  --recurrence '0 8 * * MON-FRI' \
  --min-size 5

Scenarie 4: Route 53-failover til DR-område

Scenarie: En virksomhed kører en primær webapplikation i us-east-1 og vil skifte over til en statisk vedligeholdelsesside hostet på S3 i us-west-2, hvis den primære applikation ikke længere er sund. Løsning: Opret et Route 53-sundhedstjek, der overvåger endpointet for den primære ALB. Opret to Route 53-poster med en failover-routingpolitik: En primær post, der peger på ALB'en (tilknyttet sundhedstjekket), og en sekundær post, der peger på det statiske S3-websted. Hvis sundhedstjekket mislykkes, leverer Route 53 automatisk DNS-svaret fra den sekundære post.

# Create Route 53 health check for primary ALB
aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "app.example.com",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

# Primary failover record (associated with health check)
# Secondary failover record -> S3 static website endpoint
# Route 53 automatically switches if health check fails

Scenarie 5: Afkobling med SQS for robusthed

Scenarie: En backend til ordrebehandling skriver til en database, men databasen bliver nogle gange utilgængelig under vedligeholdelsesvinduer, hvilket medfører, at ordrer går tabt. Løsning: Placér en SQS-kø mellem frontend'en (som modtager ordrer) og backend'en (som behandler dem). Ordrer lægges straks i køen, så kunden får en øjeblikkelig bekræftelse. Baggrundsarbejdere henter ordrer fra køen og behandler dem, når databasen er tilgængelig. Under vedligeholdelse samler ordrerne sig i køen i stedet for at blive kasseret — det giver robusthed gennem asynkron afkobling.

# SQS-based order decoupling pattern
# 1. Frontend: PUT order to SQS (returns 200 immediately to customer)
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --message-body '{"orderId": "ORD-123", "items": [...]}'

# 2. Backend worker: polls SQS when DB is available
aws sqs receive-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --max-number-of-messages 10

# 3. On success: delete message from queue
# 4. On failure: visibility timeout expires -> message reappears for retry
# 5. After max retries: message goes to Dead Letter Queue (DLQ)

Scenarie 6: Pilot Light til DR

Scenarie: En virksomhed har brug for en disaster recovery-løsning med en RPO på 1 time og en RTO på 4 timer inden for et moderat budget. Løsning: Implementer en Pilot Light-DR-strategi. Hold den centrale database replikeret til DR-området ved hjælp af RDS Cross-Region Read Replica. Applikationsserverne kører ikke i DR-området under normal drift — kun den minimale 'kerne' (databasen) holdes varm. I tilfælde af en katastrofe promoveres Read Replica til en selvstændig instans, og applikationsservere startes fra forudoprettede AMI'er ved hjælp af CloudFormation. RTO'en er timer snarere end minutter, fordi serverne skal startes.

# Pilot Light: replicate database to DR Region
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --source-region us-east-1 \
  --destination-region us-west-2

# During disaster: promote replica in us-west-2 to standalone
aws rds promote-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --region us-west-2
# Then launch app servers from AMIs using CloudFormation in us-west-2

Scenarie 7: SQS Dead-Letter Queue til mislykkede meddelelser

Scenarie: Meddelelser på en SQS-kø kan gentagne gange ikke behandles på grund af en fejl i forbrugerens Lambda. Meddelelserne dukker hele tiden op igen og blokerer køen. Løsning: Konfigurer en Dead-Letter Queue (DLQ) på hovedkøen. Når en meddelelse ikke kan behandles et konfigurerbart antal gange (maxReceiveCount), flytter SQS den automatisk til DLQ'en i stedet for at levere den igen for evigt. Det frigiver hovedkøen, så sunde meddelelser kan behandles. Indstil en CloudWatch-alarm på DLQ'ens måling ApproximateNumberOfMessagesVisible for at advare udviklingsteamet, når meddelelser ophobes i DLQ'en.

# Set redrive policy to move failed messages to DLQ after 3 attempts
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123:orders-dlq\", \"maxReceiveCount\": \"3\"}"
  }'

# CloudWatch alarm on DLQ depth
aws cloudwatch put-metric-alarm \
  --alarm-name orders-dlq-depth \
  --metric-name ApproximateNumberOfMessagesVisible \
  --namespace AWS/SQS \
  --dimensions Name=QueueName,Value=orders-dlq \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 --period 60 --statistic Sum

Scenarie 8: Aurora Global Database

Scenarie: En virksomhed opererer i USA og Europa. Brugere i Europa oplever høj latenstid ved læsning fra databasen, fordi RDS befinder sig i us-east-1. Løsning: Brug Amazon Aurora Global Database. Den primære klynge er i us-east-1, og en sekundær skrivebeskyttet klynge tilføjes i eu-west-1. Aurora replikerer data til det sekundære område med typisk latenstid under 1 sekund ved hjælp af replikering på lagerniveau. Europæiske brugere læser fra den sekundære klynge i eu-west-1. Ved en regional katastrofe kan den sekundære klynge promoveres til primær på under 1 minut (den bedste RTO blandt alle AWS-muligheder for databaser i flere områder).

# Add a secondary region to an Aurora Global Database
aws rds create-global-cluster \
  --global-cluster-identifier prod-global \
  --source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:prod-aurora

# Add secondary Region cluster
aws rds create-db-cluster \
  --db-cluster-identifier prod-aurora-eu \
  --engine aurora-postgresql \
  --global-cluster-identifier prod-global \
  --region eu-west-1

Scenarie 9: ECS-tjeneste med ALB og Auto Scaling

Scenarie: En containeriseret API-tjeneste, der kører på ECS Fargate, skal skaleres baseret på CPU-udnyttelse og kunne modstå AZ-fejl. Løsning: Registrer ECS-tjenesten med en målgruppe for Application Load Balancer, så trafikken fordeles mellem de kørende opgaver. Placér opgaver på tværs af flere AZ'er ved at angive flere undernet i tjenestens konfiguration. Konfigurer ECS Service Auto Scaling med en politik for målsporing af CPU-udnyttelsen i ECS-tjenesten, så antallet af opgaver automatisk skaleres op og ned. Hvis en AZ svigter, genstarter ECS de fejlede opgaver i sunde AZ'er.

# Create ECS Fargate service with ALB and multi-AZ placement
aws ecs create-service \
  --cluster prod-cluster \
  --service-name api-service \
  --task-definition api-task:5 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-1a", "subnet-1b", "subnet-1c"],
      "securityGroups": ["sg-app"],
      "assignPublicIp": "DISABLED"
    }
  }' \
  --load-balancers '[{
    "targetGroupArn": "arn:...:targetgroup/api-tg/abc",
    "containerName": "api",
    "containerPort": 8080
  }]'

Scenarie 10: Failover med sundhedstjek ved hjælp af Route 53

Scenarie: En virksomhed kører to EC2-instanser i forskellige AZ'er, som leverer det samme domæne. Den vil have, at Route 53 automatisk stopper med at sende trafik til en instans, der ikke er sund. Løsning: Brug Route 53 Weighted Routing med lige vægte (50/50), og tilknyt et sundhedstjek af endpointet til hver post. Når Route 53 registrerer et usundt endpoint, fjerner den posten fra DNS-svarene og sender 100 % af trafikken til det sunde endpoint. Når instansen kommer sig, og sundhedstjekkene igen lykkes, omfordeler Route 53 automatisk trafikken — der er ikke brug for manuelle DNS-ændringer.

# Route 53 weighted record with health check association
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "instance-1a",
        "Weight": 50,
        "HealthCheckId": "hc-abc123",
        "TTL": 30,
        "ResourceRecords": [{"Value": "10.0.1.10"}]
      }
    }]
  }'

Scenarie 11: DynamoDB Global Tables til HA i flere områder

Scenarie: En mobilspilapplikation skal kunne læse og skrive spillerdata med lav latenstid fra både us-east-1 og ap-southeast-1. En DynamoDB-tabel i ét område medfører høj latenstid for asiatiske brugere. Løsning: Aktivér DynamoDB Global Tables. Global Tables replikerer automatisk data på tværs af de angivne områder ved hjælp af multi-master-replikering — alle områder kan modtage skrivehandlinger. Asiatiske brugere skriver til og læser fra replikaen i ap-southeast-1 med lokal latenstid (~5 ms). Global Tables håndterer konfliktløsning ved hjælp af strategien 'sidst skrevne vinder', baseret på tidsstempler. RTO'en ved et fuldstændigt regionalt svigt er næsten nul — trafikken dirigeres ganske enkelt til det område, der stadig fungerer.

# Convert a DynamoDB table to a Global Table
# (table must exist in all target Regions first)
aws dynamodb create-global-table \
  --global-table-name PlayerData \
  --replication-group '[{"RegionName": "us-east-1"}, {"RegionName": "ap-southeast-1"}]'

# Add another Region to an existing Global Table
aws dynamodb update-global-table \
  --global-table-name PlayerData \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'

Hurtig kontrol

Test din forståelse af begreberne i AWS Solutions Architect (SAA-C03) fra denne lektion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion arbejdede du med scenarier, der dækkede: Multi-AZ ASG og RDS til HA inden for samme område, Route 53-failover-routing til DR på tværs af områder, SQS DLQ til isolering af mislykkede meddelelser uden at blokere køer og Aurora Global Database til skalering af læsninger på tværs af områder og failover med RTO under ét minut. Dernæst arbejder du med scenarier for højtydende og omkostningsoptimeret arkitektur.

Gratis at komme i gang

Lær Cloud & IT Cert Prep med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 150
Lektioner: 600

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Scenarier for robuste arkitekturer med høj tilgængelighed” gratis?

Ja — hele teksten til “Scenarier for robuste arkitekturer med høj tilgængelighed” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Cloud & IT Cert Prep-kurset, skal du opgradere til CoddyKit PRO. Cloud & IT Cert Prep-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Scenarier for robuste arkitekturer med høj tilgængelighed”?

Arbejd med scenarier om databasefailover på tværs af AZ'er, automatisk skalering ved pludselig trafik og failover baseret på Route 53-tilstandstjek for at styrke dine begreber om pålidelighed Du øver dig i Cloud & IT Cert Prep med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på Cloud & IT Cert Prep?

Der kræves ingen tidligere erfaring. Cloud & IT Cert Prep på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.

Hvor lang tid tager lektionen “Scenarier for robuste arkitekturer med høj tilgængelighed”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne Cloud & IT Cert Prep-lektion?

Ja. Alle Cloud & IT Cert Prep-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

Scenarier for sikre arkitekturer
Scenarier for robuste arkitekturer med høj tilgængelighed
Scenarier med høj ydeevne og omkostningsoptimering
Blandet mini-eksamen i fuld længde

← Tilbage til Cloud & IT Cert Prep