ASP.NET Session State Sharing across Multiple Azure Regions

Many high-traffic ASP.NET applications in Microsoft Azure are deployed over multiple dedicated regions to handle geographically separated traffic. In these situations, the load balancer sends traffic to the region closest to the user for faster response times. In this scenario, you may run into a situation where you have to redirect some of your traffic to and from one Microsoft Azure region to another. This situation may occur because you have too much traffic in one region and another underutilized region. Another reason may be a region down for maintenance. When you redirect traffic, users normally lose their ASP.NET sessions because Session State is unavailable in the other region, interrupting users. In Microsoft Azure, the only way you can avoid such interruptions is if you keep a common ASP.NET Session State storage across multiple Microsoft Azure regions. However, this option has severe performance issues because there is likely to be a large percentage of ASP.NET sessions being accessed across the WAN.

Key Takeaways

Regional Session Persistence: NCache ensures ASP.NET sessions remain active and accessible even when user traffic is redirected across geographically separate Microsoft Azure regions.
Intelligent Migration via sid-prefix: By assigning a unique sid-prefix to each regional cache, NCache identifies the origin of a session and automatically moves it to the new local region upon the first request.
Prevention of Session Loss: The multi-site Session State Provider (SSP) eliminates the risk of session abandonment during regional failovers, ensuring a seamless user experience without data loss.
Performance-Optimized WAN Sharing: NCache minimizes latency by only migrating specific sessions when necessary, rather than utilizing heavy, constant full-mesh replication across the Azure WAN.

NCache in Azure

NCache is an extremely fast and scalable distributed cache for .NET applications in Microsoft Azure. It provides intelligent multi-region ASP.NET Session State support for your ASP.NET applications deployed in multiple Microsoft Azure regions.

Architectural diagram showing NCache distributed cache cluster in Azure Virtual Network providing multi-region session sharing for .NET and Java remote clients with linear scalability.

Figure: NCache Multi-Region Azure Session Caching Architecture

The benefits of this configuration are as follows:

Use the cache from any Microsoft Azure/AWS application and website.
Share the cache across multiple Microsoft Azure applications and even to other platforms like AWS, Google Compute Engine, Rackspace, your private cloud, and more.
Share the cache across multiple locations for the same or different applications.

How to Move ASP.NET Sessions Across Microsoft Azure Regions Without Data Loss

NCache in Azure intelligently detects and then automatically moves your ASP.NET sessions from one Microsoft Azure region to another when a user request is redirected. All subsequent requests are served from this new region. This is possible as ASP.NET application seamlessly shares sessions across Microsoft Azure regions without impacting performance or causing data loss.

NCache allows you to achieve multi-region ASP.NET Session State capability by defining primary and secondary caches in each location. Additionally, you must also specify the “sid-prefix” attribute. This helps the NCache for Azure SSP module identify which sessions belong to which region. It also helps establish whether to redirect various ASP.NET sessions to another region.

The following table highlights the architectural advantages of using NCache’s distributed in-memory provider over traditional relational storage for managing sessions in a multi-region Azure environment.

Technical Metric	Standard Azure SQL Session Provider	NCache Multi-Site Session Provider
Data Access Latency	High: Relational overhead with disk-based BLOB storage for session objects.	Sub-millisecond: Native In-memory Key-Value store with binary serialization.
Scalability Model	Vertical: Limited by single-instance SQL DTUs or vCores as performance degrades under concurrency	Horizontal (Linear): Scale out by adding nodes and partitioning traffic across a distributed cluster
WAN Optimization	Relational Replication: High bandwidth cost for full-database geo-replication.	Intelligent Migration: Uses sid-prefix to move only requested sessions across regions.
Consistency (RPO)	Delayed: Subject to SQL geo-replication lag; risk of “Stale Session” on failover.	High: Multi-site replication ensures session availability in secondary regions in real-time.
App Configuration	Manual: Requires SQL schema scripts and complex connection string management.	Native Plugin: Standard ASP.NET Custom mode configuration with zero code changes.
Data Handling	BLOB-based: Treats sessions as heavy binary blobs, causing database “bloat.”	Object-based: Optimized for small, high-frequency session objects.

