Category: Route 53

Reduce DDoS Risks Using Amazon Route 53 and AWS Shield

by Jeff Barr | on | in AWS Shield, Route 53 | | Comments

In late October of 2016 a large-scale cyber attack consisting of multiple denial of service attacks targeted a well-known DNS provider. The attack, consisting of a flood of DNS lookups from tens of millions of IP addresses, made many Internet sites and services unavailable to users in North America and Europe. This Distributed Denial of Service (DDoS) attack was believe to have been executed using a botnet consisting of a multitude of Internet-connected devices such as printers, camera, residential network gateways, and even baby monitors. These devices had been infected with the Mirai malware and generated several hundreds of gigabytes of traffic per second. Many corporate and educational networks simply do not have the capacity to absorb a volumetric attack of this size.

In the wake of this attack and others that have preceded it, our customers have been asking us for recommendations and best practices that will allow them to build systems that are more resilient to various types of DDoS attacks. The short-form answer involves a combination of scale, fault tolerance, and mitigation (the AWS Best Practices for DDoS Resiliency white paper goes in to far more detail) and makes use of Amazon Route 53 and AWS Shield (read AWS Shield – Protect Your Applications from DDoS Attacks to learn more).

Scale – Route 53 is hosted at numerous AWS edge locations, creating a global surface area capable of absorbing large amounts of DNS traffic. Other edge-based services, including Amazon CloudFront and AWS WAF, also have a global surface area and are also able to handle large amounts of traffic.

Fault Tolerance – Each edge location has many connections to the Internet. This allows for diverse paths and helps to isolate and contain faults. Route 53 also uses shuffle sharding and anycast striping to increase availability. With shuffle sharding, each name server in your delegation set corresponds to a unique set of edge locations. This arrangement increases fault tolerance and minimizes overlap between AWS customers. If one name server in the delegation set is not available, the client system or application will simply retry and receive a response from a name server at a different edge location. Anycast striping is used to direct DNS requests to an optimal location. This has the effect of spreading load and reducing DNS latency.

Mitigation – AWS Shield Standard protects you from 96% of today’s most common attacks. This includes SYN/ACK floods, Reflection attacks, and HTTP slow reads. As I noted in my post above, this protection is applied automatically and transparently to your Elastic Load Balancers, CloudFront distributions, and Route 53 resources at no extra cost. Protection (including deterministic packet filtering and priority based traffic shaping) is deployed to all AWS edge locations and inspects all traffic with just microseconds of overhead, all in a totally transparent fashion. AWS Shield Advanced includes additional DDoS mitigation capability, 24×7 access to our DDoS Response Team, real time metrics and reports, and DDoS cost protection.

To learn more, read the DDoS Resiliency white paper and learn about Route 53 anycast.



New – Route 53 Traffic Flow

by Jeff Barr | on | in Route 53 | | Comments

I registered my first domain name almost 20 years ago! Back then, the mapping from a domain name to a server was simple and straightforward. Load balancers, geographic redundancy, website monitoring, cloud computing, and the like had not yet entered the scene. The mapping was always from a domain name to a single, unchanging IP address.

Today of course, the situation is a lot different. The mapping from domain name to IP address is no longer necessarily 1 to 1. Sophisticated sites can route requests to servers that are as close as possible to the requester, and may also want to use the requester’s location in other ways.

Route 53 Traffic Flow
In order to make it easier for you to build and run cloud-based applications that embody these characteristics, we introduced a new Traffic Flow feature for Amazon Route 53 last week. You can use this feature to build a routing system that uses a combination of geographic location, latency, and availability to route traffic from your users to your cloud or on-premises endpoints.

You can build your traffic routing policies from scratch, or you can pick a template from a library and then customize it. You can create multiple policies for a given DNS name, and decide which one is active at any given time. Even better, you can do all of this graphically, from within the Route 53 Console.

Creating a Traffic Policy
I will create a traffic policy for one of my domain names, I start by entering a name and a description:

The console displays the graphical traffic policy editor:

The Start point is simply a DNS entry:

It can connect to several different types of rules and endpoints:

If I choose to create a new endpoint, the editor prompts me for the details:

I can map the Start point to an IP address by choosing Value and entering the address:

At this point I have designed a simple policy that maps the A record to a fixed IP address.

Perhaps I have a production server and a pre-production server, and I would like to send 95% of the traffic to the first one and the remaining 5% to the second. I can do this by creating a Weighted rule that looks like this:

As you can see above, I can also point each element of the rule at one of my Route 53 health checks. If I do this, traffic will be routed to the endpoint only if the health check indicates that the endpoint is healthy.

I can also create a Failover rule. For example, I can route traffic to an IP address if the server is healthy, and to a static, fallback website hosted in S3 if it is not. Here’s how I do that:

The next option is to create a Geolocation rule. I can use a rule of this type to route traffic based on the geographic origin of the DNS query. Here’s a sample:

The final type of rule is called a Latency rule. A rule of this type routes traffic to the AWS region with the lowest latency, as measured from the location of the DNS request. Perhaps I have EC2 instances in the US East (Northern Virginia) and Asia Pacific (Tokyo) regions, and want to provide a good experience by routing traffic as appropriate. Here’s how I would set that up:

The rules can be combined to create more complex traffic flows. Here’s part of a policy that combines Geolocation, Latency, Weighting, and Failover rules, in that order:

After all of this experimentation, I moved ahead with the first policy that I showed up: a simple mapping from IP address to endpoint. I clicked on Save as new version.

Create Policy Records
The next is to create policy records that actually implement (DNS-wise) the traffic policy. The console makes this really easy. I simply select the domain name and the DNS name:

When this action finishes (generally within a minute or two), the DNS records for the new policy take effect in Route 53. As is always the case when you make changes, the DNS TTL (Time to Live) for the domain can mean that changes can take a while to propagate to other DNS servers and to client applications that cache the results of DNS lookups.

You can create and store multiple versions of each of your traffic policies, and then put any desired version in to effect (by creating policy records) as desired:

Available Now
This new feature is available now and you can start using it today. To learn more, read about Using Traffic Flow to Route DNS Traffic in the Route 53 Developer Guide. Pricing starts at $50.00 per policy record per month (see Route 53 Pricing for more info).


Route 53 Improvements – Calculated Health Checks and Latency Checks

by Jeff Barr | on | in Route 53 | | Comments

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service. Route 53 connects user requests to infrastructure running in AWS (EC2 instances, load balancers, and S3 buckets), and can also be used to route users to infrastructure outside of AWS. You can configure Route 53 to perform periodic health checks, and to fail over to alternate endpoints should a check fail. You can also create a monitoring & alerting system for your websites and applications using the health checks.

Today we are adding two new types of health checks: calculated and latency measurement.

Calculated Health Checks
You can now combine the results of multiple Route 53 health checks into a single value using Boolean operations (AND, OR, and NOT). This allows you to create a single health check that combines the results of other checks in a useful way. For example, I have three web sites on the same EC2 instance. I’ll start by creating health checks for each one:

Next I’ll create a calculated health check that represents the overall health of the instance:

As you can see from the screen shot, I could also choose to create a health check that would report as healthy as long as a certain number (perhaps 2 out of 3) of the other health checks were also healthy. This would avoid false alarms and would allow me to take one site down for maintenance without causing this health check to fail.

While my example checked three different domains that happened to be running on the same instance, this is not a constraint. You could check multiple website components that happened to be on the same domain but managed by different administrative groups within your organization. Or, you could check multiple domains that supply web services to your app, and then roll up the results into a single check that represents the state of your dependencies.

Latency Measurement Health Checks
You can also configure Route 53 to measure and report on metrics that affect latency: TCP connection time, time to first byte, and (for SSL connections) the time to complete the SSL handshake. The first one indicates how long it takes Route 53 to establish a connection to the endpoint; the second one indicates the overall time until the first byte of data is returned. The third measures the time it takes to set up an SSL connection, an operation which involves 2 round-trips.

