ARR affinity

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.