Failover e routing basato sulla geolocalizzazione

L'instradamento Failover implementa una configurazione active-passive: un record viene designato come Primary e un altro come Secondary. Route 53 restituisce sempre il record Primary finché il relativo controllo di integrità ha esito positivo. Se Primary diventa non integro, Route 53 passa automaticamente a restituire il record Secondary.

L'instradamento Failover è il modello di riferimento per gli scenari di disaster recovery in cui si dispone di un ambiente di produzione (primary) e di un ambiente standby (secondary), che deve ricevere traffico solo quando il primary è inattivo.

Per configurare l'instradamento Failover, crei due record con lo stesso nome DNS: uno con Failover=PRIMARY e uno con Failover=SECONDARY. Colleghi un controllo di integrità al record Primary. Anche il record Secondary dovrebbe avere un controllo di integrità se punta a una risorsa che potrebbe avere un guasto indipendente.

Il record Secondary funge da fallback statico: può puntare a un sito web statico S3, a una pagina di manutenzione o a un ambiente standby ridimensionato. Anche se Secondary non dispone di un controllo di integrità, Route 53 vi esegue sempre il fallback quando Primary ha un guasto.

L'instradamento Failover crea una configurazione active-passive: durante il normale funzionamento, solo Primary serve il traffico; Secondary rimane inattivo in attesa di subentrare. Questo riduce al minimo il costo dello standby, ma comporta un tempo di ripristino leggermente più lungo, dovuto al tempo necessario per la scadenza del TTL DNS e al passaggio di Route 53.

Per le configurazioni active-active, in cui entrambe le risorse servono il traffico contemporaneamente, utilizzi l'instradamento Weighted con pesi uguali oppure l'instradamento Latency. Se una risorsa ha un guasto, il relativo controllo di integrità ha esito negativo e Route 53 la rimuove automaticamente dalle risposte DNS, ottenendo una configurazione active-active con failover integrato.

L'instradamento Geolocation instrada le query DNS in base alla posizione geografica del resolver DNS, in genere il resolver dell'ISP dell'utente o il Route 53 Resolver di AWS. Può creare record per continenti, Paesi o Stati degli Stati Uniti specifici; Route 53 restituisce il record la cui posizione corrisponde in modo più specifico all'origine della query.

Se nessun record relativo a una posizione specifica corrisponde, Route 53 restituisce un record predefinito, se configurato. In assenza di un record predefinito, le query provenienti da posizioni non corrispondenti ricevono NODATA. Crei sempre un record predefinito per gestire gli utenti provenienti da posizioni non configurate esplicitamente.

Principali casi d'uso dell'instradamento Geolocation:

• Contenuti specifici per lingua: instradi gli utenti francofoni verso un'origine CDN in lingua francese e quelli germanofoni verso un'origine tedesca
• Conformità normativa: garantisca che i dati degli utenti dell'UE rimangano nelle Regioni dell'UE (GDPR) oppure blocchi l'accesso da Paesi specifici
• Prezzi o disponibilità localizzati: mostri prezzi specifici per Regione oppure limiti i servizi ai territori supportati
• Geo-blocking: restituisca una pagina di blocco o una risposta vuota agli utenti provenienti da posizioni soggette a restrizioni, facendo puntare il relativo record geolocation a un endpoint di manutenzione

Route 53 usa la geolocalizzazione più specifica: un record a livello di Stato ha la precedenza su un record a livello di Paese, che ha la precedenza su un record a livello di continente, che a sua volta ha la precedenza sul record predefinito. La geolocalizzazione a livello di Stato è disponibile solo per gli Stati Uniti.

Se omette un record predefinito e la posizione di un utente non corrisponde ad alcun record configurato, Route 53 restituisce NXDOMAIN o NODATA: l'accesso degli utenti nelle Regioni non configurate viene così interrotto senza segnalarlo esplicitamente. Aggiunga sempre un record geolocation predefinito come regola generale per evitare errori silenziosi.