The latency measurement is performed as a part of the health check, and (if you check on Latency graphs) reported to CloudWatch.

Here’s how you configure latency measurement when you are setting up a health check:

The results are visible in the Console:

You can view the results with respect a single AWS region by selecting it from menu (a blended result is shown by default). You can also see the individual metrics (currently 32 per endpoint) in the CloudWatch console:

Available Now
The new health checks are available now and you can start using them today. Take a look at the Route 53 Pricing page to learn more about pricing for health checks.


Route 53 Update – Tagging, CloudTrail, One-Click Alarms, Visible Health Check Status

by Jeff Barr | on | in Amazon CloudTrail, Amazon CloudWatch, Route 53 |

Amazon Route 53 is a highly available and scalable Domain Name Service (DNS) web service. In a nutshell, it translates symbolic names such as into numerical IP addresses like

Today we are making Route 53 even more useful with the addition of four new features:

  1. Tagging of domains and hosted zones.
  2. API logging via CloudTrail.
  3. One-click alarms.
  4. Visible health check status.

Let’s take a look at each of these new features!

Tagging of Route 53 Resources
You can now organize your Route 53 resources (domains, hosted zones, and health checks) using tags. You can use the Cost Explorer to track the costs of the tagged resources and you can use Resource Groups to create and maintain collections of resources that share a common set of tags:

You can add and manage tags from the AWS Command Line Interface (CLI), the AWS Tools for Windows PowerShell, and the Route 53 APIs.

API Logging via CloudTrail
Calls to the Route 53 API are now logged to AWS CloudTrail. The information collected by CloudTrail can be used for resource tracking, security analysis, and compliance auditing.

One-Click Alarms
You can now create CloudWatch alarms to monitor the health of your Route 53 domains with a single click:

Visible Health Check Status
The status of your health checks is now visible at a glance in the Route 53 console:

Available Now
These features are available now and you can start using them today!




AWS Expansion – WorkSpaces, Directory Service, ElastiCache, GovCloud, Kinesis, Traditional Chinese, More

by Jeff Barr | on | in Amazon CloudFront, Amazon ElastiCache, Amazon Kinesis, Amazon WorkSpaces, AWS Directory Service, AWS GovCloud (US), Route 53 | | Comments

We’ve increased the geographic footprint and international relevance of several AWS services this past month. Here’s a summary:

For more information on service availability, please take a look at our Products and Services by Region page.



Resource Groups and Tagging for AWS

by Jeff Barr | on | in Amazon EC2, Amazon Elastic MapReduce, Amazon RDS, Amazon S3, Route 53, Virtual Private Cloud | | Comments

For many years, AWS customers have used tags to organize their EC2 resources (instances, images, load balancers, security groups, and so forth), RDS resources (DB instances, option groups, and more), VPC resources (gateways, option sets, network ACLS, subnets, and the like) Route 53 health checks, and S3 buckets. Tags are used to label, collect, and organize resources and become increasingly important as you use AWS in larger and more sophisticated ways. For example, you can tag relevant resources and then take advantage AWS Cost Allocation for Customer Bills.

Today we are making tags even more useful with the introduction of a pair of new features: Resource Groups and a Tag Editor. Resource Groups allow you to easily create, maintain, and view a collection of resources that share common tags. The new Tag Editor allows you to easily manage tags across services and Regions. You can search globally and edit tags in bulk, all with a couple of clicks.

Let’s take a closer look at both of these cool new features! Both of them can be accessed from the new AWS menu:

Tag Editor
Until today, when you decided to start making use of tags, you were faced with the task of stepping through your AWS resources on a service-by-service, region-by-region basis and applying tags as needed. The new Tag Editor centralizes and streamlines this process.

Let’s say I want to find and then tag all of my EC2 resources. The first step is to open up the Tag Editor and search for them:

The Tag Editor searches my account for the desired resource types across all of the selected Regions and then displays all of the matches:

I can then select all or some of the resources for editing. When I click on the Edit tags for selected button, I can see and edit existing tags and add new ones. I can also see existing System tags:

I can see which values are in use for a particular tag by simply hovering over the Multiple values indicator:

I can change multiple tags simultaneously (changes take effect when I click on Apply changes):

Resource Groups
A Resource Group is a collection of resources that shares one or more tags. It can span Regions and services and can be used to create what is, in effect, a custom console that organizes and consolidates the information you need on a per-project basis.

You can create a new Resource Group with a couple of clicks. I tagged a bunch of my AWS resources with Service and then added the EC2 instances, DB instances, and S3 buckets to a new Resource Group:

My Resource Groups are available from within the AWS menu:

Selecting a group displays information about the resources in the group, including any alarm conditions (as appropriate):

This information can be further expanded:

Each identity within an AWS account can have its own set of Resource Groups. They can be shared between identities by clicking on the Share icon:

Down the Road
We are, as usual, very interested in your feedback on this feature and would love to hear from you! To get in touch, simply open up the Resource Groups Console and click on the Feedback button.

Available Now
Resource Groups and the Tag Editor are available now and you can start using them today!


Route 53 Update – Private DNS and More

by Jeff Barr | on | in Amazon EC2, Route 53, Virtual Private Cloud | | Comments

Amazon Route 53 is a highly available and scalable Domain Name Service. As you probably know, it translates domain names in to numerical IP addresses. This level of indirection allows you to refer to a computer by its name (which usually remains the same for an extended period of time) instead of by its address (which could change from minute to minute for any number of reasons).

Up until now, the primary use for [r53_u] is for lookup of global, public names. While it was sometimes possible to use it for private names within an Amazon Virtual Private Cloud, the names were still globally visible, even if the IP addresses were internal to the VPC and hence unreachable.

Today we are announcing Private DNS for Route 53. You can now easily manage authoritative DNS within your Virtual Private Clouds. This allows you to use custom DNS names for your internal resources without exposing the names or IP addresses to the public Internet.

As part of today’s launch, we are upgrading the AWS Management Console so that it provides you with additional information when a health check fails. We are also announcing support for reusable delegation sets. This will simplify management of name servers when you are using Route 53 to manage multiple domains.

Let’s take a look at each of these new features!

Private DNS
You can now use Route 53 to manage the internal DNS names for your application resources (web servers, application servers, databases, and so forth) without exposing this information to the public Internet. This adds an additional layer of security, and also allows you to fail over from a primary resource to a secondary one (often called a “flip”) by simply mapping the DNS name to a different IP address.

Route 53 also allows you set up Split-horizon DNS. Once set up, a given DNS name will map to one IP address when a lookup is initiated from within a VPC, and to a different address when the lookup originates elsewhere.

You can get started with Route 53 Private DNS by creating a Route 53 Hosted Zone, choosing the Private Hosted Zone option, and designating a VPC:

The console will display the type of each of your hosted zones:

To learn, read the documentation for Working with Private Hosted Zones.

Reusable Delegation Sets
When you use Route 53 to host DNS for a domain, it sets up four authoritative name servers collectively known as a delegation set. As part of today’s release we are simplifying domain management by allowing you to use the same delegation set for any number of your domains. This is a somewhat advanced, API-only feature that can prove to be useful in a couple of different ways:

  • If you are moving a large group of domains from another provider to Route 53, you can provide them with a single list of four name servers and have them applied to all of the domains that you are moving.
  • You can create generic “white label” name servers such as and, use them in your delegation set, and point them to your actual Route 53 name servers.

To learn more, read the API documentation for Actions on Reusable Delegation Sets.

Health Check Failure Reasons
We introduced Health Checks for Route 53 last year and added editing and tagging of health checks earlier this year. We are now extending this feature again and are making the results of each health check available in the Console and the Route 53 API. Here’s how they appear in the Console:

