An ALIAS record is just an internal-to-Route-53 mapping "when people ask for X, pretend they asked for Y instead". This is conceptually similar to a server-side CNAME. The reason these don't have TTL is because users don't see them.
The returned record, of course, has a TTL, and the ALIAS mechanism will not alter the TTL of the aliased data, so in the case of an ELB you are talking a TTL of one hour. There are no magic bullets to the distributed cache expiration problem.
(The other comments in this article about TTL seem quite confused, though, so this explanation might not actually have helped. Even if you have a 20-year TTL, you are going to see changes immediately from clients that do not have the data cached anywhere on their path to the origin.)
(In particular, there is no difference at all to switching the ALIAS record out for an A record with regards to your TTL: if the user has the target of the old mapping cached they will use it, otherwise they will get the new one. It isn't really "getting away with" that behavior, and it isn't sue to Amazon's DNS being special.)
Agreed, at the time we were quite confused and still are about the intricacies of TTL. Sucks that there's not really a good way to address it. Maybe just keep the TTLs at 300 always?
Some ISPs (in particular, those in countries far from the US, such as those in the Middle East, although occasionally even Europe) do not even honor the hour-long TTL used by ELB (for reasons of latency, not load), so if you care about your traffic not being routed to someone else's server, you should not allow ELB to get exposed to end user requests (in my case, I use it to balance my backend servers, but the only incoming connections it handles are from CDNetworks, whom I know has a to-specification implementation of DNS caching).
Nicer thing to do would be to have the maintenance IP as your last A record. If the client can't reach your regular servers, it will automatically fall back to the maintenance IP.
That's not actually how A records work. Clients are supposed to randomly select one of the A records, although this doesn't always distribute the load as randomly as it should. (My company's site used to have 4 A records for 4 load balancers, and we found that one of them received 25-30% more traffic than the rest.) Clients certainly don't have a mechanism to retry if one of them fails -- they'll be stuck with the failing IP for the length of the TTL.
The returned record, of course, has a TTL, and the ALIAS mechanism will not alter the TTL of the aliased data, so in the case of an ELB you are talking a TTL of one hour. There are no magic bullets to the distributed cache expiration problem.
(The other comments in this article about TTL seem quite confused, though, so this explanation might not actually have helped. Even if you have a 20-year TTL, you are going to see changes immediately from clients that do not have the data cached anywhere on their path to the origin.)
(In particular, there is no difference at all to switching the ALIAS record out for an A record with regards to your TTL: if the user has the target of the old mapping cached they will use it, otherwise they will get the new one. It isn't really "getting away with" that behavior, and it isn't sue to Amazon's DNS being special.)