Can I ignore Set-Cookie for static assets? CloudFlare with AWS ALB origin

Currently I have a slightly irritating issue with static assets served from an AWS Application Load Balancer (ALB) origin with sticky sessions enabled.

ALB sets a cookie called AWSALB so it can try to send a user to the same instance in the pool for every request. This is useful for dynamic requests, but some of the static resources (CSS and JavaScript mainly) also come from the origin. The Set-Cookie header added by ALB means that CloudFlare bypasses its cache for all of these resources, slowing them down and unnecessarily sending requests to the origin.

Is there a way to whitelist or ignore this cookie? I suspect I could do it with workers, but given they run pre-cache that is an awful lot of requests I’d have to pay for given everything is completely static.

I know that it would be better not to use sticky sessions, or to serve static assets from an alternative domain with a different ALB setup, or to ship assets to a single location at deploy time. These are medium term options, though not without their own complications, but it would be good to understand if there is something I can do in the interim to quickly get static assets cached by CloudFlare.

You are correct. There are two people posting similar questions related to AWS ELB sticky sessions for the past 2 days.

This is one of the ways to remove cookies in the response.

Is your website handles different content/response based on different user/session? If yes, you’d better leave sticky session turn on in AWS ELB.

I guess this is a better way, and you can eliminate AWS ELB because you are just hosting static assets and most of the time they will be cached by Cloudflare.


Anyway, if you are not using AWS Auto Scaling group in conjunction with ELB, then Cloudflare Load Balancer may suit your use case, since it supports sticky sessions too.

Apologies. I did try to search but it may be I got caught out by the change of name from ELB to ALB.

This may be worth a try. It makes me slightly nervous moving the load balancer outside the same ecosystem, but its’ not doing anything all that clever right now (no auto scaling), and gives us plenty of problems when we have to ask AWS support to prewarm the ALB, so maybe this route would bring some advantages.

No worries. If you are not using Auto Scaling group, you can give Cloudflare Load Balancer a try (unless you are going to implement Auto Scaling group in the future).

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.