Pilot Light och varm reservmiljö

När den primära regionen slutar fungera och failover med Pilot Light utlöses: Steg 1 — Befordra RDS Read Replica i DR-regionen till en fristående primär databas. Steg 2 — Starta EC2-instanser från den förbyggda AMI:n eller startmallen. Steg 3 — Skapa eller aktivera Application Load Balancer och registrera de nya EC2-instanserna. Steg 4 — Uppdatera applikationskonfigurationen så att den pekar på den befordrade databasens slutpunkt. Steg 5 — Route 53:s failover med hälsokontroll slutför DNS-omkopplingen. Total tid: 30–60 minuter.

Med strategin Warm Standby körs en komplett men nedskalad version av produktionsmiljön kontinuerligt i DR-regionen. Alla applikationsskikt är aktiva — webbservrar, applikationsservrar och databas — men med minskad kapacitet (till exempel 2 instanser i stället för 20). Under failover skalar du upp DR-miljön så att den motsvarar produktionsbelastningen. Route 53 växlar automatiskt över trafiken genom failover med hälsokontroll. RTO:n är vanligtvis under 15 minuter. Warm Standby är den mest populära DR-nivån för affärskritiska applikationer.

Aurora Global Database är den idealiska databastekniken för DR med Warm Standby. Klustret i den sekundära regionen körs alltid, tar alltid emot replikering (fördröjning på <1 sekund) och kan befordras till primärt på under 1 minut — betydligt snabbare än att befordra en RDS Read Replica (vilket kräver att replikeringen stoppas och att den återstående fördröjningen tillämpas). Därför rekommenderas Aurora Global Database när ditt RTO-krav ligger på minuter snarare än tiotals minuter.

Både Pilot Light och Warm Standby förlitar sig på failover-routing i Route 53 för att automatiskt omdirigera trafik. Konfigurera en Primary-post som pekar på ALB:n eller slutpunkten i produktionsregionen och koppla en hälsokontroll till den. Konfigurera en Secondary-post som pekar på slutpunkten i DR-regionen. När Route 53 upptäcker att den primära hälsokontrollen har misslyckats under den konfigurerade tröskelperioden slutar tjänsten att returnera den primära posten och tillhandahåller endast den sekundära posten — allt inom DNS TTL-perioden.

För att Warm Standby ska nå sitt RTO-mål måste DR-miljön vara förvärmd — fullständigt konfigurerad och testad, så att uppskalning under failover är den enda åtgärd som krävs. Det innebär att databasanslutningar är etablerade och cachade, att applikationens konfigurationsfiler hänvisar till slutpunkter i DR-regionen, att EC2-instanser körs bakom ALB:n (även om de är få) och att hälsokontrollerna fungerar. Genomför månatliga DR-övningar där du simulerar failover för att säkerställa att miljön hålls aktuell med produktionskonfigurationen.

Den största operativa utmaningen är att hålla DR-miljön synkroniserad med produktionen. Om du konfigurerar produktionen manuellt och glömmer att uppdatera DR kanske DR-miljön inte fungerar korrekt under en verklig katastrof. Lösningen är Infrastructure as Code (IaC) med samma mallar distribuerade till båda regionerna. Använd AWS CloudFormation StackSets eller Terraform with multiple workspaces för att distribuera identisk infrastruktur till båda regionerna från en enda kodbas. Detta eliminerar konfigurationsdrift.

Kostnadsskillnaden mellan de två strategierna är betydande. Pilot Light kostar endast för databasreplikan (vanligtvis 50–100 % av kostnaden för den primära databasen) samt minimal nätverksinfrastruktur i DR-regionen. Applikationsservrarna är avstängda, så inga EC2-kostnader tillkommer. Warm Standby medför kostnader för nedskalade EC2-instanser, en ALB och eventuellt ett mindre cachekluster — vanligtvis 15–30 % av kostnaden för hela produktionsmiljön. Frågan är om den snabbare RTO:n med Warm Standby motiverar den högre löpande kostnaden.

När primärregionen har återställts behöver ni en plan för failback så att ni kan återgå till den. Failback är ofta den mest komplicerade delen av DR: under avbrottet kan DR-regionen ha behandlat nya data som måste synkroniseras tillbaka till primärregionen. För databaser kan ni behöva konfigurera omvänd replikering eller synkronisera om från DR till primärregionen. För Route 53 återställer ni den primära posten med dess hälsokontroll. Planera och testa alltid er failback-procedur lika noggrant som själva failover-proceduren.

Välj Pilot Light när: ert RTO tillåter 30–60 minuter och ni vill minimera DR-kostnaderna. Den största risken är tiden som krävs för att starta och konfigurera applikationsservrar under press vid en katastrof. Välj Warm Standby när: ert RTO kräver återställning inom 15 minuter, applikationen är tillräckligt komplex för att det ska vara riskabelt att starta den från grunden under en katastrof, eller ert SLA-åtagande gentemot kunderna kräver snabbare återställning. För de flesta produktionsarbetsbelastningar med medelhög kritikalitet är Warm Standby den bästa avvägningen.

I den här lektionen lärde ni er att Pilot Light endast håller databasen igång i DR och startar applikationsservrar under failover, att Warm Standby kör en komplett, nedskalad miljö som skalas upp under failover och att Infrastructure as Code förhindrar konfigurationsdrift mellan primära miljöer och DR-miljöer. Planera och testa alltid failback-procedurer såväl som failover-procedurer. Härnäst utforskar vi multi-site active-active med DynamoDB Global Tables och Route 53.