Health check e failover DNS

I controlli dello stato di Route 53 monitorano continuamente lo stato dei vostri endpoint, ad esempio server web, load balancer o qualsiasi endpoint HTTP/HTTPS/TCP accessibile tramite Internet. In base ai risultati dei controlli dello stato, Route 53 può aggiornare automaticamente il routing DNS per evitare di inviare traffico a risorse non integre.

I controlli dello stato vengono fatturati per controllo al mese. I controllori globali dello stato di Route 53, situati in più Regioni, verificano contemporaneamente il vostro endpoint, fornendo ridondanza anche per il controllo dello stato stesso. Un endpoint viene considerato non integro solo quando un numero soglia di controllori concorda sul fatto che abbia avuto un errore.

I controlli dello stato degli endpoint monitorano uno specifico indirizzo IP o nome di dominio utilizzando il protocollo scelto (HTTP, HTTPS o TCP), la porta e, facoltativamente, un percorso. Per i controlli HTTP/HTTPS, Route 53 verifica che l'endpoint restituisca un codice di stato HTTP 2xx o 3xx entro il periodo di timeout. Per i controlli HTTPS, può anche convalidare facoltativamente il certificato TLS.

Opzioni di configurazione principali: intervallo delle richieste (10 o 30 secondi: 10 secondi consentono un rilevamento più rapido, ma hanno un costo maggiore), soglia di errore (da 1 a 10 errori consecutivi prima di contrassegnare l'endpoint come non integro) e corrispondenza di stringhe (verifica facoltativa che il corpo della risposta contenga una stringa specifica).

I controlli dello stato calcolati combinano i risultati di più controlli dello stato secondari utilizzando la logica booleana (AND, OR, NOT). Consentono di definire lo stato dell'applicazione in base a più segnali senza creare catene di routing complesse.

Esempio: un'applicazione web è integra solo se superano il controllo sia il server API SIA il database. Crei un controllo dello stato calcolato con tipo AND che faccia riferimento a entrambi i controlli degli endpoint. Se uno dei due ha esito negativo, il controllo dello stato calcolato fallisce e Route 53 rimuove il record DNS associato dalle risposte.

I controlli dello stato basati sugli allarmi CloudWatch collegano un controllo dello stato di Route 53 allo stato di un allarme CloudWatch. Se l'allarme è nello stato ALARM, il controllo dello stato viene contrassegnato come non integro; se è nello stato OK o INSUFFICIENT_DATA, viene contrassegnato come integro.

Questo approccio è particolarmente utile per gli endpoint all'interno di un VPC, che non possono essere raggiunti dai controllori esterni dello stato di Route 53. Invece di verificare direttamente l'endpoint privato, crei metriche e allarmi CloudWatch per tale endpoint, quindi basi il controllo dello stato di Route 53 sullo stato dell'allarme. Questo consente anche di eseguire controlli dello stato basati su metriche aziendali, come il tasso di errore o la profondità della coda.

I controllori dello stato di Route 53 sono server gestiti da AWS situati all'esterno del vostro VPC, che raggiungono gli endpoint tramite Internet pubblico. Le risorse nelle sottoreti private non sono raggiungibili dai controlli standard dello stato degli endpoint. Per gli endpoint privati, utilizzi uno dei seguenti approcci:

• Pubblicare una metrica CloudWatch personalizzata dall'interno del VPC (ad esempio, un segnale di esito positivo/negativo proveniente dall'applicazione), creare un allarme e utilizzare un controllo dello stato basato su un allarme CloudWatch
• Utilizzare un allarme composito CloudWatch che aggreghi metriche di ELB, RDS o dell'applicazione all'interno del VPC

Questo approccio è fondamentale per database in sottoreti private, load balancer interni e servizi backend.

Può visualizzare lo stato dei controlli nella console di Route 53, alla voce Health Checks, oppure interrogarlo tramite l'API. Route 53 pubblica le metriche dei controlli dello stato in CloudWatch nello spazio dei nomi AWS/Route53, tra cui HealthCheckStatus (1 = integro, 0 = non integro) e HealthCheckPercentageHealthy (percentuale di controllori di Route 53 che segnalano l'endpoint come integro).

Configuri gli allarmi CloudWatch su HealthCheckStatus per ricevere notifiche SNS quando un endpoint diventa non integro, così da avere visibilità del problema prima che il team di reperibilità si accorga che il failover DNS è già avvenuto.

