Alright, let's cut to the chase. I've spent the last three days chasing a ghost in my AWS bill that turned out to be *not* a misconfigured Lambda, but a cascading failure of auto-scaling groups. The root cause? Our beloved Cloudflare Access, which we slapped in front of everything for that sweet zero-trust vibe, is completely butchering session stickiness for our stateful apps.
We've got this legacy .NET app (don't ask) running on an EC2 ASG behind an ALB. The ALB is configured for sticky sessions using AWS load balancer generated cookies, the usual drill. It works flawlessly... until we put it behind a Cloudflare Access policy. The moment you require a `cloudflareaccess.com` login, the stickiness just evaporates. It's like the session affinity cookie gets lost in the handoff.
Here's the symptom loop we observed:
* User authenticates via Access (happy path).
* Hits the app, gets a `AWSALB` cookie.
* Makes a subsequent request... and gets routed to a different instance.
* Session data lost, user gets booted or sees someone else's data (nightmare fuel).
* This causes the app to spin up new sessions, hammering the backend, and suddenly my EC2 instance counts are doing interpretive dance numbers. Cha-ching. 🤑
My theory is that the Access proxy is either:
* Not passing through the session cookie correctly on the initial request.
* Modifying the request in a way that the ALB doesn't recognize it as belonging to a previous sticky session.
* Something funky with HTTPS-only cookies and the proxy's termination.
Has anyone else fought this dragon and lived to tell the tale? I've scoured the docs and community posts but mostly find people talking about *Cloudflare's own* load balancer stickiness, not preserving backend stickiness through the Access tunnel.
I tried a workaround with a Page Rule to cache the cookie, which felt like using a sledgehammer to fix a watch, and it didn't even work. My current stopgap is a horrible `workers` script that tries to inject the header, but it's brittle.
**What I need to know:**
* Is there a specific `cloudflareaccess.com` setting or header I'm missing?
* Should I be using the `CF-Connecting-IP` header or something on the ALB side to hash for stickiness instead?
* Or is the only "real" solution to move session state completely out-of-process (Redis) and accept that stickiness is dead with Access?
I love Access for what it does, but this is a massive, billable footgun for stateful applications. Spare me the "go serverless" sermon—I've already calculated the Lambda cost and it's worse.
Your cloud bill is too high.