Cloud & IT Cert Prep · leksjon

Multi-site aktiv-aktiv med Global Tables og Route 53

Kjør full produksjonskapasitet i to eller flere Region-er samtidig ved hjelp av DynamoDB Global Tables, Aurora Global Database og forsinkelsesbasert ruting i Route 53

Leksjon 4 av 413 trinn

Multi-site aktiv-aktiv med Global Tables og Route 53 er en gratis leksjon i Cloud & IT Cert Prep på CoddyKit. Dette er leksjon 4 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Cloud & IT Cert Prep, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Cloud & IT Cert Prep inneholder totalt 4 leksjoner.

Multi-site active-active forklart

Multi-Site Active-Active er det høyeste nivået for katastrofegjenoppretting, der applikasjonen kjører med full produksjonskapasitet i to eller flere AWS-regioner samtidig. I motsetning til active-passive, der en standby-region venter på å ta over, betjener begge regionene aktiv brukertrafikk til enhver tid. Når én region svikter, tar den andre umiddelbart over 100 % av trafikken uten forsinkelse for failover. Dette mønsteret reduserer også ventetiden for globalt distribuerte brukere ved å betjene dem fra regionen som ligger nærmest.

# 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 for DynamoDB Global Tables

DynamoDB Global Tables er datagrunnlaget for active-active-arkitekturer. Global Tables muliggjør replikering med flere mastere på tvers av regioner — applikasjoner i alle regioner kan lese og skrive til en lokal DynamoDB-tabell, og endringer replikeres til alle andre regioner innen omtrent ett sekund. Du aktiverer Global Tables ved å angi hvilke regioner tabellen skal finnes i. AWS håndterer all replikering, konfliktløsning (last-writer-wins) og failover automatisk.

# 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 for aktive skrivninger og lesinger

Aurora Global Database tilbyr active-active-lesing, men active-passive-skriving. Alle sekundærregioner betjener leseforespørsler med under ett sekunds replikeringsefterslep, mens bare primærregionen godtar skrivninger. Dette passer godt for leseintensive applikasjoner som ønsker lesing med lav ventetid globalt, samtidig som de har en tydelig primærregion for skrivninger. Ved regional svikt i primærregionen kan du gjøre en sekundærregion til primærregion på under ett minutt, slik at du oppnår lav RTO for skrive-laget. Dette kan sammenlignes med DynamoDB Global Tables, som støtter active-active-skriving i alle 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

Ruting med Route 53 for active-active

Route 53 fungerer som trafikkdirigent for multi-site active-active-arkitekturer. Bruk latency-based routing for å sende hver bruker til regionen med lavest nettverksventetid fra brukerens plassering. Knytt health checks til hver regional post — når en region ikke består helsesjekken, fjerner Route 53 den automatisk fra DNS-svarene og sender all trafikk til de gjenværende friske regionene. Sett DNS-ens TTL til 60 sekunder eller mindre for å minimere tiden det tar før brukere går over til den friske 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 for håndtering av trafikk

Når én region svikter i et active-active-oppsett, må den gjenværende regionen håndtere to ganger (eller mer) den normale trafikken. Auto Scaling Group må ha tilstrekkelig makskapasitet og retningslinjer for oppskalering som reagerer raskt. Konfigurer target tracking scaling basert på ALB-forespørsler per mål, slik at ASG automatisk legger til instanser når trafikken dobles. Vurder også forhåndsoppvarming: Observer under failover-øvelser hvor raskt ASG skalerer opp, og kontroller at gruppen kan nå den nødvendige kapasiteten innenfor RTO-målet.

# 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
  }'

Sesjonsbehandling i active-active

I en arkitektur med én region kan brukersesjoner lagres lokalt på applikasjonsserverne. I active-active med flere regioner kan brukere veksle mellom regioner ved påfølgende forespørsler, slik at sesjoner på serversiden brytes. Løsninger: 1) Tilstandsløse sesjoner — lagre sesjonsdata i en signert JWT eller informasjonskapsel som alle servere i alle regioner kan validere. 2) DynamoDB Global Tables for sesjoner — lagre sesjoner sentralt med tilgang på millisekundnivå fra alle regioner. 3) ElastiCache med Global Datastore — Redis-replikering på tvers av regioner for lagring av sesjoner.

# 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

Skrivekonflikter og konfliktløsning

Den største utfordringen med active-active og skrivninger fra flere mastere er skrivekonflikter. Hvis to brukere i forskjellige regioner oppdaterer den samme posten samtidig, hvilken oppdatering skal vinne? DynamoDB Global Tables bruker last-writer-wins basert på tidspunktet for skrivningen. Dette fungerer godt for de fleste bruksområder, men kan føre til datatap ved konkurrerende oppdateringer (for eksempel når to brukere øker en teller samtidig). Utform datamodellen slik at samtidige skrivninger til samme element fra forskjellige regioner unngås, ved hjelp av conditional writes eller ved å fordele dataeierskapet etter 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