Quando Route 53 rileva che il controllo dello stato di un record Primary ha avuto esito negativo, rimuove il Primary dalle risposte DNS e restituisce l'indirizzo del Secondary. Questo processo è chiamato failover DNS. Il passaggio avviene entro il periodo di valutazione (numero di errori dei controllori dello stato × intervallo delle richieste), a cui si aggiunge il TTL del record.

Esempio: intervallo delle richieste = 30 s, soglia di errore = 3, TTL = 60 s. Il tempo massimo di failover è circa 3 × 30 + 60 = 150 secondi. Impostando un TTL inferiore (ad esempio 10 secondi) e un intervallo di controllo dello stato più rapido (10 s), è possibile ridurlo a 3 × 10 + 10 = 40 secondi.

I controlli dello stato possono essere associati anche ai record Weighted e Latency, non solo ai record Failover. Quando il controllo dello stato di un record Weighted ha esito negativo, Route 53 ridistribuisce proporzionalmente il peso del traffico di quel record tra i record Weighted integri. Quando il controllo dello stato di un record Latency ha esito negativo, Route 53 indirizza le query al record integro con la latenza immediatamente successiva più bassa.

In questo modo, le policy di routing Weighted e Latency diventano resilienti agli errori degli endpoint senza richiedere record Failover espliciti. Si tratta di un pattern comune per SAA-C03: il routing Latency tra Regioni, combinato con i controlli dello stato, offre sia l'ottimizzazione delle prestazioni sia il disaster recovery automatico.

Un pattern active-active multi-Regione resiliente che utilizza Route 53:

1. Crei record Latency per ogni Regione (us-east-1, eu-west-1, ap-southeast-1), ciascuno con un controllo dello stato
2. Quando tutte le Regioni sono integre, gli utenti vengono indirizzati alla Regione con la latenza più bassa
3. Se il controllo dello stato di una Regione ha esito negativo (applicazione non funzionante o non reattiva), Route 53 la rimuove automaticamente dalle risposte DNS e indirizza le query alla migliore Regione integra successiva
4. Quando la Regione con problemi torna operativa, il controllo dello stato ha esito positivo e Route 53 la reinserisce nella rotazione

Questo garantisce un failover globale automatico con ottimizzazione delle prestazioni, senza richiedere interventi manuali.

I controllori dello stato di Route 53 hanno origine da un insieme di intervalli IP pubblicati nella sezione ROUTE53_HEALTHCHECKS del file JSON degli intervalli IP di AWS. Se il vostro endpoint è protetto da un firewall o da un security group che limita l'accesso in ingresso, dovete consentire il traffico proveniente da questi intervalli IP affinché i controlli dello stato vadano a buon fine.

In alternativa, utilizzate un endpoint con accesso pubblico che faccia da proxy verso il backend privato (ad esempio un ALB) per eseguire i controlli dello stato. Il security group dell'ALB deve consentire solo gli intervalli IP di Route 53, mentre il security group del backend deve consentire solo il security group dell'ALB, mantenendo un approccio di difesa in profondità.

Best practice per i controlli dello stato di Route 53:

• Crei un endpoint /health dedicato che verifichi tutte le dipendenze critiche (connettività al database, raggiungibilità della cache) e restituisca 200 solo quando il sistema è completamente operativo
• Utilizzi un intervallo delle richieste di 10 secondi per gli endpoint di produzione critici, così da rilevare più rapidamente gli errori
• Monitori HealthCheckPercentageHealthy in CloudWatch: un errore parziale (quando falliscono alcuni, ma non tutti, i controllori dello stato di Route 53) può indicare un problema di rete regionale o intermittente
• Per le risorse private nel VPC, utilizzi controlli dello stato basati sugli allarmi CloudWatch e sulle metriche dell'applicazione
• Testi il failover in ambienti non di produzione prima di farvi affidamento in produzione

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

In questa lezione ha imparato che: i controlli dello stato degli endpoint verificano HTTP/HTTPS/TCP tramite controllori esterni di Route 53, i controlli dello stato basati sugli allarmi CloudWatch consentono di monitorare le risorse private del VPC e i controlli dello stato calcolati combinano più segnali con la logica booleana. La velocità del failover DNS dipende dall'intervallo del controllo dello stato, dalla soglia di errore e dal TTL. Prossimamente analizzeremo le distribuzioni e le origini CloudFront.