Note that the health checks cannot connect with services that are running within a private subnet of a VPC. Similarly, Route 53 Private DNS records cant be associated with health checks.

Go For It
These features are available now and you can start using them today!


Route 53 Update – Domain Name Registration, Geo Routing, and a Price Reduction

by Jeff Barr | on | in Price Reduction, Route 53 | | Comments

Amazon Route 53 is a highly available and scalable Domain Name Service (DNS), including a powerful Health Checking Service. Today we are extending Route 53 with support for domain name registration and management and Geo DNS. We are also reducing the price for Route 53 queries! Let’s take a closer look at each one of these items.

Domain Name Registration and Management
I registered my first domain name in 1995! Back then, just about every aspect of domain management and registration was difficult, expensive, and manual. After you found a good name, you had to convince one or two of your tech-savvy friends to host your DNS records, register the name using an email-based form, and then bring your site online. With the advent of web-based registration and multiple registrars the process became a lot smoother and more economical.

Up until now, you had to register your domain at an external registrar, create the Hosted Zone in Route 53, and then configure your domain’s entry at the registrar to point to the Route 53 name servers. With today’s launch of Route 53 Domain Name Registration, you can now take care of the entire process from within the AWS Management Console (API access is also available, of course). You can buy, manage, and transfer (both in and out) domains from a wide selection of generic and country-specific top-level domains (TLDs). As part of the registration process, we’ll automatically create and configure a Route 53 Hosted Zone for you. You can think up a good name, register it, and be online with static (Amazon Simple Storage Service (S3)) or dynamic content (Amazon Elastic Compute Cloud (EC2), AWS Elastic Beanstalk, or AWS OpsWorks) in minutes.

If you, like many other AWS customers, own hundreds or thousands of domain names, you know first-hand how much effort goes in to watching for pending expirations and renewing your domain names. By transferring your domain to Route 53, you can take advantage of our configurable expiration notification and our optional auto-renewal. You can avoid embarrassing (and potentially expensive) mistakes and you can focus on your application instead of on your domain names. You can even reclaim the brain cells that once stored all of those user names and passwords.

Let’s walk through the process of finding and registering a domain name using the AWS Management Console and the Route 53 API.

The Route 53 Dashboard gives me a big-picture view of my Hosted Zones, Health Checks, and Domains:

I begin the registration process by entering the desired name and selecting a TLD from the menu:

The console checks on availability within the selected domain and in some other popular domains. I can add the names I want to the cart (.com and .info in this case):

Then I enter my contact details:

I can choose to enable privacy protection for my domain. This option will hide most of my personal information from the public Whois database in order to thwart scraping and spamming.

When everything is ready to go, I simply agree to the terms and my domain(s) will be registered:

I can see all of my domains in the console:

I can also see detailed information on a single domain:

I can also transfer domains into or out of Route 53:

As I mentioned earlier, I can also investigate, purchase, and manage domains through the Route 53 API. Let’s say that you are picking a name for a new arrival to your family and you want to make sure that you can acquire a suitable domain name (in most cases, consultation with your significant other is also advisable). Here’s some code to automate the entire process! I used the AWS SDK for PHP.

The first step is to set the desired last name and gender, and the list of acceptable TLDs:

$LastName = 'Barr';
$Gender   = 'F';
$TLDs     = array('.com', '.org');

Then I include the AWS SDK and the PHP Simple HTML DOM and create the Route 53 client object:

require 'aws.phar';
require 'simple_html_dom.php';

// Connect to Route 53
$Client = \Aws\Route53Domains\Route53DomainsClient::factory(array('region' => 'us-east-1'));

Now I need an array of the most popular baby names. I took this list and parsed the HTML to create a PHP array:

$HTML       = file_get_html("");
$FirstNames = array();

$Lists = $HTML->find('table tr ol');
$Items = $Lists[($Gender == 'F') ? 0 : 1];

foreach ($Items->find('li') as $Item)
  $FirstNames[] = $Item->find('a', 0)->innertext;

