ARR affinity - Azure Glossary

Understand the concept

In plain English

ARR affinity is the sticky-session behavior in Azure App Service that tries to send a user back to the same worker instance after the first request. It can help older stateful web apps that keep session data on the local worker. It can also hurt scaling because traffic may not spread evenly across all instances. Modern stateless apps often disable it and store session state in Redis, a database, or another shared service. Treat ARR affinity as a compatibility choice, not a default performance feature.

Why it matters

ARR affinity matters because it can quietly turn a scaled-out App Service plan into uneven traffic distribution. One worker may become hot while others have capacity, making performance problems look like random application behavior. For stateful legacy apps, disabling it without moving session state can break users. For modern stateless apps, leaving it enabled can reduce the benefit of horizontal scaling and complicate failure recovery. Architects need to decide deliberately: either externalize state and disable affinity, or document why sticky sessions are still required. The term is small, but it changes how traffic, scale, reliability, and troubleshooting behave. That context turns an isolated setting into a practical decision about ownership, timing, risk, and measurable follow-through.

Official wording and source

ARR affinity is the Azure App Service session affinity behavior that can create sticky sessions by routing a client back to the worker that handled prior requests.

Open Microsoft Learn

Technical context

Technically, ARR affinity comes from Application Request Routing behavior in the App Service front-end layer and is configured through the clientAffinityEnabled setting. When enabled, platform cookies such as ARRAffinity can influence how repeat requests are pinned to an instance. The setting interacts with scale-out, slots, custom domains, Front Door, Application Gateway, host-name preservation, SignalR, and application-level cookies. The important design question is whether the app requires local in-memory session state. If not, disabling affinity usually improves balancing and resilience.

Exam context

Compare with

Load Balancer Front Door

Where it is used

Where you see it

You see ARR affinity in App Service general settings, ARM or Bicep properties, az webapp config output, and browser cookies named ARRAffinity. during troubleshooting, ownership review, remediation planning, and release readiness.
It appears during scale-out reviews when one worker is overloaded while other App Service instances remain mostly idle. during troubleshooting, ownership review, remediation planning, and release readiness.
It also shows up in migration work when stateful legacy apps must either keep sticky sessions or move session state elsewhere. during troubleshooting, ownership review, remediation planning, and release readiness.

Common situations

Keep or disable sticky sessions during App Service scale-out decisions.
Diagnose uneven worker load caused by client affinity cookies.
Prepare applications to move session state out of worker memory.
Validate SignalR, authentication, and cart flows before removing affinity.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 ARR affinity in action Scenario, objectives, solution, measured impact, and takeaway.

Scenario

BrightCart Apparel migrated a stateful ASP.NET storefront to Azure App Service and saw one worker saturate during promotional traffic.

Goals

Reduce uneven CPU load across scaled-out App Service instances.
Preserve shopping-cart sessions during the migration.
Avoid buying unnecessary worker capacity.
Create a safe rollback path for routing changes.

Approach using ARR affinity

Architects confirmed that local session state was the real reason ARR affinity had been left on. The team moved shopping-cart state into Azure Cache for Redis using managed identity and private networking, then tested browser flows with affinity enabled and disabled. CLI checks captured clientAffinityEnabled for staging and production slots before the swap. After release, operators watched instance-level CPU, request counts, Redis latency, and cart-abandonment metrics. ARR affinity was disabled only after canary traffic proved that any worker could serve repeat requests. They also documented owners, review cadence, rollback steps, acceptance criteria, and success thresholds so the pattern could be reused by adjacent teams without redesign.

Potential outcomes

Instance CPU imbalance dropped from 72 percentage points to under 15.
The team avoided adding two extra App Service instances for the campaign.
Cart-abandonment rate stayed within normal weekly variance after the change.
Rollback documentation let operators re-enable affinity within minutes if needed.

What to learn

ARR affinity should be decided by session architecture, not by habit or fear of scale-out.

Scenario 02 ARR affinity in action Scenario, objectives, solution, measured impact, and takeaway.

Scenario

CivicPass Benefits, a public-service portal, had random login complaints after adding Azure Front Door in front of App Service.

Goals

Stabilize user sessions across the new edge-routing path.
Identify whether App Service or Front Door affinity controlled routing.
Avoid treating routing cookies as authentication evidence.
Document the supported topology for future portal teams.

Approach using ARR affinity

The platform team traced browser cookies, Front Door origin behavior, App Service clientAffinityEnabled, and host-name preservation settings. They found that custom-domain handling caused inconsistent cookie scope while the application also depended on local session state. Engineers moved authentication session data to a shared store, corrected host-name forwarding, and disabled App Service ARR affinity after validation. Security reviewed the design to confirm no authorization decisions relied on affinity cookies. The final runbook showed how edge routing, app routing, and application cookies interacted. They also documented owners, review cadence, rollback steps, acceptance criteria, and success thresholds so the pattern could be reused by adjacent teams without redesign.

