I’m wondering why tutor choose ELB over Route53? In my opinion, question doesn’t say anything about if ELB is used or not. If we just add another instance and simply add its IP to Route Route 53, we’ll get scalability without taking application down.
However, if we setup ELB and configure ELB with EC2 instances, our application will be down for sometime. Since site is hosting an e-commerce application, no one can afford to go offline especially when it’s prime time.
5 Answers
2 Reasons – Route53 is DNS service, adding more servers as demand surge, you can update Route53 records immediately but there is always inherent DNS propagation Delay (usually 30min+), another reason would be manual updation of Route53 Records everytime a server is added to the fleet. I would rather argue why not ELB Network LB – it does support sticky session, supports SSL , does load balancing too and question talks about 10x increase in traffic volume which hints at need of High thoughput which is supported Network LB
My answer to this question was ELB Network LB and I am not sure why that’s not a correct answer, since according to the documentation NLB support both sticky session and SSL – https://aws.amazon.com/elasticloadbalancing/features/. Also NLB is faster.
I think the question might be created before Sticky Session and SSL support was added to NLB. I think NLB should’ve be the correct answer as of July 2020.
Agreed NLB is the correct answer. Frustrating that the course has not been updated to reflect that. Same issue regarding the absence of Transit Gateways.
Agree NLB should be the correct answer. considering the rapid growth of traffic, NLB will be better compared to ALB.
Agree, plus, it’s cheaper than ALB. And supports TLS termination and Sticky Sessions. Actually, as the questions does not provide a specific number of answers, I would go with both: ALB and NLB.
DNS multivalue does not ensure the IP’s that it sends are indeed working when the client tries to access the IP address. R53 does follow health checks before it builds the random list of IP’s, but that does not guarantee that the IP’s it sent are working when the client accesses them (too many possible dns caches between the client and R53 is one issue).
The NLB can work, of course, but in typical AWS style, their questions will give you clues on what they are looking for. In this case, it’s a web server, so that leads us to an ALB over an NLB.
Both NLB and ALB can be in front of a web server. What’s your point by saying it’s an NLB because it’s a web server?
The scenario doesn’t describe that the sever is already in an ASG or behind an ELB. The SSL termination can happen at the web server. The simplest, not most optimal though, is Route 53 multivalue. The question doesn’t require that adding servers needs to be automatically.
ALB with health checks
The question was ask what the reasonable ways are, not what the best way is. Therefore I think the answer should be NLB and ALB.
Agree.
Spoiler Alert! The wording of the question immediately eliminates 4 of the answers.
The scenario doesn’t describe that the sever is already in an ASG or behind an ELB. The SSL termination can happen at the web server. The simplest, not most optimal though, is Route 53 multivalue. The question doesn’t require that adding servers needs to be automatically.
where the question is saying that its having only one EC2 server, I could not understand where the ELB option available also fail-over. Only cloud front distribution can reduce the load which will help cashing frequently queried item at edge location
Besides the aforementioned reasons, Route 53 Multi-Value does NOT guarantee load-balancing, because your pushing that decision/responsibility to client applications (I guess the common use-case would be failing over on client-side, not load-balancing).