Route 53 Traffic Flow | Hacker News Reader

Route 53 Traffic Flow

docs.aws.amazon.com

65 pointstobltobs15 comments

Be careful with Route53 if you have low-latency requirements. In my experience, Route53 has highly-variable DNS resolution latency. When I contacted Amazon, they basically said it was good enough. Tellingly, Amazon itself uses Dyn for Amazon.com.

I do absolutely love the feature set and convenience of Route53, however.

Re: latency - be careful how you're testing. Providers often announce only a subset of their IP space from any given datacenter, so you might end up with eg. a nameserver in Virginia, Dallas, and NY. If you run a synthetic round robin test you'll get variable latency. But actual resolvers will hone in on and prefer the fastest from the set, only occasionally checking the others; your real customer latency is generally equal to the fastest of available NSs. This plus the amount of caching that happens in DNS makes the performance implications of the design minimal, and it comes with huge availability advantages.

That being said, you may still get crap latencies if all four of your NSs are getting anycasted to far away places. ;)

I wouldn't read too much into amazon.com not being on R53. That company behaves like a diverse set of companies under one umbrella name, and some of those move at a much slower, much more conservative pace than others (more like "if it ain't broke...")

If it ain't broke, why aren't we using it?

This really just looks like a visual interface for what was already possible using Route53 (albeit in a much more convoluted way). It seems AWS is investing in visual alternatives for some of the more complicated aspects of its environment. They just released a similar visual editor for CloudFormation[1] a few weeks ago.

[1] https://aws.amazon.com/blogs/aws/new-aws-cloudformation-desi...

Glad to see cloud formation getting some love.

The real problem with CF however is that if something goes wrong during a CF deploy you don't have enough control to stop it. If CF doesn't have perms to remove an interface or something it can just spin for 1 or 2 hours. During that time you can't make changes to your stack!

Versioning makes it significantly more powerful than just an editor on top of Route 53 API. With Traffic Flow one can migrate records from Policy v1 to v2 or to AnotherPolicy v8 with zero downtime. DIY approach wouldn't be as trivial.

Can you use AWS53 latency, failover and geolocation for sites not hosted on EC2?

Yes you can.

Yes and no. You can use it, but with latency the only way to specify the location of your servers is by relating them to a AWS region [1]. This works more or less. Rather less for us-west [2]. For a simple failover this shouldn't matter.

[1] AWS Regions: ap-northeast-1: Asia Pacific (Tokyo) ap-southeast-1: Asia Pacific (Singapore) ap-southeast-2: Asia Pacific (Sydney) eu-central-1: EU (Frankfurt) eu-west-1: EU (Ireland) sa-east-1: South America (Sao Paulo) us-east-1: US East (N. Virginia) us-west-1: US West (N. California) us-west-2: US West (Oregon)

[2] For me the most parts of the US are mapped to us-east, even most part of the west coast. However, I am a noob in regards to DNS routing realities.

This. In general, you want to be measuring the latency directly to the resources you're routing to - the Internet's a screwy place, and latency to an AWS datacenter in Virginia might not match latency to your datacenter nearish Virginia. AWS provides a latency dataset for their infrastructure, but I'd probably stick to geo if I'm routing to resources not actually on their infra.

Other providers (eg. NS1) offer more ways to feed data into their system, so you may be able to create your own latency dataset and ship it off to them to use as a routing policy. Most large companies have built similar looking systems for tracking client latency to their DCs (look up Facebook's sonar/cartographer for an example). Synthetic, backbone monitoring like pingdom/gomez/etc. is usually not as useful for latency routing as RUM metrics.

Edit: And to be clear, failover and geo have no ties whatsoever to running on EC2. They're also common features across managed DNS providers, so it'd be very easy to run the same config across multiple providers for redundancy or migrate off of R53 without lockin (check out Netflix's denominator library).

If you are looking for these kinds of features outside of AWS, check out NS1 or Dyn.

A great idea, but the pricing seems a little steep ($50/mo/policy) for something that can already be done using routing policies in your hosted zones.

The #1 thing I want from Route 53 is a "redirect record", as I have what feels like an infinite number of hostnames whose sole purpose is to be typo-fixes for domain names with multiple obvious spellings, and the current solution from Amazon involves me having to use S3 static web hosting with redirects combined with Route 53 in a way that makes the S3 console almost impossible to browse anymore due to the insane number of bogus entries.

http://stackoverflow.com/questions/10115799/set-up-dns-based...

(And S3's feature is brittle and itself complex to configure correctly. And it requires talking to Amazon to get a bucket limit increase. And it is actually super slow, for something that can and should be implemented using Amazon's Route 53 infrastructure rather than using Amazon's S3 infrastructure: if those same nodes that already are set up for anycast also listened for HTTP and returned what are essentially DNS requests made via HTTP for that one kind of record, the problem would be solved in a way that is clean from a conceptual level and efficient from an implementation level. It would be absolutely amazing.)

This seems like a use case literally every person with a website has: you need to redirect the .net and .org to .com, for example. I have a ton more, as I have things like {cydia,mobile}{-,}impactor.{com,net,org}, but everyone has at least a few. I mean, we also all have a redirect for "www." either to or from the bare domain, right? And that one is super performance sensitive as it is used constantly: it is stupid to have that in your app layer using those resources and incurring that latency, but that is how many people set that up.

It really seems like a simple problem to solve. Maybe "too simple"? Is it just not fun to work on? There are a ton of these things that would benefit every single user, from users who barely know how to build websites to people who build complex networks of cloud resources. Another example is virtual serial console access.

Many years ago I requested this one on their forums, and I just got an email notification earlier this year telling me someone else has added a +1, after this thread died down the year after I posted it. Way way too often there is an issue on a server where the SSH daemon can't start because of some tiny mistake: you just need to log in and correct one configuration option, or even more infuriatingly, press "y" at some operating system prompt that is blocking you. I catalogued other reasons I used that feature from my old hosting provider on the thread.

https://forums.aws.amazon.com/thread.jspa?messageID=233302

Back in the day this was fatal to the server. With EBS you can unmount the disk from the computer, attach it to another one, modify it, and then put it back in the original computer... but that is not a reasonable way of solving this problem.

And this also comes up for experts: I have deployment scripts that automatically build computers, and debugging them is a pain in the ass. Amazon lets you see the console output, but it has some ludicrous delay on the data. If I could watch the process happen interactively, and then fix and continue issues while I debug my scripts, it would save me a ton of time.

My old hosting company actually had this feature, and I still use it to this day occasionally when there are network issues. If I want to mess with the box's firewall, I log in via the serial console, so I don't have to worry about firewalling myself from accessing the machine. It is downright epic.

All of the comments on Route 53 Traffic flow I am seeing here are "I can already do this better" and "I wouldn't use Amazon to build this kind of thing anyway". Solve the redirect problem: people seriously advocate for getting hosting from a cheap non-Amazon provider to do these redirects (that's what I do!) because there is no truly good way to do this currently. Build me a serial console: it is crazy that I feel like there is anywhere at all where a company like 1&1 has a better cloud-oriented feature for virtualizing running systems than EC2 :/.

How many records do you have?

Cloud instances are ephemeral. Stop treating them as long-lived pets and all the deploy/config pain you described simply vanishes. You won't even want to tail a serial port anymore. It'll be like living in the future.

Reply on news.ycombinator.com