Potential outcomes

Login-related support tickets fell 63% after the shared-session release.
Security removed affinity cookies from troubleshooting evidence templates.
Front Door and App Service routing settings were standardized across three portals.
Average page latency improved 18% because traffic spread more evenly.

What to learn

ARR affinity becomes risky when teams confuse routing continuity with secure, portable session design.

Scenario 03 ARR affinity in action Scenario, objectives, solution, measured impact, and takeaway.

Scenario

FreshFleet Foods ran a driver-dispatch portal on App Service and needed predictable performance during regional lunch-hour spikes.

Goals

Support traffic spikes without pinning too many drivers to one worker.
Keep dispatch workflows stable during worker restarts.
Measure whether sticky sessions improved or hurt latency.
Reduce manual restarts used to clear hot instances.

Approach using ARR affinity

Operations first captured instance-level metrics and confirmed that the app had already externalized state into SQL and Redis. ARR affinity was still enabled from an old template. The team used CLI to verify configuration drift across regions, disabled affinity in a staging slot, and ran a synthetic driver workflow during scale-out and worker recycle tests. Production rollout happened region by region with dashboards showing per-instance request count, latency, and error rates. The incident runbook was updated to check affinity before scaling decisions. They also documented owners, review cadence, rollback steps, acceptance criteria, and success thresholds so the pattern could be reused by adjacent teams without redesign.

Potential outcomes

Hot-instance incidents dropped from nine per month to one per month.
Lunch-hour p95 latency improved 27% across the busiest regions.
Manual worker restarts were nearly eliminated during the following quarter.
Regional configuration drift was removed from all App Service templates.

What to learn

For stateless App Service apps, disabling ARR affinity can turn scale-out capacity into real performance improvement.

Azure CLI

Azure CLI is useful for ARR affinity because the setting is easy to miss in the portal during performance incidents. CLI can show clientAffinityEnabled, compare slots or environments, and apply a controlled change with a record of who changed what. Use read-only inspection before toggling anything, then validate traffic distribution and session behavior. For production, pair the CLI output with instance metrics and the application’s session-state design.

Useful for

Show App Service configuration and confirm whether clientAffinityEnabled is true for the production app.
Compare staging and production slots before a swap so affinity behavior does not change unexpectedly.
Disable ARR affinity for a stateless app after session storage and rollback plans are validated.
Capture configuration evidence during uneven instance-load incidents or post-migration performance reviews.

Before you run a command

Confirm whether the application stores session data locally, in Redis, in a database, or nowhere at all.
Check upstream services such as Front Door or Application Gateway that may also influence session affinity.
Warn owners that changing the setting can affect routing behavior and may require session validation.
Gather instance-level metrics first so post-change traffic distribution can be compared honestly.

What the output tells you

The clientAffinityEnabled value tells whether App Service is configured to use platform sticky-session behavior.
Slot or environment differences reveal drift that could surprise users during swaps, migrations, or failovers.
Instance metrics after a change show whether requests are spreading more evenly across available workers.
Cookie observations can confirm browser behavior, but configuration output remains the authoritative platform setting.

Mapped commands

Check ARR affinity setting

az webapp show --name <app-name> --resource-group <resource-group> --query clientAffinityEnabled

az webappdiscoverWeb

Disable ARR affinity

az webapp update --name <app-name> --resource-group <resource-group> --client-affinity-enabled false

az webappconfigureWeb

Architecture context

