Configurazione dei controlli dell'integrità personalizzati per failover DNS per un'API di Gateway API

È possibile utilizzare i controlli dell'integrità di Amazon Route 53 per controllare il failover DNS da un'API di API Gateway in una Regione AWS primaria ad un'altra in una regione secondaria. Questo può aiutare a mitigare gli impatti in caso di problema regionale. Se si utilizza un dominio personalizzato, è possibile eseguire il failover senza richiedere ai client di modificare gli endpoint API.

Quando si sceglie Evaluate Target Health (Valutazione dello stato target) per un record alias, tali record non riescono solo quando il servizio API Gateway non è disponibile nella regione. In alcuni casi, le API di API Gateway possono subire un'interruzione prima di tale momento. Per controllare direttamente il failover DNS, configurare i controlli dell'integrità di Route 53 personalizzati per le API di Gateway API. In questo esempio, si utilizza un allarme CloudWatch che consente agli operatori di controllare il failover DNS. Per ulteriori esempi e altre considerazioni sulla configurazione del failover, consulta Creating Disaster Recovery Mechanisms Using Route 53 e Performing Route 53 health checks on private resources in a VPC with AWS Lambda and CloudWatch.

Prerequisiti

Per completare questa procedura, è necessario creare e configurare le risorse seguenti:

Per ulteriori informazioni su come creare record DNS di failover Route 53 per i nomi di dominio, consulta Scelta una policy di instradamento nella Guida per sviluppatori Amazon Route 53. Per ulteriori informazioni su come monitorare un allarme CloudWatch, consulta Monitoraggio di un allarme CloudWatch nella Guida per sviluppatori Amazon Route 53.

Fase 1: Configurazione delle risorse

In questo esempio, vengono create le seguenti risorse per configurare il failover DNS per il nome di dominio in uso:

Innanzitutto, accertarsi di disporre di tutte le risorse richieste nelle regioni primaria e secondaria. La regione secondaria deve contenere l'allarme e il controllo dell'integrità. In questo modo, non si dipende dalla regione primaria per eseguire il failover. Per modelli AWS CloudFormation di esempio che creano queste risorse, consulta primary.yaml e secondary.yaml.

Fase 2: Avvio del failover nella regione secondaria

Nell'esempio seguente, la regione di standby riceve una metrica CloudWatch e avvia il failover. Utilizziamo una metrica personalizzata che richiede l'intervento dell'operatore per avviare il failover.

aws cloudwatch put-metric-data \
    --metric-name Failover \
    --namespace HealthCheck \
    --unit Count \
    --value 1 \
    --region us-west-1

Sostituisci i dati dei parametri con i dati corrispondenti per l'allarme CloudWatch configurato.

Fase 3: Test del failover

Richiamare l'API e verificare di ricevere una risposta dalla regione secondaria. Se si sono utilizzati i modelli di esempio della fase 1, la risposta cambia da {"message": "Hello from the primary Region!"} a {"message": "Hello from the secondary Region!"} dopo il failover.

curl https://my-api.example.com

{"message": "Hello from the secondary Region!"}   

Fase 4: Ritorno alla regione primaria

Per tornare alla regione primaria, inviare una metrica CloudWatch che determini il superamento del controllo dell'integrità.

aws cloudwatch put-metric-data \
    --metric-name Failover \
    --namespace HealthCheck \
    --unit Count \
    --value 0 \
    --region us-west-1

Sostituisci i dati dei parametri con i dati corrispondenti per l'allarme CloudWatch configurato.

Richiamare l'API e verificare di ricevere una risposta dalla regione primaria. Se si sono utilizzati i modelli di esempio della fase 1, la risposta cambia da {"message": "Hello from the secondary Region!"} a {"message": "Hello from the primary Region!"}.

curl https://my-api.example.com

{"message": "Hello from the primary Region!"}

Fasi successive: personalizzare e verificare periodicamente

Questo esempio dimostra un modo per configurare il failover DNS. È possibile utilizzare un'ampia varietà di metriche CloudWatch o endpoint HTTP per i controlli dell'integrità che gestiscono il failover. Verificare periodicamente i meccanismi di failover per accertarsi che funzionino come previsto e che gli operatori conoscano le procedure di failover.