To do so you must first create a ASP.NET Web Project and install the AspNet.SessionState.NCache NuGet package by executing the following command in the Package Manager Console:

1	Install-Package AspNet.SessionState.NCache

After the NuGet is successfully installed, You can verify it’s installation by checking if an assembly and provider similar to the following are available in your web.config:

…

<sessionState cookieless="false"

regenerateExpiredSessionId="true"

mode="Custom"

customProvider="NCacheSessionProvider"

timeout="20">

<add name="NCacheSessionProvider"

type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider"

exceptionsEnabled="true"

enableSessionLocking="true"

emptySessionWhenLocked="false"

sessionLockingRetry="-1"

sessionAppId="NCacheTest"

useInProc="false"

enableLogs="false"

cacheName="democache"

writeExceptionsToEventLog="false"

AsyncSession="false"

useJsonSerialization="false" />

</providers>

</sessionState>

Next, you will need to add a <configSections> tag (similar to the following snippet) to the web.config. This tag must be the first child of the <configuration> tag:

</configSections>

- You must add the following custom ncache section immediately after, to identify your session caches for the various Microsoft Azure Regions:

</sessionLocation>

</ncache>

Automating Azure Region Redirection via NCache Session ID Prefixes

All ASP.NET sessions originating from a Microsoft Azure region are originally stored in the primary cache in that location. However, when a request from another region is redirected to the current one then the multi-region SSP module detects whether the ASP.NET Session State resides in one of the other Microsoft Azure regions using the “sid-prefix” (ASP.NET Session ID). After which it automatically contacts the corresponding secondary cache in a remote region and moves it to the primary cache in the current region. All subsequent requests are then served from this new location.

For example, you have defined London_Cache to be your primary cache. On the other hand, NewYork_Cache and Tokyo_Cache are secondary caches for the London site. You also specify “LDC”, “NYC”, and “TKC” as sid-prefix attached to each session-id corresponding to London_Cache, NewYork_Cache, and Tokyo_Cache sessions, respectively. Now, all the ASP.NET sessions from the London region have “LDC” attached as a prefix to their ASP.NET Session IDs and are stored and served from London_Cache. This is a primary cache for the London region.
If a request is redirected from another region such as New York or Tokyo to the London region then this Session State is immediately identified based on sid-prefix. It is then it is transferred from NewYork_Cache or Tokyo_Cache to London_Cache. All subsequent requests are served from London_Cache locally once ASP.NET Session State is moved to the London region.

Conclusion

NCache for Azure supports multi-region ASP.NET Session State. It also allows you to have your applications in two or more active Microsoft Azure regions. It lets you redirect traffic between multiple locations to handle traffic overflows and site maintenance.

Frequently Asked Questions (FAQ)

Q: How does NCache handle session affinity during an Azure regional failover?
A: When Azure Traffic Manager redirects a user to a new region NCache reads the sid-prefix of the incoming session ID. If the prefix belongs to a remote region NCache automatically fetches that session from the source cache and moves it to the new local cache to ensure continuity.

Q: Does sharing sessions across Azure regions require code changes?
A: No. This solution is implemented through configuration. You only need to install the NCache Session State Provider NuGet package and update your config files to define the regional cache clusters and their respective prefixes.

Q: What happens to the original session data after it is moved to a new region?
A: Once a session is successfully migrated to the new local region it is managed locally. All subsequent updates to that session occur in the new region’s cache which prevents unnecessary WAN traffic for future requests during that user’s active period.

Q: How does this approach differ from standard session replication?
A: Unlike full-mesh replication where every session is copied to every region NCache uses on-demand migration. This significantly reduces WAN bandwidth consumption because session data only travels across the network if a user is actually redirected to a different geographic location.