De fyra AWS DR-strategierna i detalj

AWS dokumenterar fyra distinkta strategier i sitt Disaster Recovery Workloads-whitepaper. De skiljer sig fundamentalt i kostnad, komplexitet och återställningstid.

Backup & Restore

Den enklaste och billigaste strategin. Du tar regelbundna säkerhetskopior (snapshots av EBS-volymer, RDS-backuper, S3-replikering) och återställer från dessa vid behov.

RTO: Timmar (typiskt 4–24 timmar beroende på datamängd)

RPO: Beror på backupfrekvens (vanligen 1–24 timmar)

Kostnad: Låg — du betalar huvudsakligen för lagring

AWS Backup är den centrala tjänsten här. Den stödjer EBS, RDS, DynamoDB, EFS, FSx och S3 med policybaserad schemaläggning och cross-region kopiering. För svenska organisationer innebär det att du kan ha dagliga backuper i eu-north-1 med kopior till eu-west-1.

När det passar: Utvecklingsmiljöer, interna system med låg kritikalitet, arkivdata. Inte lämpligt för kundnära produktion med SLA-krav.

Pilot Light

Pilot Light innebär att du håller kärnkomponenterna — typiskt databaser och konfiguration — replikerade och redo i den sekundära regionen, men utan att köra applikationsservrar. Vid failover startar du de saknade komponenterna.

RTO: 10–30 minuter (med bra automation)

RPO: Sekunder till minuter (med kontinuerlig databasreplikering)

Kostnad: Måttlig — du betalar för databasinstanser och replikering, men inte för compute i vänteläge

Typisk implementation: RDS Multi-AZ med cross-region read replica, AMI:er förregistrerade i sekundär region, Launch Templates redo att instansieras via Auto Scaling Groups. Infrastructure as Code (IaC) via Terraform eller CloudFormation är i princip obligatoriskt — du vill inte manuellt klicka ihop en miljö under en pågående kris.

När det passar: Affärskritiska system där 15–30 minuters RTO är acceptabelt och du vill hålla DR-kostnaden under kontroll.

Warm Standby

En nedskalad men fullt fungerande kopia av din produktionsmiljö körs i den sekundära regionen. Vid failover skalar du upp till full kapacitet.

RTO: Minuter (typiskt 2–10 minuter)

RPO: Sekunder (med kontinuerlig replikering)

Kostnad: Betydande — typiskt 15–30 % av produktionskostnaden löpande

Det som skiljer Warm Standby från Pilot Light är att applikationslagret faktiskt körs. Du kan ha minsta möjliga instansstorlekar i varje tier, med Auto Scaling-policies som tar miljön till full kapacitet vid behov. Route 53 health checks detekterar avbrottet och failover-routing aktiveras.

När det passar: De flesta medelstora till stora organisationer med kundnära system, e-handelsplattformar, SaaS-tjänster.

Multi-Site Active-Active

Båda regionerna hanterar trafik samtidigt. Det finns ingen "sekundär" region — båda är primära. Vid avbrott i en region absorberar den andra all trafik.

RTO: Sekunder (i princip noll märkbar nedtid för slutanvändaren)

RPO: Noll (med synkron replikering) eller nära noll (med asynkron)

Kostnad: Hög — du kör i princip dubbel infrastruktur

Detta kräver applikationer som är designade för multi-region från grunden: globala DynamoDB-tabeller, Aurora Global Database, Route 53 med latency-based routing eller weighted routing. Datastyrning blir komplex — speciellt med GDPR-krav på dataresidency.

När det passar: Verksamhetskritiska globala tjänster där varje sekunds driftstopp har mätbar ekonomisk påverkan. Finanssektorn, stora SaaS-plattformar, hälso- och sjukvårdssystem.

Jämförelsetabell: AWS DR-strategier

AWS-tjänster som bygger DR-strategin

AWS Elastic Disaster Recovery (AWS DRS)

Efterföljaren till CloudEndure Disaster Recovery. Tjänsten erbjuder kontinuerlig block-level replikering av dina servrar till en staging-area i målregionen. Vid failover konverteras dessa till EC2-instanser.