With the desired last name and the list of popular first names in hand (or in memory to be precise), I can generate interesting combinations and call the Route 53 checkDomainAvailability function to see if they are available:

foreach ($FirstNames as $FirstName)
  foreach ($TLDs as $TLD)
    $DomainName = $FirstName . '-' . $LastName . $TLD;

    $Result = $Client->checkDomainAvailability(array(
      'DomainName'  => $DomainName,
      'IdnLangCode' => 'eng'));
  echo "{$DomainName}: {$Result['Availability']}\n";

I could also choose to register the first available name (again, consultation with your significant other is recommended here). I’ll package up the contact information since I’ll need it a couple of times:

$ContactInfo = array(
  'ContactType'      => 'PERSON',
  'FirstName'        => 'Jeff',
  'LastName'         => 'Barr',
  'OrganizationName' => 'Amazon Web Services',
  'AddressLine1'     => 'XXXX  Xth Avenue',
  'City'             => 'Seattle',
  'State'            => 'WA',
  'CountryCode'      => 'US',
  'ZipCode'          => '98101',
  'PhoneNumber'      => '+1.206XXXXXXX',
  'Email'            => '');

And then I use the registerDomain function to register the domain:

if ($Result['Availability'] === 'AVAILABLE')
  echo "Registering {$DomainName}\n");

  $Result = $Client->registerDomain(array(
    'DomainName'              => $DomainName,
    'IdnLangCode'             => 'eng',
    'AutoRenew'               => true,
    'DurationInYears'         => 1,
    'BillingContact'          => $ContactInfo,
    'RegistrantContact'       => $ContactInfo,
    'TechContact'             => $ContactInfo,
    'AdminContact'            => $ContactInfo,
    'OwnerPrivacyProtected'   => true,
    'AdminPrivacyProtected'   => true,
    'TechPrivacyProtected'    => true,
    'BillingPrivacyProtected' => true));

Geo Routing
Route 53’s new Geo Routing feature lets you choose the most appropriate AWS resource for content delivery based on the location where the DNS queries originate. You can now build applications that respond more efficiently to user requests, with responses that are wholly appropriate for the location. Each location (a continent, a country, or a US state) can be independently mapped to static or dynamic AWS resources. Some locations can receive static resources served from S3 while others receive dynamic resources from an application running on EC2 or Elastic Beanstalk.

You can use this feature in many different ways. Here are a few ideas to get you started:

  • Global Applications – Route requests to Amazon Elastic Compute Cloud (EC2) instances hosted in an AWS Region that is in the same continent as the request. You could do this to maximize performance or to meet legal or regulatory requirements.
  • Content Management – Provide users access with access to content that has been optimized, customized, licensed, or approved for their geographic location. For example, you could choose to use distinct content and resources for red and blue portions of the United States. Or, you could run a contest or promotion that is only valid in certain parts of world and use this feature to provide an initial level of filtering.
  • Consistent Endpoints – Set up a mapping of locations to endpoints to ensure that a particular location always maps to the same endpoint. If you are running a MMOG, routing based on location can increase performance, reduce latency, give you better control over time-based scaling, and increase the likelihood that users with similar backgrounds and cultures will participate in the same shard of the game.

