Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Opzioni di disaster recovery nel cloud

Le strategie di disaster recovery disponibili in AWS possono essere ampiamente suddivise in quattro approcci, che vanno dal basso costo e dalla bassa complessità dei backup a strategie più complesse che utilizzano più regioni attive. Le strategie attive/passive utilizzano un sito attivo (come una regione AWS) per ospitare il carico di lavoro e servire il traffico. Il sito passivo (ad esempio un'altra regione AWS) viene utilizzato per il ripristino. Il sito passivo non serve attivamente il traffico fino a quando non viene attivato un evento di failover.

È fondamentale valutare e testare regolarmente la strategia di disaster recovery in modo da poterla utilizzare con fiducia, se necessario. Usa AWS Resilience Hub per convalidare e monitorare continuamente la resilienza dei tuoi AWS carichi di lavoro, inclusa la probabilità di raggiungere gli obiettivi RTO e RPO.

Figura 6 - Strategie di disaster recovery

Per un evento di emergenza basato sull'interruzione o la perdita di un data center fisico per un carico di lavoro ben progettato e ad alta disponibilità, può essere necessario solo un approccio di backup e ripristino al disaster recovery. Se la definizione di emergenza non si limita all'interruzione o alla perdita di un data center fisico ma riguarda una regione o se si è soggetti a requisiti normativi che lo richiedono, è consigliabile prendere in considerazione Pilot Light, Warm Standby o Multi-Site Active/Active.

Quando scegli la tua strategia e le risorse AWS per implementarla, tieni presente che all'interno di AWS, di solito dividiamo i servizi in piano dati e piano di controllo. Il piano dati è responsabile della fornitura del servizio in tempo reale mentre i piani di controllo (control-plane) consentono di configurare l'ambiente. Per la massima resilienza, è necessario utilizzare solo le operazioni del piano dati come parte delle operazioni di failover. Questo perché i piani dati in genere hanno obiettivi di progettazione di disponibilità più elevati rispetto ai piani di controllo.

Backup e ripristino

Il backup e il ripristino sono un approccio adatto per mitigare la perdita o il danneggiamento dei dati. Questo approccio può essere utilizzato anche per mitigare un disastro regionale replicando i dati in altre regioni AWS o per mitigare la mancanza di ridondanza per i carichi di lavoro distribuiti in una singola zona di disponibilità. Oltre ai dati, è necessario ridistribuire l'infrastruttura, la configurazione e il codice dell'applicazione nella regione di ripristino. Per consentire una ridistribuzione rapida dell'infrastruttura senza errori, è consigliabile eseguire sempre la distribuzione utilizzando l'infrastruttura come codice (IaC) utilizzando servizi come o il. AWS CloudFormationAWS Cloud Development Kit (AWS CDK) Senza IaC, potrebbe essere complesso ripristinare i carichi di lavoro nella regione di ripristino, il che comporterà un aumento dei tempi di ripristino e probabilmente il superamento dell'RTO. Oltre ai dati utente, assicurati di eseguire anche il backup del codice e della configurazione, tra cui Amazon Machine Images (AMIs) che usi per creare EC2 istanze Amazon. Puoi utilizzarlo AWS CodePipelineper automatizzare la ridistribuzione del codice e della configurazione dell'applicazione.

Figura 7 - Architettura di backup e ripristino

Servizi AWS

I dati del carico di lavoro richiederanno una strategia di backup che venga eseguita periodicamente o sia continua. La frequenza con cui esegui il backup determinerà il punto di ripristino raggiungibile (che deve essere allineato per soddisfare l'RPO). Il backup dovrebbe inoltre offrire un modo per ripristinarlo al momento in cui è stato eseguito. Il backup con point-in-time ripristino è disponibile tramite i seguenti servizi e risorse:

Per Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3), puoi utilizzare Amazon S3 Cross-Region Replication (CRR) per copiare in modo asincrono oggetti su un bucket S3 nella regione DR in modo continuo, fornendo al contempo il controllo delle versioni per gli oggetti archiviati in modo da poter scegliere il punto di ripristino. La replica continua dei dati ha il vantaggio di essere il tempo più breve (quasi zero) per eseguire il backup dei dati, ma potrebbe non proteggere da eventi di emergenza come il danneggiamento dei dati o attacchi dolosi (come l'eliminazione non autorizzata dei dati) e dai point-in-time backup. La replica continua è trattata nella sezione AWS Services for Pilot Light.

AWS Backupfornisce una posizione centralizzata per configurare, pianificare e monitorare le funzionalità di backup di AWS per i seguenti servizi e risorse:

AWS Backup supporta la copia di backup tra regioni, ad esempio in una regione di disaster recovery.

Come strategia di disaster recovery aggiuntiva per i tuoi dati Amazon S3, abilita il controllo delle versioni degli oggetti S3. Il controllo delle versioni degli oggetti protegge i dati in S3 dalle conseguenze delle azioni di eliminazione o modifica conservando la versione originale prima dell'azione. Il controllo delle versioni degli oggetti può essere un'utile mitigazione per i disastri di tipo umano. Se utilizzi la replica S3 per eseguire il backup dei dati nella tua regione DR, per impostazione predefinita, quando un oggetto viene eliminato nel bucket di origine, Amazon S3 aggiunge un marker di eliminazione solo nel bucket di origine. Questo approccio protegge i dati nella regione DR da eliminazioni dannose nella regione di origine.

Oltre ai dati, è necessario eseguire il backup della configurazione e dell'infrastruttura necessarie per ridistribuire il carico di lavoro e raggiungere il Recovery Time Objective (RTO). AWS CloudFormationfornisce Infrastructure as Code (IaC) e ti consente di definire tutte le risorse AWS nel tuo carico di lavoro in modo da poterlo distribuire e ridistribuire in modo affidabile su più account AWS e regioni AWS. Puoi eseguire il backup EC2 delle istanze Amazon utilizzate dal tuo carico di lavoro come Amazon Machine Images ()AMIs. L'AMI viene creata da istantanee del volume root dell'istanza e di qualsiasi altro volume EBS collegato all'istanza. Puoi utilizzare questa AMI per avviare una versione ripristinata dell' EC2 istanza. Un AMI può essere copiato all'interno o tra le regioni. In alternativa, puoi utilizzare AWS Backupper copiare i backup tra account e in altre regioni AWS. La funzionalità di backup su più account aiuta a proteggere da eventi di emergenza che includono minacce interne o compromissione dell'account. AWS Backup aggiunge inoltre funzionalità aggiuntive per il EC2 backup: oltre ai singoli volumi EBS dell'istanza, AWS Backup archivia e tiene traccia dei seguenti metadati: tipo di istanza, cloud privato virtuale (VPC) configurato, gruppo di sicurezza, ruolo IAM, configurazione di monitoraggio e tag. Tuttavia, questi metadati aggiuntivi vengono utilizzati solo per il ripristino del EC2 backup nella stessa regione AWS.

Tutti i dati archiviati nella regione di disaster recovery come backup devono essere ripristinati al momento del failover. AWS Backup offre funzionalità di ripristino, ma attualmente non abilita il ripristino programmato o automatico. Puoi implementare il ripristino automatico nella regione DR utilizzando l'SDK AWS da APIs richiedere AWS Backup. Puoi impostarlo come un processo ricorrente regolarmente o attivare il ripristino ogni volta che viene completato un backup. La figura seguente mostra un esempio di ripristino automatico utilizzando Amazon Simple Notification Service (Amazon AWS LambdaSNS) e. L'implementazione di un ripristino periodico dei dati pianificato è una buona idea in quanto il ripristino dei dati dal backup è un'operazione del piano di controllo. Se questa operazione non fosse disponibile durante un disastro, avresti comunque a disposizione archivi dati utilizzabili creati da un backup recente.

Figura 8 - Ripristino e test dei backup

Pilot light

Con l'approccio pilot light, puoi replicare i dati da una regione all'altra e fornire una copia dell'infrastruttura di carico di lavoro principale. Le risorse necessarie per supportare la replica dei dati e il backup, come database e archiviazione di oggetti, sono sempre attive. Altri elementi, come i server delle applicazioni, vengono caricati con il codice e le configurazioni dell'applicazione, ma sono «disattivati» e vengono utilizzati solo durante i test o quando viene richiamato il failover del disaster recovery. Nel cloud, hai la flessibilità di eseguire il deprovisioning delle risorse quando non ne hai bisogno e il provisioning quando ne hai bisogno. Una procedura consigliata per «disattivarla» consiste nel non distribuire la risorsa e quindi creare la configurazione e le funzionalità necessarie per distribuirla («accenderla») quando necessario. A differenza dell'approccio di backup e ripristino, l'infrastruttura principale è sempre disponibile e si ha sempre la possibilità di fornire rapidamente un ambiente di produzione su vasta scala attivando e scalando i server delle applicazioni.

Figura 9 - Architettura dell'illuminazione pilota

Un approccio pilota leggero riduce al minimo i costi correnti del disaster recovery riducendo al minimo le risorse attive e semplifica il ripristino al momento del disastro perché i requisiti dell'infrastruttura di base sono tutti soddisfatti. Questa opzione di ripristino richiede la modifica dell'approccio di implementazione. È necessario apportare modifiche all'infrastruttura di base in ciascuna regione e implementare le modifiche del carico di lavoro (configurazione, codice) contemporaneamente in ciascuna regione. Questo passaggio può essere semplificato automatizzando le implementazioni e utilizzando l'infrastruttura come codice (IaC) per distribuire l'infrastruttura su più account e regioni (implementazione completa dell'infrastruttura nella regione principale e implementazione dell'infrastruttura ridimensionata/disattivata nelle regioni DR). Si consiglia di utilizzare un account diverso per regione per fornire il massimo livello di isolamento delle risorse e della sicurezza (nel caso in cui anche le credenziali compromesse rientrino nei piani di disaster recovery).

Con questo approccio, è inoltre necessario mitigare un problema di dati. La replica continua dei dati ti protegge da alcuni tipi di emergenza, ma potrebbe non proteggerti dal danneggiamento o dalla distruzione dei dati, a meno che la tua strategia non includa anche il controllo delle versioni dei dati archiviati o opzioni di ripristino. point-in-time È possibile eseguire il backup dei dati replicati nella regione di emergenza per creare point-in-time backup nella stessa regione.

Servizi AWS

Oltre a utilizzare i servizi AWS descritti nella sezione Backup and Restore per creare point-in-time backup, prendi in considerazione anche i seguenti servizi per la tua strategia pilota.

Per una fase pilota, la replica continua dei dati su database e archivi di dati attivi nella regione DR è l'approccio migliore per un RPO basso (se utilizzato in aggiunta ai point-in-time backup discussi in precedenza). AWS fornisce una replica dei dati continua, interregionale e asincrona utilizzando i seguenti servizi e risorse:

Con la replica continua, le versioni dei dati sono disponibili quasi immediatamente nella regione DR. I tempi di replica effettivi possono essere monitorati utilizzando funzionalità di servizio come S3 Replication Time Control (S3 RTC) per oggetti S3 e funzionalità di gestione dei database globali Amazon Aurora.

Quando si esegue il failover per eseguire il carico di lavoro di lettura/scrittura dalla regione di disaster recovery, è necessario promuovere una replica di lettura RDS per farla diventare l'istanza principale. Per le istanze DB diverse da Aurora, il completamento del processo richiede alcuni minuti e il riavvio fa parte del processo. Per la replica tra regioni (CRR) e il failover con RDS, l'utilizzo del database globale Amazon Aurora offre diversi vantaggi. Il database globale utilizza un'infrastruttura dedicata che lascia i database completamente disponibili per servire la tua applicazione e può replicarsi nella regione secondaria con una latenza tipica inferiore a un secondo (e all'interno di una regione AWS è molto inferiore a 100 millisecondi). Con il database globale di Amazon Aurora, se la tua regione principale subisce un peggioramento delle prestazioni o un'interruzione delle prestazioni, puoi promuovere una delle regioni secondarie affinché si assuma responsabilità di lettura/scrittura in meno di un minuto, anche in caso di interruzione totale a livello regionale. Puoi anche configurare Aurora per monitorare il tempo di ritardo dell'RPO di tutti i cluster secondari per assicurarti che almeno un cluster secondario rimanga all'interno della finestra RPO di destinazione.

È necessario implementare una versione ridotta dell'infrastruttura di carico di lavoro principale con un numero inferiore o inferiore di risorse nella regione DR. Utilizzando AWS CloudFormation, puoi definire la tua infrastruttura e distribuirla in modo coerente tra gli account AWS e tra le regioni AWS. AWS CloudFormation utilizza pseudo parametri predefiniti per identificare l'account AWS e la regione AWS in cui viene distribuito. Pertanto, puoi implementare la logica delle condizioni nei tuoi CloudFormation modelli per distribuire solo la versione ridotta dell'infrastruttura nella regione DR. Ad EC2 esempio, le implementazioni, un'Amazon Machine Image (AMI) fornisce informazioni come la configurazione hardware e il software installato. È possibile implementare una pipeline Image Builder che crei ciò di cui AMIs si ha bisogno e copiarla sia nella regione principale che in quella di backup. Questo aiuta a garantire che queste Golden AMIs abbiano tutto il necessario per ridistribuire o scalare il carico di lavoro in una nuova regione, in caso di emergenza. Le EC2 istanze Amazon vengono distribuite in una configurazione ridotta (meno istanze rispetto alla regione principale). Per scalare l'infrastruttura in modo da supportare il traffico di produzione, consulta Amazon Auto EC2 Scaling nella sezione Warm Standby.

Per una configurazione attiva/passiva come Pilot Light, tutto il traffico viene inizialmente indirizzato alla regione principale e passa alla regione di disaster recovery se la regione primaria non è più disponibile. Questa operazione di failover può essere avviata automaticamente o manualmente. Il failover avviato automaticamente sulla base di controlli o allarmi di stato deve essere usato con cautela. Anche utilizzando le migliori pratiche illustrate qui, i tempi di ripristino e il punto di ripristino saranno superiori a zero, con una certa perdita di disponibilità e di dati. Se si esegue il failover quando non è necessario (falso allarme), si subiscono tali perdite. Pertanto si usa spesso il failover avviato manualmente. In questo caso, devi comunque automatizzare i passaggi del failover, in modo che l'avvio manuale si limiti al clic su un pulsante.

Esistono diverse opzioni di gestione del traffico da considerare quando si utilizzano AWS i servizi.

Tra le opzioni, vi è l'utilizzo di Amazon Route 53. Utilizzando Amazon Route 53, puoi associare più endpoint IP in una o più regioni AWS a un nome di dominio Route 53. Quindi, puoi indirizzare il traffico verso l'endpoint appropriato con quel nome di dominio. In caso di failover, è necessario spostare il traffico verso l'endpoint di ripristino e allontanarlo dall'endpoint principale. I controlli di integrità di Amazon Route 53 monitorano questi endpoint. Utilizzando questi controlli di integrità, puoi configurare il failover DNS avviato automaticamente per garantire che il traffico venga inviato solo a endpoint integri, un'operazione altamente affidabile eseguita sul piano dati. Per implementarlo utilizzando il failover avviato manualmente, puoi utilizzare Amazon Application Recovery Controller (ARC). Con ARC, puoi creare controlli di integrità di Route 53 che in realtà non controllano lo stato, ma agiscono invece come interruttori di accensione/spegnimento su cui hai il pieno controllo. Utilizzando l'AWS CLI o l'SDK AWS, puoi eseguire il failover degli script utilizzando questa API del piano dati ad alta disponibilità. Lo script attiva questi switch (i controlli di integrità della Route 53) dicendo a Route 53 di inviare il traffico alla regione di ripristino anziché alla regione principale. Un'altra opzione per il failover avviato manualmente, che alcuni hanno utilizzato, consiste nell'utilizzare una politica di routing ponderata e modificare il peso delle regioni primarie e di ripristino in modo che tutto il traffico venga indirizzato alla regione di ripristino. Tuttavia, tieni presente che si tratta di un'operazione sul piano di controllo e quindi non così resiliente come l'approccio al piano dati che utilizza Amazon Application Recovery Controller (ARC).

Un'altra opzione è quella di utilizzare AWS Global Accelerator. Utilizzando l' AnyCast IP, puoi associare più endpoint in una o più regioni AWS allo stesso indirizzo o agli stessi indirizzi IP pubblici statici. AWS Global Accelerator quindi indirizza il traffico verso l'endpoint appropriato associato a quell'indirizzo. I controlli dello stato di Global Accelerator monitorano gli endpoint. Utilizzando questi controlli di integrità, AWS Global Accelerator verifica lo stato delle applicazioni e indirizza automaticamente il traffico degli utenti verso l'endpoint dell'applicazione integro. Per il failover avviato manualmente, è possibile regolare l'endpoint che riceve il traffico utilizzando le ghiere di controllo, ma tenete presente che si tratta di un'operazione del piano di controllo. Global Accelerator offre latenze inferiori all'endpoint dell'applicazione poiché utilizza l'estesa rete edge di AWS per indirizzare il traffico sulla dorsale della rete AWS il prima possibile. Global Accelerator evita inoltre i problemi di memorizzazione nella cache che possono verificarsi con i sistemi DNS (come Route 53).

Amazon CloudFront offre il failover di origine, in base al quale, se una determinata richiesta all'endpoint primario fallisce, CloudFront indirizza la richiesta all'endpoint secondario. A differenza delle operazioni di failover descritte in precedenza, tutte le richieste successive vanno comunque all'endpoint primario e il failover viene eseguito per ogni richiesta.

AWS Disaster Recovery elastico

AWS Elastic Disaster Recovery (DRS) replica continuamente le applicazioni e i database ospitati sul server da qualsiasi origine AWS utilizzando la replica a livello di blocco del server sottostante. Elastic Disaster Recovery consente di utilizzare una regione Cloud AWS come obiettivo di disaster recovery per un carico di lavoro ospitato in locale o su un altro provider di servizi cloud e il relativo ambiente. Può essere utilizzato anche per il disaster recovery dei carichi di lavoro AWS ospitati se sono costituiti solo da applicazioni e database ospitati su EC2 (ovvero non su RDS). Elastic Disaster Recovery utilizza la strategia Pilot Light, mantenendo una copia dei dati e delle risorse «disattivate» in un Amazon Virtual Private Cloud (Amazon VPC) utilizzato come area di staging. Quando viene attivato un evento di failover, le risorse in fasi vengono utilizzate per creare automaticamente una distribuzione a piena capacità nell'Amazon VPC di destinazione utilizzato come posizione di ripristino.

Figura 10 - Architettura AWS elastica di disaster recovery

Warm standby

L'approccio warm standby implica la verifica della presenza di una copia ridotta verticalmente, ma comunque funzionale, dell'ambiente di produzione in un'altra regione. Questo approccio estende il concetto di Pilot Light e diminuisce il tempo di ripristino, poiché il carico di lavoro è sempre attivo in un'altra regione. Questo approccio consente inoltre di eseguire più facilmente i test o di implementare test continui per aumentare la fiducia nella capacità di ripristino in caso di emergenza.

Figura 11 - Architettura Warm Standby

Nota: la differenza tra luce pilota e standby caldo a volte può essere difficile da capire. Entrambi includono un ambiente nella regione DR con copie delle risorse principali della regione. La differenza è che Pilot Light non può elaborare le richieste senza prima intraprendere un'azione aggiuntiva, mentre lo standby caldo può gestire immediatamente il traffico (a livelli di capacità ridotti). L'approccio pilot light richiede di «accendere» i server, possibilmente implementare un'infrastruttura aggiuntiva (non core) e scalare, mentre lo standby caldo richiede solo la scalabilità (tutto è già installato e funzionante). Utilizzate le vostre esigenze RTO e RPO per aiutarvi a scegliere tra questi approcci.

Servizi AWS

Tutti i servizi AWS coperti da backup e ripristino e pilot light vengono utilizzati anche in modalità warm standby per il backup dei dati, la replica dei dati, il routing del traffico attivo/passivo e l'implementazione dell'infrastruttura, comprese le istanze. EC2

Amazon EC2 Auto Scaling viene utilizzato per scalare risorse tra cui EC2 istanze Amazon, attività Amazon ECS, throughput di Amazon DynamoDB e repliche Amazon Aurora all'interno di una regione AWS. Amazon EC2 Auto Scaling ridimensiona la distribuzione dell' EC2 istanza tra zone di disponibilità all'interno di una regione AWS, fornendo resilienza all'interno di tale regione. Utilizzate Auto Scaling per estendere la vostra regione DR alla piena capacità di produzione, come parte di strategie pilota di standby a luce o a caldo. Ad esempio, per EC2, aumentare l'impostazione di capacità desiderata nel gruppo Auto Scaling. Puoi modificare questa impostazione manualmente tramite AWS Management Console, automaticamente tramite l'SDK AWS o ridistribuendo il AWS CloudFormation modello utilizzando il nuovo valore di capacità desiderato. Puoi utilizzare AWS CloudFormation i parametri per semplificare la ridistribuzione del modello. CloudFormation Assicuratevi che le quote di servizio nella vostra regione DR siano sufficientemente alte da non limitare la scalabilità fino alla capacità di produzione.

Poiché l'Auto Scaling è un'attività del piano di controllo, dipendere da essa ridurrà la resilienza della strategia di ripristino complessiva. È un compromesso. È possibile scegliere di fornire una capacità sufficiente in modo che la regione di ripristino sia in grado di gestire l'intero carico di produzione man mano che viene distribuito. Questa configurazione staticamente stabile è denominata hot standby (vedere la sezione successiva). Oppure puoi scegliere di fornire meno risorse, il che costerà meno, ma affidandoti all'Auto Scaling. Alcune implementazioni di DR impiegheranno risorse sufficienti per gestire il traffico iniziale, garantendo un RTO basso, e quindi si affideranno all'Auto Scaling per aumentare il traffico successivo.

Attivo/attivo multi-sito

È possibile eseguire il carico di lavoro contemporaneamente in più regioni come parte di una strategia attiva/passiva multisito o attiva/passiva in standby a caldo. Multisito. active/active serves traffic from all regions to which it is deployed, whereas hot standby serves traffic only from a single region, and the other Region(s) are only used for disaster recovery. With a multi-site active/active approach, users are able to access your workload in any of the Regions in which it is deployed. This approach is the most complex and costly approach to disaster recovery, but it can reduce your recovery time to near zero for most disasters with the correct technology choices and implementation (however data corruption may need to rely on backups, which usually results in a non-zero recovery point). Hot standby uses an active/passive configuration where users are only directed to a single region and DR regions do not take traffic. Most customers find that if they are going to stand up a full environment in the second Region, it makes sense to use it active/active In alternativa, se non desideri utilizzare entrambe le regioni per gestire il traffico degli utenti, Warm Standby offre un approccio più economico e meno complesso dal punto di vista operativo.

Figura 12 - Architettura attiva/attiva multisito (modifica di un percorso attivo in Inattivo per hot standby)

Con un approccio multisito active/active, because the workload is running in more than one Region, there is no such thing as failover in this scenario. Disaster recovery testing in this case would focus on how the workload reacts to loss of a Region: Is traffic routed away from the failed Region? Can the other Region(s) handle all the traffic? Testing for a data disaster is also required. Backup and recovery are still required and should be tested regularly. It should also be noted that recovery times for a data disaster involving data corruption, deletion, or obfuscation will always be greater than zero and the recovery point will always be at some point before the disaster was discovered. If the additional complexity and cost of a multi-site active/active (o hot standby) è necessario mantenere tempi di ripristino vicini allo zero, quindi è necessario compiere ulteriori sforzi per mantenere la sicurezza e prevenire gli errori umani per mitigare i disastri umani.

Servizi AWS

Tutti i servizi AWS coperti da backup e ripristino, pilot light e warm standby vengono utilizzati anche qui per il backup point-in-time dei dati, la replica dei dati, il routing del traffico attivo/attivo e l'implementazione e la scalabilità dell'infrastruttura, comprese le istanze. EC2

Per gli scenari attivi/passivi discussi in precedenza (Pilot Light e Warm Standby), è AWS Global Accelerator possibile utilizzare sia Amazon Route 53 che per instradare il traffico di rete verso la regione attiva. Per quanto riguarda la strategia attiva/attiva in questo caso, entrambi questi servizi consentono anche la definizione di politiche che determinano quali utenti accedono a quale endpoint regionale attivo. Con AWS Global Accelerator you è possibile impostare una ghiera di controllo del traffico per controllare la percentuale di traffico indirizzata a ciascun endpoint dell'applicazione. Amazon Route 53 supporta questo approccio percentuale e anche molte altre policy disponibili, tra cui quelle basate sulla geoprossimità e sulla latenza. Global Accelerator sfrutta automaticamente l'ampia rete di server edge AWS per effettuare l'onboard del traffico verso la dorsale della rete AWS il prima possibile, con conseguente riduzione delle latenze di richiesta.

La replica asincrona dei dati con questa strategia consente un RPO vicino allo zero. I servizi AWS come il database globale di Amazon Aurora utilizzano un'infrastruttura dedicata che lascia i database completamente disponibili per servire la tua applicazione e possono essere replicati in un massimo di cinque regioni secondarie con una latenza tipica inferiore a un secondo. Sta progettando active/passive strategies, writes occur only to the primary Region. The difference with active/active il modo in cui viene gestita la coerenza dei dati con le scritture su ciascuna regione attiva. È comune progettare le letture degli utenti in modo che vengano servite dalla regione a loro più vicina, nota come read local. Con le scritture, hai diverse opzioni:

AWS CloudFormation è uno strumento potente per applicare un'infrastruttura distribuita in modo coerente tra gli account AWS in più regioni AWS. AWS CloudFormation StackSetsestende questa funzionalità consentendoti di creare, aggiornare o eliminare CloudFormation stack su più account e regioni con un'unica operazione. Sebbene AWS CloudFormation utilizzi YAML o JSON per definire l'infrastruttura come codice, AWS Cloud Development Kit (AWS CDK)consente di definire l'infrastruttura come codice utilizzando linguaggi di programmazione familiari. Il codice viene convertito in CloudFormation cui viene poi utilizzato per distribuire risorse in AWS.