Cloud & IT Cert Prep · Lektion

Multi-Site Active-Active med Global Tables och Route 53

Kör full produktionskapacitet i två eller flera regioner samtidigt med DynamoDB Global Tables, Aurora Global Database och latensbaserad routning i Route 53.

Lektion 4 av 413 steg

Multi-Site Active-Active med Global Tables och Route 53 är en gratis lektion i Cloud & IT Cert Prep på CoddyKit. Detta är lektion 4 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Cloud & IT Cert Prep, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Cloud & IT Cert Prep innehåller totalt 4 lektioner.

Multi-Site Active-Active definierat

Multi-Site Active-Active är den högsta nivån av katastrofåterställning, där applikationen körs med full produktionskapacitet i två eller fler AWS-regioner samtidigt. Till skillnad från active-passive, där en standby-miljö väntar på att ta över, betjänar båda regionerna aktiv användartrafik hela tiden i active-active. När en region slutar fungera tar den andra omedelbart över 100 % av trafiken utan någon fördröjning för failover. Detta mönster minskar även fördröjningen för globalt distribuerade användare genom att betjäna dem från närmaste region.

# Active-Active traffic split (normal operation):
# us-east-1: serving ~50% of users (North America)
# eu-west-1: serving ~50% of users (Europe)

# Active-Active traffic split (us-east-1 failure):
# us-east-1: 0% (health check failed)
# eu-west-1: 100% (ASG scales up automatically)

# RTO: near-zero (DNS TTL propagation only)
# RPO: near-zero (with DynamoDB Global Tables)

Arkitektur för DynamoDB Global Tables

DynamoDB Global Tables utgör databasen för active-active-arkitekturer. Global Tables möjliggör multi-master-replikering över flera regioner — applikationer i valfri region kan läsa och skriva till en lokal DynamoDB-tabell, och ändringar replikeras till alla andra regioner inom cirka 1 sekund. Ni aktiverar Global Tables genom att ange vilka regioner tabellen ska finnas i. AWS hanterar all replikering, konfliktlösning (den senaste skrivningen vinner) och failover automatiskt.

# Create DynamoDB table and add global regions
aws dynamodb create-table \
  --table-name UserSessions \
  --attribute-definitions AttributeName=userId,AttributeType=S \
  --key-schema AttributeName=userId,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region us-east-1

# Add replica regions for Global Table
aws dynamodb update-table \
  --table-name UserSessions \
  --replica-updates '[{"Create":{"RegionName":"eu-west-1"}},{"Create":{"RegionName":"ap-southeast-1"}}]' \
  --region us-east-1

Aurora Global Database för aktiva skrivningar och läsningar

Aurora Global Database tillhandahåller aktiva läsningar men passiva skrivningar i en active-active-arkitektur. Alla sekundära regioner betjänar läsningar med mindre än 1 sekunds replikeringseftersläpning, medan endast primärregionen tar emot skrivningar. Detta passar bra för läsintensiva applikationer som vill ha läsningar med låg fördröjning globalt och en tydlig primärregion för skrivningar. Vid ett regionalt fel i primärregionen kan ni befordra en sekundärregion till primärregion på mindre än 1 minut, vilket ger ett lågt RTO för skrivnivån. Jämför detta med DynamoDB Global Tables, som stöder aktiva skrivningar i alla regioner.

# Aurora Global Database read configuration
# Primary region (us-east-1): reads + writes
# Secondary region (eu-west-1): reads only
#   ~100ms replication lag, serves EU users low-latency reads

# Application reads from local Aurora endpoint
# Application writes to primary region Aurora endpoint

# Java connection string with region routing:
# readEndpoint=eu-west-1.cluster-ro-xxx.aurora.amazonaws.com
# writeEndpoint=us-east-1.cluster-xxx.aurora.amazonaws.com

Route 53-dirigering för Active-Active

Route 53 fungerar som trafikdirigerare för multi-site active-active-arkitekturer. Använd latensbaserad dirigering för att skicka varje användare till regionen med lägst nätverkslatens från användarens plats. Koppla hälsokontroller till varje regional post — när en region inte klarar sin hälsokontroll tar Route 53 automatiskt bort den från DNS-svaren och skickar all trafik till de återstående friska regionerna. Ange TTL till 60 sekunder eller mindre i DNS för att minimera tiden det tar för användare att växla över till den friska regionen.

# Route 53 latency routing with health checks
aws route53 change-resource-record-sets \
  --hosted-zone-id ZXXX \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "Region": "us-east-1",
          "SetIdentifier": "us-east-1",
          "HealthCheckId": "hc-us-east-1",
          "AliasTarget": {"DNSName": "alb-us-east-1.amazonaws.com", "EvaluateTargetHealth": false}
        }
      }
    ]
  }'

Auto Scaling för att hantera trafik

När en region slutar fungera i en active-active-konfiguration måste den kvarvarande regionen hantera två gånger (eller mer) den normala trafiken. Er Auto Scaling Group måste ha tillräcklig maximal kapacitet och skalningsprinciper för uppskalning som reagerar snabbt. Konfigurera målföljande skalning baserat på ALB:s antal begäranden per mål, så att ASG automatiskt lägger till instanser när trafiken fördubblas. Överväg även förvärmning: observera under failover-övningar hur snabbt er ASG skalar upp och säkerställ att den kan nå den nödvändiga kapaciteten inom ert RTO-mål.

# ASG target tracking for request count
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name app-asg-eu-west-1 \
  --policy-name scale-on-requests \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 1000,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/my-alb/xxx/targetgroup/my-tg/yyy"
    },
    "ScaleInCooldown": 60,
    "ScaleOutCooldown": 30
  }'

Sessionshantering i Active-Active

I en arkitektur med en region kan användarsessioner lagras lokalt på applikationsservrarna. I en active-active-konfiguration över flera regioner kan användare växla mellan regioner vid efterföljande begäranden, vilket gör serversidesessioner oanvändbara. Lösningar: 1) Tillståndslösa sessioner — lagra sessionsdata i en signerad JWT eller cookie som alla servrar i alla regioner kan validera. 2) DynamoDB Global Tables för sessioner — lagra sessioner centralt med åtkomst på millisekundnivå från alla regioner. 3) ElastiCache med Global Datastore — replikera Redis mellan regioner för sessionslagring.

# DynamoDB Global Table for session storage
# Session item structure:
{
  'sessionId': 'sess-abc123',
  'userId': 'usr-456',
  'data': {'cart': [...], 'preferences': {}},
  'expiresAt': 1750000000,
  'lastUpdatedRegion': 'us-east-1'
}

# Application reads from local region DynamoDB
# Writes replicate to all regions within ~1 second
# No sticky sessions needed on the ALB

Skrivkonflikter och konfliktlösning

Den största utmaningen med active-active och skrivningar från flera masterinstanser är skrivkonflikter. Om två användare i olika regioner uppdaterar samma post samtidigt, vilken uppdatering ska vinna? DynamoDB Global Tables använder principen den senaste skrivningen vinner, baserat på tidpunkten för skrivningen. Detta fungerar bra för de flesta användningsfall men kan orsaka dataförlust vid konkurrerande uppdateringar, till exempel när två användare ökar samma räknare samtidigt. Utforma datamodellen så att samtidiga skrivningar till samma objekt från olika regioner undviks, genom att använda villkorade skrivningar eller fördela dataägarskapet per region.

# Avoid conflicts with conditional writes
aws dynamodb update-item \
  --table-name UserProfiles \
  --key '{"userId":{"S":"usr-123"}}' \
  --update-expression 'SET profileVersion = profileVersion + :inc, username = :name' \
  --condition-expression 'profileVersion = :expectedVersion' \
  --expression-attribute-values '{
    ":inc":{"N":"1"},
    ":name":{"S":"newname"},
    ":expectedVersion":{"N":"5"}
  }'
# If another region already updated version, this fails gracefully

S3-replikering i Active-Active

För objektlagring i active-active använder ni S3 Cross-Region Replication med dubbelriktad replikering (tillgängligt för buckets där versionshantering är aktiverad). Till skillnad från enkelriktad CRR håller dubbelriktad replikering buckets i båda regionerna synkroniserade — objekt som skrivs i den ena regionen replikeras automatiskt till den andra. Detta är avgörande för applikationer som skriver användaruppladdade filer till den lokala regionens S3-bucket men behöver göra filerna åtkomliga globalt. Aktivera S3 Replication Time Control (RTC) för att garantera att 99,99 % av objekten replikeras inom 15 minuter.

# Bidirectional S3 replication
# Bucket A (us-east-1) replicates to Bucket B (eu-west-1)
# Bucket B (eu-west-1) replicates to Bucket A (us-east-1)

# Enable S3 RTC for guaranteed replication time
aws s3api put-bucket-replication \
  --bucket us-east-1-uploads \
  --replication-configuration '{
    "Rules": [{
      "Status": "Enabled",
      "ReplicationTime": {"Status": "Enabled", "Time": {"Minutes": 15}},
      "Metrics": {"Status": "Enabled", "EventThreshold": {"Minutes": 15}},
      "Destination": {"Bucket": "arn:aws:s3:::eu-west-1-uploads"}
    }]
  }'

CloudFront med ursprung i flera regioner

Använd CloudFront med origin-grupper för att skapa ett active-active-CDN med automatisk failover. Konfigurera ett primärt origin (ALB i us-east-1) och ett sekundärt origin (ALB i eu-west-1). CloudFront växlar automatiskt över till det sekundära origin när det primära returnerar 5xx-fel. För statiska resurser som levereras från S3 konfigurerar ni origin-grupper som pekar på S3-buckets i flera regioner med dubbelriktad replikering. Detta lägger till ett motståndskraftslager på CDN-nivå ovanpå er active-active-dirigering i Route 53.

