Managing ASP.Net Session State With DynamoDB

Today we have guest post from Norm Johanson, a Software Developer on our Developer Resources team. Norm has put together a post to show you how to track the session state of an ASP.NET application uusing Amazon DynamoDB.

— Jeff;

When developing a new ASP.NET application, a common approach is to store session data in memory. Unfortunately, this approach doesn’t scale very well; once your application grows beyond a single web server, the session state must be shared between servers. The common solution to sharing session state over multiple web servers is to set up a dedicated session state server with SQL Server. Of course, this approach has certain drawbacks: you must administer another machine, the session state server is a single point of failure, and the session state server can be a performance bottleneck.

Amazon DynamoDB, a new NoSQL database store from Amazon Web Services (AWS), is designed to address these drawbacks. The only administrative decision to make is how much you want to scale.

Configuring Amazon DynamoDB
In version 1.5.0.0 of the AWS SDK for .NET, we added the AWS.Extensions.dll which contains an ASP.NET session state provider. We also added the AmazonDynamoDBSessionProviderSample sample which demonstrates using Amazon DynamoDB as a session state provider.

To configure an ASP.NET application to use Amazon DynamoDB as the session state server, you need to add references to AWSSDK.dll and AWS.Extensions.dll which are both part of the AWS SDK for .NET installer and available through NuGet. Next, edit your application’s web.config filein the system.web element, replace or add the sessionState node with the following XML fragment:

You need to provide access and secret keys for a valid AWS account where indicated. This is the account that will be used to communicate with Amazon DynamoDB to store and retrieve the session state. If you are using the AWS SDK for .NET and are setting the access and secret keys in the appSettings section of your application’s web.config file, you can leave the access and secret keys blank in the sessionState element; the SDK will then discover the keys at runtime.

When your application starts, it looks for a DynamoDB table called ASP.NET_SessionState. We recommend that you create this table before first running your application, with a string hash key, no range key and the desired values for ReadCapacityUnits and WriteCapacityUnits. If you are eligible for the AWS Free Usage Tier, you can consume up to 100 MB of DynamoDB storage, 5 units of write capacity, and 10 units of read capacity at no charge for one year. See the DynamoDB pricing page for additional information. If you don’t create the table before starting the application it can be created automatically during initial startup. See the web.config options below for how to configure the Amazon DynamoDB table.

That is all there is to it. Once the application is configured and the table is created, sessions can be used like any other session provider.

Web.config Options
Below are the configuration attributes that can be used in the XML provider definition in your web.config file:

• AWSAccessKey – access key to use. This can be set either in the provider definition or in the appSettings section.
• AWSSecretKey – secret key to use. This can be set either in the provider definition or in the appSettings section.
• Region – required string attribute. The region to use DynamoDB in.
• Application – optional string attribute. Application is used to partition the session data in the table so it can be used for more than one application.
• Table – optional string attribute. The name of the table used to store session data. The default is ASP.NET_SessionState.
• ReadCapacityUnits – optional int attribute. The read capacity units if the table is not yet created. The default is 10.
• WriteCapacityUnits – optional int attribute. The write capacity units if the table is not yet created. The default is 5.
• CreateIfNotExist – optional boolean attribute. CreateIfNotExist controls whether the table will be auto created if it doesn’t exist. The default is true. If this flag is set to false and the table doesn’t exist, an exception will be thrown.

Security Considerations
As a security best practice, we recommend that you run your applications with the credentials of an AWS Identity and Access Management (IAM) user. You can use either the AWS Console or the AWS Toolkit for Visual Studio to create IAM users and define access policies.

The session state provider needs to be able to call the DeleteItem, DescribeTable, GetItem, PutItem and UpdateItem operations for the table storing the session data. The sample policy below can be used to restrict the IAM user to just the operations needed by the provider:

— Norm Johanson