Security: Security for ARR affinity focuses on cookie behavior, session design, and front-door topology. The affinity cookie is a routing aid, not an authentication control, and the application must not treat worker affinity as proof of identity or authorization. Host-name mismatches, proxy layers, and custom domains can affect cookie scope and browser behavior. If the app stores sensitive session data on a worker, the larger security issue is local state design, not the cookie itself. Prefer external session stores with encryption, managed identity, private networking, and explicit expiration. Review whether screenshots, logs, or headers expose cookies during troubleshooting. Access reviews, logging, and exception handling keep the control accountable beyond the initial configuration and rollout. Reliability: Reliability depends on whether the application can survive worker movement. With ARR affinity enabled, users may remain tied to one worker until that worker restarts, fails, drains, or loses cookie continuity. This can protect fragile stateful sessions, but it can also concentrate load and make a single unhealthy instance affect the same users repeatedly. With affinity disabled, traffic spreads more evenly and failover is cleaner, but session state must live outside the worker. Reliable App Service designs test both scale-out and instance recycle behavior, then document the chosen setting and the evidence that user sessions still work. Runbooks should capture expected behavior, safe fallback choices, owner escalation paths, and validation after change. Operations: Operationally, ARR affinity should be visible in App Service configuration reviews, scaling runbooks, and incident diagnostics. Operators should know whether the app is stateful, where session state lives, and how many workers are serving traffic. CLI checks can confirm clientAffinityEnabled before and after a deployment or slot swap. During uneven load incidents, inspect instance-level metrics, cookies, Front Door or Application Gateway settings, and application session storage. Changing the setting can restart or affect traffic behavior, so treat it as a controlled change with rollback notes, user-impact expectations, and post-change validation. Clear ownership, repeatable checks, dated notes, and escalation paths prevent the signal from becoming tribal knowledge. Cost: Cost impact for ARR affinity is indirect but real. If sticky sessions concentrate traffic on fewer workers, teams may scale out more than necessary or overprovision an App Service plan to protect one hot instance. If disabling affinity requires Redis, database session storage, or code changes, those services and engineering time must be included in the decision. The cheapest reliable pattern is usually stateless application code with shared state where needed and even traffic distribution across workers. Cost reviews should compare extra worker capacity, session-store cost, incident labor, and the value of better scale efficiency. Cost owners should tie the setting to retention, scale, support effort, and realistic recovery expectations. Performance: Performance can improve or degrade depending on the application design. Sticky sessions may reduce session lookup complexity for legacy apps, but they can also create hot workers, uneven CPU, memory pressure, and inconsistent response times. Disabling ARR affinity usually helps stateless apps distribute traffic evenly across scaled-out instances, especially behind Front Door or Application Gateway. Performance testing should include multiple users, browser cookie behavior, scale-out events, worker restarts, and session-dependent workflows. Watch instance-level metrics, not just average app latency, because a sticky-session problem can hide behind healthy aggregate numbers. Teams should validate latency, throughput, saturation, cache behavior, and user impact before treating the setting as harmless.

Security: Security for ARR affinity focuses on cookie behavior, session design, and front-door topology. The affinity cookie is a routing aid, not an authentication control, and the application must not treat worker affinity as proof of identity or authorization. Host-name mismatches, proxy layers, and custom domains can affect cookie scope and browser behavior. If the app stores sensitive session data on a worker, the larger security issue is local state design, not the cookie itself. Prefer external session stores with encryption, managed identity, private networking, and explicit expiration. Review whether screenshots, logs, or headers expose cookies during troubleshooting. Access reviews, logging, and exception handling keep the control accountable beyond the initial configuration and rollout.
Cost: Cost impact for ARR affinity is indirect but real. If sticky sessions concentrate traffic on fewer workers, teams may scale out more than necessary or overprovision an App Service plan to protect one hot instance. If disabling affinity requires Redis, database session storage, or code changes, those services and engineering time must be included in the decision. The cheapest reliable pattern is usually stateless application code with shared state where needed and even traffic distribution across workers. Cost reviews should compare extra worker capacity, session-store cost, incident labor, and the value of better scale efficiency. Cost owners should tie the setting to retention, scale, support effort, and realistic recovery expectations.
Reliability: Reliability depends on whether the application can survive worker movement. With ARR affinity enabled, users may remain tied to one worker until that worker restarts, fails, drains, or loses cookie continuity. This can protect fragile stateful sessions, but it can also concentrate load and make a single unhealthy instance affect the same users repeatedly. With affinity disabled, traffic spreads more evenly and failover is cleaner, but session state must live outside the worker. Reliable App Service designs test both scale-out and instance recycle behavior, then document the chosen setting and the evidence that user sessions still work. Runbooks should capture expected behavior, safe fallback choices, owner escalation paths, and validation after change.
Performance: Performance can improve or degrade depending on the application design. Sticky sessions may reduce session lookup complexity for legacy apps, but they can also create hot workers, uneven CPU, memory pressure, and inconsistent response times. Disabling ARR affinity usually helps stateless apps distribute traffic evenly across scaled-out instances, especially behind Front Door or Application Gateway. Performance testing should include multiple users, browser cookie behavior, scale-out events, worker restarts, and session-dependent workflows. Watch instance-level metrics, not just average app latency, because a sticky-session problem can hide behind healthy aggregate numbers. Teams should validate latency, throughput, saturation, cache behavior, and user impact before treating the setting as harmless.
Operations: Operationally, ARR affinity should be visible in App Service configuration reviews, scaling runbooks, and incident diagnostics. Operators should know whether the app is stateful, where session state lives, and how many workers are serving traffic. CLI checks can confirm clientAffinityEnabled before and after a deployment or slot swap. During uneven load incidents, inspect instance-level metrics, cookies, Front Door or Application Gateway settings, and application session storage. Changing the setting can restart or affect traffic behavior, so treat it as a controlled change with rollback notes, user-impact expectations, and post-change validation. Clear ownership, repeatable checks, dated notes, and escalation paths prevent the signal from becoming tribal knowledge.

Common mistakes

Assuming ARR affinity is required for every App Service app instead of checking where session state lives.
Disabling sticky sessions on a legacy stateful app before moving local session data to a shared store.
Looking only at average latency while one sticky worker is overloaded and other workers look healthy.
Forgetting that Front Door, Application Gateway, custom domains, and host-name preservation can affect cookies.