# CloudFront origin group for multi-region failover
aws cloudfront create-distribution \
  --distribution-config '{
    "Origins": {
      "Quantity": 2,
      "Items": [
        {"Id": "us-east-1", "DomainName": "alb-us-east-1.amazonaws.com"},
        {"Id": "eu-west-1", "DomainName": "alb-eu-west-1.amazonaws.com"}
      ]
    },
    "OriginGroups": {
      "Items": [{
        "Id": "multi-region-group",
        "FailoverCriteria": {"StatusCodes": {"Items": [500,502,503,504]}},
        "Members": {"Items": [{"OriginId": "us-east-1"},{"OriginId": "eu-west-1"}]}
      }]
    }
  }'

Övervakning av Active-Active-hälsa

Active-active-arkitekturer kräver robust övervakning för att säkerställa att båda regionerna är friska och att trafiken fördelas som förväntat. Viktiga mätvärden är: Route 53 HealthCheckPercentageHealthy per region, DynamoDB ReplicationLatency för eftersläpning i Global Tables, ALB RequestCount per region för att verifiera trafikfördelningen samt CloudWatch-instrumentpaneler för flera konton och regioner för en samlad vy. Konfigurera larm när replikeringens eftersläpning överskrider ert RPO-tröskelvärde eller när trafikfördelningen blir kraftigt obalanserad.

# CloudWatch alarm for DynamoDB Global Table replication lag
aws cloudwatch put-metric-alarm \
  --alarm-name 'GlobalTable-ReplicationLag-eu-west-1' \
  --metric-name ReplicationLatency \
  --namespace AWS/DynamoDB \
  --dimensions Name=TableName,Value=UserSessions Name=ReceivingRegion,Value=eu-west-1 \
  --period 60 \
  --evaluation-periods 3 \
  --threshold 5000 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123:ops-alerts

När Active-Active är rätt val

Active-active passar när: användarna är globalt distribuerade och latensen till en enda region är oacceptabel. RTO måste vara nära noll — verksamheten kan inte tolerera ens några minuters driftstopp. Hög skrivkapacitet kräver att skrivningar fördelas över flera regioner. Regulatoriska krav föreskriver databehandling i det egna landet. Kostnaden är betydligt högre än för andra DR-nivåer, så välj endast active-active när verksamhetskraven och ekonomin tydligt motiverar det. För många arbetsbelastningar räcker Warm Standby och är betydligt billigare.

# Active-Active justification checklist:
# [ ] Users in 2+ continents with latency SLAs
# [ ] RTO requirement < 5 minutes
# [ ] Revenue impact of downtime justifies 2x+ cost
# [ ] Data must remain within specific regions (regulations)
# [ ] Write throughput exceeds single-region capacity

# If fewer than 2-3 boxes checked:
# Consider Warm Standby instead (lower cost, adequate RTO)

Snabbtest

Testa er förståelse av AWS Solutions Architect-koncepten (SAA-C03) från den här lektionen.

Besvara frågan i den interaktiva lektionen

Lektionens sammanfattning

I den här lektionen lärde ni er att DynamoDB Global Tables möjliggör multi-master-skrivningar över regioner för äkta active-active, att latensbaserad dirigering i Route 53 med hälsokontroller skickar användare till närmaste friska region och att sessionshantering måste vara tillståndslös eller använda globalt replikerad lagring i active-active. Active-active ger ett RTO och RPO nära noll, men till en betydligt högre kostnad. Härnäst utforskar vi pelarna Operational Excellence och Security i Well-Architected Framework.

Gratis att börja

Lär dig Cloud & IT Cert Prep med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser: 150
Lektioner: 600

Börja lära dig gratis Visa hela kursen

Vanliga frågor

Är lektionen ”Multi-Site Active-Active med Global Tables och Route 53” gratis?

Ja – hela texten till ”Multi-Site Active-Active med Global Tables och Route 53” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Cloud & IT Cert Prep, kan Ni uppgradera till CoddyKit PRO. Kursen i Cloud & IT Cert Prep innehåller totalt 4 lektioner.

Vad lär jag mig i ”Multi-Site Active-Active med Global Tables och Route 53”?

Kör full produktionskapacitet i två eller flera regioner samtidigt med DynamoDB Global Tables, Aurora Global Database och latensbaserad routning i Route 53. Ni övar på Cloud & IT Cert Prep med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Cloud & IT Cert Prep?

Du behöver inga förkunskaper. Utbildningen i Cloud & IT Cert Prep på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 4 av 4.

Hur lång tid tar lektionen ”Multi-Site Active-Active med Global Tables och Route 53”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Cloud & IT Cert Prep-lektionen?

Ja. Varje Cloud & IT Cert Prep-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

RTO, RPO och DR-nivåer
Säkerhetskopiering och återställning
Pilot Light och varm reservmiljö
Multi-Site Active-Active med Global Tables och Route 53

← Tillbaka till Cloud & IT Cert Prep