
Route 53 Traffic Flow - tobltobs
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/traffic-flow.html?sc_ichannel=em&sc_icountry=global&sc_icampaigntype=launch&sc_icampaign=EM_158148660&sc_idetail=1063446210&ref_=pe_411040_158148660_9
======
astral303
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.

~~~
revertts
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...")

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

------
cddotdotslash
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...](https://aws.amazon.com/blogs/aws/new-aws-cloudformation-designer-
support-for-more-services/)

~~~
andrewvc
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!

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

~~~
tobltobs
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.

~~~
revertts
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).

------
jdmaurer
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.

------
saurik
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...](http://stackoverflow.com/questions/10115799/set-up-dns-based-url-
forwarding-in-amazon-route53)

(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](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 :/.

~~~
inopinatus
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.

