1

I've taken this straight from some AWS documentation:

"As traffic to your application changes over time, Elastic Load Balancing scales your load balancer and updates the DNS entry. Note that the DNS entry also specifies the time-to-live (TTL) as 60 seconds, which ensures that the IP addresses can be remapped quickly in response to changing traffic."

Two questions:

1) I was under the impression originally that a single static IP address would be mapped to multiple instances of an AWS load balancer, thereby causing fault tolerance on the balancer level, if for instance one machine crashed for whatever reason, the static IP address registered to my domain name would simply be dynamically 'moved' to another balancer instance and continue serving requests. Is this wrong? Based on the quote above from AWS, it seems that the only magic happening here is that AWS's DNS servers hold multiple A records for your AWS registered domain name, and after 60 seconds of no connection from the client, the TTL expires and Amazon's DNS entry is updated to only start sending requests to active IP's. This still takes 60 seconds on the client side of failed connection. True or false? And why?

2) If the above is true, would it be functionally equivalent if I were using a host provider of say, GoDaddy, entered multiple "A" name records, and set the TTL to 60 seconds?

Thanks!

TyRyDurden
  • 331
  • 4
  • 15

1 Answers1

1

The ELB is assigned a DNS name which you can then assign to an A record as an alias, see here. If you have your ELB set up with multiple instances you define the health check. You can determine what path is checked, how often, and how many failures indicate an instance is down (for example check / every 10s with a 5s timeout and if it fails 2 times consider it unhealthy. When an instance becomes unhealthy all the remaining instances still serve requests just fine without delay. If the instance returns to a healthy state (for example its passes 2 checks in a row) then it returns as a healthy host in the load balancer.

What the quote is referring to is the load balancer itself. In the event it has an issue or an AZ becomes unavailable its describing what happens with the underlying ELB DNS record, not the alias record you assign to it.

Whether or not traffic is effected is partially dependent on how sessions are handled by your setup. Whether they are sticky or handled by another system like elasticache or your database.

Brandon Miller
  • 4,695
  • 1
  • 20
  • 27
  • So essentially, you purchase a domain hosted on AWS, creating a DNS entry in Amazon's DNS system, then Route 53 will receive requests at that domain name and will map requests to one or more IP addresses (which are your individual load balancer hosts composing your ELB)? And with that logic I'm assuming Route 53 plugs into the health checks and only routes to "up" load balancers? – TyRyDurden Jun 07 '18 at 01:23
  • Route53 will always route to the ELB. The ELB handles which of yours hosts are up. The ELB DNS record routes to a couple IPs at any given time. Your ELB is up in multiple zones at any given time. – Brandon Miller Jun 07 '18 at 01:30
  • Right. So let me see if I understand what you're saying. Route53 is in charge of the DNS entries. When an end user enters a domain in the URL, it will resolve (via route53) to your ELB if you so choose to point your domain to your ELB via an Alias record. From there, the ELB determines which individual LB host to forward the request to and through based on health checks. Bottom line though, end user requests to your domain name will (hypothetically) always reach your ELB, and therefore one of your LB instances. Correct? – TyRyDurden Jun 07 '18 at 01:37
  • 1
    Yep thats the gist of it. – Brandon Miller Jun 07 '18 at 01:37
  • Then to answer my original question, this is different than simply having a hostname with multiple A records pointing to the individual LB instances. In that scenario, a down instance would cause the client to have to try again in n seconds with a different IP. Using EBS and Route53, EBS is executing health checks much more rapidly, and any request that gets routed through will only be forwarded to a running LB instance. If I'm understanding the gist of it correctly. – TyRyDurden Jun 07 '18 at 01:46
  • 1
    Correct. As long as your health checks are configured to fail relatively fast when something is broken. Once a host is unhealthy it wont send traffic there anymore. – Brandon Miller Jun 07 '18 at 01:52
  • Thanks for the great explanation. I guess what I'm ultimately getting at is a recursive problem. Like what happens if the actual EBS server that manages the individual instance goes down - still a single point of failure lol. I guess there's ultimately no way around that, the request data has to be sent to a single entrypoint for this whole thing to work! – TyRyDurden Jun 07 '18 at 01:56
  • @TyRyDurden note that Elastic Beanstalk is not called "EBS." EBS is a different service. There is no single point of failure EB "server" that manages the individual instances, and the ELB nodes are fault tolerant. If an ELB node fails, its IP address is automatically removed from behind the alias target. Within 60 seconds, a failed ELB node will disappear from DNS. Failures are rare. – Michael - sqlbot Jun 07 '18 at 14:35