Det som gör DRS värdefullt är att replikeringen sker på blocknivå, oberoende av operativsystem eller applikation. Du behöver inte redesigna din applikation — tjänsten replikerar allt som körs på instansen. RPO hamnar typiskt under 1 sekund.

Vi använder DRS frekvent för kunder som migrerar från on-premises och vill ha DR på plats redan under migrationsfasen. Molnmigrering

AWS Backup

Centraliserad backuptjänst med stöd för de flesta AWS-datatjänster. Backup Plans definierar scheman och retentionsperioder, och Backup Vault Lock ger WORM-funktionalitet (Write Once Read Many) för compliance-krav.

Cross-account och cross-region backup är kritiskt — om ett konto komprometteras (ransomware är en realitet, inte en hypotetisk risk) måste backuperna vara otillgängliga från det komprometterade kontot. AWS Organizations med Backup Policies ger den kontrollen.

Amazon Route 53

DNS-tjänsten som orkestrar failover. Health checks övervakar endpoints och triggar routing-ändringar. Failover-routing skickar trafik till den sekundära regionen när den primära inte svarar. TTL-inställningar avgör hur snabbt klienter byter — håll TTL låg (60 sekunder) för DR-domäner.

Amazon Aurora Global Database

För relationsdatabaser med krav på låg RPO och snabb failover. Replikering sker på storage-lagret med typisk latens under 1 sekund mellan regioner. Managed planned failover tar under 2 minuter; unplanned failover kräver manuell promotion men ger RPO under 1 sekund.

GDPR, NIS2 och DR-planering i Sverige

Disaster recovery är inte bara en teknisk fråga — det är en regulatorisk. NIS2-direktivet ställer explicita krav på affärskontinuitet och incidenthantering för organisationer inom väsentliga och viktiga sektorer. Integritetsskyddsmyndigheten (IMY) förväntar sig att personuppgiftsansvariga kan visa att de har tekniska och organisatoriska åtgärder för att säkerställa datatillgänglighet (GDPR artikel 32).

Praktiska implikationer:

• Dataresidency: DR-replikering bör ske inom EU/EES. Från eu-north-1 till eu-west-1 eller eu-central-1 — inte till us-east-1.
• Kryptering: Data i transit (TLS) och at rest (KMS med kundhanterade nycklar) är ett minimikrav.
• Dokumentation: Din DR-plan, testresultat och faktisk RTO/RPO bör dokumenteras som del av DPIA och vara tillgänglig vid tillsynsbesök.
• Incidentrapportering: NIS2 kräver initial rapportering inom 24 timmar. En fungerande DR-plan reducerar incidentens påverkan och förenklar rapporteringen.

Molnsäkerhet

Så bygger du en DR-plan som faktiskt fungerar

Steg 1: Klassificera dina arbetsbelastningar

Inte alla system behöver Multi-Site Active-Active. Kategorisera dina system i kritikalitetsnivåer:

• Tier 1 (mission-critical): Kundnära produktion, betalningsflöden → Warm Standby eller Active-Active
• Tier 2 (business-critical): Interna affärssystem, CRM → Pilot Light eller Warm Standby
• Tier 3 (operational): Dev/test, interna verktyg → Backup & Restore

Steg 2: Definiera RTO/RPO per tier

Arbeta med verksamheten, inte bara IT. Frågan "hur länge kan vi vara nere?" besvaras av affärssidan. IT:s uppgift är att leverera arkitekturen som möter kravet till rimlig kostnad.

Steg 3: Implementera med IaC

Hela DR-miljön bör vara definierad i Terraform eller CloudFormation. Om din DR-region inte kan provisioneras genom att köra terraform apply, är den inte tillförlitlig. Manuella steg är felpunkter under stress.

Steg 4: Automatisera testningen

AWS DRS har inbyggd drill-funktionalitet. Använd den. Schemalägg kvartalsvis testning som del av er change management-process. Dokumentera faktisk RTO/RPO vid varje test och jämför med SLA.

Steg 5: Integrera med övervaknings- och larmkedjan