L'instradamento Geoproximity instrada il traffico in base alla distanza geografica fisica tra utenti e risorse, con un bias opzionale per ampliare o ridurre il raggio effettivo di instradamento di ciascuna risorsa. Un bias positivo amplia l'area geografica servita da una risorsa; un bias negativo la riduce.

Geoproximity è disponibile solo tramite Traffic Flow, l'editor visivo delle policy di instradamento di Route 53, e supporta sia le Regioni AWS, di cui Route 53 conosce automaticamente le coordinate, sia le posizioni delle risorse personalizzate, per le quali è necessario fornire latitudine e longitudine.

Route 53 Traffic Flow è un editor visivo delle policy che consente di creare logiche di instradamento complesse combinando più policy in un diagramma ad albero. Ad esempio, può applicare prima Geolocation per separare il traffico dell'UE, poi Latency all'interno dell'UE per scegliere la Regione con le migliori prestazioni e infine l'instradamento Weighted all'interno di ogni Regione per i deployment blue-green.

Le policy Traffic Flow sono versionate, consentendo di testare le modifiche in sicurezza. Può associare una policy Traffic Flow a uno o più nomi DNS; gli aggiornamenti alla policy vengono propagati immediatamente senza ricreare i singoli record.

L'instradamento Failover può essere annidato all'interno di altre policy. Un modello comune consiste nell'utilizzare Latency per scegliere la Regione più vicina, ma nell'usare all'interno di ogni Regione un record Failover, in modo che, se l'endpoint primario di quella Regione ha un guasto, il traffico passi automaticamente a un endpoint secondario nella stessa Regione.

Un altro modello è l'active-passive multi-Regione, che utilizza Latency per l'endpoint primario. Se il controllo di integrità della Regione primaria ha esito negativo, Route 53 passa alla Regione integra successiva con la latenza più bassa, combinando di fatto l'ottimizzazione della latenza con il failover DR.

Affinché l'instradamento Failover funzioni correttamente, al record Primary deve** essere associato un controllo di integrità. In assenza di un controllo di integrità, Route 53 considera Primary sempre integro e non passa mai a Secondary. Il record Secondary può facoltativamente avere un proprio controllo di integrità; se anche Secondary ha un guasto, Route 53 restituisce comunque il suo indirizzo, poiché rappresenta l'ultima risorsa.

Tipi di controllo di integrità utilizzabili con Failover: controlli di endpoint HTTP/HTTPS, controlli TCP e controlli basati su allarmi CloudWatch, utili per segnali compositi sullo stato dell'applicazione che combinano più metriche.

Questa distinzione ricorre spesso nell'esame SAA-C03:

• Geolocation: instrada in base a dove si trova geograficamente l'utente; restituisce sempre lo stesso endpoint per un determinato Paese o continente, indipendentemente dalle prestazioni; viene utilizzato per la localizzazione dei contenuti e la conformità
• Latency: instrada in base alle prestazioni della rete verso l'utente; può instradare un utente in Europa verso us-east-1 se in quel momento è più veloce di eu-west-1; viene utilizzato per ottimizzare le prestazioni

Parole chiave nelle domande d'esame: 'conformità ai requisiti di residenza dei dati', 'contenuti specifici per Paese', 'bloccare gli utenti di determinate Regioni' → Geolocation. 'Regione più vicina', 'latenza più bassa', 'prestazioni migliori per utenti globali' → Latency.

Verifichi la propria comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che: il routing di failover crea un'HA active-passive passando al Secondary quando il controllo dello stato del Primary non va a buon fine, il routing basato sulla geolocalizzazione indirizza gli utenti in base alla loro origine geografica per garantire la conformità e la localizzazione, mentre il routing basato sulla geoproximity utilizza la distanza fisica con un bias configurabile tramite Traffic Flow. Aggiunga sempre un record di geolocalizzazione predefinito per gestire le posizioni non corrispondenti. Prossimamente analizzeremo in dettaglio i controlli dello stato e il failover DNS.