IMHO the answer is incorrect for this ALB question

[dimaz]

Please see the screenshot. Question never mentions that application is stateless and if it is not, disabling session stickiness can be pretty bad and should not be viewed as a valid solution. Also, question does not say that 6 instances were added after the first instance was accepting the load for some time (and thus causing sessions to “stick” to it), it can read like all 7 instances were deployed at the same time in which case session stickiness should not cause issues. And wrongly configured health check CAN potentially cause that effect making ALB believe that the 6 additional instances are unhealthy so not routing traffic to them. Overall it feels like the question is not very clear and the answer is not 100% correct for the question as it is worded now.

Cheers

[Nikee-TutorialsDojo]

Hello Dimaz,

Thank you for messaging us. Let me clarify why option 1 is the correct answer.

The most effective solution to the problem described in the question is Option 1: Turn off sticky sessions on the ALB. Sticky sessions, when enabled, direct traffic from the same client to the same EC2 instance for the duration of the session. This can cause one EC2 instance to receive a disproportionate amount of traffic, leading to performance issues and increased latency, as described in the question. Since the problem is that traffic is favoring a single EC2 instance, sticky sessions are likely the cause. Disabling sticky sessions will allow the ALB to distribute traffic more evenly across all healthy EC2 instances, improving load balancing and ensuring that no single instance is overloaded.

On the other hand, Option 4: Modify the interval for health checks would not directly address the issue of traffic imbalance. Health checks ensure that only healthy instances receive traffic, but the question doesn’t indicate that instances are being marked as unhealthy. The core problem here seems to be that traffic is being routed unevenly to one instance, and modifying health check intervals would not solve that. If the cases are healthy, adjusting the health check timing won’t change the traffic distribution behavior. Therefore, Option 1 is the more appropriate solution as it directly tackles the cause of the traffic imbalance, ensuring better load balancing across all instances.

Hope this helps clarify your confusion. Please message us if you have further questions.

Regards,

Nikee @ Tutorials Dojo

[dimaz]

Hi, Nikee, thanks for replying so quick.

I agree with your reasons that health check interval may not be an answer here but my main point is that session stickiness can not be a valid solution either. I do understand how session stickiness works, I used it before, but the thing is that if your application keeps the state (the session data) and expects requests from the same user/session to end up on the same EC2 instance – you can NOT disable session stickiness as it will break the user experience completely – users will be treated as authenticated by one instance and unauthenticated by another. You can only disable session stickiness if you know your application is ok with it – that is it is stateless. But the question does not mention that so it is just not safe to make a change like that knowing it may make a situation worse and replace one overloaded instance with equally distributed load but users being unable to use the app.

Cheers

[Nikee-TutorialsDojo]

Hi Dimaz,

Thanks for your further response and thoughtful points. I understand where you’re coming from, especially when it comes to stateful applications and the importance of session stickiness. However, based on the details provided, I’d like to reiterate why Option 1: Turn off sticky sessions, is the most appropriate answer for the scenario presented in the question.

The question clearly describes a situation where traffic favors a single EC2 instance, leading to latency issues due to the overloaded instance. In cases like this, one of the common causes is session stickiness (also known as session affinity), which directs all requests from a given client (based on the session) to the same EC2 instance.

When session stickiness is enabled on the Application Load Balancer (ALB), the traffic can become unevenly distributed, particularly when multiple users or sessions exist. This results in one EC2 instance receiving more traffic than others, which leads to overloading of that instance and latency in handling requests, as you mentioned.

As suggested in Option 1, disabling session stickiness would allow the ALB to distribute the traffic more evenly across all healthy EC2 instances. This helps prevent one instance from getting overloaded because all requests for the same session keep going to that instance. By turning off session stickiness, the load balancer ensures that requests are sent to different instances rather than always routing the same user session to one specific instance.

In a stateless application, this approach makes the most sense for achieving better load balancing, which directly addresses the problem described in the question. The goal here is to fix the issue of uneven traffic distribution, which is what the question focuses on.

Regarding stateful applications, you’re correct that session stickiness is critical for stateful applications that must preserve session data or ensure that users interact with the same EC2 instance throughout their session (e.g., for user authentication). In those cases, turning off sticky sessions would indeed cause user experience issues (e.g., users being logged out or encountering broken sessions).

However, the question doesn’t provide any information suggesting that the application is stateful or that session management is a critical part of the design. Therefore, based on the scenario as worded in the question, we assume that sticky sessions are likely the cause of the issue, and turning them off would resolve the uneven load distribution problem. If the application were stateful and session stickiness was essential, the solution would be different, but that’s not explicitly stated in the question.

Given the context of the question and the symptoms described (one EC2 instance receiving more traffic than others, leading to latency), Option 1: Turn off sticky sessions is indeed the most effective and appropriate solution. Disabling sticky sessions, in this case, would allow the ALB to distribute traffic more evenly across all EC2 instances, addressing the issue of latency and improving overall performance.

We will update the question to specify whether the application is stateful or stateless to ensure better clarity. This will help avoid any confusion about when turning off sticky sessions would be appropriate and provide the question as clearly as possible for all scenarios.

I hope this helps clarify the reasoning behind choosing Option 1 as the best solution for this particular scenario. Feel free to reach out if you’d like to discuss this further!

Best regards,

Nikee @ Tutorials Dojo