Sticky sessions for AWS NLB over TLS
Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.
Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
In certain environments, it might be mandatory to have all network traffic encrypted, even the internal traffic between your Jira nodes and the Load Balancer. AWS NLB offers the ability to encrypt traffic between the target group (Jira application nodes) and the load balancer VPS with TLS, however that removes the session stickiness functionality which is required for a Jira Data Environment.
Without session stickiness, users will keep being redirected to different nodes each time they make a request, and their requests will fail as sessions are not replicated across Jira nodes (see JRASERVER-67647 - Getting issue details... STATUS ).
Environment
- Jira Data Center
- AWS NLB as Load Balancer
- TLS traffic between targets and the NLB
Solution
Due to architectural restrictions in AWS NLB, it's not possible to enable stickiness when using TLS encryption between the LB and the targets. Customers that have faced such requirements have been instructed by Amazon support to move TLS encryption back in the chain, onto the app servers directly. The traffic can then be passed through the NLB as TCP traffic and not TLS traffic, and session stickiness is enabled on the NLB directly, without compromising complete end-to-end encryption in the environment.