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à.
# Esercitazioni
Questa sezione tratta i seguenti tutorial:
**Utilizzo di Route 53 come servizio DNS per i sottodomini**
Scopri come utilizzare Route 53 come servizio DNS per un sottodominio nuovo o esistente continuando a utilizzare un altro servizio DNS per il dominio principale.
**Passaggio al routing basato sulla latenza**
Scopri come migrare gradualmente dal routing standard al routing basato sulla latenza in Route 53, indirizzando gli utenti verso l'endpoint con la latenza più bassa disponibile. AWS
Combina record ponderati e di latenza per una transizione fluida e a basso rischio con funzionalità complete di controllo e rollback.
**Aggiungere un'altra regione al routing basato sulla latenza**
Espandi la configurazione del routing basato sulla latenza aggiungendo una nuova AWS regione e spostando gradualmente il traffico verso la nuova regione.
**Instradamento del traffico verso più istanze Amazon EC2 in una regione**
Usa una combinazione di latenza e record ponderati per indirizzare il traffico verso più istanze Amazon EC2 all'interno di una specifica. Regione AWS
**Gestione di oltre 100 record ponderati**
Scopri come indirizzare il traffico verso più di 100 endpoint creando un albero di record di alias ponderati e record ponderati.
**Ponderazione delle risposte multi-record con tolleranza agli errori**
Scopri come ponderare le risposte DNS che contengono più record, garantendo la tolleranza agli errori e il bilanciamento del carico su più endpoint.
Questi tutorial coprono vari casi d'uso e scenari, aiutandoti a sfruttare efficacemente le politiche di routing, i record ponderati e il routing basato sulla latenza di Route 53 per ottimizzare la gestione del DNS e il routing del traffico.
**Topics**
+ [Utilizzo di Amazon Route 53 come servizio DNS per i sottodomini senza migrare il dominio padre](creating-migrating.md)
+ [Transitioning to latency-based routing in Amazon Route 53](TutorialTransitionToLBR.md)
+ [Aggiunta di un'altra regione al routing basato sulla latenza in Amazon Route 53](TutorialAddingLBRRegion.md)
+ [Utilizzo di record di latenza e ponderati in Amazon Route 53 per instradare il traffico a più istanze Amazon EC2 in una regione](TutorialLBRMultipleEC2InRegion.md)
+ [Gestione di più di 100 record ponderati in Amazon Route 53](TutorialManagingOver100WRR.md)
+ [Ponderazione di risposte multi-record con tolleranza ai guasti in Amazon Route 53](TutorialWeightedFTMR.md)
# Utilizzo di Amazon Route 53 come servizio DNS per i sottodomini senza migrare il dominio padre
Amazon Route 53 offre flessibilità nella gestione del DNS per i sottodomini, consentendoti di sfruttarne le funzionalità senza la necessità di migrare l'intero dominio principale.
Puoi creare un nuovo sottodominio o migrarne uno esistente su Route 53, mantenendo il dominio principale ospitato presso un altro provider di servizi DNS.
**Creazione di un nuovo sottodominio con Route 53:**
1. Crea una zona ospitata per il nuovo sottodominio.
1. Aggiungi i record DNS desiderati (ad esempio, A, CNAME, MX) per il sottodominio alla zona ospitata.
1. Ottieni i name server Route 53 assegnati alla zona ospitata.
1. Aggiorna la configurazione DNS del dominio principale aggiungendo i record NS (Name Server) per il sottodominio, che puntano ai name server Route 53.
**Migrazione di un sottodominio esistente su Route 53:**
1. Creare una zona ospitata per il sottodominio.
1. Ottieni la configurazione DNS corrente per il sottodominio dal tuo provider di servizi DNS esistente.
1. Aggiungi i record DNS corrispondenti alla zona ospitata.
1. Ottieni i name server Route 53 assegnati alla zona ospitata.
1. Aggiorna la configurazione DNS del dominio principale aggiungendo i record NS per il sottodominio, che puntano ai name server Route 53.
Seguendo questi passaggi, puoi sfruttare le funzionalità avanzate di Route 53, come i controlli di integrità, le politiche di routing e la gestione del flusso di traffico, per i tuoi sottodomini mantenendo al contempo la configurazione DNS del dominio principale con il tuo provider esistente.
**Topics**
+ [Creazione di un sottodominio che usa Amazon Route 53 come servizio DNS senza migrazione del dominio padre](CreatingNewSubdomain.md)
+ [Migrazione del servizio DNS per un sottodominio ad Amazon Route 53 senza migrazione del dominio padre](MigratingSubdomain.md)
# Creazione di un sottodominio che usa Amazon Route 53 come servizio DNS senza migrazione del dominio padre
Crea un sottodominio che utilizza Amazon Route 53 come servizio DNS senza migrare il dominio padre da un altro servizio DNS.
Il processo ha i seguenti passaggi di base:
1. [Determinare](#decide-procedure-create-subdomain) se occorre utilizzare questa procedura.
1. [Crea una zona ospitata Route 53 per il sottodominio](#CreateZoneNewSubdomain).
1. [Aggiungi record](#AddNewSubdomainRecords) per il sottodominio alla zona ospitata Route 53.
1. *Solo API*: [conferma che le modifiche sono state estese](#CheckStatusNewSubdomain) a tutti i server DNS di Route 53.
**Nota**
Attualmente, l'unico modo per verificare che le modifiche si siano propagate consiste nell'utilizzare l'azione [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. In genere le modifiche si propagano a tutti i server Route 53 entro 60 secondi.
1. [Aggiornare il servizio DNS per il dominio padre aggiungendo i record dei server dei nomi per il sottodominio](#UpdateDNSParentDomain).
## Individuazione delle procedure da usare per la creazione di un sottodominio
Le procedure in questo argomento illustrano come eseguire un'operazione insolita. Se stai già utilizzando Route 53 come servizio DNS per il tuo dominio e desideri semplicemente indirizzare il traffico da un sottodominio, come www.example.com, verso le tue risorse, ad esempio un server Web in esecuzione su un'istanza, vedi. EC2 [Routing del traffico per sottodomini](dns-routing-traffic-for-subdomains.md)
Utilizza questa procedura *solo* se stai utilizzando un altro servizio DNS per un dominio, ad esempio esempio.com, e desideri iniziare a utilizzare Route 53 come servizio DNS per un nuovo sottodominio di quel dominio, ad esempio www.esempio.com.
## Creazione di una zona ospitata per il nuovo sottodominio
Se desideri utilizzare Amazon Route 53 come servizio DNS per un nuovo sottodominio senza migrare il dominio padre, inizia creando una zona ospitata per il sottodominio. Route 53 memorizza informazioni sul tuo sottodominio nella hosted zone.
Per informazioni su come creare una zona ospitata utilizzando la console Route 53, consulta [Creazione di una zona ospitata pubblica](CreatingHostedZone.md).
## Creazione di record
Puoi creare i record utilizzando la console Amazon Route 53 o l'API Route 53. I record che crei in Route 53 diventeranno i record che DNS usa dopo che deleghi la responsabilità per il sottodominio a Route 53, come spiegato in [Aggiornamento del servizio DNS con record di server dei nomi per il sottodominio](#UpdateDNSParentDomain), in un secondo momento.
**Importante**
Non creare ulteriori record di server di nomi (NS) o origine di autorità (SOA) nella zona ospitata di Route 53 e non eliminare i record SOA e NS esistenti.
Per creare i record tramite la console Route 53, consulta [Utilizzo dei record](rrsets-working-with.md). Per creare i record tramite l'API Route 53, consulta `ChangeResourceRecordSets`. Per ulteriori informazioni, [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)consulta *[Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/)*.
## Verifica dello stato delle modifiche (solo API)
La creazione di una nuova zona ospitata e la modifica dei record richiedono tempo per la propagazione ai server DNS di Route 53. Se in passato [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)creavi i tuoi record, puoi utilizzare l'`GetChange`azione per determinare se le modifiche si sono propagate. (`ChangeResourceRecordSets`restituisce un valore per`ChangeId`, che è possibile includere in una `GetChange` richiesta successiva. `ChangeId`non è disponibile se i record sono stati creati utilizzando la console.) Per ulteriori informazioni, consulta [GET GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) nel *riferimento alle API di Amazon Route 53*.
**Nota**
In genere le modifiche si propagano a tutti i server Route 53 entro 60 secondi.
## Aggiornamento del servizio DNS con record di server dei nomi per il sottodominio
Dopo che le modifiche ai record Amazon Route 53 sono state propagate (consulta [Verifica dello stato delle modifiche (solo API)](#CheckStatusNewSubdomain)), aggiorna il servizio DNS per il dominio padre aggiungendo record NS per il sottodominio. Questo è noto come delegare la responsabilità per il sottodominio a Route 53. Ad esempio, se il dominio padre esempio.com è ospitato con un altro servizio DNS ed è stato creato il sottodominio test.esempio.com in Route 53, devi aggiornare il servizio DNS per esempio.com con i nuovi record NS per test.esempio.com.
Esegui la seguente procedura.
1. Utilizzando il metodo fornito dal servizio DNS, esegui il backup dei file di zona per il dominio padre.
1. Nella console Route 53, ottieni i server dei nomi per la tua zona ospitata Route 53
1. Accedi Console di gestione AWS e apri la console Route 53 all'indirizzo [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Nel pannello di navigazione, scegli **Zone ospitate**.
1. Nella pagina **Zone ospitate**, scegli il pulsante di opzione (non il nome) per la zona ospitata, quindi seleziona **Visualizza dettagli**.
1. Nella pagina dei dettagli della zona ospitata, scegli **Dettagli della zona ospitata**.
1. Prendi nota dei quattro server indicati per **Server dei nomi**.
In alternativa, puoi utilizzare l'operazione `GetHostedZone`. Per ulteriori informazioni, [GetHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetHostedZone.html)consulta *Amazon Route 53 API Reference*.
1. Utilizzando il metodo fornito dal servizio DNS del dominio padre, aggiungi record NS per il sottodominio al file di zona per il dominio padre. In questi record NS, specifica i quattro server dei nomi di Route 53 che sono associati alla zona ospitata creata nella Fase 1.
**Importante**
Non aggiungere un record di origine di autorità (SOA) per il file di zona per il dominio padre. Poiché il sottodominio utilizzerà Route 53, il servizio DNS per il dominio padre non è l'autorità per il sottodominio.
Se il servizio DNS ha aggiunto automaticamente un record SOA per il sottodominio, elimina il record per il sottodominio. Tuttavia, non eliminare il record SOA per il dominio padre.
# Migrazione del servizio DNS per un sottodominio ad Amazon Route 53 senza migrazione del dominio padre
Puoi eseguire la migrazione di un sottodominio per utilizzare Amazon Route 53 come servizio DNS senza migrare il dominio padre da un altro servizio DNS.
Il processo ha i seguenti passaggi di base:
1. [Determinare](#decide-procedure-migrate-subdomain) se occorre utilizzare questa procedura.
1. [Crea una zona ospitata Route 53 per il sottodominio](#CreateZoneMigratedSubdomain).
1. [Ottenere l'attuale configurazione DNS dal fornitore di servizi DNS per il dominio padre](#GetParentDomainResourceRecords).
1. [Aggiungi record](#AddMigratedSubdomainRecords) per il sottodominio alla zona ospitata Route 53.
1. *Solo API*: [conferma che le modifiche sono state estese](#MigratingSubdomainCheckStatus) a tutti i server DNS di Route 53.
**Nota**
Attualmente, l'unico modo per verificare che le modifiche si siano propagate consiste nell'utilizzare l'azione [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. In genere le modifiche si propagano a tutti i server Route 53 entro 60 secondi.
1. [Aggiornare la configurazione DNS con il fornitore di servizi DNS per il dominio padre aggiungendo record del server dei nomi per il sottodominio](#UpdateOldDNS).
## Individuazione delle procedure da usare per la creazione di un sottodominio
Le procedure in questo argomento illustrano come eseguire un'operazione insolita. Se stai già utilizzando Route 53 come servizio DNS per il tuo dominio e desideri semplicemente indirizzare il traffico da un sottodominio, come www.example.com, verso le tue risorse, ad esempio un server Web in esecuzione su un'istanza, vedi. EC2 [Routing del traffico per sottodomini](dns-routing-traffic-for-subdomains.md)
Utilizza questa procedura *solo* se stai utilizzando un altro servizio DNS per un dominio, ad esempio esempio.com, e desideri iniziare a utilizzare Route 53 come servizio DNS per un sottodominio esistente di quel dominio, ad esempio www.esempio.com.
## Creazione di una zona ospitata per il sottodominio
Se desideri migrare un sottodominio da un altro servizio DNS ad Amazon Route 53 ma non desideri migrare il dominio padre, inizia creando una zona ospitata per il sottodominio. Route 53 memorizza informazioni sul tuo sottodominio nella hosted zone.
Per informazioni su come creare una zona ospitata utilizzando la console Route 53, consulta [Creazione di una zona ospitata pubblica](CreatingHostedZone.md).
## Ottenere l'attuale configurazione DNS dal fornitore di servizi DNS
Per semplificare il processo di migrazione di un sottodominio esistente a Route 53, ottieni l'attuale configurazione DNS per il dominio dal provider di servizi DNS, che attualmente esegue manutenzione sul dominio. Puoi utilizzare queste informazioni come base per configurare Route 53 come servizio DNS per il sottodominio.
Ciò che chiedi e il formato che ottieni in varia in base all'azienda che utilizzi come fornitore di servizi DNS. Idealmente, riceverai un file di zona, che contiene informazioni su tutti i record nella configurazione corrente. (I record indicano al DNS come desideri che venga indirizzato il traffico per i tuoi domini e sottodomini. Ad esempio, quando qualcuno inserisce il tuo nome di dominio in un browser Web, desideri che il traffico venga indirizzato a un server Web nel tuo data center, a un' EC2 istanza Amazon, a una CloudFront distribuzione o a qualche altra posizione?) Se puoi ottenere un file di zona dal tuo attuale provider di servizi DNS, puoi modificare il file di zona per rimuovere i record per cui non desideri eseguire la migrazione a Amazon Route 53. Quindi puoi importare i record rimanenti nella tua zona ospitata Route 53, il che semplifica notevolmente il processo. Prova a chiedere all'assistenza clienti del tuo attuale fornitore di servizi DNS come ottenere un *file di zona* o un *elenco di record*.
## Creazione di record
Utilizzando i record ottenuti dal provider di servizi DNS corrente come punto di partenza, crea i record corrispondenti nella zona ospitata di Amazon Route 53 creata per il sottodominio. I record che crei in Route 53 diventeranno i record che DNS usa dopo che deleghi la responsabilità per il sottodominio a Route 53, come spiegato in [Aggiornamento del servizio DNS con record di server dei nomi per il sottodominio](#UpdateOldDNS), in un secondo momento.
**Importante**
Non creare ulteriori record di server di nomi (NS) o origine di autorità (SOA) nella zona ospitata di Route 53 e non eliminare i record SOA e NS esistenti.
Per creare i record tramite la console Route 53, consulta [Utilizzo dei record](rrsets-working-with.md). Per creare i record tramite l'API Route 53, consulta `ChangeResourceRecordSets`. Per ulteriori informazioni, [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)consulta *[Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/)*.
## Verifica dello stato delle modifiche (solo API)
La creazione di una nuova zona ospitata e la modifica dei record richiedono tempo per la propagazione ai server DNS di Route 53. Se in passato [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)creavi i tuoi record, puoi utilizzare l'`GetChange`azione per determinare se le modifiche si sono propagate. (`ChangeResourceRecordSets`restituisce un valore per`ChangeId`, che è possibile includere in una `GetChange` richiesta successiva. `ChangeId`non è disponibile se i record sono stati creati utilizzando la console.) Per ulteriori informazioni, consulta [GET GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) nel *riferimento alle API di Amazon Route 53*.
**Nota**
In genere le modifiche si propagano a tutti i server Route 53 entro 60 secondi.
## Aggiornamento del servizio DNS con record di server dei nomi per il sottodominio
Dopo che le modifiche ai record Amazon Route 53 sono state propagate (consulta [Verifica dello stato delle modifiche (solo API)](#MigratingSubdomainCheckStatus)), aggiorna il servizio DNS per il dominio padre aggiungendo record NS per il sottodominio. Questo è noto come delegare la responsabilità per il sottodominio a Route 53. Ad esempio, supponiamo che il dominio padre esempio.com sia ospitato con un altro servizio DNS e che tu stia migrando il sottodominio test.esempio.com a Route 53. Devi creare una zona ospitata per test.esempio.com e aggiornare il servizio DNS per esempio.com con il record NS che Route 53 ha assegnato alla nuova zona ospitata per test.esempio.com.
Esegui la seguente procedura.
1. Utilizzando il metodo fornito dal servizio DNS, esegui il backup dei file di zona per il dominio padre.
1. Se il precedente fornitore di servizi DNS per il dominio dispone di un metodo per modificare le impostazioni di TTL per i propri server di nomi, ti consigliamo di modificare le impostazioni su 900 secondi. Questo limita il tempo durante il quale le richieste client tentano di risolvere i nomi di dominio utilizzando server di nomi obsoleti. Se l'attuale TTL è 172800 secondi (due giorni), che è un'impostazione di default comune, devi comunque attendere due giorni affinché resolver e client smettono di memorizzare nella cache i record DNS utilizzando il TTL precedente. Una volta scadute le impostazioni di TTL, potrai eliminare in modo sicuro i record che sono stati archiviati presso il provider precedente e apportare le modifiche solo a Route 53.
1. Nella console Route 53, ottieni i server dei nomi per la tua zona ospitata Route 53
1. Accedi Console di gestione AWS e apri la console Route 53 all'indirizzo [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Nel pannello di navigazione, scegli **Zone ospitate**.
1. Nella pagina **Zone ospitate**, scegli il pulsante di opzione (non il nome) per la zona ospitata, quindi seleziona **Visualizza dettagli**.
1. Nella pagina dei dettagli della zona ospitata, scegli **Dettagli della zona ospitata**.
1. Prendi nota dei quattro server indicati per **Server dei nomi**.
In alternativa, puoi utilizzare l'operazione `GetHostedZone`. Per ulteriori informazioni, [GetHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetHostedZone.html)consulta *Amazon Route 53 API Reference*.
1. Utilizzando il metodo fornito dal servizio DNS del dominio padre, aggiungi record NS per il sottodominio al file di zona per il dominio padre. Dai ai record NS lo stesso nome del sottodominio. Per i valori nei record NS, specifica i quattro server dei nomi di Route 53 associati alla zona ospitata creata nella Fase 2. Servizi DNS diversi usano una terminologia differente. Potrebbe essere necessario contattare il supporto tecnico del servizio DNS per ulteriori informazioni su come eseguire questa operazione.
**Importante**
Non aggiungere un record di origine di autorità (SOA) per il file di zona per il dominio padre. Poiché il sottodominio utilizzerà Route 53, il servizio DNS per il dominio padre non è l'autorità per il sottodominio.
Se il servizio DNS ha aggiunto automaticamente un record SOA per il sottodominio, elimina il record per il sottodominio. Tuttavia, non eliminare il record SOA per il dominio padre.
A seconda delle impostazioni di TTL per i server di nomi per il dominio padre, la propagazione delle modifiche apportate ai resolver DNS può richiedere 48 ore o più. Durante tale periodo, i resolver DNS possono ancora rispondere a richieste con i server di nomi per il servizio DNS del dominio padre. Inoltre, i computer client potrebbero continuare a disporre del nome del server precedente per il sottodominio nella cache.
1. Dopo che le impostazioni TTL del registrar per il dominio scadono (vedi Fase 2), eliminare i seguenti record dal file di zona per il dominio padre:
+ I record aggiunti a Route 53 come descritto in [Creazione di record](#AddMigratedSubdomainRecords).
+ I record NS del servizio DNS. Una volta completata l'eliminazione di record NS, gli unici record NS nel file di zona saranno quelli creati nella Fase 4.
# Transitioning to latency-based routing in Amazon Route 53
Con il routing basato sulla latenza, Amazon Route 53 può indirizzare gli utenti verso l'endpoint con la latenza più bassa disponibile. AWS Ad esempio, è possibile associare un nome DNS come `www.example.com` a un Classic Load Balancer, Application Load Balancer o Network Load Balancer ELB o a istanze Amazon EC2 o indirizzi IP elastici ospitati nelle regioni Stati Uniti orientali (Ohio) e Europa (Irlanda). I server DNS di Route 53 decidono, in base alle condizioni di rete delle ultime due settimane, quali istanze in quali regioni devono servire particolari utenti. Un utente a Londra potrebbe essere indirizzato all'istanza Europa (Irlanda), un utente a Chicago potrebbe essere indirizzato all'istanza Stati Uniti orientali (Ohio) e così via. Route 53 supporta il routing basato sulla latenza per record A, AAAA, TXT e CNAME, nonché alias a record A e AAAA.
**Nota**
I dati sulla latenza tra utenti e risorse si basano interamente sul traffico tra utenti e data center. AWS Se non utilizzi risorse in una AWS regione, la latenza effettiva tra gli utenti e le risorse può variare in modo significativo rispetto ai dati di AWS latenza. Questo vale anche se le tue risorse si trovano nella stessa città di una AWS regione.
Per una transizione fluida, puoi combinare record ponderati e di latenza per migrare gradualmente da routing standard a routing basato sulla latenza con il controllo completo e funzionalità di rollback in ogni fase. Immaginiamo un esempio in cui `www.example.com` è attualmente ospitato su un'istanza Amazon EC2 nella regione Stati Uniti orientali (Ohio). L'istanza ha l'indirizzo IP elastico (EIP) `W.W.W.W`. Supponiamo che desideri continuare a instradare il traffico alla regione Stati Uniti orientali (Ohio) quando applicabile mentre inizi anche a indirizzare gli utenti ad altre istanze Amazon EC2 nella regione Stati Uniti occidentali (California settentrionale) (IP elastico `X.X.X.X`) e nella regione Europa (Irlanda) (IP elastico `Y.Y.Y.Y`). La zona ospitata di Route 53 `example.com` dispone già di un record per `www.example.com` che ha un **Tipo** A e un **Valore**(un indirizzo IP) pari a `W.W.W.W`.
Una volta terminato con il seguente esempio, avrai due record alias ponderati:
+ Dovrai convertire i tuoi record esistenti per `www.example.com` in un record alias ponderato che continua a indirizzare la maggior parte del traffico all'istanza Amazon EC2 nella regione Stati Uniti orientali (Ohio).
+ Puoi creare un altro record alias ponderato che inizialmente direziona solo una piccola porzione di traffico verso i record di latenza, che instradano il traffico verso le tre regioni.
Aggiornando i pesi in questi record alias ponderati puoi passare gradualmente da instradare il traffico solo alla regione Stati Uniti orientali (Ohio) a instradare il traffico a tutte le tre regioni in cui disponi di istanze Amazon EC2.
**Come passare a un routing basato sulla latenza**
1. Creare una copia del record per `www.example.com`, ma utilizzare un nuovo nome di dominio, ad esempio `copy-www.example.com`. Assegnare al nuovo record lo stesso **Type (Tipo)** (A) e **Value (Valore)** (`W.W.W.W`) del record per `www.example.com`.
1. Aggiornare il record A esistente per `www.example.com` per renderlo un record alias ponderato:
+ Per **Valore/instradamento traffico a**, scegli **Alias a un altro record in questa zona ospitata** e specifica `copy-www.example.com`.
+ Per **Peso**, specifica 100.
Una volta completato l'aggiornamento, Route 53 continuerà a usare questo record per indirizzare tutto il traffico alla risorsa che dispone di un indirizzo IP di `W.W.W.W`.
1. Crea un record di latenza per ciascuna delle istanze Amazon EC2, ad esempio:
+ Stati Uniti orientali (Ohio), indirizzo IP elastico `W.W.W.W`
+ Stati Uniti occidentali (California settentrionale), indirizzo IP elastico `X.X.X.X`
+ Europa (Irlanda), indirizzo IP elastico `Y.Y.Y.Y`
Assegnare a tutti i record di latenza lo stesso nome di dominio, ad esempio, `www-lbr.example.com` e lo stesso tipo, A.
Al termine della creazione dei record di latenza, Route 53 continuerà a instradare il traffico usando il record che hai aggiornato nella fase 2.
Puoi usare `www-lbr.example.com` per eseguire il testing di convalida, per esempio, per assicurare che ciascun endpoint possa accettare richieste.
1. Ora aggiungiamo il record di latenza `www-lbr.example.com` nel record ponderato `www.example.com` e iniziamo a instradare il traffico limitato alle istanze Amazon EC2 corrispondenti. Questo significa che l'istanza Amazon EC2 nella regione Stati Uniti orientali (Ohio) otterrà il traffico da entrambi i record ponderati.
Creare un altro record alias ponderato per `www.example.com`:
+ Per **Valore/instradamento traffico a**, scegli **Alias a un altro record in questa zona ospitata** e specifica `www-lbr.example.com.`
+ Per **Peso**, specifica 1.
Al termine, quando anche la sincronizzazione delle modifiche apportate ai server Route 53 è terminata, Route 53 inizierà a instradare un'esigua frazione di traffico (1/101) alle istanze Amazon EC2 per le quali sono stati creati record di latenza nella Fase 3.
1. Mentre acquisisci sicurezza sul fatto che i tuoi endpoint vengano adeguatamente scalati per il traffico in entrata, regola i pesi di conseguenza. Ad esempio, se desidera che il 10% delle tue richieste siano basate sul routing basato sulla latenza, modifica il peso su 90 e 10 rispettivamente.
Per ulteriori informazioni sulla creazione di record di latenza, consulta [Creazione di record utilizzando la console Amazon Route 53](resource-record-sets-creating.md).
# Aggiunta di un'altra regione al routing basato sulla latenza in Amazon Route 53
Se stai utilizzando il routing basato sulla latenza e desideri aggiungere un'istanza a una nuova regione, puoi spostare gradualmente il traffico verso la nuova regione nello stesso modo in cui viene spostato progressivamente il traffico al routing basato sulla latenza in [Transitioning to latency-based routing in Amazon Route 53](TutorialTransitionToLBR.md).
Ad esempio, supponiamo che stai utilizzando il routing basato sulla latenza per instradare il traffico `www.example.com` e desideri aggiungere un'istanza Amazon EC2 in Asia Pacifico (Tokyo) alle tue istanze in Stati Uniti orientali (Ohio), Stati Uniti occidentali (California settentrionale) e Europa (Irlanda). L'esempio di procedura seguente illustra un modo in cui è possibile aggiungere un'istanza in un'altra regione.
Per questo esempio, la zona ospitata Amazon Route 53 per `example.com` ha già un alias ponderato per `www.example.com` che instrada il traffico ai record basati sulla latenza per `www-lbr.example.com`:
+ Stati Uniti orientali (Ohio), indirizzo IP elastico `W.W.W.W`
+ Stati Uniti occidentali (California settentrionale), indirizzo IP elastico `X.X.X.X`
+ Europa (Irlanda), indirizzo IP elastico `Y.Y.Y.Y`
Il record alias ponderato ha un peso di 100. Dopo essere passato al routing basato sulla latenza, presupponi che elimini l'altro record ponderato utilizzato per la transizione.
**Come aggiungere un'altra regione al routing basato sulla latenza in Route 53**
1. Creare quattro nuovi record basati sulla latenza che includono le tre regioni originali e la nuova regione in cui desideri iniziare a instradare il traffico.
+ Stati Uniti orientali (Ohio), indirizzo IP elastico `W.W.W.W`
+ Stati Uniti occidentali (California settentrionale), indirizzo IP elastico `X.X.X.X`
+ Europa (Irlanda), indirizzo IP elastico `Y.Y.Y.Y`
+ Asia Pacifico (Tokyo), indirizzo IP elastico `Z.Z.Z.Z`
Assegnare a tutti i record di latenza lo stesso nuovo nome di dominio, ad esempio, `www-lbr-2012-04-30.example.com` e lo stesso tipo, A.
Al termine della creazione dei record di latenza, Route 53 continuerà a instradare il traffico usando il record alias ponderato (`www.example.com`) e i record di latenza (`www-lbr.example.com`) originali.
Puoi usare i record `www-lbr-2012-04-30.example.com` per eseguire il testing di convalida, per esempio, per assicurare che ciascun endpoint possa accettare richieste.
1. Creare un record alias ponderato per i nuovi record di latenza:
+ Per il nome di dominio, specifica il nome per il record alias ponderati esistente, `www.example.com`.
+ Per **Valore/instradamento traffico a**, scegli **Alias a un altro record in questa zona ospitata** e specifica `www-lbr-2012-04-30.example.com`.
+ Per **Peso**, specifica 1.
Al termine, Route 53 inizierà a instradare un'esigua frazione di traffico (1/101) alle istanze Amazon EC2 per cui sono stati creati i record di latenza `www-lbr-2012-04-30.example.com` nella Fase 1. Il resto del traffico continuerà a essere instradato ai record di latenza `www-lbr.example.com`, che non includono l'istanza Amazon EC2 nella regione Asia Pacifico (Tokyo).
1. Mentre acquisisci sicurezza sul fatto che i tuoi endpoint vengano adeguatamente scalati per il traffico in entrata, regola i pesi di conseguenza. Ad esempio, se desideri che il 10% delle tue richieste vengano instradate ai record di latenza che includono la regione di Tokyo, modifica il peso per `www-lbr.example.com` da 100 a 90 e il peso per `www-lbr-2012-04-30.example.com` da 1 a 10.
Per ulteriori informazioni sulla creazione di record, consulta [Creazione di record utilizzando la console Amazon Route 53](resource-record-sets-creating.md).
# Utilizzo di record di latenza e ponderati in Amazon Route 53 per instradare il traffico a più istanze Amazon EC2 in una regione
Se la tua applicazione è in esecuzione su istanze Amazon EC2 in una o più regioni e se disponi di più istanze Amazon EC2 in una o più regioni, puoi usare il routing basato sulla latenza per instradare il traffico alla regione corretta e quindi utilizzare record ponderati per instradare il traffico verso le istanze all'interno della regione in base ai pesi da te specificati.
Ad esempio, se disponi di tre istanze Amazon EC2 con indirizzi IP elastici nella regione Stati Uniti orientali (Ohio) e desideri distribuire le richieste in modo uniforme sui tre indirizzi IP per gli utenti per i quali Stati Uniti orientali (Ohio) è la regione appropriata. È sufficiente una sola istanza Amazon EC2 nelle altre regioni, anche se è possibile applicare la stessa tecnica a più regioni contemporaneamente.
**Come utilizzare i record di latenza e ponderati in Amazon Route 53 per instradare il traffico a più istanze Amazon EC2 in una regione**
1. Crea un gruppo di record ponderati per le istanze Amazon EC2 nella regione. Tenere presente quanto segue:
+ Assegna a ogni record ponderato lo stesso valore per **Nome record** (ad esempio, `us-east.example.com`) e **Tipo di record**.
+ Per **Valore/instradamento traffico a**, scegli **Indirizzo IP o un altro valore a seconda del tipo di record** e specifica il valore di uno degli indirizzi IP elastici.
+ Se desideri che il peso delle istanze Amazon EC2 sia uguale, specifica lo stesso valore per **Peso**.
+ Specifica un valore univoco per **Set ID (Imposta ID)** per ogni record.
Per ulteriori informazioni sui record ponderati, consulta [Routing ponderato](routing-policy-weighted.md).
1. Se disponi di più istanze Amazon EC2 in altre regioni, ripeti la Fase 1 per le altre regioni. Specificare un valore diverso per **Name (Nome)** in ciascuna regione.
1. Per ogni regione in cui sono presenti più istanze Amazon EC2 (per esempio, Stati Uniti orientali (Ohio)), crea un record alias di latenza. Per **Valore/instradamento traffico a**, scegli **Alias a un altro record in questa zona ospitata** e specifica il valore del campo **Nome record** (ad esempio, `us-east.example.com`) che è stato assegnato ai record ponderati in tale regione.
1. Per ogni regione in cui disponi di una istanza Amazon EC2, crea un record di latenza. Per il valore di **Nome record**, specifica lo stesso valore specificato per i record alias di latenza di record creati nella Fase 3. Per **Valore/instradamento traffico a**, scegli **Indirizzo IP o un altro valore a seconda del tipo di record** e specifica il valore l'indirizzo IP elastico dell'istanza Amazon EC2 in quella regione.
Per ulteriori informazioni sull'aggiunta di record di alias alle istanze Amazon EC2, consulta [Routing del traffico a un'istanza Amazon EC2](routing-to-ec2-instance.md)
Per ulteriori informazioni sulla creazione di record, consulta [Creazione di record utilizzando la console Amazon Route 53](resource-record-sets-creating.md).
# Gestione di più di 100 record ponderati in Amazon Route 53
Amazon Route 53 consente di configurare i record ponderati. Per un determinato nome e tipo (ad esempio `www.example.com`, tipo A), è possibile configurare un massimo di 100 risposte alternative, ognuna con il proprio peso. Durante la risposta alle query per `www.example.com`, i server DNS di Route 53 selezionano una risposta random ponderata da restituire ai resolver DNS. Il valore di un record ponderato che ha un peso di 2 viene restituito, in media, due volte più spesso del valore di un record ponderato che ha un peso di 1.
Se hai bisogno di indirizzare il traffico verso più di 100 endpoint, un modo per farlo è di utilizzare una struttura di record alias ponderati e record ponderati. Ad esempio, il primo "livello" della struttura potrebbe contenere fino a 100 record alias ponderati, ciascuno dei quali può, a sua volta, puntare fino a un massimo di 100 record ponderati. Route 53 consente fino a tre livelli di conversione, che consentono di gestire fino a 1.000.000 endpoint ponderati univoci.
Una semplice struttura a due livelli può essere simile a questa:
**Record di alias ponderati**
+ Alias `www.example.com` a `www-a.example.com` con un peso di 1
+ Alias `www.example.com` a `www-b.example.com` con un peso di 1
**Record ponderati**
+ `www-a.example.com`, tipo A, valore 192.0.2.1, peso 1
+ `www-a.example.com`, tipo A, valore 192.0.2.2, peso 1
+ `www-b.example.com`, tipo A, valore 192.0.2.3, peso 1
+ `www-b.example.com`, tipo A, valore 192.0.2.4, peso 1
Per ulteriori informazioni sulla creazione di record, consulta [Utilizzo dei record](rrsets-working-with.md).
# Ponderazione di risposte multi-record con tolleranza ai guasti in Amazon Route 53
**Nota**
I record che utilizzano la policy di routing di risposta multivalore si comportano in modo analogo alla configurazione documentata in questo tutorial. La differenza principale è che la configurazione del tutorial consente di specificare un peso, che può essere utile quando i tuoi endpoint hanno capacità diverse. Per ulteriori informazioni, consulta [Routing di risposta multivalore](routing-policy-multivalue.md).
Un record ponderato di Amazon Route 53 può essere associato a un solo record, ovvero una combinazione di un nome (ad esempio, `example.com`) e un tipo di record (ad esempio, A). Ma è spesso auspicabile pesare risposte DNS che contengono più record.
Ad esempio, si possono avere otto istanze Amazon EC2 o endpoint IP elastici per un servizio. Se il client di quel servizio supportano i nuovi tentativi di connessione (come tutti i browser più comuni), fornire più indirizzi IP nelle risposte DNS dà ai client endpoint alternativi in caso di errore di un endpoint particolare. Puoi persino proteggerti dal guasto di una zona di disponibilità se configuri le risposte in modo che contengano una combinazione di IPs ospitate in due o più zone di disponibilità.
Le risposte multi-record sono utili anche quando un numero elevato di client mobili (per esempio, applicazioni Web mobili) condividono un piccolo set di cache DNS. In questo caso, le risposte multi-record consentono ai client di indirizzare le richieste ai vari endpoint anche se ricevono una comune risposta DNS dalla cache condivisa.
Questi tipi di risposte multi-record possono essere ottenute utilizzando una combinazione di record e record alias ponderati. È possibile raggruppare otto endpoint in due distinti di set di record contenenti quattro indirizzi IP ciascuno:
`endpoint-a.example.com`, tipo A, con i seguenti valori:
+ 192.0.2.1
+ 192.0.2.2
+ 192.0.2.128
+ 192.0.2.129
`endpoint-b.example.com`, tipo A, con i seguenti valori:
+ 192.0.2.3
+ 192.0.2.4
+ 192.0.2.130
+ 192.0.2.131
È quindi possibile creare un record alias ponderato che punti a ciascun gruppo:
+ Alias `www.example.com` a `endpoint-a.example.com`, tipo A, peso di 1
+ Alias `www.example.com` a `endpoint-b.example.com`, tipo A, peso di 1
Per ulteriori informazioni sulla creazione di record, consulta [Utilizzo dei record](rrsets-working-with.md).