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à.
# Configurazione dei controlli dell'integrità personalizzati per failover DNS per un'API di Gateway API
Puoi utilizzare i controlli di integrità di Amazon Route 53 per controllare il failover DNS da un'API API Gateway in una regione primaria Regione AWS a una 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](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth>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, il tuo API Gateway APIs può subire interruzioni prima di quel momento. Per controllare direttamente il failover DNS, configura i controlli di integrità personalizzati di Route 53 per il tuo API Gateway. APIs Per questo esempio, si utilizza un CloudWatch allarme che aiuta gli operatori a controllare il failover DNS. Per altri esempi e altre considerazioni sulla configurazione del failover, consulta [Creazione di meccanismi di disaster recovery utilizzando Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) ed [Esecuzione dei controlli di integrità di Route 53 su risorse private in un VPC](https://aws.amazon.com/blogs/networking-and-content-delivery/performing-route-53-health-checks-on-private-resources-in-a-vpc-with-aws-lambda-and-amazon-cloudwatch/) con e. AWS Lambda CloudWatch
**Topics**
+ [Prerequisiti](#dns-failover-prereqs)
+ [Fase 1: Configurazione delle risorse](#dns-failover-intial-setup)
+ [Fase 2: Avvio del failover nella regione secondaria](#dns-failover-initiate)
+ [Fase 3: Test del failover](#dns-failover-test)
+ [Fase 4: Ritorno alla regione primaria](#dns-failover-return)
+ [Fasi successive: personalizzare e verificare periodicamente](#dns-failover-next-steps)
## Prerequisiti
Per completare questa procedura, è necessario creare e configurare le risorse seguenti:
+ Un nome di dominio di cui si è proprietari.
+ Un certificato ACM per quel nome di dominio in due. Regioni AWS Per ulteriori informazioni, consulta [Prerequisiti per i nomi di dominio personalizzati](how-to-custom-domains.md#how-to-custom-domains-prerequisites).
+ Una zona ospitata Route 53 per il nome di dominio in uso. Per ulteriori informazioni, consulta [Utilizzo delle zone ospitate](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) nella Guida per gli sviluppatori di Amazon Route 53.
Per ulteriori informazioni su come creare record DNS di failover Route 53 per i nomi di dominio, consulta [Scelta una policy di instradamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) nella Guida per sviluppatori Amazon Route 53. Per ulteriori informazioni su come monitorare un CloudWatch allarme, consulta [Monitoring a CloudWatch alarm](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html#health-checks-creating-values-cloudwatch) nella Amazon Route 53 Developer Guide.
## 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:
+ API Gateway APIs in due Regioni AWS
+ Nomi di dominio personalizzati API Gateway con lo stesso nome in due Regioni AWS
+ Mappature API Gateway che collegano l'API Gateway APIs ai nomi di dominio personalizzati
+ Record DNS di failover di Route 53 per i nomi di dominio
+ Un CloudWatch allarme nella regione secondaria
+ Un controllo dello stato di salute della Route 53 basato sull' CloudWatch allarme nella regione secondaria
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. Ad esempio, CloudFormation i modelli che creano queste risorse, vedi [samples/primary.zip](samples/primary.zip)e [samples/secondary.zip](samples/secondary.zip).
**Importante**
Prima del failover nella regione secondaria, accertarsi che tutte le risorse necessarie siano disponibili. In caso contrario, l'API non sarà pronta per il traffico nella regione secondaria.
## Fase 2: Avvio del failover nella regione secondaria
Nell'esempio seguente, la regione di standby riceve una CloudWatch metrica 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 metrici con i dati corrispondenti per l'allarme che hai configurato. CloudWatch
## 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 principale, invia una CloudWatch metrica che determini il superamento del controllo sanitario.
```
aws cloudwatch put-metric-data \
--metric-name Failover \
--namespace HealthCheck \
--unit Count \
--value 0 \
--region us-west-1
```
Sostituisci i dati metrici con i dati corrispondenti per l' CloudWatch allarme che hai 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 una varietà di CloudWatch metriche o endpoint HTTP per i controlli di 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.