For objektlagring i active-active bruker du S3 Cross-Region Replication with bidirectional replication (tilgjengelig for bøtter med versjonering aktivert). I motsetning til enveis-CRR holder toveisreplikering bøttene i begge regioner synkronisert — objekter som skrives i én region, replikeres automatisk til den andre. Dette er avgjørende for applikasjoner som skriver brukeropplastede filer til S3-bøtten i den lokale regionen, men som trenger at filene er tilgjengelige globalt. Aktiver S3 Replication Time Control (RTC) for å garantere at 99,99 % av objektene replikeres innen 15 minutter.

# 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 opphav i flere regioner

Bruk CloudFront with origin groups for å opprette et active-active-CDN med automatisk failover. Konfigurer et primæropphav (ALB i us-east-1) og et sekundæropphav (ALB i eu-west-1). CloudFront går automatisk over til sekundæropphavet når primæropphavet returnerer 5xx-feil. For statiske ressurser som leveres fra S3 konfigurerer du origin groups som peker til S3-bøtter i flere regioner med toveisreplikering. Dette legger et robust CDN-lag på toppen av active-active-rutingen 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"}]}
      }]
    }
  }'

Overvåking av active-active-helsen

Active-active-arkitekturer krever robust overvåking for å sikre at begge regionene er friske, og at trafikken fordeles som forventet. Viktige måltall er: Route 53 HealthCheckPercentageHealthy per region, DynamoDB ReplicationLatency for etterslep i Global Tables, ALB RequestCount per region for å kontrollere trafikkfordelingen, og CloudWatch cross-account/cross-region dashboards for en samlet oversikt. Sett opp alarmer når replikeringsefterslepet overskrider RPO-terskelen, eller når trafikkfordelingen blir svært ubalansert.

# 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 er det riktige valget

Active-active passer når: brukerne er globalt distribuert og ventetiden til én enkelt region er uakseptabel. RTO må være nær null — virksomheten kan ikke tåle selv noen minutters nedetid. Høy skrivegjennomstrømning krever at skrivninger fordeles mellom regioner. Regulatoriske krav pålegger databehandling i det aktuelle landet. Kostnaden er betydelig høyere enn for andre DR-nivåer, så velg bare active-active når virksomhetskravene og økonomien tydelig rettferdiggjør det. For mange arbeidsbelastninger er Warm Standby tilstrekkelig og langt rimeligere.

# 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)

Kjapp kontroll

Test forståelsen din av AWS Solutions Architect (SAA-C03)-konseptene fra denne leksjonen.

Besvar den i den interaktive leksjonen

Oppsummering av leksjonen

I denne leksjonen lærte du at DynamoDB Global Tables muliggjør skrivninger fra flere mastere på tvers av regioner for ekte active-active, at latency-basert ruting i Route 53 med helsesjekker sender brukere til den nærmeste friske regionen, og at sesjonsbehandling må være tilstandsløs eller bruke globalt replikert lagring i active-active. Active-active gir nær null i RTO og RPO, men til en betydelig høyere kostnad. Deretter utforsker vi søylene Operational Excellence og Security i Well-Architected Framework.

Gratis å komme i gang

Lær deg Cloud & IT Cert Prep med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 150
Leksjoner: 600

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Multi-site aktiv-aktiv med Global Tables og Route 53» gratis?

Ja – hele teksten i «Multi-site aktiv-aktiv med Global Tables og Route 53» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Cloud & IT Cert Prep-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Cloud & IT Cert Prep inneholder totalt 4 leksjoner.

Hva lærer jeg i «Multi-site aktiv-aktiv med Global Tables og Route 53»?

Kjør full produksjonskapasitet i to eller flere Region-er samtidig ved hjelp av DynamoDB Global Tables, Aurora Global Database og forsinkelsesbasert ruting i Route 53 Du øver på Cloud & IT Cert Prep med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Cloud & IT Cert Prep?

Ingen tidligere erfaring er nødvendig. Cloud & IT Cert Prep på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 4 av 4.

Hvor lang tid tar leksjonen «Multi-site aktiv-aktiv med Global Tables og Route 53»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

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

Ja. Alle Cloud & IT Cert Prep-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

RTO, RPO og DR-nivåer
Sikkerhetskopiering og gjenoppretting
Pilot Light og varm reserve
Multi-site aktiv-aktiv med Global Tables og Route 53

← Tilbake til Cloud & IT Cert Prep