From Learn Amazon Web Services in a Month of Lunches by David Clinton Until something breaks, you normally won’t spend a lot of time thinking about DNS servers – unless, of course, you want your customers to be able to access your website by its plain text name. For that to happen, you’ll have to reserve the name you’d like with a domain name registrar. The job of a registrar is to update the indexes used by the big DNS servers, so that translation requests from anyone on the Internet can be quickly satisfied. Once you’re over that critical hurdle, you can go back to ignoring DNS once again. Just don’t forget, using a dns performance test isn’t that easy… at least not yet it isn’t. You’ll quickly get used to it.

Save 37% on Learn Amazon Web Services in a Month of Lunches. Just enter code fccclinton into the discount code box at checkout at manning.com.

Working with Amazon’s Route 53

We all know how important a domain name is if you’re trying to build a big online presence. A short, concise domain name that sums up your business or website is crucial for your success. For example, a lot of people go on Authority Domains so they are able to buy their own premium dot NET domain with ease. But there are lots of different ways to purchase domain name and, as is often the case, some options are better than others. This is why we’re going to be going over one of them today — Route 53.

When you’ve found a domain name that fits your needs and Route 53 confirms that it’s available, add it to your cart and follow along through the checkout process to submit your payment for your first year’s registration fee (domain registrations usually cost between $10 and $15 a year and are not included in Free Tier usage). In a short while, your new domain will show up in the Route 53 dashboard.

Configuring your hosted zone

While your domain is now good and registered, you haven’t yet told it what to do with incoming requests. So, from the dashboard, click on “Hosted zones” and then “Create Hosted Zone.” Fill in your domain name and, assuming you want your domain to be publicly available, select “Public Hosted Zone” in the pull down menu you can see in figure 1.

Figure 1. The “Create Hosted Zone” page where you supply the basic data for your domain.

By the way, just what is a hosted zone? It’s the way AWS describes the information you provide to define how traffic aimed at your domain name will be managed.

Configuring Record Sets

When you click on the link to your new hosted zone, you’ll find yourself on a page with two pre-created record sets: SOA (Start of Authority), identifying your domain’s basic DNS configuration information; and NS, the list of authoritative name servers that can be queried about your domain host (these are the public services that provide answers to domain name translation requests).

If you are going to use a domain that’s been registered with another provider, you’ll need to copy the four NS records you see here and import them into the appropriate interface page of your provider’s account management site. This will tell Internet routers to direct any traffic aimed at your domain name to Route 53’s name servers.

We’ll need to add at least one more record. A “record set”, by the way, is a set of structured data that defines a particular aspect of domain behavior.

As you can see from figure 2, I’ve created a hosted zone for a made-up domain – stuff.org – that’s already been given NS and SOA records. Naturally, we wouldn’t get too far in the real world with stuff.org (I’m sure someone already owns it), but it’ll do nicely for this demonstration. We will now need to add a new record that will tell anyone using our domain name servers (by pointing their browsers to stuff.org) to request the IP address used by our web server. To do that, click the “Create Record Set” button and a new panel will appear on the right (it’s already visible in my example).

Figure 2. The Resource Set administration page. Here’s where you add or edit the resource sets for your hosted zone.

Since our website is accessible via a normal IPv4 IP address (as opposed to IPv6 or some other kind of resource type), we’ll select an A record type and enter our site’s public IP address into the Value box. Leaving the “Name” box empty will apply the rules of this record to requests for “stuff.org” only (as opposed to a sub domain like anothername.stuff.org or, as we’ll soon see, www.stuff.org).

The TTL (“Time To Live”) rule determines how long a target value (like, for instance, the value of a DNS record provided by a name server) will remain valid before it’s automatically refreshed. The higher the value (meaning the more time you allow between refreshes), the lower your cost. However, that also means that changes to records (i.e. updates between pages) will take longer to be noticed by end users.

It might take a few hours for the new rules to propagate through enough public records to reliably direct traffic to your site. You can always test it by simply pointing your own browser to your domain name to see what happens.

Record sets: other use cases

Now, you might be surprised to know that the way things sit right now, only browser requests using the stuff.org address will be successful, but www.stuff.org will not! That’s because “www” doesn’t really play any significant role in Internet addressing, and is treated like a separate sub domain. And that means, that unless you tell your DNS server what to do with an address formed that way, users who do type “www” won’t get to your site.

To fix that, we’ll need to create an Alias record set. Click “Create Record Set” once again, and this time enter “www” into the Name field. Click the “Yes” radio button next to Alias, and then click once in the Alias Target field that will appear. As you can see from figure 3, a menu has popped up with links to any existing record sets based on resources that might currently exist in your account that could be used as a target. “stuff.org” is the last one on the list (or, perhaps more accurately in this case, the only one available). To select stuff.org, click on it, and then click “Create”.

Figure 3. Creating a new alias record set – this time to accommodate www URL prefixes.

Note also how my first A record is now displayed along with the other active record sets in the main panel.

If you need to redirect traffic aimed at one name (like, for instance, vids.stuff.com) to a different name (like videos.stuff.com) then you could create a CNAME (Canonical Name) record. This might be useful if you’ve got a number of domains that are all supposed to lead to a single site.

I should add that all of this is possible despite the fact that the IP address I used (54.32.154.87) doesn’t actually exist, and that, obviously, I have no control over the domain stuff.org (without access to its name servers, I’d have no way to point visitors to my IP address). Route 53 provides me the platform to create as many hosted zones and record sets as my little heart desires, while leaving the practical details – like their validity – in my hands.

Having said that, I would be charged a fee of $0.50 for every month I left my stuff.org hosted zone active, regardless of how much work it was actually doing. To allow experiments and testing, AWS won’t charge for zones that are deleted within twelve hours.

Elastic IP addresses

Which IP address should you use for this hosted zone? Let’s say that you’ve made a WordPress site on EC2 – the public IP that you were assigned when you created it would work, but it would be a terrible idea to use it. That’s because there’s no guarantee that that address will be persistently associated with your EC2 instance. If, say, your instance ever crashes, it will probably receive a new IP when it starts up again (thereby breaking all the existing links to your site). At some point, you might also want the power to transfer an existing IP address from one instance to another, but that’s something you just can’t do with the IP you’ve got now.

Associating an *Amazon Elastic IP* address to your instance can solve all those problems by giving you a single, static address that you can closely control. And it’s dead easy.

From the EC2 Dashboard, click on the “Elastic IPs” link in the left panel and then on the “Allocate New Address” button. Confirm that’s what you want to do and, within a few minutes at most, the new Elastic IP will appear in the Dashboard. Once it’s there, you can associate your new IP with any existing instance (or network interface) within your account. Select your IP, click on the “Actions” button, and then on “Associate Address”, then (figure 4), click once inside the Instance field to see a list of available instances. Once you click on “Associate” that instance will be publicly accessible through the Elastic IP.

Figure 4. The Associate Address popup box you use to apply an Amazon Elastic IP address to your EC2 instance.

Routing policies

The busier your website gets, the more likely it is that you will choose to incorporate multiple servers into the overall design. You might do this to make your content more highly available so that, even if one server fails, traffic can be shifted to another one that’s still healthy. Or perhaps you want the ability to improve your users’ experience by efficiently distributing workloads across multiple resources so that no one server slows down through overwork. The health checks and routing policies that can be applied through Route 53 can simplify the configuration and management of such designs.

What’s a health check? Usually, it’s an automated, server-based process that periodically tries to load a specified remote web page to confirm that it’s still available. If the web page fails to load, some pre-determined action like an email notification or an update of a routing configuration setting will be triggered.

What about a routing policy – what’s that? That’s when you configure your networking software to base traffic routing decisions on the contents or characteristics of the moving data, or on network conditions. Yup. Ok. How about in English this time? Fine. Suppose you’re running two servers configured with significantly different capacities, each providing the same content. You don’t want to send equal volumes of traffic to each of the servers, as that might overload the weaker instance, and leave the stronger one under-utilized. To prevent that, you can create what’s called a weighted rule, where a higher proportion of total visits are directed to a particular instance. You could also set up a failover rule (where, in the event your primary server fails a health check, traffic is redirected to a backup), a geolocation rule (which serves specialized content to visitors tailored to their countries or regions of origin), or a latency rule (which directs users to the servers located geographically closest to them).

For more info on Amazon Web Services, check out the book on liveBook here and see this Slideshare presentation.