This page shows how to enable session affinity for your Cloud Runservice revision.

How session affinity works

By default, session affinity is not enabled, so requests fromthe same client might be handled by different instances, as shownhere:

If you enable session affinity, Cloud Run routes sequential requestsfor a given client to the same revision instance. Cloud Runuses a session affinity cookie with a TTL of 30 days, and inspects its value toidentify multiple requests by the same client and directs all these requests tothe same instance, as shown here:

Key behaviors to be aware of

As shown in the diagram above, with session affinity enabled, a client will reach thesame instance. However, note that the instance can receiverequests from different clients. Session affinity does not mean that theinstance is dedicated only to one client.

Due to the autoscaling behavior of Cloud Run, session affinity isbest effort affinity. If the instance is terminated for any reason, or reachesmaximum request concurrency or maximum CPU utilization, then sessionaffinity is broken and further requests are routed to a different instance.

Although you can cache client session data in memory of instances,you cannot assume that a client will always reconnect to the same instance,even when session affinity is enabled.

Cloud Load Balancing session affinity and Cloud Run session affinity are two separate and independent implementations of session affinity.You can enable Cloud Run's session affinity on a Cloud Run service, even if it's behind a load balancer.However, you shouldn't enable Cloud Load Balancing session affinity on aserverless network endpoint group, since it'snot supported.

Session affinity and traffic splitting

You enable or disable session affinity at the revision level. If youenable session affinity on a Cloud Run revision and also usetraffic splitting,session affinity takes precedence over any traffic splitting. In extreme cases, ifa single client using session affinity is responsible for a vast majority of allrequests, all of those requests can be routed to a given revision regardless ofthe traffic splitting configuration.

If you enable traffic splitting for revisions where some of the revisions have sessionaffinity enabled and some do not, the result is that requests are gradually shiftedtowards revisions that have session affinity enabled, even though you do not explicitlychange the traffic split configuration. The reason for this is that every requestthat doesn't have a session affinity cookie attached is subject to a random split,where some will eventually be assigned to a revision with session affinity andsubsequently those requests will stay with that particular revision.

When updating the traffic splitting configuration for a Cloud Runservice, subsequent requests with session affinitycookies attached might be assigned to a different revision.Cloud Run minimizes the number of clients that areredirected to a new revision.

For example, if a service was splitting traffic at 90%/10%, and the trafficsplit is updated to 80%/20%, then 10% of the traffic will be redirected tothe revision that is now serving 20% of the traffic.

Set session affinity

Any configuration change leads to thecreation of a new revision. Subsequent revisions will also automatically getthis configuration setting unless you make explicit updates to change it.

You can set session affinity using the Google Cloud console, thegcloud command line, or using a .yaml file when youcreate a new service ordeploy a new revision:

gcloudrunservicesupdateSERVICE--session-affinity

gcloudrunservicesupdateSERVICE--no-session-affinity

resource"google_cloud_run_v2_service""default"{name="cloudrun-service-aff"location="REGION"deletion_protection=falseingress="INGRESS_TRAFFIC_ALL"template{containers{image="us-docker.pkg.dev/cloudrun/container/hello"}session_affinity=BOOL}}

View session affinity settings

To view the current session affinity settings for yourCloud Run service: