# Tutorials
This section covers the following tutorials:
**Using Route 53 as the DNS service for subdomains**
Learn how to use Route 53 as the DNS service for a new or existing subdomain while still using another DNS service for the parent domain.
**Transitioning to Latency-based routing**
Discover how to gradually migrate from standard routing to latency-based routing in Route 53, directing users to the lowest-latency AWS endpoint available.
Combine weighted and latency records for a smooth, low-risk transition with full control and rollback capability.
**Adding another Region to latency-based routing**
Expand your latency-based routing setup by adding a new AWS Region and gradually shifting traffic to the new Region.
**Routing traffic to multiple Amazon EC2 instances in a Region**
Use a combination of latency and weighted records to route traffic to multiple Amazon EC2 instances within a specific AWS Region.
**Managing over 100 weighted records**
Learn how to direct traffic to more than 100 endpoints by creating a tree of weighted alias records and weighted records.
**Weighting fault-tolerant multi-record answers**
Understand how to weight DNS responses that contain multiple records, providing fault tolerance and load balancing across multiple endpoints.
These tutorials cover various use cases and scenarios, helping you effectively leverage Route 53's routing policies, weighted records, and latency-based routing to optimize your DNS management and traffic routing.
**Topics**
+ [Using Amazon Route 53 as the DNS service for subdomains without migrating the parent domain](creating-migrating.md)
+ [Transitioning to latency-based routing in Amazon Route 53](TutorialTransitionToLBR.md)
+ [Adding another Region to your latency-based routing in Amazon Route 53](TutorialAddingLBRRegion.md)
+ [Using latency and weighted records in Amazon Route 53 to route traffic to multiple Amazon EC2 instances in a Region](TutorialLBRMultipleEC2InRegion.md)
+ [Managing over 100 weighted records in Amazon Route 53](TutorialManagingOver100WRR.md)
+ [Weighting fault-tolerant multi-record answers in Amazon Route 53](TutorialWeightedFTMR.md)
# Using Amazon Route 53 as the DNS service for subdomains without migrating the parent domain
Amazon Route 53 provides flexibility in managing DNS for subdomains, allowing you to leverage its features without the need to migrate the entire parent domain.
You can either create a new subdomain or migrate an existing one to Route 53, while keeping the parent domain hosted with another DNS service provider.
**Creating a new subdomain with Route 53:**
1. Create a hosted zone for the new subdomain.
1. Add the desired DNS records (e.g., A, CNAME, MX) for the subdomain to the hosted zone.
1. Obtain the Route 53 name servers assigned to the hosted zone.
1. Update the DNS configuration of the parent domain by adding NS (Name Server) records for the subdomain, pointing to the Route 53 name servers.
**Migrating an existing subdomain to Route 53:**
1. Create a hosted zone for the subdomain.
1. Obtain the current DNS configuration for the subdomain from your existing DNS service provider.
1. Add the corresponding DNS records to the hosted zone.
1. Obtain the Route 53 name servers assigned to the hosted zone.
1. Update the DNS configuration of the parent domain by adding NS records for the subdomain, pointing to the Route 53 name servers.
By following these steps, you can leverage Route 53's advanced features, such as health checks, routing policies, and traffic flow management, for your subdomains while maintaining the parent domain's DNS configuration with your existing provider.
**Topics**
+ [Creating a subdomain that uses Amazon Route 53 as the DNS service without migrating the parent domain](CreatingNewSubdomain.md)
+ [Migrating DNS service for a subdomain to Amazon Route 53 without migrating the parent domain](MigratingSubdomain.md)
# Creating a subdomain that uses Amazon Route 53 as the DNS service without migrating the parent domain
You can create a subdomain that uses Amazon Route 53 as the DNS service without migrating the parent domain from another DNS service.
The process has the following basic steps:
1. [Figure out](#decide-procedure-create-subdomain) whether you should even be using this procedure.
1. [Create a Route 53 hosted zone for the subdomain](#CreateZoneNewSubdomain).
1. [Add records](#AddNewSubdomainRecords) for the new subdomain to your Route 53 hosted zone.
1. *API only:* [Confirm that your changes have propagated](#CheckStatusNewSubdomain) to all Route 53 DNS servers.
**Note**
Currently, the only way to verify that changes have propagated is to use the [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API action. Changes generally propagate to all Route 53 name servers within 60 seconds.
1. [Update the DNS service for the parent domain by adding name server records for the subdomain](#UpdateDNSParentDomain).
## Deciding which procedures to use for creating a subdomain
The procedures in this topic explain how to perform an uncommon operation. If you're already using Route 53 as the DNS service for your domain and you just want to route traffic for a subdomain, such as www.example.com, to your resources, such as a web server running on an EC2 instance, see [Routing traffic for subdomains](dns-routing-traffic-for-subdomains.md).
Use this procedure *only* if you're using another DNS service for a domain, such as example.com, and you want to start using Route 53 as the DNS service for a new subdomain of that domain, such as www.example.com.
## Creating a hosted zone for the new subdomain
When you want to use Amazon Route 53 as the DNS service for a new subdomain without migrating the parent domain, you start by creating a hosted zone for the subdomain. Route 53 stores information about your subdomain in the hosted zone.
For information about how to create a hosted zone using the Route 53 console, see [Creating a public hosted zone](CreatingHostedZone.md).
## Creating records
You can create records using either the Amazon Route 53 console or the Route 53 API. The records that you create in Route 53 will become the records that DNS uses after you delegate responsibility for the subdomain to Route 53, as explained in [Updating your DNS service with name server records for the subdomain](#UpdateDNSParentDomain), later in the process.
**Important**
Do not create additional name server (NS) or start of authority (SOA) records in the Route 53 hosted zone, and do not delete the existing NS and SOA records.
To create records using the Route 53 console, see [Working with records](rrsets-working-with.md). To create records using the Route 53 API, use `ChangeResourceRecordSets`. For more information, see [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) in the *[Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/)*.
## Checking the status of your changes (API only)
Creating a new hosted zone and changing records take time to propagate to the Route 53 DNS servers. If you used [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) to create your records, you can use the `GetChange` action to determine whether your changes have propagated. (`ChangeResourceRecordSets` returns a value for `ChangeId`, which you can include in a subsequent `GetChange` request. `ChangeId` is not available if you created the records by using the console.) For more information, see [GET GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) in the *Amazon Route 53 API Reference*.
**Note**
Changes generally propagate to all Route 53 name servers within 60 seconds.
## Updating your DNS service with name server records for the subdomain
After your changes to Amazon Route 53 records have propagated (see [Checking the status of your changes (API only)](#CheckStatusNewSubdomain)), update the DNS service for the parent domain by adding NS records for the subdomain. This is known as delegating responsibility for the subdomain to Route 53. For example, if the parent domain example.com is hosted with another DNS service and you created the subdomain test.example.com in Route 53, you must update the DNS service for example.com with new NS records for test.example.com.
Perform the following procedure.
1. Using the method provided by your DNS service, back up the zone file for the parent domain.
1. In the Route 53 console, get the name servers for your Route 53 hosted zone:
1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. In the navigation pane, click **Hosted zones**.
1. On the **Hosted zones** page, choose the radio button (not the name) for the hosted zone, then choose **View details**.
1. On the details page for the hosted zone, choose **Hosted zone details**.
1. Make note of the four servers listed for **Name servers**.
Alternatively, you can use the `GetHostedZone` action. For more information, see [GetHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetHostedZone.html) in the *Amazon Route 53 API Reference*.
1. Using the method provided by the DNS service of the parent domain, add NS records for the subdomain to the zone file for the parent domain. In these NS records, specify the four Route 53 name servers that are associated with the hosted zone that you created in Step 1.
**Important**
Do not add a start of authority (SOA) record to the zone file for the parent domain. Because the subdomain will use Route 53, the DNS service for the parent domain is not the authority for the subdomain.
If your DNS service automatically added an SOA record for the subdomain, delete the record for the subdomain. However, do not delete the SOA record for the parent domain.
# Migrating DNS service for a subdomain to Amazon Route 53 without migrating the parent domain
You can migrate a subdomain to use Amazon Route 53 as the DNS service without migrating the parent domain from another DNS service.
The process has the following basic steps:
1. [Figure out](#decide-procedure-migrate-subdomain) whether you should even be using this procedure.
1. [Create a Route 53 hosted zone for the subdomain](#CreateZoneMigratedSubdomain).
1. [Get the current DNS configuration from the current DNS service provider for the parent domain](#GetParentDomainResourceRecords).
1. [Add records](#AddMigratedSubdomainRecords) for the subdomain to your Route 53 hosted zone.
1. *API only:* [Confirm that your changes have propagated](#MigratingSubdomainCheckStatus) to all Route 53 DNS servers.
**Note**
Currently, the only way to verify that changes have propagated is to use the [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API action. Changes generally propagate to all Route 53 name servers within 60 seconds.
1. [Update the DNS configuration with the DNS service provider for the parent domain by adding name server records for the subdomain](#UpdateOldDNS).
## Deciding which procedures to use for creating a subdomain
The procedures in this topic explain how to perform an uncommon operation. If you're already using Route 53 as the DNS service for your domain and you just want to route traffic for a subdomain, such as www.example.com, to your resources, such as a web server running on an EC2 instance, see [Routing traffic for subdomains](dns-routing-traffic-for-subdomains.md).
Use this procedure *only* if you're using another DNS service for a domain, such as example.com, and you want to start using Route 53 as the DNS service for an existing subdomain of that domain, such as www.example.com.
## Creating a hosted zone for the subdomain
If you want to migrate a subdomain from another DNS service to Amazon Route 53 but you don't want to migrate the parent domain, start by creating a hosted zone for the subdomain. Route 53 stores information about your subdomain in the hosted zone.
For information about how to create a hosted zone using the Route 53 console, see [Creating a public hosted zone](CreatingHostedZone.md).
## Getting your current DNS configuration from your DNS service provider
To simplify the process of migrating an existing subdomain to Route 53, get the current DNS configuration for the domain from the DNS service provider that is currently servicing the domain. You can use this information as a basis for configuring Route 53 as the DNS service for the subdomain.
What you ask for and the format that it comes in depends on which company you're currently using as your DNS service provider. Ideally, they'll give you a zone file, which contains information about all of the records in your current configuration. (Records tell DNS how you want traffic to be routed for your domains and subdomains. For example, when someone enters your domain name in a web browser, do you want traffic to be routed to a web server in your data center, to an Amazon EC2 instance, to a CloudFront distribution, or to some other location?) If you can get a zone file from your current DNS service provider, you can edit the zone file to remove the records that you don't want to migrate to Amazon Route 53. Then you can import the remaining records into your Route 53 hosted zone, which greatly simplifies the process. Try asking customer support for your current DNS service provider how to get a *zone file* or a *records list*.
## Creating records
Using the records that you got from your current DNS service provider as a starting point, create corresponding records in the Amazon Route 53 hosted zone that you created for the subdomain. The records that you create in Route 53 will become the records that DNS uses after you delegate responsibility for the subdomain to Route 53, as explained in [Updating your DNS service with name server records for the subdomain](#UpdateOldDNS), later in the process.
**Important**
Do not create additional name server (NS) or start of authority (SOA) records in the Route 53 hosted zone, and do not delete the existing NS and SOA records.
To create records using the Route 53 console, see [Working with records](rrsets-working-with.md). To create records using the Route 53 API, use `ChangeResourceRecordSets`. For more information, see [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) in the *[Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/)*.
## Checking the status of your changes (API only)
Creating a new hosted zone and changing records take time to propagate to the Route 53 DNS servers. If you used [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) to create your records, you can use the `GetChange` action to determine whether your changes have propagated. (`ChangeResourceRecordSets` returns a value for `ChangeId`, which you can include in a subsequent `GetChange` request. `ChangeId` is not available if you created the records by using the console.) For more information, see [GET GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) in the *Amazon Route 53 API Reference*.
**Note**
Changes generally propagate to all Route 53 name servers within 60 seconds.
## Updating your DNS service with name server records for the subdomain
After your changes to Amazon Route 53 records have propagated (see [Checking the status of your changes (API only)](#MigratingSubdomainCheckStatus)), update the DNS service for the parent domain by adding NS records for the subdomain. This is known as delegating responsibility for the subdomain to Route 53. For example, suppose the parent domain example.com is hosted with another DNS service and you're migrating the subdomain test.example.com to Route 53. You must create a hosted zone for test.example.com and update the DNS service for example.com with the NS records that Route 53 assigned to the new hosted zone for test.example.com.
Perform the following procedure.
1. Using the method provided by your DNS service, back up the zone file for the parent domain.
1. If the previous DNS service provider for the domain has a method to change the TTL settings for their name servers, we recommend that you change the settings to 900 seconds. This limits the time during which client requests will try to resolve domain names using obsolete name servers. If the current TTL is 172800 seconds (two days), which is a common default setting, you still need to wait two days for resolvers and clients to stop caching DNS records using the previous TTL. After the TTL settings expire, you can safely delete the records that are stored at the previous provider and make changes only to Route 53.
1. In the Route 53 console, get the name servers for your Route 53 hosted zone:
1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. In the navigation pane, click **Hosted zones**.
1. On the **Hosted zones** page, choose the radio button (not the name) for the hosted zone, then choose **View details**.
1. On the details page for the hosted zone, choose **Hosted zone details**.
1. Make note of the four servers listed for **Name servers**.
Alternatively, you can use the `GetHostedZone` action. For more information, see [GetHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetHostedZone.html) in the *Amazon Route 53 API Reference*.
1. Using the method provided by the DNS service of the parent domain, add NS records for the subdomain to the zone file for the parent domain. Give the NS records the same name as the subdomain. For the values in the NS records, specify the four Route 53 name servers that are associated with the hosted zone that you created in Step 2. Note that different DNS services use different terminology. You might need to contact technical support for your DNS service to learn how to perform this step.
**Important**
Do not add a start of authority (SOA) record to the zone file for the parent domain. Because the subdomain will use Route 53, the DNS service for the parent domain is not the authority for the subdomain.
If your DNS service automatically added an SOA record for the subdomain, delete the record for the subdomain. However, do not delete the SOA record for the parent domain.
Depending on the TTL settings for the name servers for the parent domain, the propagation of your changes to DNS resolvers can take 48 hours or more. During this period, DNS resolvers may still answer requests with the name servers for the DNS service of the parent domain. In addition, client computers may continue to have the previous name servers for the subdomain in their cache.
1. After the registrar's TTL settings for the domain expire (see Step 2), delete the following records from the zone file for the parent domain:
+ The records that you added to Route 53 as described in [Creating records](#AddMigratedSubdomainRecords).
+ Your DNS service's NS records. When you are finished deleting NS records, the only NS records in the zone file will be the ones that you created in Step 4.
# Transitioning to latency-based routing in Amazon Route 53
With latency-based routing, Amazon Route 53 can direct your users to the lowest-latency AWS endpoint available. For example, you might associate a DNS name like `www.example.com` with an ELB Classic, Application, or Network Load Balancer, or with Amazon EC2 instances or Elastic IP addresses that are hosted in the US East (Ohio) and Europe (Ireland) regions. The Route 53 DNS servers decide, based on network conditions of the past couple of weeks, which instances in which regions should serve particular users. A user in London will likely be directed to the Europe (Ireland) instance, a user in Chicago will likely be directed to the US East (Ohio) instance, and so on. Route 53 supports latency-based routing for A, AAAA, TXT, and CNAME records, as well as aliases to A and AAAA records.
**Note**
Data about the latency between users and your resources is based entirely on traffic between users and AWS data centers. If you aren't using resources in an AWS Region, the actual latency between your users and your resources can vary significantly from AWS latency data. This is true even if your resources are located in the same city as an AWS Region.
For a smooth, low-risk transition, you can combine weighted and latency records to gradually migrate from standard routing to latency-based routing with full control and rollback capability at each stage. Let's consider an example in which `www.example.com` is currently hosted on an Amazon EC2 instance in the US East (Ohio) region. The instance has the Elastic IP address `W.W.W.W`. Suppose you want to continue routing traffic to the US East (Ohio) region when applicable while also beginning to direct users to additional Amazon EC2 instances in the US West (N. California) region (Elastic IP `X.X.X.X`) and in the Europe (Ireland) region (Elastic IP `Y.Y.Y.Y`). The Route 53 hosted zone for `example.com` already has a record for `www.example.com` that has a **Type** of A and a **Value** (an IP address) of `W.W.W.W`.
When you're finished with the following example, you'll have two weighted alias records:
+ You'll convert your existing record for `www.example.com` into a weighted alias record that continues to direct the majority of your traffic to your existing Amazon EC2 instance in the US East (Ohio) region.
+ You'll create another weighted alias record that initially directs only a small portion of your traffic to your latency records, which route traffic to all three regions.
By updating the weights in these weighted alias records, you can gradually shift from routing traffic only to the US East (Ohio) region to routing traffic to all three regions in which you have Amazon EC2 instances.
**To transition to latency-based routing**
1. Make a copy of the record for `www.example.com`, but use a new domain name, for example, `copy-www.example.com`. Give the new record the same **Type** (A) and **Value** (`W.W.W.W`) as the record for `www.example.com`.
1. Update the existing A record for `www.example.com` to make it a weighted alias record:
+ For **Value/Route traffic to**, choose **Alias to another record in this hosted zone**, and specify `copy-www.example.com`.
+ For **Weight**, specify 100.
When you're finished with the update, Route 53 will continue to use this record to route all traffic to the resource that has an IP address of `W.W.W.W`.
1. Create a latency record for each of your Amazon EC2 instances, for example:
+ US East (Ohio), Elastic IP address `W.W.W.W`
+ US West (N. California), Elastic IP address `X.X.X.X`
+ Europe (Ireland), Elastic IP address `Y.Y.Y.Y`
Give all of the latency records the same domain name, for example, `www-lbr.example.com` and the same type, A.
When you're finished creating the latency records, Route 53 will continue to route traffic using the record that you updated in Step 2.
You can use `www-lbr.example.com` for validation testing, for example, to ensure that each endpoint can accept requests.
1. Let's now add the `www-lbr.example.com` latency record into the `www.example.com` weighted record and begin routing limited traffic to the corresponding Amazon EC2 instances. This means that the Amazon EC2 instance in the US East (Ohio) region will be getting traffic from both weighted records.
Create another weighted alias record for `www.example.com`:
+ For **Value/Route traffic to**, choose **Alias to another record in this hosted zone**, and specify `www-lbr.example.com.`
+ For **Weight**, specify 1.
When you finish and your changes are synchronized to Route 53 servers, Route 53 will begin to route a tiny fraction of your traffic (1/101) to the Amazon EC2 instances for which you created latency records in Step 3.
1. As you develop confidence that your endpoints are adequately scaled for the incoming traffic, adjust the weights accordingly. For example, if you want 10% of your requests to be based on latency-based routing, change the weights to 90 and 10, respectively.
For more information about creating latency records, see [Creating records by using the Amazon Route 53 console](resource-record-sets-creating.md).
# Adding another Region to your latency-based routing in Amazon Route 53
If you're using latency based routing and you want to add an instance in a new region, you can gradually shift traffic to the new region in the same way that you gradually shifted traffic to latency-based routing in [Transitioning to latency-based routing in Amazon Route 53](TutorialTransitionToLBR.md).
For example, suppose you're using latency-based routing to route traffic for `www.example.com`, and you want to add an Amazon EC2 instance in Asia Pacific (Tokyo) to your instances in US East (Ohio), US West (N. California), and Europe (Ireland). The following example procedure explains one way that you could add an instance in another region.
For this example, the Amazon Route 53 hosted zone for `example.com` already has a weighted alias record for `www.example.com` that is routing traffic to the latency-based records for `www-lbr.example.com`:
+ US East (Ohio), Elastic IP address `W.W.W.W`
+ US West (N. California), Elastic IP address `X.X.X.X`
+ Europe (Ireland), Elastic IP address `Y.Y.Y.Y`
The weighted alias record has a weight of 100. After you transitioned to latency-based routing, assume that you deleted the other weighted record that you used for the transition.
**To add another Region to your latency-based routing in Route 53**
1. Create four new latency-based records that include the three original regions as well as the new region to which you want to start routing traffic.
+ US East (Ohio), Elastic IP address `W.W.W.W`
+ US West (N. California), Elastic IP address `X.X.X.X`
+ Europe (Ireland), Elastic IP address `Y.Y.Y.Y`
+ Asia Pacific (Tokyo), Elastic IP address `Z.Z.Z.Z`
Give all of the latency records the same new domain name, for example, `www-lbr-2012-04-30.example.com`, and the same type, A.
When you're finished creating the latency records, Route 53 will continue to route traffic using the original weighted alias record (`www.example.com`) and latency records (`www-lbr.example.com`).
You can use the `www-lbr-2012-04-30.example.com` records for validation testing, for example, to ensure that each endpoint can accept requests.
1. Create a weighted alias record for the new latency records:
+ For the domain name, specify the name for the existing weighted alias record, `www.example.com`.
+ For **Value/Route traffic to**, choose **Alias to another record in this hosted zone**, and specify `www-lbr-2012-04-30.example.com`.
+ For **Weight**, specify 1.
When you finish, Route 53 will begin to route a tiny fraction of your traffic (1/101) to the Amazon EC2 instances for which you created the `www-lbr-2012-04-30.example.com` latency records in Step 1. The remainder of the traffic will continue to be routed to the `www-lbr.example.com` latency records, which do not include the Amazon EC2 instance in the Asia Pacific (Tokyo) region.
1. As you develop confidence that your endpoints are adequately scaled for the incoming traffic, adjust the weights accordingly. For example, if you want 10% of your requests to be routed to the latency records that include the Tokyo region, change the weight for `www-lbr.example.com` from 100 to 90 and the weight for `www-lbr-2012-04-30.example.com` from 1 to 10.
For more information about creating records, see [Creating records by using the Amazon Route 53 console](resource-record-sets-creating.md).
# Using latency and weighted records in Amazon Route 53 to route traffic to multiple Amazon EC2 instances in a Region
If your application is running on Amazon EC2 instances in two or more Amazon EC2 regions, and if you have more than one Amazon EC2 instance in one or more regions, you can use latency-based routing to route traffic to the correct region and then use weighted records to route traffic to instances within the region based on weights that you specify.
For example, suppose you have three Amazon EC2 instances with Elastic IP addresses in the US East (Ohio) region and you want to distribute requests across all three IPs evenly for users for whom US East (Ohio) is the appropriate region. Just one Amazon EC2 instance is sufficient in the other regions, although you can apply the same technique to many regions at once.
**To use latency and weighted records in Amazon Route 53 to route traffic to multiple Amazon EC2 instances in a region**
1. Create a group of weighted records for the Amazon EC2 instances in the region. Note the following:
+ Give each weighted record the same value for **Record name** (for example, `us-east.example.com`) and **Record type**.
+ For **Value/Route traffic to**, choose **IP address or another value depending on the record type**, and specify the value of one of the Elastic IP addresses.
+ If you want to weight the Amazon EC2 instances equally, specify the same value for **Weight**.
+ Specify a unique value for **Set ID** for each record.
For more information about weighted record values, see [Weighted routing](routing-policy-weighted.md)
1. If you have multiple Amazon EC2 instances in other regions, repeat Step 1 for the other regions. Specify a different value for **Name** in each region.
1. For each region in which you have multiple Amazon EC2 instances (for example, US East (Ohio)), create a latency alias record. For **Value/Route traffic to**, choose **Alias to another record in this hosted zone**, and specify the value of the **Record name** field (for example, `us-east.example.com`) that you assigned to the weighted records in that region.
1. For each region in which you have one Amazon EC2 instance, create a latency record. For **Record name**, specify the same value that you specified for the latency alias records that you created in Step 3. For **Value/Route traffic to**, choose **IP address or another value depending on the record type**, and specify the Elastic IP address of the Amazon EC2 instance in that Region.
For more information about adding alias records to Amazon EC2 instances, see [Routing traffic to an Amazon EC2 instance](routing-to-ec2-instance.md)
For more information about creating records, see [Creating records by using the Amazon Route 53 console](resource-record-sets-creating.md).
# Managing over 100 weighted records in Amazon Route 53
Amazon Route 53 lets you configure weighted records. For a given name and type (for example, `www.example.com`, type A), you can configure up to 100 alternative responses, each with its own weight. When responding to queries for `www.example.com`, Route 53 DNS servers select a weighted random response to return to DNS resolvers. The value of a weighted record that has a weight of 2 is returned, on average, twice as often as the value of a weighted record that has a weight of 1.
If you need to direct traffic to more than 100 endpoints, one way to achieve this is to use a tree of weighted alias records and weighted records. For example, the first "level" of the tree may be up to 100 weighted alias records, each of which can, in turn, point to up to 100 weighted records. Route 53 permits up to three levels of recursion, allowing you to manage up to 1,000,000 unique weighted endpoints.
A simple two-level tree might look like this:
**Weighted alias records**
+ `www.example.com` aliases to `www-a.example.com` with a weight of 1
+ `www.example.com` aliases to `www-b.example.com` with a weight of 1
**Weighted records**
+ `www-a.example.com`, type A, value 192.0.2.1, weight 1
+ `www-a.example.com`, type A, value 192.0.2.2, weight 1
+ `www-b.example.com`, type A, value 192.0.2.3, weight 1
+ `www-b.example.com`, type A, value 192.0.2.4, weight 1
For more information about creating records, see [Working with records](rrsets-working-with.md).
# Weighting fault-tolerant multi-record answers in Amazon Route 53
**Note**
Records that use the multivalue answer routing policy behave in much the same way as the configuration that is documented in this tutorial. The main difference is that the tutorial configuration lets you specify weights, which can be useful when your endpoints have different capacities. For more information, see [Multivalue answer routing](routing-policy-multivalue.md).
An Amazon Route 53 weighted record can only be associated with one record, meaning a combination of one name (for example, `example.com`) and one record type (for example, A). But it is often desirable to weight DNS responses that contain multiple records.
For example, you might have eight Amazon EC2 instances or Elastic IP endpoints for a service. If the clients of that service support connection retries (as all common browsers do), then providing multiple IP addresses in DNS responses provides those clients with alternative endpoints in the event of the failure of any particular endpoint. You can even protect against the failure of an availability zone if you configure responses to contain a mix of IPs hosted in two or more availability zones.
Multi-record answers are also useful when a large number of clients (for example, mobile web applications) share a small set of DNS caches. In this case, multi-record answers allow clients to direct requests to several endpoints even if they receive a common DNS response from the shared cache.
These types of weighted multi-record answers can be achieved by using a combination of records and weighted alias records. You can group eight endpoints into two distinct record sets containing four IP addresses each:
`endpoint-a.example.com`, type A, with the following values:
+ 192.0.2.1
+ 192.0.2.2
+ 192.0.2.128
+ 192.0.2.129
`endpoint-b.example.com`, type A, with the following values:
+ 192.0.2.3
+ 192.0.2.4
+ 192.0.2.130
+ 192.0.2.131
You can then create a weighted alias record that points to each group:
+ `www.example.com` aliases to `endpoint-a.example.com`, type A, weight 1
+ `www.example.com` aliases to `endpoint-b.example.com`, type A, weight 1
For more information about creating records, see [Working with records](rrsets-working-with.md).