DR-failover bör triggas av tydliga signaler i er övervakningsplattform — inte av att någon ringer en on-call-person som manuellt fattar beslut klockan 03:00. Route 53 health checks i kombination med CloudWatch Alarms och EventBridge-regler ger automatiserad failover-logik.

Managerade molntjänster

Kostnadsstyrning av DR-miljöer

DR-infrastruktur som inte är kostnadsoptimerad tenderar att bli första offret vid budgetnedskärningar — och då står du utan DR. Flexeras State of the Cloud-rapport har konsekvent visat att kostnadshantering är organisationers främsta molnutmaning, och DR-miljöer hamnar ofta i blindzonen.

Praktiska åtgärder:

• Right-sizing i Warm Standby: Kör minsta möjliga instanstyp och lita på Auto Scaling vid failover
• Reserved Instances / Savings Plans: Även DR-databaser som körs 24/7 bör omfattas av reservationsavtal
• S3 Lifecycle Policies: Flytta äldre backuper till S3 Glacier automatiskt
• Taggning: Tagga all DR-infrastruktur konsekvent så att FinOps-teamet kan spåra kostnaden

Cloud FinOps

Opsios perspektiv: Vad vi ser i produktion

I vår SOC/NOC i Karlstad hanterar vi DR-scenarion regelbundet — inte som simulering utan som verkliga händelser. Tre mönster återkommer:

1. Otestade DR-planer som misslyckas vid behov. Den vanligaste orsaken? IAM-roller och KMS-nyckelpolicies som inte replikerats korrekt till den sekundära regionen. Infrastrukturen finns, men behörigheterna saknas.

2. DNS-TTL som inte sänkts. Standardvärdet på Route 53 är 300 sekunder. Under ett verkligt avbrott betyder det att klienter fortsätter nå den döda regionen i upp till 5 minuter efter failover — vilket adderar direkt till RTO.

3. Databasinkonsistens vid asynkron replikering. Aurora Global Database ger sub-sekund RPO under normala förhållanden, men vid nätverkspartitionering kan replikeringslagget öka. Organisationer som inte övervakar ReplicaLag-metriken blir överraskade.

Managerad DevOps

Vanliga frågor

Vad är skillnaden mellan RTO och RPO?

RTO (Recovery Time Objective) anger hur lång tid det maximalt får ta att återställa en tjänst efter avbrott. RPO (Recovery Point Objective) anger hur mycket data du tolererar att förlora, mätt i tid. Ett RPO på 1 timme innebär att du accepterar att förlora upp till 1 timmes data. Tillsammans styr dessa mått hela DR-strategin.

Vilken AWS DR-strategi passar för medelstora svenska företag?

För de flesta medelstora företag ger Warm Standby bäst balans mellan kostnad och återställningstid. Du håller en nedskalad kopia av din miljö redo i en sekundär region och kan skala upp till full kapacitet inom minuter. Pilot Light fungerar om du tolererar 10–30 minuters RTO.

Kan vi uppfylla GDPR med DR-replikering till en annan AWS-region?

Ja, så länge den sekundära regionen ligger inom EU/EES. Replikering från eu-north-1 (Stockholm) till eu-west-1 (Irland) eller eu-central-1 (Frankfurt) håller data inom EU. Dokumentera dataöverföringen i din DPIA och säkerställ att kryptering i transit och at rest är aktiverad.

Hur ofta bör vi testa vår DR-plan?

Minst kvartalsvis — och alltid efter större infrastrukturändringar. Automatiserade DR-tester via AWS Elastic Disaster Recovery kan köras veckovis utan att påverka produktion. Vi rekommenderar att varje test dokumenteras med faktisk uppmätt RTO/RPO för att validera mot SLA.

Vad kostar AWS disaster recovery?

Kostnaden varierar enormt beroende på strategi. Backup & Restore kostar kanske några hundra kronor per månad i S3-lagring. Multi-Site Active-Active dubblerar i princip din infrastrukturkostnad. Warm Standby landar typiskt på 15–30 % av produktionsmiljöns kostnad. Rätt dimensionering via FinOps-analys är avgörande.

For hands-on delivery in India, see konsult consulting for enterprise.

For hands-on delivery in India, see drift for enterprise.