AWS : Storing Session State

AWS SimpleDB, Memcache and DynamoDB can all be used.  DynamoDB is a good option as there is already a session provider for DynamoDB :

http://aws.typepad.com/aws/2012/09/managing-aspnet-session-state-with-dynamodb.html

For SQL Server, you can also look at session management in SQL server for persistence  and use built in .net session provider modules.

You can also manage session state using AWS RDS for SQL Server, MySQL or Oracle.

Running web application on AWS

In most cases, you will not just be running just an Oracle database on AWS.  You will be running a web based application.  For Oracle focused developers and engineers, running web applications on AWS is not an area of expertise. Here are the best documents, documentation, and diagrams to review for developing web based applications on AWS:

http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_web_01.pdf

http://media.amazonwebservices.com/AWS_Web_Hosting_Best_Practices.pdf

http://docs.aws.amazon.com/gettingstarted/latest/wah-linux/web-app-hosting-intro.html

Support for session state and database failover when application server goes down are a couple of details that most Oracle folks ask about.  Information can be found here:

Session state: Good blog post here: http://harish11g.blogspot.com/2012/10/web-session-synchronization-aws-ec2.html . The last option is DynamoDB which is the method used most often.

Database failover:

1. Using RDS this is automatic: When automatic failover occurs, your application can remain unaware of what's happening behind the scenes. The CNAME record for your DB instance will be altered to point to the newly promoted standby. Your client library must be able to close and reopen the connection in the event of a failover.
2. Using Oracle on EC2 : You would use Elastic Ips and use this pattern : http://aws.amazon.com/articles/2127188135977316 . You cloud use ENIs so private Ips could be used http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#create-a-low-budget-high-availability-solution

Oracle WebLogic with AWS Auto Scaling

The question of using Oracle WebLogic with AWS Auto Scaling and propagation of session state is often asked.  Before getting into the details, let's look at the two ways of handling session state at the server layer (using cookies in the browser can be used as well):
1. Session stickiness : session data issue is to send all requests in a user session consistently to the same backend server. 
2. Session in database : Another solution is to keep the per-session data in a database.  Of course, AWS ElastiCache, SimpleDB or DynamoDB, or RDS.

If the session is stored in a database, nothing needs to be done when using Auto Scaling with WebLogic; for obvious reasons.

When sticky sessions is used, nothing needs to be done, but the reason is not so obvious so let's discuss it.

When a request comes into a WebLogic cluster via a load balancer (AWS ELB for example) or through Apache (mod_proxy_balancer plug in) the first time,  WebLogic creates an HTTP session on the primary node and also puts session state on a backup node. (You can provide guidance/control where to put the failure/backup).  If the server goes down that contains the primary WebLogic node, the new primary node will know where the backup session is stored and the session state will automatically get replicated to the new node.  So when AWS Auto Scaling is used there is nothing that needs to be done from an AWS perspective.