- What is a Domain Name System (DNS) Service?
- What is Amazon Route 53?
- What can I do with Amazon Route 53?
- How do I get started with Amazon Route 53?
- How does Amazon Route 53 provide high availability and low latency?
- What are the DNS server names for the Amazon Route 53 service?
- How do I transfer my existing domain to Amazon Route 53 without disrupting my existing web traffic?
- Which DNS record types does Amazon Route 53 support?
- Does Amazon Route 53 support wildcard entries? If so, what record types support them?
- Does Amazon Route 53 support Weighted Round Robin (WRR)?
- Can I point my zone apex (example.com versus www.example.com) at my Elastic Load Balancer?
- Can I point my zone apex (example.com versus www.example.com) at my website hosted on Amazon S3?
- Can I point my zone apex (example.com versus www.example.com) at my Amazon CloudFront distribution?
- Can I use 'Alias' records with sub-domains?
- Does Amazon Route 53 support DNSSEC?
- Does Amazon Route 53 also provide website hosting?
- How can I use Amazon Route 53 with Amazon Simple Storage Service (Amazon S3) and Amazon CloudFront?
- How quickly will changes I make to my DNS settings on Amazon Route 53 propagate globally?
- Does Amazon Route 53 use an anycast network?
- What is the default TTL for the various record types and can I change these values?
- What is the difference between a Domain and a Hosted Zone?
- Are changes to resource records sets transactional?
- What is the price of Amazon Route 53?
- Can I register domain names with Amazon Route 53?
- What types of access controls can I set for the management of my Domains on Amazon Route 53?
- Can I create multiple hosted zones for the same domain name?
- Is there a limit to the number of domains I can manage using Amazon Route 53?
- Does Amazon Route 53 support IPv6?
- Can I associate multiple IP addresses with a single record?
- Can I use Amazon Route 53 to manage my organization’s private IP addresses?
- I have subscribed for Amazon Route 53 but when I try to use the service it says "The AWS Access Key ID needs a subscription for the service"
- What is Amazon Route 53’s Latency Based Routing (LBR) feature?
- How do I get started using Amazon Route 53’s latency Based Routing (LBR) feature?
- What is the price for Amazon Route 53's Latency Based Routing (LBR) feature?
- Does Amazon Route 53 offer a Service Level Agreement (SLA)?
- What is DNS Failover?
- How do I get started with DNS Failover?
- Does DNS Failover support Elastic Load Balancers (ELBs) as endpoints?
- Can I configure a backup site only to be used when a health check fails?
- What DNS record types can I associate with Route 53 health checks?
- Can I health check an endpoint if I don’t know its IP address?
- One of my endpoints is outside AWS. Can I set up DNS Failover on this endpoint?
- If failover occurs and I have multiple healthy endpoints remaining, will Route 53 consider the load on my healthy endpoints when determining where to send traffic from the failed endpoint?
- How many consecutive health check observations does an endpoint need to fail to be considered “failed”?
- When my failed endpoint becomes healthy again, how is the DNS failover reversed?
- What is the interval between health check observations?
- How much load should I expect a health check to generate on my endpoint (for example, a web server)?
- Do Route 53 health checks follow HTTP redirects?
- What is the sequence of events when failover happens?
- Do I need to adjust the TTL for my records in order to use DNS Failover?
- What happens if all of my endpoints are unhealthy?
- Can I use DNS Failover without using Latency Based Routing (LBR)?
- Can I configure a health check on a site accessible only via HTTPS?
- Do HTTPS health checks validate the endpoint’s SSL certificate?
- Do HTTPS health checks support Server Name Indication (SNI)?
- How can I use health checks to verify that my web server is returning the correct content?
- How do I see the status of a health check that I’ve created?
- How can I be notified if one of my endpoints starts failing its health check?
- I created an alarm for my health check, but I need to re-send the confirmation email for the alarm's SNS topic. How can I re-send this email?
- I’m using DNS Failover with Elastic Load Balancers (ELBs) as endpoints. How can I see the status of these endpoints?
- What is the cost to use CloudWatch metrics for my Route 53 health checks?
- How can I import a zone into Route 53?
DNS is a globally distributed service that translates human readable names like www.example.com into the numeric IP addresses like 192.0.2.1 that computers use to connect to each other. The Internet’s DNS system works much like a phone book by managing the mapping between names and numbers. For DNS, the names are domain names (www.example.com) that are easy for people to remember and the numbers are IP addresses (192.0.2.1) that specify the location of computers on the Internet. DNS servers translate requests for names into IP addresses, controlling which server an end user will connect to when they type a domain name into their web browser.
Amazon Route 53 is a highly available and scalable DNS service designed to give developers and businesses an extremely reliable and cost effective way to route end users to Internet applications. The name for our service (Route 53) comes from the fact that DNS servers respond to queries on port 53 and provide answers that route end users to your applications on the Internet.
With Amazon Route 53, you can create and manage your public DNS records. Like a phone book, Route 53 lets you manage the IP addresses listed for your domain names in the Internet’s DNS phone book. Route 53 also answers requests to translate specific domain names like www.example.com into their corresponding IP addresses like 192.0.2.1. You can use Route 53 to create DNS records for a new domain or transfer DNS records for an existing domain. The simple, standards-based REST API for Route 53 allows you to easily create, update and manage DNS records.
Amazon Route 53 has a simple web service interface that lets you get started in minutes. Your DNS records are organized into “hosted zones” that you configure with the AWS Management Console or Route 53’s API. To use Route 53, you simply:
- Subscribe to the service by clicking on the sign-up button on the service page.
- Use the AWS Management Console or the CreateHostedZone API to create a hosted zone that can store DNS records for your domain. Upon creating the hosted zone, you receive four Route 53 name servers across four different Top-Level Domains (TLDs) to help ensure a high level of availability.
- Your hosted zone will be initially populated with a basic set of DNS records, including four virtual name servers that will answer queries for your domain. You can add, delete or change records in this set by using the AWS Management Console or by calling the ChangeResourceRecordSet API . A list of supported DNS records is available here.
- Inform the registrar with whom you registered your domain name to update the name servers for your domain to the ones associated with your hosted zone.
Route 53 is built using AWS’s highly available and reliable infrastructure. The globally distributed nature of our DNS servers helps ensure a consistent ability to route your end users to your application by circumventing any internet or network related issues. Route 53 is designed to provide the level of dependability required by important applications. Using a global anycast network of DNS servers around the world, Route 53 is designed to automatically answer queries from the optimal location depending on network conditions. As a result, the service offers low query latency for your end users.
To provide you with a highly available service, each Amazon Route 53 hosted zone is served by its own set of virtual DNS servers. The DNS server names for each hosted zone are thus assigned by the system when that hosted zone is created.
First, you need to get a list of the DNS record data for your domain name, generally available in the form of a “zone file” that you can get from your existing DNS provider. With the DNS record data in hand, you can use Route 53’s Management Console or simple web-services interface to create a hosted zone that can store the DNS records for your domain. To complete the domain transfer process, inform the registrar with whom you registered your domain name to update the name servers for your domain to the ones associated with your hosted zone. As soon as your registrar propagates the new name server delegations, the DNS queries from your end users will start to get answered by the Route 53 DNS servers.
Amazon Route 53 currently supports the following DNS record types:
- A (address record)
- AAAA (IPv6 address record)
- CNAME (canonical name record)
- MX (mail exchange record)
- NS (name server record)
- PTR (pointer record)
- SOA (start of authority record)
- SPF (sender policy framework)
- SRV (service locator)
- TXT (text record)
- Additionally, Route 53 offers ‘Alias’ records (a Route 53-specific virtual record). Alias records are used to map resource record sets in your hosted zone to Elastic Load Balancing load balancers, CloudFront distributions, or S3 buckets that are configured as websites. Alias records work like a CNAME record in that you can map one DNS name (example.com) to another ‘target’ DNS name (elb1234.elb.amazonaws.com). They differ from a CNAME record in that they are not visible to resolvers. Resolvers only see the A record and the resulting IP address of the target record.
We anticipate adding additional record types in the future.
Yes. To make it even easier for you to configure DNS settings for your domain, Amazon Route 53 supports wildcard entries for all record types. A wildcard entry is a record in a DNS zone that will match requests for any domain name based on the configuration you set. For example, a wildcard DNS record such as *.example.com will match queries for www.example.com and subdomain.example.com.
Yes. Weighted Round Robin allows you to assign weights to resource record sets in order to specify the frequency with which different responses are served. You may want to use this capability to do A/B testing, sending a small portion of traffic to a server on which you’ve made a software change. For instance, suppose you have two record sets associated with one DNS name—one with weight 3 and one with weight 1. In this case, 75% of the time Route 53 will return the record set with weight 3 and 25% of the time Route 53 will return the record set with weight 1. Weights can be any number between 0 and 255.
Yes. Amazon Route 53 offers a special type of record called an ‘Alias’ record that lets you map your zone apex (example.com) DNS name to your ELB DNS name (i.e. elb1234.elb.amazonaws.com). IP addresses associated with Amazon Elastic Load Balancers can change at any time due to scaling up, scaling down, or software updates. Route 53 responds to each request for an Alias record with one or more IP addresses for the load balancer. Queries to Alias records that are mapped to ELB load balancers are free. These queries are listed as “Intra-AWS-DNS-Queries” on the Amazon Route 53 usage report.
Yes. Amazon Route 53 offers a special type of record called an ‘Alias’ record that lets you map your zone apex (example.com) DNS name to your Amazon S3 website bucket (i.e. example.com.s3-website-us-west-2.amazonaws.com). IP addresses associated with Amazon S3 website endpoints can change at any time due to scaling up, scaling down, or software updates. Route 53 responds to each request for an Alias record with one IP address for the bucket. Route 53 doesn't charge for queries to Alias records that are mapped to an S3 bucket that is configured as a website. These queries are listed as “Intra-AWS-DNS-Queries” on the Amazon Route 53 usage report.
Yes. Amazon Route 53 offers a special type of record called an ‘Alias’ record that lets you map your zone apex (example.com) DNS name to your Amazon CloudFront distribution (for example, d123.cloudfront.net). IP addresses associated with Amazon CloudFront endpoints vary based on your end user’s location (in order to direct the end user to the nearest CloudFront edge location) and can change at any time due to scaling up, scaling down, or software updates. Route 53 responds to each request for an Alias record with the IP address(es) for the distribution. Route 53 doesn't charge for queries to Alias records that are mapped to a CloudFront distribution. These queries are listed as “Intra-AWS-DNS-Queries” on the Amazon Route 53 usage report.
Yes. You can also use Alias records to map your sub-domains (www.example.com, pictures.example.com, etc.) to your ELB load balancers, CloudFront distributions, or S3 website buckets.
No. Amazon Route 53 does not support DNSSEC at this time.
No. Amazon Route 53 is an authoritative DNS service and does not provide website hosting. However, you can use Amazon Simple Storage Service (Amazon S3) to host a static website. To host a dynamic website or other web applications, you can use Amazon Elastic Compute Cloud (Amazon EC2), which provides flexibility, control, and significant cost savings over traditional web hosting solutions. Learn more about Amazon EC2 here. For both static and dynamic websites, you can provide low latency delivery to your global end users with Amazon CloudFront. Learn more about Amazon CloudFront here.
For websites delivered via Amazon CloudFront or static websites hosted on Amazon S3, you can use the Amazon Route 53 service to create an Alias record for your domain which points to the CloudFront distribution or S3 website bucket. For S3 buckets not configured to host static websites, you can create a CNAME record for your domain and the S3 bucket name. In all cases, note that you will also need to configure your S3 bucket or your CloudFront distribution respectively with the alternate domain name entry to completely establish the alias between your domain name and the AWS domain name for your bucket or distribution.
For CloudFront distributions and S3 buckets configured to host static websites, we recommend creating an ‘Alias’ record that maps to your CloudFront distribution or S3 website bucket, instead of using CNAMEs. Alias records have two advantages: first, unlike CNAMEs, you can create an Alias record for your zone apex (e.g. example.com, instead of www.example.com), and second, queries to Alias records are free of charge.
Amazon Route 53 is designed to propagate updates you make to your DNS records to its world-wide network of authoritative DNS servers within 60 seconds under normal conditions. A change is successfully propagated world-wide when the API call returns an INSYNC status listing.
Note that caching DNS resolvers are outside the control of the Amazon Route 53 service and will cache your resource record sets according to their time to live (TTL). The INSYNC or PENDING status of a change refers only to the state of Route 53’s authoritative DNS servers.
Yes. Anycast is a networking and routing technology that helps your end users’ DNS queries get answered from the optimal Route 53 location given network conditions. As a result, your users get high availability and improved performance with Route 53.
The time for which a DNS resolver caches a response is set by a value called the time to live (TTL) associated with every record. Amazon Route 53 does not have a default TTL for any record type. You must always specify a TTL for each record so that caching DNS resolvers can cache your DNS records to the length of time specified through the TTL.
A domain is a general DNS concept. Domain names are easily recognizable names for numerically addressed Internet resources. For example, amazon.com is a domain. A hosted zone is an Amazon Route 53 concept. A hosted zone is analogous to a traditional DNS zone file; it represents a collection of records that can be managed together, belonging to a single parent domain name. All resource record sets within a hosted zone must have the hosted zone’s domain name as a suffix. For example, the amazon.com hosted zone may contain records named www.amazon.com, and www.aws.amazon.com, but not a record named www.amazon.ca. You can use the Route 53 Management Console or API to create, inspect, modify, and delete hosted zones.
Yes. A transactional change helps ensure that the change is consistent, reliable, and independent of other changes. Amazon Route 53 has been designed so that changes complete entirely on any individual DNS server, or not at all. This helps ensure your DNS queries are always answered consistently, which is important when making changes such as flipping between destination servers. When using the API, each call to ChangeResourceRecordSets returns an identifier that can be used to track the status of the change. Once the status is reported as INSYNC, your change has been performed on all of the Route 53 DNS servers.
Amazon Route 53 charges are based on actual usage of the service in two areas: Hosted Zones and Queries.
- You pay $0.50 per month per hosted zone for the first 25 hosted zones that you manage with Route 53, and $0.10 per month for each additional hosted zone.
- The monthly hosted zone prices are not prorated for partial months; a hosted zone is charged upon set-up and on the first day of each subsequent month. To allow testing, a hosted zone that is deleted within 12 hours of creation is not charged; however, any queries on that zone will be charged at the rates below.
- You pay $0.50 per million queries for the first 1 billion queries per month and $0.25 per million queries for any additional queries. This charge is prorated; for instance, a hosted zone with 100,000 queries would be charged $0.05. Queries to Alias records that resolve to Elastic Load Balancing instances or S3 website buckets are free of charge.
You pay only for what you use. There are no minimum fees, no minimum usage commitments, and no overage charges. You can estimate your monthly bill using the AWS Simple Monthly Calculator.
No. Amazon Route 53 does not provide registrar support or integration at this time. For Route 53 to be able to answer DNS queries for your domains, you must inform the registrar you registered your domain name with to update your name server settings, by listing the Route 53 name servers for your hosted zone.
You can control management access to your Amazon Route 53 hosted zone by using the AWS Identity and Access Management (IAM) service. AWS IAM allows you to control who in your organization can make changes to your DNS records by creating multiple users and managing the permissions for each of these users within your AWS Account. Learn more about AWS IAM here.
Yes. Creating multiple hosted zones allows you to verify your DNS setting in a “test” environment, and then replicate those settings on a “production” hosted zone. For example, hosted zone Z1234 might be your test version of example.com, hosted on name servers ns-1, ns-2, ns-3, and ns-4. Similarly, hosted zone Z5678 might be your production version of example.com, hosted on ns-5, ns-6, ns-7, and ns-8. Since each hosted zone has a virtual set of name servers associated with that zone, Route 53 will answer DNS queries for example.com differently depending on which name server you send the DNS query to.
Each Amazon Route 53 account is limited to a maximum of 500 hosted zones and 10,000 resource record sets per hosted zone. Complete our request for a higher limit here and we will respond to your request within two business days.
Amazon Route 53 supports both forward (AAAA) and reverse (PTR) IPv6 records. However, the Route 53 service itself is not available over IPv6 at this time.
Yes. Associating multiple IP addresses with a single record is often used for balancing the load of geographically-distributed web servers. Amazon Route 53 allows you to list multiple IP addresses for an A record and responds to DNS requests with the list of all configured IP addresses.
Amazon Route 53 does not currently offer a private DNS service. You can define DNS records that will return private IP addresses (addresses from RFC5735) in Route 53, but these records are themselves not private and any requester may query their value if the requester knows the record name.
When you sign up for a new AWS service, it can take up to 24 hours in some cases to complete activation, during which time you cannot sign up for the service again. If you've been waiting longer than 24 hours without receiving an email confirming activation, this could indicate a problem with your account or the authorization of your payment details. Please contact AWS Customer Service for help.
LBR (Latency Based Routing) is a new feature for Amazon Route 53 that helps you improve your application’s performance for a global audience. You can run applications in multiple AWS regions and Amazon Route 53, using dozens of edge locations worldwide, will route end users to the AWS region that provides the lowest latency.
You can start using Amazon Route 53’s new LBR feature quickly and easily by using either the AWS Management Console or a simple API. You simply create a record set that includes the IP addresses or ELB names of various AWS endpoints and mark that record set as an LBR-enabled Record Set, much like you mark a record set as a Weighted Record Set. Amazon Route 53 takes care of the rest - determining the best endpoint for each request and routing end users accordingly, much like Amazon CloudFront, Amazon’s global content delivery service, does. You can learn more about how to use Latency Based Routing in the Amazon Route 53 Developer Guide.
Like all AWS services, there are no upfront fees or long term commitments to use Amazon Route 53 and LBR. Customers simply pay for the hosted zones and queries they actually use. Please visit the Amazon Route 53 pricing page for details on pricing for Standard and Latency Based Routing queries.
Yes. The Amazon Route 53 SLA provides for a service credit if a customer’s monthly uptime percentage is below our service commitment in any billing cycle. More information can be found here.
DNS Failover consists of two components: health checks and failover. Health checks are automated requests sent over the Internet to your application to verify that your application is reachable, available, and functional. You can configure the health checks to be similar to the typical requests made by your users, such as requesting a web page from a specific URL. With DNS failover, Route 53 only returns answers for resources that are healthy and reachable from the outside world, so that your end users are routed away from a failed or unhealthy part of your application.
Visit the Amazon Route 53 Developer Guide for details on getting started. You can also configure DNS Failover from within the Route 53 Console.
Yes, you can configure DNS Failover for Elastic Load Balancers (ELBs). To enable DNS Failover for an ELB endpoint, create an Alias record pointing to the ELB and set the “Evaluate Target Health” parameter to true. Route 53 creates and manages the health checks for your ELB automatically. You do not need to create your own Route 53 health check of the ELB. You also do not need to associate your resource record set for the ELB with your own health check, because Route 53 automatically associates it with the health checks that Route 53 manages on your behalf. The ELB health check will also inherit the health of your backend instances behind that ELB. For more details on using DNS Failover with ELB endpoints, please consult the Route 53 Developer Guide.
Yes, you can use DNS Failover to maintain a backup site (for example, a static site running on an Amazon S3 website bucket) and fail over to this site in the event that your primary site becomes unreachable.
You can associate any record type supported by Route 53 except SOA and NS records.
Yes. You can configure DNS Failover for Elastic Load Balancers and Amazon S3 website buckets via the Amazon Route 53 Console without needing to create a health check of your own. For these endpoint types, Route 53 automatically creates and manages health checks on your behalf which are used when you create an Alias record pointing to the ELB or S3 website bucket and enable the "Evaluate Target Health" parameter on the Alias record.
For all other endpoints, you can specify either the DNS name (e.g. www.example.com) or the IP address of the endpoint when you create a health check for that endpoint.
Yes. Just like you can create a Route 53 resource record that points to an address outside AWS, you can set up health checks for parts of your application running outside AWS, and you can fail over to any endpoint that you choose, regardless of location. For example, you may have a legacy application running in a datacenter outside AWS and a backup instance of that application running within AWS. You can set up health checks of your legacy application running outside AWS, and if the application fails the health checks, you can fail over automatically to the backup instance in AWS.
No, Route 53 does not make routing decisions based on the load or available traffic capacity of your endpoints. You will need to ensure that you have available capacity at your other endpoints, or the ability to scale at those endpoints, in order to handle the traffic that had been flowing to your failed endpoint.
The default is a threshold of three health check observations: when an endpoint has failed three consecutive observations, Route 53 will consider it failed. However, Route 53 will continue to perform health check observations on the endpoint and will resume sending traffic to it once it passes three consecutive observations. You can change this threshold to any value between 1 and 10 observations. For more details, see the Amazon Route 53 Developer Guide.
After a failed endpoint passes the number of consecutive health check observations that you specify when creating the health check (the default threshold is three observations), Route 53 will restore its DNS records automatically, and traffic to that endpoint will resume with no action required on your part.
By default, health check observations are conducted at an interval of 30 seconds. You can optionally select a fast interval of 10 seconds between observations.
By checking three times more often, fast interval health checks enable Route 53 to confirm more quickly that an endpoint has failed, shortening the time required for DNS failover to redirect traffic in response to the endpoint’s failure.
Fast interval health checks also generate three times the number of requests to your endpoint, which may be a consideration if your endpoint has a limited capacity to serve web traffic. Visit the Route 53 pricing page for details on pricing for fast interval health checks and other optional health check features. For more details, see the Amazon Route 53 Developer Guide.
Each heath check is conducted from multiple locations around the world. Each location checks the endpoint independently at the interval that you select: the default interval of 30 seconds, an optional fast interval of 10 seconds). Based on the current number of health checking locations, you should expect your endpoint to receive one request every 2-3 seconds on average for standard interval health checks and one or more requests per second for fast-interval health checks. Note that the number of health-checking locations may vary in the future.
No. Route 53 health checks consider an HTTP 3xx code to be a successful response, so they don’t follow the redirect. This may cause unexpected results for string-matching health checks. The health check searches for the specified string in the body of the redirect. Because the health check doesn’t follow the redirect, it never sends a request to the location that the redirect points to and never gets a response from that location. For string matching health checks, we recommend that you avoid pointing the health check at a location that returns an HTTP redirect.
In simplest terms, the following events will take place if a health check fails and failover occurs:
- Route 53 conducts a health check of your application. In this example, your application fails three consecutive health checks, triggering the following events.
- Route 53 disables the resource records for the failed endpoint and no longer serves these records. This is the failover step, which causes traffic to begin being routed to your healthy endpoint(s) instead of your failed endpoint.
The time for which a DNS resolver caches a response is set by a value called the time to live (TTL) associated with every record. We recommend a TTL of 60 seconds or less when using DNS Failover, to minimize the amount of time it takes for traffic to stop being routed to your failed endpoint. In order to configure DNS Failover for ELB and S3 Website endpoints, you need to use Alias records which have fixed TTL of 60 seconds; for these endpoint types, you do not need to adjust TTLs in order to use DNS Failover.
Route 53 can only fail over to an endpoint that is healthy. If there are no healthy endpoints remaining in a resource record set, Route 53 will behave as if all health checks are passing.
Yes. You can configure DNS Failover without using LBR. In particular, you can use DNS failover to configure a simple failover scenario where Route 53 monitors your primary website and fails over to a backup site in the event that your primary site is unavailable.
Yes. Route 53 supports health checks over HTTPS, HTTP or TCP.
No, HTTPS health checks test whether it’s possible to connect with the endpoint over SSL and whether the endpoint returns a valid HTTP response code. However, they do not validate the SSL certificate returned by the endpoint.
No, HTTPS health checks do not support SNI at this time.
You can use Route 53 health checks to check for the presence of a designated string in a server response by selecting the “Enable String Matching” option. This option can be used to check a web server to verify that that the HTML it serves contains an expected string. Or, you can create a dedicated status page and use it to check the health of the server from an internal or operational perspective. For more details, see the Amazon Route 53 Developer Guide.
Each health check’s results are published as a CloudWatch metric. You can view a graph of the CloudWatch metric in the health checks tab of the Route 53 console to see the current and historical status of the health check. You can also create CloudWatch alarms on the metric in order to send notifications if the status of the health check changes.
The CloudWatch metrics for all of your Route 53 health checks are also visible in the CloudWatch console. The metric name is "HealthCheckStatus", and the CloudWatch metric contains the Health Check ID (for example, 01beb6a3-e1c2-4a2b-a0b7-7031e9060a6a) which you can use to identify which health check the metric is tracking.
Because each Route 53 health check publishes its results as a CloudWatch metric, you can configure the full range of CloudWatch notifications and automated actions which can be triggered when the health check value changes beyond a threshold that you specify. First, in either the Route 53 or CloudWatch console, configure a CloudWatch alarm on the health check metric. Then add a notification action and specify the email or SNS topic that you want to publish your notification to. Please consult the Route 53 Developer Guide for full details.
Confirmation emails can be re-sent from the SNS console.To find the name of the SNS topic associated with the alarm, click the alarm name within the Route 53 console and looking in the box labeled "Send notification to."
Within the SNS console, expand the list of topics, and select the topic from your alarm. Open the "Create Subscription" box and select Email for protocol and enter the desired email address. Clicking "Subscribe" will re-send the confirmation email.
The recommended method for setting up DNS Failover with ELB endpoints is to use Alias records with the "Evaluate Target Health" option. Because you don't create your own health checks for ELB endpoints when using this option, there are no specific CloudWatch metrics generated by Route 53 for these endpoints.
You can get metrics on the health of your load balancer in two ways. First, Elastic Load Balancing publishes metrics that indicate the health of the load balancer and the number of healthy instances behind it. For details on configuring CloudWatch metrics for ELB, consult the ELB developer guide. Second, you can create your own health check against the CNAME provided by the ELB, e.g. elb-example-123456678.us-west-2.elb.amazonaws.com. You won’t use this health check for DNS Failover itself (because the “Evaluate Target Health” option provides DNS Failover for you), but you can view the CloudWatch metrics for this health check and create alarms to be notified if the health check fails.
For complete details on using DNS Failover with ELB endpoints, please consult the Route 53 Developer Guide.
CloudWatch metrics for Route 53 health checks are available free of charge.
Route 53 supports importing standard DNS zone files which can be exported from many DNS providers as well as standard DNS server software such as BIND. For newly-created hosted zones, as well as existing hosted zones that are empty except for the default NS and SOA records, you can paste your zone file directly into the Route 53 console, and Route 53 automatically creates the records in your hosted zone. To get started with zone file import, read our walkthrough in the Amazon Route 53 Developer Guide.