To make use of this feature, you simply create some Route 53 Record Sets that have the Routing Policy set to Geolocation. Think of each Record Set as a mapping from a DNS entry (e.g. to a particular AWS resource an S3 bucket, an EC2 instance, or an Elastic Load Balancer. With today’s launch, each Record Set with a Geolocation policy becomes effective only when the incoming request for the DNS entry originates within the bounds (as determined by an IP to geo lookup) of a particular continent, country, or US state. The Record Sets form a hierarchy in the obvious way and the most specific one is always used. You can also choose to create a default entry that will be used if no other entries match.

You can set up this feature from the AWS Management Console, the Route 53 API, or the AWS Command Line Interface (CLI). Depending on your application, you might want to think about an implementation that generates Record Sets based on information coming from a database of some sort.

Let’s say that I want to provide static content to most visitors to, and dynamic content to visitors from Asia. Here’s what I need to do. First I create a default Record Set for “www” that points to my S3 bucket:

Then I create another one “www”, this one Geolocated for Asia. This one points to an Elastic Load Balancer:

Price Reduction
Last, but certainly not least, I am happy to tell you that we have reduced the prices for Standard and LBR (Latency-Based Routing) queries by 20%. The following prices go in to effect as of August 1, 2014:

  1. Standard Queries – $0.40 per million queries for the first billion queries per month; $0.20 per million queries after that.
  2. LBR Queries – $0.60 per million queries for the first billion queries per month; $0.30 per million queries after that.
  3. Geo DNS Queries – $0.70 per million queries for the first billion queries per month; $0.35 per million queries after that.

Available Now
These new features are available now and the price reduction goes in to effect tomorrow.


PS – Thanks to Steve Nelson of AP42 for digging up the Internic Domain Registration Template!

New Location for CloudFront and Route 53 – Melbourne, Australia

by Jeff Barr | on | in Amazon CloudFront, Route 53 | | Comments

I am happy to announce the launch of an edge location in Melbourne, Australia for Amazon CloudFront and Amazon Route 53.

Global Coverage
This new location will improve performance and availability for end users of applications being served by CloudFront and Route 53 and bring the total number of AWS edge locations to 52 worldwide. Here’s the breakdown:

  • United States (20)
  • Europe (16)
  • Asia (12)
  • Australia (2)
  • South America (2)

CloudFront and Route 53 customers don’t need to do anything to your applications to take advantage of this new edge location – requests from your end users in these locations will automatically be routed for the best possible performance.

Full Functionality
This new edge location supports all Amazon CloudFront functionality, including accelerating your entire website (static, dynamic and interactive content), live and on-demand streaming media, and security features like custom SSL certificates, private content, and geo-restriction of content. It also supports all Amazon Route 53 functionality including health checks, DNS failover, and latency-based routing.

Learn More at our Webinars
If you are interested in using CloudFront and would like to learn more about the newest features, please consider joining us for the following online events:


Route 53 Health Check Update – Editing and Tagging

by Jeff Barr | on | in Route 53 | | Comments

Amazon Route 53 is a highly available and highly scalable DNS service. Route 53 is able to meet the needs of complex enterprises, while remaining simple enough to be a good fit for personal websites.

We added support for Route 53 health checks a little over a year ago, and have enhanced the model several times since then. We now publish the results to CloudWatch and graph them in the AWS Management Console. We also support string matching and checking of HTTPS sites and checking based on domain names.

Today we are enhancing the Route 53 health check model again. The checks are now editable, and can be tagged for tracking and cost accounting purposes. We are also adding a couple of additional API functions.

Editable Health Checks
You can now edit the parameters of existing health checks. This is easier and more efficient than deleting and re-creating the health check when you need to alter the target IP address or domain name, port, filename / path, or search string:

With this change, health checks gain long term value. You can change the parameters without having to re-associate them with the desired record sets, and you no longer lose the CloudWatch history.

Tagging of Health Checks
Over the past couple of years, we have given you the ability to add tags (name/value pairs) to many types of AWS resources. Today we continue that tradition, giving you the ability to add tags to your Route 53 health checks. The Name tag is added to all new health checks automatically; you can add it to your existing health checks with a couple of clicks. You can use cost allocation tags for billing purposes or to attach other kinds of metadata to your health checks.

You can also select a health check to see its tags:

New API Functions
We have added a pair of new functions to the Route 53 API. You can use these functions to increase the power and sophistication of your DNS management and monitoring tools. Here’s what we have added:

  • GetCheckerIpRanges – This function returns the list of the IP ranges that Route 53 uses to check the health of your resources. You can configure your route and firewall rules to allow access from these ranges for health checking purposes.
  • GetHealthCheckCount – This function returns the number of health checks that are associated with your AWS account.

Available Now
As usual, these new features are available now and you can start using them today.