By using AWS re:Post, you agree to the Terms of Use
AWS re:Postre:Post

CloudFront breaks session sickiness

0

We have a quite simple webapp infrastructure: 2 backend EC2 in a target group, internet facing ALB and CloudFront. Session stickiness is turned on on the target group.

When we have only one default behavior with Managed-CachingDisabled and Managed-AllViewer policies session stickiness is fine. Obviously this doesn't cache anything.

When I add a new behavior to cache resources in media folder session stickiness doesn't work any more. This policy uses one query string param in cache key, otherwise it is like Managed-CachingOptimized

both CF and ALB on HTTPS, same SSL cert installed on both.

I don't really understand why stickiness stops working even if we have AWSALB cookie on cached items too.

Please let me know if you need any other details.

Topics
ComputeNetworking & Content Delivery
Tags
Website HostingElastic Load BalancingAmazon CloudFrontApplication Load Balancer
Language
English
SkornyikG
asked a year ago971 views
1 Answer
0

Hi there,

ALB sticky sessions utilize cookies in order to determine the target that should handle subsequent requests [1], while CloudFront does not forward cookies in the origin request unless specified in either the cache policy or origin request policy. The cookies that CloudFront needs to forward will depend on whether the ALB is using duration-based cookies, application-based cookies, or both.

If the value of these cookies affects the cached content that is returned to the viewer, then you will want to ensure that each cookie name is added to your cache policy, so that the cookie and its value are part of the cache key [2]. If the value of these cookies does not affect the cached content that's returned to the viewer, then you could consider adding in these cookies in the origin request policy, or using the Managed-AllViewer origin request policy on your media cache behavior to forward the cookies to your origin [3].

If stickiness is not working even when the AWSALB cookie has been added to your cache policy, it may be that additional cookies are being utilized for stickiness that aren't being included in the cache policy or origin request policy, such as the AWSALBCORS cookie for CORS requests or "AWSALBAPP-" cookies if application-based stickiness is being used. To ensure all AWSALB-related cookies are included, you can add "AWSALB*" to your policy. You can also use your browser's developer tools or a HAR capture to identify other cookies that are being set on the client [4], and then add in the necessary cookies to your policies.

References

[1] https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html

[2] https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-the-cache-key.html

[3] https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.html

[4] https://aws.amazon.com/premiumsupport/knowledge-center/support-case-browser-har-file/

SUPPORT ENGINEER
Michael_L
answered a year ago
  • SkornyikG a year ago

    Thank you for the detailed answer. AWSALB* value doesn't affect the content and adding them to cache key doesn't make much sense to me because those values are constantly changing As origin request policy we are using Managed-AllViewer, though in case of "cache hit" there is no origin request, as I understand. Still we can see AWSALB changing on requests served from cache.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content